在做 Scrum 的迭代计划时,不同的团队有很多不同的做法。在敏捷中国讨论组中,对敏捷计划与估计的方法进行了激烈的讨论( Scrum sprint plan 中规模估算的做法调查,关于 story point 的单位)。
克强罗列出有四种敏捷计划估计的方法:
- 假设 1 个 usre story point 需 1 个理想人天,Velocity 为理想人天 / 实际人天数
- 选择最小工作单元为 1 个 User story point,velocity 为 user story point 数量 / 理想人天数
- 选择最小的工作单元为 1 个 User story point,velocity 为 user story point 数量 / 实际人天数
- 使用 use case point 作为规模,velocity 为 use case point 数量 / 实际天数
首先讨论的焦点集中于对用于“故事点”的理解上。大家对“‘故事点’是没有单位的”形成共识。Xu Yi 首先指出:
user story 用于评估 user story 的相对大小(bigness),它并无一个可用于度量的单位值。一定程度上可以说 story point 最终会达到具有一定的单位效用。当某产品开发大团队(包括若干 scrum 团队)保持团队稳定,以及开发足够长时间后达到 velocity 稳定时,可以借由建立一定程度上 story point 向“成本”、“时间”等度量的映射,使其成为“虚单位”。
Daniel Teng 也在博客中分析了在敏捷迭代计划中为什么使用“故事点”,以及为什么“故事点”是没有单位的(巧妙使用“故事点”进行敏捷估计)。使用“故事点”的好处包括:
- 使用相对估计
- 关注规模
- 忽略个人能力的不同
- 可以相加。
至于“故事点”的原因在于:
- “故事点”是一个相对量
- 不同团队的单位“故事点”是不同的,也很难统一。
接下来讨论集中于具体使用“理想人天”和“故事点”做迭代计划的具体方法上。姜志辉的团队的做法是:
我们采用的是 bob 的 dx 迭代 +Joel 的任务分配法。 应该说,原则来自于 bob,方法来自于 joel。
Andy 的做法是:
- 记录前面几个 sprint 的实际的可以利用的资源(以人天为单位) 和 实现功能的 IMD(Ideal Man Day),计算 资源利用率:实际完成功能的 IMD / 实际可利用的资源。 源利用率可以取多个 sprint 的平均值,也可取上个 sprint 的单点值。
- 即将开始的 Sprint 内可以利用的资源是可以首先计算的,乘以资源利用率 ,得到 本 sprint 的 IMD
- 按功能的优先级,本次 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 的工作量。
看来不同团队对敏捷计划与估计的理解不尽相同,做法也各异。您的团队在迭代计划使用哪一种方法呢?
评论