Sprint进度的测量

我经常发现使用Scrum的团队对如何能够最好地跟踪进度有疑惑。一般来说,有几个方法可以选择。有些团队把每个用户故事拆分成以天为单位的任务。但是...

scrumcn1305615765
我经常发现使用Scrum的团队对如何能够最好地跟踪进度有疑惑。一般来说,有几个方法可以选择。有些团队把每个用户故事拆分成刚好一天能够完成的任务。但是我见到不少团队在尝试过这么做以后,发现过程中遇到很多麻烦,因为有些任务需要不到一天,而有很多需要两天甚至以上,所以很难将所有任务都准确地拆分成正好一天能够完成。

有的团队把用户故事拆分成任务以后,花费大量的时间来计算每个任务所占的故事点数。而这个会在计划会议上完成,因此整个会议要持续4到6个小时。在下文中,我们把这种方法叫做“故事点数分配法”。

第三种方法是我最喜欢的一种,我觉得它是最有用的,因为这种方法不需要花费很多时间,这和Scrum中帮助团队避免花费太多时间在获得准确性的其他方面是一致的,例如,在Scrum中使用斐波那契数列或者2次方数列来进行用户故事的估计。

只要有机会,我都会推荐下面这种方法。这种方法的基本技巧就在于,持续地更新每个用户故事的估计所需剩余时间(ETC)。一般来说你可以在每日站会之后更新数据,如果你已经能够掌握时间盒的运用的话,你甚至可以在每日站会当中来更新。总而言之,这种方法的最基本思想就是让团队每天估计并且更新完成某个用户故事所需要的故事点数。

让我们来看看这个例子。假设我们的Sprint长度是两个星期。在计划会议之后,团队承诺完成A到G一共7个用户故事,放在下面的表格里面(图1)。
scrumcn1305615787
图1

 scrumcn1305615845
图2

在完成了星期一下午的工作以后,团队在星期二的早上聚集到一起举行每日站会,然后估计所有在进行中的用户故事所需要的剩余时间。从图2中可以看出,用户故事A和B正在进行中,于是团队根据当前的进展重新估计了这两个用户故事剩余的故事点数。做出估计的依据应该是整个用户故事所剩余的工作量,而不是被拆分的任务。下面是团队重新估计后得出的燃尽图(图3)。
scrumcn1305615878
图3

团队应该每天重新估计每个进行中的用户故事的剩余工作量。图4展示了从开始到完成的过程,图5则是Sprint结束时的燃尽图。

scrumcn1305615896
图4

 scrumcn1305615917
图5

我经常听到其中一个的争论是“但是ETC并不是百分之百准确的”。这是肯定的,没有任何的估计是百分之百准确的。但是,每天重新估计进行中的用户故事的剩余工作量比把故事点从Sprint开始分配到各个任务中,然后每天把剩余的故事点数加起来更加能够让你了解实际剩余的工作量。这是为什么呢?

我们可以用锥型不确定性理论来解释。在项目管理中,锥型不确定性描述了项目过程中不确定性数量了变化过程。在项目刚开始的时候,相对地我们对项目的了解较少,因此估计也会包含比较大的不确定性。随着我们完成了越来越多的开发工作和研究工作,我们对项目的了解也越来越多,不确定因素也会越来越少。(http://en.wikipedia.org/wiki/Cone_of_Uncertainty)

scrumcn1305615947

正如你所想到的那样,锥型不确定性理论对传统的项目管理模型有很强的依赖。尽管如此,它的原理同时也适用于敏捷的项目管理。

还记得“故事点数分配法”(把每个用户故事的点数分配的各个任务当中)吗?我们可以说我们已经有一个不错的误差了,姑且说是+/-25%(1.25/0.75)吧。当然这种方法不会让我们得到百分之百的准确度。当项目进行的时候,为了能够更好地计算剩余的工作量,团队会标记已经完成的任务,然后把在进行中的任务所占的故事点数相加。这么做的问题是,尽管我们现在能够掌握比我们第一次估计的时候更多的信息,但是由于我们没有对用户故事进行重新估计,于是我们的准确度就会卡在+/-25%这个槛上。

如果我们不在一开始就把故事点数分配到各个任务上会发生什么事呢?自然我们就不会把所有剩余的任务所占的故事点数加起来来获得剩余的工作量。我们只能够重新估计每个进行中的故事的剩余工作量。这样我们就可以保证我们重新估计的时候不会还带着+/-25%的误差,而且可以越来越接近锥型的右侧,也就是误差为0的地方,因为我们每次重新估计的时候就会比上一次更加了解项目掌握的信息也会更多。这样做会比单纯维护在计划会议上作出的估计要准确得多。

我推荐各个团队在下一个Sprint中尝试这种方法。如果使用得当的话,你将会很快地留意到持续估计剩余工作量的好处。

原文地址:http://www.scrumalliance.org/articles/356-measuring-sprint-progress

 

使用估算扑克做工作量的估算

微信扫一扫,立刻免费使用微信版估算扑克

Scrum中文网微信号:Scrum_CN

scrumcnweixin

使用估算扑克来做工作量估算是最有效,也是非常有趣的一种估算方式。估算扑克由一组类似斐波纳契数列的数字组成,这些数字包括:0,0.5,1,2,3,5,8,20,40,?,∞, 每幅扑克有四组这样的数字,可供4个人使用。

估算扑克的使用方法:

1.每个团队成员拿到一组卡片,包括0,0.5,1,2,3,5,8,13,20,40,?,∞,共计12张。
2. 产品负责人或者一名团队成员扮演阅读者的角色,他负责阅读需要估算产品Backlog的条目,并且询问大家是否有疑问。
3. 团队讨论这个条目。
4. 当团队理解了这个条目之后,每个团队成员按照自己的想法给出估算结果,并且选择对应的扑克出牌,估算结果不能告诉其他人,出牌时数字朝下扣在桌面上。
5. 所有人都出牌之后,阅读者向大家确认是否都已经确定估算结果,确认后,数”1,2,3″,大家同时展示估算结果。
6.团队评估不同的估算结果.我们是否想法一致?我们是否存在分歧?有没有什么是我没有考虑到的?团队共同讨论估算的差异,最终达成一致。
7. 回到第二步,开始估算下一个条目。

 为什么要使用估算扑克来做估算

有人可能会问,在传统的做法中,我们一般是让一个专家或者项目经理来做估算,给出结果,然后团队照做就可以了,多个人都参与估算不是浪费时间吗?
使用估算扑克来做估算基于两个结论,
第一:团队的智慧要高于某一个人的智慧。
第二:真正参与工作的人做出的估计要高于其他人做出的估计。
估算扑克有效还有如下几个方面的原因:
1. 传统估算通常是一个人在思考,而使用估算扑克估算时,鼓励跨职能团队的多个团队成员参与估算,团队成员可以从不同的视角来思考和分析问题,估算的过程中考虑的更加全面、估算也更加准确。
2. 在估算的过程中,团队对估算的结果进行讨论和评判,在一个高度透明的环境下,估算的结果更加真实和客观。这样也避免了很多时候过于武断,或是拍脑袋做出的决定。
3. 估算的过程也是一个知识分享和学习的过程,对某一个条目不清楚的成员通过其他成员的阐述会增加对该条目涉及到的要点的认识。

如何获取估算扑克?

估算扑克由于需求量很小,所以目前市场上是买不到的。 您有以下几种方式可以获取:
1. 选择专业的扑克定制厂商定制,一般是5000到10000副起印。
2. 联系Scrum中文网购买,每幅扑克30元,联系方式: info@scrumcn.com.邮件标题注明购买估算扑克,邮件中请提供您的所在单位、邮寄地址、购买数量、联系人姓名及手机,以方便我们与您联系。
3. 获取电子可打印版本,自己裁剪,URL: http://www.scrumcn.com//down/html/index.php?29.html  。
4.扫描Scrum中文网微信(文章开头),立刻免费微信版估算扑克,T-shirt Size估算。

巧妙使用“故事点”进行敏捷估算

克强在“敏捷中国”讨论组中引发对敏捷的估算的讨论(“Scrum sprint plan中规模估算的做法调查”,“关于story point的单位”)。我想分享一下我自己对敏捷估算方法的理解以及对于“故事点”的认识。

在敏捷开发中,团队通过两种方法对迭代做计划。
  • 基于承诺”Commitment”。做法很简单:
    • Product Owner从Product Backlog中取下一个用户故事(按照优先级),对这个用户故事进行解释,
    • 团队对用户故事进行讨论,明确需要解决的问题,
    • 整个团队确定是否能够在下一个迭代周期中完成这个故事,
      • 如果团队没有信心完成该故事,计划会议结束,或者把这个用户故事进一步划分成更小的用户故事重复第一步。
      • 如果团队有信心完成该任务,重复第一步。
  • 基于速率”Velocity”
    • 确定Product Backlog中用户故事的规模(用“故事点”)
    • 确定团队迭代的开发速度(“昨天的天气”)
    • 从Product Backlog中取出相应量的用户故事。
基于速率的估算中,需要确定一个“故事点”,也就是确定一个速度的单位。而在敏捷计划与估算计中,这个“故事点”是没有单位的。为什么?首先来看一下传统的规模估算的方法(标准日、代码行数)的问题。
  • 绝对估算 vs. 相对估算
    传统的方式是通过计算出一个绝对值(有单位,比如多少人天,多少代码行)。然后,做出计划。很大的问题是,人天生不擅长做绝对估算,人们更擅长做相对估算,更容易在相对估算值上达成共识。举一个简单例子,估算从上海市人民广场到徐家汇的距离,如果使用公里或者米等绝对单位,多个估算者很难达成共识,往往陷入没有必要的讨论和争吵。而如果用相对距离,比如从人民广场到徐家汇的距离相当于两倍的从人民广场到火车站的距离,人们就很容易、很快达成共识。因此对一个需求点来说,关注于相对大小也更容易使整个团队在估算值上达成共识。
  • 关注规模(而不是将不同维度的概念混淆)
    比较合理的估算方法是,首先估算整个规模,然后有一定的历史数据,知道速度,从而可以做出计划,推算出时间。比如我们看书,一共三百页,一天看十页,很容易就算出是三十天。如果使用理想日(时间维度),其实就是把这个过程搞反了,从时间维度反过来推算规模。同时使用“故事点”可以综合考虑一些其他因素包括复杂度、不确定性等,基于故事点的规模估算是在综合考虑各种因素之后的综合估算。而用代码行数很难对复杂度、不确定性等作出估算
  • 忽略个人能力的不同
    不同人的理想日和代码行数估算是不同的,是根据每个人的能力和认识的不同而不同的。但是使用关注“相对大小”的“故事点”就可以解决这个问题。同样举距离的例子,每个人的能力是不同的(有人步行、有人跑步、有人公车、有人地铁、有人开法拉利),但是所有人得出的相对规模值还是一样的。因此使用相对规模估算就可以不需要考虑这种个人能力因素。
  • 不可相加
    传统估算方式的一个很大的问题是,估算不能相加。每个人的理想日是不一样的,这样成员甲的估算(理想日)就不能和成员乙的估算(理想日)相加。基于这种相加结果的计划肯定是不准确的。在敏捷开发中,需要整个团队一起对任务进行估算,因此需要一个能够达成团队共识的标准 – 也就是“故事点”。
因此,为什么“故事点”没有单位?
  • 首先,故事点是一个相对量,相对值是没有单位的;小学乘法:被乘数 × 倍数 = 积。故事点估算值就是这个倍数。
  • 其次每个团队的单位“故事点”是不同的,很难也不需要统一。
最后,其实敏捷的计划估算与传统的计划估算很大的不同是对计划的态度。在敏捷开发中,计划估算只是一个对未来的预测,因为是一个预测,所以总是有不确定性。敏捷开发计划承认这种不确定性,因此对计划估算的态度应该是不断根据新的发现,对计划进行不断的调整,但是不需要过于关注预测的准确性(我们的工作是为客户开发有用的软件,而不是提供可靠的计划。如果公司以预测的准确性来衡量员工的绩效,那其实大家也该考虑换一个地方了,这又是一种局部优化)。

关于作者:

爱迪德高级软件经理,InfoQ中文站特约编辑。他是亚洲第一位也是目前唯一一位认证Scrum教练(Certified Scrum Coach)Daniel具有多年的敏捷项目(Scrum & XP)实践经验以及丰富的带队经验。

Daniel20061月创建了Irdeto上海研发团队,并将ScrumXP成功引入了团队。目前该团队主要负责数百万美金级别的大型付费媒体计费及客户关系管理系统的开发及维护,四年中成功发布产品的两个新版本。系统现在在美洲、欧洲以及亚洲的许多国家运行。

Daniel一直致力于将海外的敏捷思想、理论及方法以及实践介绍到国内,帮助国内的软件团队高效并有趣地工作,真正为客户创造价值。作为敏捷社区的活跃分子,Daniel通过博客、InfoQ以及讨论组等宣传敏捷。Daniel经常受邀到各个会议中针对敏捷话题进行演讲,他是敏捷中国2009的讲师,并受邀QCon北京2010以及在CSDN举办的软件开发2.0大会2009等中作关于敏捷的演讲。

Dianelblog: http://www.cnblogs.com/tengzy/

Scrum中的工作量估算

当我们提起工作量估算的时候,我们会碰到同样的问题,我们如何来做估算?有什么方法可以遵循呢?如何估算才更准确?我对某个功能做了估算,但它超出了预计的开发时间,为什么?

Scrum团队已经做了很严肃的承诺去完成开发工作(可以交付的产品),必须要深思熟虑才可能成功。成功的工作里昂估算的几个步骤:

估算每个团队成员有多少时间可以在Sprint中被使用:

估算每一个团队成员在当前的Sprint中有多少时间可以被使用时Sprint计划会议的一个非常非常重要的部分。需要注意的是如果一个开发人员估算一个任务8小时可以完成,这个并不等于他一天可以做完。事实上,没有人会做在座位上一动不动,工作8个小时,参加会议的时间,午饭时间,意外的打断,看email, 接听电话等等都要考虑进去。

刚刚开始实践Scrum的人经常会问“是否需要预留一些时间来做bug修改?”。我当然不会准备两个Sprint,一个用来做产品backlog的开发,一个做bug修改。bug修改的时间应该是每天例行的时间,也就是说这是我们每天例行工作的一部分,扣除这些例行的时间,剩下的才是你可以承诺给Sprint的时间。1. 估算每个成员有多少时间花在和Sprint相关的工作上。

Sprint可用的工作时间= 平均日工作时间 – 其他活动.
平均日工作时间 = e.g. 8 hours
其他活动: = e.g. 4 hours
Emails and Phone : 1 Hrs
午饭: 1 Hrs
读Blogs/bbs : 0.5 Hrs
Bug fixes : 1.5 hrs
Sprint可用的工作时间= 4 hours

为产品Backlog中的每个项目估算工作量: 

有完成过类似工作经验的人来做相关的估算会更好一些,有历史数据可供参考。最好是让相关的有类似工作经验的人参与进来做适当的估算。经过几个Sprint之后,团队成员就会找准自己的位置,知道自己可完成多少工作。这也会使估算更为准确一些。

2. 所有的团队成员都要参与工作量估算的游戏。

3. 从Product Backlog中挑出排列好优先级的项目,要能够完全理解它,知道应该做什么,有哪些依赖、复杂度,风险等。如果需要的话让Product Owner做相关的澄清。
4. 细化理解后的项目为2-16 h/m工作量的小任务。

5. 为每个小的任务估算时间.

关于工作量估算的一些注意点:
1.一旦已经承诺要递交的Sprint的工作任务,团队成员不应该在受到外界的干扰,比如指派新的工作任务,或改变工作任务等。

2. 余下的工作将被移动到下个Sprint中。
3. 为了达到目标,团队必须是自我组织,并且团队成员之间是透明的。