再议故事点︱用户故事专栏
2022-12-15
来源：徐东伟敏捷教练 作者：Ron Jeffries
我想说，故事点可能是我发明的，如果真的是我发明的，我现在要说抱歉。让我们探讨一下我现在对故事点是怎么看的。至少有人想知道这些。
当然，“故事”这个东西是从XP来的，不是从Scrum来的。但不知道为啥，Scrum实践者采用了“故事”这个东西。尽管官方的《Scrum指南》提到的是产品待办事项，但认为产品待办事项就是指用户故事却成了一种常见的Scrum实践。
在XP中，故事最初是按时间估算的：也就是实现故事所需的时间。先估算“理想人天”，就是别的啥也不干，也不休息，需要多长时间能做完。我们将理想人天数乘以“负载系数”，就可以转换为实际的实施时间。负载系数通常为3：也就是说，3天才能完成1“理想人天”的工作。
但是在实际工作中，我们用时间做估算，通常会忽略“理想”二字。结果是，我们的利益相关者经常困惑于，为什么要花3天的时间才能完成1天的工作；或者，从另一个角度来看，为什么我们不能在3周内完成50天的工作。
正是因为这样，我记得，我们开始把“理想人天”称为“点”。因此，一个故事估计需要3个点，就意味着它大约需要9天才能完成。我们实际上只使用“点”来决定要往迭代里放多少工作，所以如果我们说大约20点，没有人真的反对。
可能是我提出了改名的建议。如果真的是我做的，我现在要说抱歉。以下是我目前对这个话题的一些想法。我有这些想法的起因是，我的同事西蒙通过电子邮件问我：
你真的后悔发明了故事点吗，还是仅仅因为人们没有正确理解相对大小而对它们的滥用感到遗憾？
我回答说
我当然痛惜他们的滥用；
我认为用它们来预测“我们什么时候能完成”这个想法太弱了；
我认为要将实际值与估算值进行比较真是够浪费的；
我认为比较团队之间的估算质量或速率伤害挺大的。
01比较
“敏捷”的某些方法建议跨团队故事点做标准化，是想通过这种方法，让计划更容易做。虽然从表面上看这似乎很合理，但很容易落入比较团队的陷阱。很多时候，很多组织确实会这样做。
首先，即使他们“看起来一样”，但每个团队都有自己的技能，在自己的环境中工作。所以，如果他们去估算两个看起来相同的故事，一个团队说是2，另一个团队说是6，那就不太有趣了，而且这肯定不是比较团队的有用方法。
现在，你和我看到这种情况，就会很好奇地去了解一下：首先，情况是否相似到足以进行比较？然后，估算值较高的团队是否需要我们提供帮助？这就是含蓄或明确地认为“较慢”的团队处于劣势或在某种程度上搞砸了——这非常糟，但不幸的是，这很常见。
我认为，许多经理看到两支团队都在产出一些东西，就会经不起诱惑，一定要将他们进行比较。如果我认为这个诱惑是不可抗拒的，那么我会放弃使用故事点的概念，甚至在可能的情况下，放弃对故事进行估算。这时我们要考虑“如何尽可能少做估算”。
02跟踪
对许多管理者来说，既然有“估算”，就应该有“实际”，这就意味着应该将“估算”与“实际”进行比较，并确保“估算”与“实际”相符。如果没有，这意味着人们应该学会更好地进行估算。
对我来说，在真正的敏捷中，重要的事情是选择接下来要做的少数几件事，并及时
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
-
延伸阅读：
-
