讲师： 陈 勇| 06月30日 13:00~06月30日 14:00 北京紫光国际大厦-主会场 所属专题： 开放空间会议

序：

By 专题制作人：李忠利

“响应变化胜过遵循计划”，<wbr>所以敏捷开发中的估算过程主要指在每个迭代计划会中，<wbr>由开发人员自主估算本次迭代的工作内容。可是，<wbr>随着一个个迭代结束，<wbr>开发人员可能才逐渐感觉到整个项目需要一年，而实际上，<span style="margin: 0px; padding: 0px; border: 0px; font-family: arial, sans-serif;font-size:undefined; font-style: inherit; font-variant: inherit; line-height: inherit; vertical-align: baseline;">高层领导<wbr>早就签订合同或立项要求整个项目在半年内完成</wbr></span><span style="margin: 0px; padding: 0px; border: 0px; font-family: arial, sans-serif;font-size:undefined; font-style: inherit; font-variant: inherit; line-height: inherit; vertical-align: baseline;">……</span><span style="margin: 0px; padding: 0px; border: 0px; font-family: arial, sans-serif;font-size:undefined; font-style: inherit; font-variant: inherit; line-height: inherit; vertical-align: baseline;">而这个项目如果<wbr>真的超期了一倍，那么到底是高层领导的决策失误，</wbr></span><span style="margin: 0px; padding: 0px; border: 0px; font-family: arial, sans-serif;font-size:undefined; font-style: inherit; font-variant: inherit; line-height: inherit; vertical-align: baseline;">还是团队的生产<wbr>率只有别人的一半？</wbr></span></wbr></wbr></wbr></wbr>

这就让我们不禁想问：

有没有一种方法，在签署合同或立项前，<wbr>仅仅凭借几页Word和有限交互，就能把十几人年的项目推算到±<wbr>20%的精度内？</wbr></wbr>

有没有一种方法，不仅能在早期做估算，还能把估算结果直接演进为敏捷开发中的史诗故事和用户故事？

有没有一种方法，不仅能让开发者意识到代码的不断增长，也能让客户和领导同步地理解并认可需求的蔓延？

有没有一种方法，能在项目结束时，简单数数史诗故事和用户故事，<wbr>就能将项目的完成情况与此团队的历史做纵向比较，<wbr>甚至还能与其他团队、乃至业界的数据做横向比较，<wbr>并让客户和老板信服？</wbr></wbr></wbr>

……

这注定是一个极富争议的话题，从开始到最后，<wbr>专题制作人和评审组的意见一直大相径庭。我们见过有争议的话题，<wbr>但从未发生过分歧如此之大的事情！</wbr></wbr>

在Scrum Gatheing北京的Open Space中， “火星人”创始人兼首席架构师陈勇，<wbr>将向大家展示如何使用这种方法的经验总结。</wbr>

话题介绍 ：

众所周知，敏捷开发中的估算过程主要集中在迭代计划会中，由开发人员自主估算本次迭代的工作内容。可是，如果开发人员的估算推测整个周期需要一年，而整个项目已经立项要在半年内完成，该如何处理？

本讲座所涉及的早期估算方法引入了功能点分析FPA的概念，可以让产品经理在项目之初勾勒功能轮廓的时候，基于非常少的信息和文字即可大致推算出所需的工时。此功能轮廓的描述内容还能在进一步的开发过程中，直接演进为有相对固定颗粒度的史诗故事和用户故事。

此早期估算方法的主要来自IIOM（国际外包管理协会）“火星人敏捷开发平台”本身的研发过程的经验总结。

目标受众：产品经理/PO，项目经理

文中涉及的讨论在此链接中有详尽描述（应PMBar邀请所作的三次在线研讨汇总）http://blog.csdn.net/cheny_com/article/details/7692917

整体脉络如下，点击小图看大图：

1. 开发人员只需要在迭代前选择少数故事进行少量精细估算，而产品经理需要面对海量故事且可能在甚早期（立项，报价）进行粗略估算，怎么办？

2. 用户故事（从下面数第三个蓝条）跨度从1D到2M不等，无法简单地通过计数来进行早期估算；但功能点的业务操作（EI/EO/EQ即常说的增删改查）和业务数据（ILF/EIF即常说的信息点、实体）则存在非常一致的绝对尺寸。

3. 通过计数业务数据ILF可进行甚早期估算（这是NESMA的第二级简化方法）

4. 业务数据判断规则和修正系数（用于不同难度的应用），此规则比IFPUG和NESMA的规则略通俗化，但结果为1：1。

5. 业务数据（ILF/EIF）演进为史诗故事也叫数据故事，业务操作（EI/EO/EQ）演化为传统的用户故事（作为一个……可以……以便……）

6. 增强/重构/缺陷/债务是更小颗粒度上的故事，不属于客户理解的“产品的业务功能”

7. 通过将增强/重构/缺陷/债务等子故事关联到数据故事（史诗故事）或操作故事（即“作为一个……可以……以便……”）来进行管理

8. 这一方法能使用同一套数据同时打通下图中的7种管理方法或实践。

具有丰富的工程技术与项目管理实践经验，从其程序员、项目经理、CMMI/FPA功能点估算/敏捷咨询师、事业部总监、副总经理等各种技术与管理岗位获得的一手经验，令其可以站在企业管理者的角度，以更广的视角来理解敏捷开发，并能配合和推动非研发部门协作推广敏捷。