BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

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

| 作者 滕振宇 关注 2 他的粉丝 发布于 2009年10月16日. 估计阅读时间: 5 分钟 | Google、Facebook、Pinterest、阿里、腾讯 等顶尖技术团队的上百个可供参考的架构实例!

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

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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

by cao Alex

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

估计大法 by Lee Vincent

Xu Yi团队的做法是:
sprint planning第一部分,团队选择有哪些user story是可以做掉的,过去的平均velocity只是作为参考而已。
sprint planning第二部分,团队将选取的user story详细分割为task,以小时为单位进行估计,而且和自己的capacity不断地进行对比,当capacity耗尽时停止。

这个做法的最大问题是:
没有利用之前的velocity统计数据来帮助减少迭代计划的估算误差,
每一轮sprint planning第二部分进行的这个估计就真的完全是估计出来的,再加上IMD也得估计,得出的结果估计就十万八千里了。

唉。。。 by 朱 敏

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

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

3 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT