本文翻译自：再谈故事点数 作者：Ron Jeffries 极限编程理念发起人，敏捷宣言的17位作者之一，第1位极限编程教练。 原文链接：https://ronjeffries.com/articles/019-01ff/story-points/Index.html
导读：
本文详细讲述了：作为「故事点数」概念的发明者，Ron 为何不再经常使用点数。他认为「故事点数」存在许多弊端，如：导致恶性竞争和团队工作的失焦。同时他也给出了弱化点数后的敏捷开发建议。
对正在采用敏捷工作法的团队来说，本文将带来新的思考和视角。
首先，「用户故事」最初是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让客户去尝试。
只有这样，我们才能尽可能快地持续产出价值。 我们希望让开发工作的价值可见，让产品负责人和用户们都迫不及待地想看到我们交付的成品。无论工作量多少，我们都应该去做对的、有价值的事情。
--
总而言之
假如确实是我发明了「故事点数」，我现在可能有点抱歉，但不真的后悔。我确实认为「点数」经常被误用：机械地使用「点数」规划开发进度，会踩进很多陷阱。
如果「点数」不能为你的团队提供很大的价值，我建议你不要过于坚持去使用它。另一方面，关于如何用好「故事点数」，我也曾写过一些别的文章在博客中你可以参考。