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

在做 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 的工作量。

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