本文翻译自：再谈故事点数
作者：Ron Jeffries 极限编程理念发起人，敏捷宣言的17位作者之一，第1位极限编程教练。
导读：
本文详细讲述了：作为「故事点数」概念的发明者，Ron 为何不再经常使用点数。
他认为「故事点数」存在许多弊端，如：导致恶性竞争和团队工作的失焦。同时他也给出了弱化点数后的敏捷开发建议。
对正在采用敏捷工作法的团队来说，本文将带来新的思考和视角。
本文总计 2640 字，阅读约需要 8 分钟。
我或许是那个发明了敏捷估算中「故事点数」概念的人，但我现在为此感到抱歉。本文是我目前对「故事点数」的看法，希望有人会感兴趣。
首先，「用户故事」最初是XP（Extreme Programming 极限编程）中的概念，而非Scrum的概念。不知何故，后来Scrum框架的实践者，采纳了这个想法。就连官方的《Scrum指南》在介绍「待办需求 backlog」时，也认为需求应该以「用户故事」去呈现。一定程度上，这个做法是对的。我之前写过一些关于「用户故事」的内容。不过这篇文章，我们只讨论敏捷估算中的「故事点数」，下文简称为「点数」。在XP中，最初估算用户故事工作量的方法是：实现该需求所需的时间。首先估一个理想天数，即：如果让你专心写这个功能，你需要用几天。然后，理想天数 x 负面因子 = 实际实施时间。如果负面因子约为3，那么要完成一个理想日的工作，实际需要3天。
然而在交流中我们通常不会直接说「理想天数」。结果就是，项目经理经常问：你们为什么要用三天时间才能做完一天的活。换个角度：为什么我们不能在三周内完成50天的工作？为了避免内耗，敏捷开发中，我们将「理想天数」归纳为虚指的「点数」。例如：实现一个用户故事需要3个点的工作量，可能意味着它约需要9天时间。但事实上，我们本希望仅使用「点数」来控制每次迭代的总工作量。所以当我们说这个迭代大概能做20个点的需求时，往往没有人真的反对。我曾想过给「点数」改名，但现在，我对该问题有了新的想法。我的同事西蒙问我：你是真的为发明「点数」而后悔，还是为它们被误解和滥用而感到遗憾？- 我认为用它们来估算「任务完成时间」是一个拙劣的想法；
更深入观察会发现，实际上，一些号称「敏捷」的团队，正在用「便于规划」的名义把「故事点数」变成「标准工时」。尽管从表面上看似乎合理，但很容易陷入比拼工作量的陷阱。首先，即使需求看起来一样，每个团队因为各自的方法、习惯和环境不同，会评出截然不同的点数。因此，即便两个看似相同的需求，很可能A团队需要2个点，而B团队要6个点。显然，这并不能直接作比较。然而管理者却试图解决这个问题：先问需求是否可以横向比较；再探讨耗费更多工时的团队是否需要帮助。这隐含着一个糟糕的判断：「速度较慢」的团队更差劲，或正陷入某种困境。当有两个团队并行开发，对许多管理者来说，将二者的工作量进行对比，是一种不可抗拒的诱惑。但这很可能导致「数量高于质量」。因此我决定尽可能少去做工作量的评估。在许多项目管理者眼里：点数≈人天。这意味着将点数与实际耗时进行比较，并企图确保估算点数的准确性。否则，就是开发人员的能力有待提高。这很糟糕。对我而言，真正的敏捷开发是：找到最有价值的功能并迅速实现它。而快速开发，则要求先完成功能中价值最高的需求，再不断迭代。而估算「点数」，对此几乎没有帮助。相反，「点数」的存在会导致管理层将他们的视线从「故事价值」上移开，而将精力集中在改进工作量的评估精度上。所以我认为：如果使用「点数」分散了团队对「价值」的注意力，那不如放下这个概念。一旦「点数」与实际工时被画上等号，管理者自然就会施加压力：他们想要「更多」。团队要做的事情很多了，但还远远不够，还可以更多更多更多……但输出价值的最佳途径不是堆量，而是经常做一些有价值的小需求。如果我们不考评工作量，而是将需求切成「足够小的」切片，那么我们将可以更平稳地持续交付、传递价值。对数量的过分关注，会阻碍价值的增长。只追求工作量所带来的的压力将不可避免的导致恶果：团队开发速度看起来快了，但最终质量捉襟见肘。新版本出现了更多缺陷，频繁修bug减缓迭代速度，代码质量迅速下降也将影响质量……事情变得越来越糟，进一步增大压力，最后滑坡成一场灾难。由此可见，错误地使用「点数」会施加错误的压力，所以我宁愿避免使用它。更进一步：我甚至不想再使用迭代或Sprint的概念。我们不再花心思填写未来几周的工作数量，相反，我们选择列出那些接下来要做的最重要的事情。过去的迭代规划是：列一些基本功能，思考如何将它们拼合成产品的下一个版本。紧接着问：什么时候能做完？答案是：没人知道。
我们当然可以改善这种不了解，但当我们在为内部或外部的客户开发解决方案时，更好的做法是：高频地提供可见的小价值；而非规划一个功能上惊天动地，却永远无法完成开发的重大版本。最佳实践是：为你的客户选择下一个版本的截止日期，并在该版本中安排更多的实用功能。而去预测完成时间，不管你以故事点数、人天，或者任何指标来进行，都会妨碍这一过程。这也是为何我认为，人们应当减少使用「点数」来规划工作。由此衍生出一个新问题：如果我不喜欢「故事点数」，我喜欢什么？
将较大的需求切分成更小的用户故事，保证每个故事都尽可能地具有高价值，但实现它所需的工作量很少。理想情况下，应该少于一天，甚至只有2-3小时。我不会与你争论故事切片是否也要估算工作量。如果你或你的团队只在自己的脑海中做算，且不告诉任何人，那么「估算点数」带来的问题都不会出现。此外，人们对「3天 vs 1天」的感知，和对「需求足够小 or 不够小」之间区别的感知，是截然不同的。或许有人会问：想知道产品需要多长时间才能发布，难道不是合理的诉求吗？对此进行工作量估算难道没有必要吗？也许有，但不要仅以工作量多少来评估你的需求。项目耗时不是「用户故事」层面应该解决的问题。
首先，思考每个版本的核心功能。讨论它们将解决什么问题，有哪些解决方案，怎么做MVP……我们不必解决所有存在的问题。事实上，只要能提供一些价值，就足以让交付顺利推进。其次，确定一个截止日期，选择那个你认为可以交付高可用性功能的时间节点。第三，对重要功能做「故事切片」。把需求切分成能在一天或更短的时间内完成的工作。把工作重心放在做「下一个最重要的功能」上。不要总去缝补最开始的那个功能，螺丝壳里做道场。尝试建立新的思维框架：「客户老爷实际上会用的一个小点，就是我们要做的功能点」。然后，做个MVP让客户去尝试。我们希望让开发工作的价值可见，让产品负责人和用户们都迫不及待地想看到我们交付的成品。无论工作量多少，我们都应该去做对的、有价值的事情。假如确实是我发明了「故事点数」，我现在可能有点抱歉，但不真的后悔。我确实认为「点数」经常被误用：机械地使用「点数」规划开发进度，会踩进很多陷阱。
如果「点数」不能为你的团队提供很大的价值，我建议你不要过于坚持去使用它。另一方面，关于如何用好「故事点数」，我也曾写过一些别的文章在博客中你可以参考。了解「故事点数」的最佳实践
认识敏捷开发的不同框架
深入理解敏捷之道
关注LigaAI，持续接收更多干货分享
LigaAI 智能研发管理平台专注灵感 回归价值 享受成果-扫码关注我们-
⇙请在PC端点击阅读原文，访问 LigaAI 吧~
或者点个在看，将干货好文分享给跟多小伙伴⇘