关于“敏捷计划与估计的方法”的讨论

作者 滕振宇 发布于 2009年10月15日

领域

过程 & 实践

主题

敏捷实施 ,

敏捷技术 ,

敏捷

标签

用户故事 ,

估算 ,

生产力 ,

故事测试

在做Scrum的迭代计划时，不同的团队有很多不同的做法。在敏捷中国讨论组中，对敏捷计划与估计的方法进行了激烈的讨论（Scrum sprint plan中规模估算的做法调查，关于story point的单位）。

克强罗列出有四种敏捷计划估计的方法：

1. 假设1个usre story point需1个理想人天，Velocity为理想人天/实际人天数
2. 选择最小工作单元为1个User story point，velocity为user story point数量/理想人天数
3. 选择最小的工作单元为1个User story point，velocity为user story point数量/实际人天数
4. 使用use case point作为规模，velocity为use case point数量/实际天数

首先讨论的焦点集中于对用于“故事点”的理解上。大家对“‘故事点’是没有单位的”形成共识。Xu Yi首先指出：

user story用于评估user story的相对大小（bigness），它并无一个可用于度量的单位值。一定程度上可以说story point最终会达到具有一定的单位效用。当某产品开发大团队（包括若干scrum团队）保持团队稳定，以及开发足够长时间后达到velocity稳定时，可以­借由建立一定程度上story point向“成本”、“时间”等度量的映射，使其成为“虚单位”。

Daniel Teng也在博客中分析了在敏捷迭代计划中为什么使用“故事点”，以及为什么“故事点”是没有单位的（巧妙使用“故事点”进行敏捷估计）。使用“故事点”的好处包括：

1. 使用相对估计
2. 关注规模
3. 忽略个人能力的不同
4. 可以相加。

至于“故事点”的原因在于：

1. “故事点”是一个相对量
2. 不同团队的单位“故事点”是不同的，也很难统一。

接下来讨论集中于具体使用“理想人天”和“故事点”做迭代计划的具体方法上。姜志辉的团队的做法是：

我们采用的是bob的dx迭代+Joel的任务分配法。 应该说，原则来自于bob，方法来自于joel。

Andy的做法是：

1. 记录前面几个sprint的实际的可以利用的资源（以人天为单位） 和 实现功能的IMD（Ideal Man Day），计算 资源利用率：实际完成功能的IMD / 实际可利用的资源。 源利用率可以取多个sprint的平均值，也可取上个sprint的单点值。
2. 即将开始的Sprint内可以利用的资源是可以首先计算的，乘以资源利用率 ，得到 本sprint的IMD
3. 按功能的优先级，本次Sprint要达到的目标，选择优先级最高的功能，分解为实现任务，并评估如何实现，不断评审优先级最高的一些功能，直至Team不能承诺成为止，也即是所选功能的累积IMD达到了 本sprint的IMD。

而Xu Yi团队的做法是：

sprint planning第一部分，团队选择有哪些user story是可以做掉的，过去的平均velocity只是作为参考而已。

sprint planning第二部分，团队将选取的user story详细分割为task，以小时为单位进行估计，而且和自己的capacity不断地进行对比，当capacity耗尽时停止。

接下来话题一转，大家集中到怎样计算每个迭代的速率(Velocity)上。Xu Yi团队的做法很简单直接：

根据过去的sprint来统计，平均下来每个sprint完成的story point就是velocity。比如前5个sprint分别完成9、12、5、16、10，那么team的velocity就是（9+12+5+16+10）­/5=10.4。

很多人有不同的观点，Vincent Lee认为：

而我说的算法是“用完成的任务点数除以实际投入的人日数”，假设前5个sprint分别完成9、12、5、16、10个story point，实际投入的人日数分别为20、20、25、25、20，（9+12+5+16+10）/（20+20+25+25+20）=0.47，利用这个数值­以及下一个sprint的可用资源（比如是25），就可以算出下一个sprint可以完成的工作量：0.47*25=11.75进一步的，由于可以乐观的认为团队熟练程度在提高，可以调高速度为0.5，于是预计可以完成0.5*25=12.5的工作量。

看来不同团队对敏捷计划与估计的理解不尽相同，做法也各异。您的团队在迭代计划使用哪一种方法呢？

滕振宇 具有多年敏捷实践经验以及丰富的带队经验，正致力于帮助国内团队导入敏捷方法以及思维。

1. 返回顶部

   发表人 cao Alex

   关于“理想人天” 和“User story point”在<<Agile Estimating and Planning>>这本书上都做了非常好的说明和例子。 个人认为首先要清楚这两种概念的含义。后面的事情，就是根据team的自身情况，来选择适合team自身的方法了。 只要符合Scrum的原则，很多做法是没有对错的。只有是不是适合现在的sprint. 多实践, 就能找到更适合你自己团队的方式。</agile>

   回复

2. 返回顶部

   估计大法

   发表人 Lee Vincent

   Xu Yi团队的做法是：
   sprint planning第一部分，团队选择有哪些user story是可以做掉的，过去的平均velocity只是作为参考而已。
   sprint planning第二部分，团队将选取的user story详细分割为task，以小时为单位进行估计，而且和自己的capacity不断地进行对比，当capacity耗尽时停止。
   
   这个做法的最大问题是：
   没有利用之前的velocity统计数据来帮助减少迭代计划的估算误差，
   每一轮sprint planning第二部分进行的这个估计就真的完全是估计出来的，再加上IMD也得估计，得出的结果估计就十万八千里了。

   回复

3. 返回顶部

   唉。。。

   发表人 朱 敏

   瀑布也好，CMM也好，敏捷也好，SCRUM也好，基本的分析、估算、计划、检查都是得做的。换了个马甲，大家就不认识他们了。

   回复

• 更早的 >