敏捷开发早期估算(开放分享)
7
序:
By 专题制作人:李忠利
“响应变化胜过遵循计划”,
这就让我们不禁想问:
有没有一种方法,在签署合同或立项前,
有没有一种方法,不仅能在早期做估算,还能把估算结果直接演进为敏捷开发中的史诗故事和用户故事?
有没有一种方法,不仅能让开发者意识到代码的不断增长,也能让客户和领导同步地理解并认可需求的蔓延?
有没有一种方法,能在项目结束时,简单数数史诗故事和用户故事,
……
这注定是一个极富争议的话题,从开始到最后,
在Scrum Gatheing北京的Open Space中, “火星人”创始人兼首席架构师陈勇,
话题介绍 :
众所周知,敏捷开发中的估算过程主要集中在迭代计划会中,由开发人员自主估算本次迭代的工作内容。可是,如果开发人员的估算推测整个周期需要一年,而整个项目已经立项要在半年内完成,该如何处理?
本讲座所涉及的早期估算方法引入了功能点分析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种管理方法或实践。