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

阅读数:1312 2009 年 9 月 23 日

话题:敏捷文化 & 方法

长久以来,对于 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