译文 | 敏捷宣言发起人:我后悔发明了「故事点数」


本文翻译自:再谈故事点数

作者:Ron Jeffries 极限编程理念发起人,敏捷宣言的17位作者之一,第1位极限编程教练。


导读:

本文详细讲述了:作为「故事点数」概念的发明者,Ron 为何不再经常使用点数。他认为「故事点数」存在许多弊端,如:导致恶性竞争和团队工作的失焦。同时他也给出了弱化点数后的敏捷开发建议。

对正在采用敏捷工作法的团队来说,本文将带来新的思考和视角。

本文总计 2640 字,阅读约需要 8 分钟。


我或许是那个发明了敏捷估算中「故事点数」概念的人,但我现在为此感到抱歉。本文是我目前对「故事点数」的看法,希望有人会感兴趣。

—— Ron Jeffries 

首先,「用户故事」最初是XP(Extreme Programming 极限编程)中的概念,而非Scrum的概念。不知何故,后来Scrum框架的实践者,采纳了这个想法。就连官方的《Scrum指南》在介绍「待办需求 backlog」时,也认为需求应该以「用户故事」去呈现。一定程度上,这个做法是对的。 


我之前写过一些关于「用户故事」的内容。不过这篇文章,我们只讨论敏捷估算中的「故事点数」,下文简称为「点数」。 在XP中,最初估算用户故事工作量的方法是:实现该需求所需的时间。


首先估一个理想天数,即:如果让你专心写这个功能,你需要用几天。然后,理想天数 x 负面因子 = 实际实施时间。如果负面因子约为3,那么要完成一个理想日的工作,实际需要3天。

然而在交流中我们通常不会直接说「理想天数」。结果就是,项目经理经常问:你们为什么要用三天时间才能做完一天的活。换个角度:为什么我们不能在三周内完成50天的工作?

 为了避免内耗,敏捷开发中,我们将「理想天数」归纳为虚指的「点数」。例如:实现一个用户故事需要3个点的工作量,可能意味着它约需要9天时间。但事实上,我们本希望仅使用「点数」来控制每次迭代的总工作量。所以当我们说这个迭代大概能做20个点的需求时,往往没有人真的反对。 

我曾想过给「点数」改名,但现在,我对该问题有了新的想法。直到我的同事西蒙问我:你是真的为发明「点数」而后悔,还是为它们被误解和滥用而感到遗憾? 

我的答案是:

  • 我当然只是对他们被滥用感到遗憾;
  • 我认为用它们来估算「任务完成时间」是一个拙劣的想法;
  • 拿实际进度与估算点数作比较,是徒劳的;
  • 对比不同团队的估算准确度,是有害的。

 更深入观察会发现,实际上,一些号称「敏捷」的团队,正在用「便于规划」的名义把「故事点数」变成「标准工时」。尽管从表面上看似乎合理,但很容易陷入比拼工作量的陷阱。 

陷阱1:攀比 

首先,即使需求看起来一样,每个团队因为各自的方法、习惯和环境不同,会评出截然不同的点数。

因此,即便两个看似相同的需求,很可能A团队需要2个点,而B团队要6个点。显然,这并不能直接作比较。

然而管理者却试图解决这个问题:先问需求是否可以横向比较;再探讨耗费更多工时的团队是否需要帮助。这隐含着一个糟糕的判断:「速度较慢」的团队更差劲,或正陷入某种困境。

当有两个团队并行开发,对许多管理者来说,将二者的工作量进行对比,是一种不可抗拒的诱惑。但这很可能导致「数量高于质量」。因此我决定尽可能少去做工作量的评估。

陷阱2:考评 

在许多项目管理者眼里:点数≈人天。这意味着将点数与实际耗时进行比较,并企图确保估算点数的准确性。否则,就是开发人员的能力有待提高。这很糟糕。

对我而言,真正的敏捷开发是:找到最有价值的功能并迅速实现它。而快速开发,则要求先完成功能中价值最高的需求,再不断迭代。而估算「点数」,对此几乎没有帮助。

相反,「点数」的存在会导致管理层将他们的视线从「故事价值」上移开,而将精力集中在改进工作量的评估精度上。所以我认为:如果使用「点数」分散了团队对「价值」的注意力,那不如放下这个概念。 

陷阱3:压力 

一旦「点数」与实际工时被画上等号,管理者自然就会施加压力:他们想要「更多」。团队要做的事情很多了,但还远远不够,还可以更多更多更多…… 但输出价值的最佳途径不是堆量,而是经常做一些有价值的小需求

如果我们不考评工作量,而是将需求切成「足够小的」切片,那么我们将可以更平稳地持续交付、传递价值。

对数量的过分关注,会阻碍价值的增长。只追求工作量所带来的的压力将不可避免的导致恶果:团队开发速度看起来快了,但最终质量捉襟见肘。新版本出现了更多缺陷,频繁修bug减缓迭代速度,代码质量迅速下降也将影响质量……事情变得越来越糟,进一步增大压力,最后滑坡成一场灾难。

由此可见,错误地使用「点数」会施加错误的压力,所以我宁愿避免使用它。更进一步:我甚至不想再使用迭代或Sprint的概念。我们不再花心思填写未来几周的工作数量,相反,我们选择列出那些接下来要做的最重要的事情。 

预测完成时间? 

过去的迭代规划是:列一些基本功能,思考如何将它们拼合成产品的下一个版本。紧接着问:什么时候能做完?答案是:没人知道。

我们当然可以改善这种不了解,但当我们在为内部或外部的客户开发解决方案时,更好的做法是:高频地提供可见的小价值;而非规划一个功能上惊天动地,却永远无法完成开发的重大版本。

最佳实践是:为你的客户选择下一个版本的截止日期,并在该版本中安排更多的实用功能。而去预测完成时间,不管你以故事点数、人天,或者任何指标来进行,都会妨碍这一过程。这也是为何我认为,人们应当减少使用「点数」来规划工作。 

故事切片 √ 

由此衍生出一个新问题:如果我不喜欢「故事点数」,我喜欢什么?答:我喜欢「故事切片」。

将较大的需求切分成更小的用户故事,保证每个故事都尽可能地具有高价值,但实现它所需的工作量很少。理想情况下,应该少于一天,甚至只有2-3小时。

我不会与你争论故事切片是否也要估算工作量。如果你或你的团队只在自己的脑海中做算,且不告诉任何人,那么「估算点数」带来的问题都不会出现。此外,人们对「3天 vs 1天」的感知,和对「需求足够小 or 不够小」之间区别的感知,是截然不同的。 

未来怎么做 

当然,如果你必须评估工作量,那请继续进行。但我仍认为有更好的做法:

首先,思考每个版本的核心功能。讨论它们将解决什么问题,有哪些解决方案,怎么做MVP……我们不必解决所有存在的问题。事实上,只要能提供一些价值,就足以让交付顺利推进。

其次,确定一个截止日期,选择那个你认为可以交付高可用性功能的时间节点。

第三,对重要功能做「故事切片」。把需求切分成能在一天或更短的时间内完成的工作。把工作重心放在做「下一个最重要的功能」上。不要总去缝补最开始的那个功能,螺丝壳里做道场。尝试建立新的思维框架:「客户老爷实际上会用的一个小点,就是我们要做的功能点」。然后,做个MVP让客户去尝试。

只有这样,我们才能尽可能快地持续产出价值。 我们希望让开发工作的价值可见,让产品负责人和用户们都迫不及待地想看到我们交付的成品。无论工作量多少,我们都应该去做对的、有价值的事情。

总而言之

假如确实是我发明了「故事点数」,我现在可能有点抱歉,但不真的后悔。我确实认为「点数」经常被误用:机械地使用「点数」规划开发进度,会踩进很多陷阱。

 如果「点数」不能为你的团队提供很大的价值,我建议你不要过于坚持去使用它。另一方面,关于如何用好「故事点数」,我也曾写过一些别的文章在博客中你可以参考。


想读到更多「故事点数」的最佳实践、认识敏捷开发的不同框架、深入理解敏捷之道?

请关注LigaAI,持续接收更多干货分享~