BT

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

Sprint规划:故事点数 vs. 小时数

| 作者 Vikas Hazrati 关注 0 他的粉丝 ,译者 郑柯 关注 3 他的粉丝 发布于 2009年9月24日. 估计阅读时间: 6 分钟 | 如何结合区块链技术,帮助企业降本增效?让我们深度了解几个成功的案例。

长久以来,对于sprint规划中应该使用故事点数还是小时数,一直有着不分胜负的争论。双方阵营似乎都有一系列理由,支持人们采纳自己的方式而不是对方的做法。Mike Cohn坚决支持将用户故事拆散成任务,然后再用小时数估算。而Jeff Sutherland提出:有些跟他一起工作过的、非常出色的团队一直在使用故事点数,并用其绘制燃尽图。很多敏捷资深人士都表达了自己的观点,说明自己喜欢哪种方式及其原因。

在Mike看来,他不喜欢在spring规划中使用故事点数,因为故事点数更适合用作长期度量,对于短时间规划没有帮助。他觉得:

假设有一支棒球队已经进入赛季中段。他们在已经进行过的41场比赛中,场均得分98分。他们可以说:“我们在剩下的赛季里大概每场平均也能得到98分。”但是他们不会在某场比赛前这样说:“我们之前的平均得分是98分,所以今晚我们会得到98分。”

这就是为什么我说速度可以用作长期预测,而不适合进行短期规划。

Tara Lee Whitaker不同意故事点数可以用作短期度量。在她看来:

如果每个故事都足够小,并因此可以“准确”估算,而且可测试性足够好,人们可以据之创建用以确认验收的测试,那么把故事拆成更小的部分,或是重新以小时数估算之,这样做也就没多大好处了。

对于以小时数估算故事这样的方式,她非常担忧:

当我们开始讨论将故事拆分成小时任务时,我主要担心的是:我们无法从这样做得到的早期警告信号中获益,并且当我们发现完成一个故事所需时间超过预期时,那已经太晚了。

Jim Schiel提出:也许有可能以故事点数和小时数两种方式来做sprint规划。然而,用小时估算的回报也许会让这种做法看起来不值得这么做。他认为:

现在咱们来看这样一个Scrum团队,他们承诺要完成10个2点的产品Backlog条目。如果他们能够全部完成,他们在这个sprint中的速度就会达到20个故事点数。下一个sprint,他们大概会尝试再次完成20个故事点数。此后的sprint的速度多少都会受上个sprint的影响。这种关系会一个一个sprint传下去,团队会得到一个大概的速度,在18与22之间。

你能用小时数来达到同样的效果么?可以,但是要想做好就得付出非常多的成本。你到底想为什么买单?是完整的、可用的软件,还是非常准确的估算?

Jack Milunsky进一步阐述了故事点数的意义,他提到了下列优势:

  • 通用度量——故事点数是整个团队中通用的度量方式,不会因为经验、个人技术水平或团队某个人而受到影响。
  • 稳定状态——等到第三个或第四个sprint过后,团队的产出就会达到稳定状态,产品负责人也更易于把稳定的故事点数填写到backlog列表中。不会多,也不会少。
  • 鼓舞士气——一旦团队达到稳定状态,业务人员就能相信技术团队的能力,这能让团队士气高昂、充满自信。

Tomas Björkholm提到选择故事点数方式的下列原因:

  • 原因之一:估算是为了描述故事的大小,而不是要知道实现这个故事需要多久。
  • 原因之二:理想化的人日作为度量标准,它会随时间推移根据团队的表现发生变化。故事点数相对稳定。
  • 原因之三:已经证明,相对估算要比绝对而且理想化的人日正确性更高;同时,由于人日是时间度量单位,尽管可以用其做出相对估算,但还是很容易偏向绝对的使用方式。

Tomas补充道:

Staffan Nöteberg在关于Pomodoro技术的演讲中提到:大多数人对于按实际时间估算都感到不舒服。由此我想到:不舒服的人,工作效率都不高;因此,按照天估算就会导致工作效率不高。

Mike Cohn提及:在故事点数和工作小时之间没有线性的对应关系。在他看来,每个故事的大小都会基于标准差有个分布范围。

一个点数等同于一个分布范围,等同于x和某个标准差的结果。同样的,2点的故事也可以依此类推……

因此,人们不能告诉项目干系人:按照以故事点数方式计算的速度,团队能在某个确定的时间完成任务。一定是个时间范围:

这个范围可是是日期范围,比如“我们可以完成你的产品backlog中所有的条目,但是完成时间大概在5月或者6月。”或者可以是功能范围,“我们可以在5月20号完成,你也是这么要求的,不过我们到时会完成120个到140个点数,也就是在这两个产品backlog条目之间。”

Mike Cohn还提供另一种方式,它可能符合精益原则,名为“承诺驱动的sprint规划 ”。使用这种方法,团队不会讨论故事点数或是速度。他们就是从backlog中取出优先级高的条目,根据各自的能力,把任务分配下去,按小时估算,并实现自己的承诺。

因此,这两种用作sprint规划的技巧各有优劣。到最后,可能还要看团队更习惯哪一种做法。您喜欢哪一种呢?原因何在?

查看英文原文:Sprint Planning: Story Points Versus Hours

评价本文

专业度
风格

您好,朋友!

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

获得来自InfoQ的更多体验。

告诉我们您的想法

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

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

Sprint规划:故事点数 vs. 小时数 by cao Alex

故事点数需要团队有一段时间的习惯和认识,才能利用的更好, 理想日比较容易实施,也容易理解。但就像前面说的: “理想日会随时间推移根据团队的表现发生变化。故事点数相对稳定。”
如果团队成员相对比较稳定,而且项目时间也不是非常的短。 用故事点数会比较好。这样等过了几个sprint,团队的速度基本稳定在一个范围内。对项目后面的发布计划等等都会有正面的影响。
若选择理想日来估算。那就一定要清楚的明白,理想日不等于工作时间,否则就会产生错觉。从而会对规模相同的用户故事给出不同的理想日。 这样团队就会不容易找到自己的比较真实的速度范围。

小时数 by Jun Ran

我比较倾向于用小时数,用故事点比较困难,也比较复杂,而简单是敏捷的基本原则之一;

用故事点的难处在于去定义每个任务的故事点数量,若没有一套通用的标准,很难使每个任务的故事点代表相同或相近的意义;

有人建议简单地用 1个理想人日(8小时) 作为一个故事点,这种转换使得故事点建立在小时数的基础上,本质上还是在使用小时数,额外去增加一个转换过程又有什么意义呢;

Re: 小时数 by 鲍 央舟

同意,如果任务break down到足够小的话,用小时数完全没有问题。用故事点数反而会使Team觉得复杂。

并不冲突吧! by Shichao Liu

拿赶路类比, 故事点数是距离(X千米), 小时数是在使用特定载具的情况下的所需时间(Y小时). 同样是1千米的路, 汽车和走路当然时间不同. 一个团队里, 新手老手解决同一个问题的时间也是不一样的. 一个条目取出来, 我们说他是1天能干完的, 必须是在确定谁来做的前提下.

即需要对问题复杂性本身的大致估算, 与实现者无关, 即故事点数.
也需要进一步参考团队的实现能力, 来估算和真实世界的对应关系.

小时数 by Fan Jun

开发人员很容易将工作对应到小时,而不是多少个点。虽然期望通过点来保证大家的统一理解,同时也能支持任何一个Story可以由任何人去做,但在实际中大部分项目Story的开发者都是相对固定的,所以估计小时数对开发者更适应。

Re: 并不冲突吧! by 峻申 吴

相当同意你的说法。我个人觉得根据“短板效应”,使用团队平均完成速度来预算还是比较公平的。因此两者没有什么冲突的地方。我的理解是下列公式:
人时×团队平均速度=故事点数。
因此如果团队平均速度是一个定量,一个sprint完成的故事点数和完成这个sprint所需人时就是线性关系了。所以我反而不同意“在故事点数和工作小时之间没有线性的对应关系。”这个说法

Re: 并不冲突吧! by 裸奔的 胖虫

拿赶路类比, 故事点数是距离(X千米), 小时数是在使用特定载具的情况下的所需时间(Y小时). 同样是1千米的路, 汽车和走路当然时间不同. 一个团队里, 新手老手解决同一个问题的时间也是不一样的. 一个条目取出来, 我们说他是1天能干完的, 必须是在确定谁来做的前提下.

即需要对问题复杂性本身的大致估算, 与实现者无关, 即故事点数.
也需要进一步参考团队的实现能力, 来估算和真实世界的对应关系.


这个貌似和我感觉上很符合,非常不错的解释

允许的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通知我

7 讨论

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


找回密码....

Follow

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

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

Like

内容自由定制

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

Notifications

获取更新

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

BT