从新审视故事点

我常说我可能发明了故事点，若是真是这样，如今我会感到很抱歉。让咱们一块儿来探索我如今对故事点的思考。至少有一我的对我所想的很感兴趣。 -- Ron Jeffries

固然，故事是极限编程的思想，不是Scrum的。不知何故，Scrum践行者接受了这个理念。尽管在Scrum官方指南中有关待办事项的内容，将待办事项做为用户故事是一种广泛的Scrum实践。

至少在某种程度上来讲，他们是对的。我已经在其余地方写了关于故事的常规用法，正如它应该被写下来同样。在这里，咱们将讨论的是"故事点"。

在极限编程中，故事最初是用来估算时间的：实现故事须要花费的时间。紧接着咱们来谈谈"理想天数"，它是用来非正式地描述若是别人让你尽本身最大努力单独完成故事需花费的时长。咱们用理想的天数乘于一个"负载因子"转换获得实际须要的时间。负载因子一般是3（3天才能完成一个理想天数的工做量）。

咱们刚谈到用天数来估算，常常是把"理想"抛开。这将致使的结果是咱们的老板很疑惑，怎么是要花费3天来完成原本1天就能够完成的任务，又或者说，为何咱们不能用3周来完成50"天"的工做。

我记得，咱们开始称"理想天数"只是"点"。因此一个故事应该用3个点来估算，这就意味着这个故事须要花费大概9天来我完成。总之，咱们确实也是只用点来决定多少工做进入一个迭代，因此若是咱们说大概20个点，没人会反对。

我可能已提出更名字的建议。若是我真这样作了，如今会感到抱歉。从给个人同事西蒙的电子邮件中，有一些关于目前我对这个话题的想法，他问到：

你真的后悔发明了故事点，或者你只是简单谴责当他们作相关度量时，没有正确理解而致使滥用吗？

我答道：

• 我固然谴责他们滥用；

• 我认为使用故事点来预测"咱们将何时完成"充其量是个无力的想法；

• 我以为跟踪实际与估算的比较充其量是浪费；

• 我以为比较团队的估算质量或速率是危险的。

让咱们更深刻一点。

实际上，一些用来作"敏捷"的方法，以更容易计划的名义，推荐给各团队规范化用户故事点。这表面上看起来很是合乎情理，却太容易掉进团队比较的陷阱，组织也是常常这样作的。

比较

首先，即便他们看起来很像，每一个团队都有本身的技能和特定工做环境。因此若是他们看两个貌似同样的故事，一个团队说这是个2，另外一个团队说这是个6，那就不是颇有趣了，固然这样比较两个团队也不是个有效的方法。

如今咱们怀着好奇心来了解这种情况，首先判断条件是否足够类似来比较，其次试问估算更高的团队，是否须要我们能提供的帮助。这样就很好。隐式或显式地结束"更慢"团队的劣势或以某种方式搞砸------这将是很是糟糕的事，但不幸的倒是很常见的。

我认为对不少管理者来讲，比较两个产品团队是件极其诱人的事。在可能的状况下，抛开故事点的概念，甚至抛开评估点的概念，我认为也是足够不可抗拒的。咱们回到如何用更少的估算来开展工做问题上，这里还有其余的文章也讲到这方面内容的。

跟踪

对于不少管理者，估算的存在乎味着"实际"的存在，意味着你应该拿估算与实际比较，确保估算与实际相匹配。当估算与实际不匹配时，就意味着人们应该要学习如何更好的估算。

对我来讲，真正的敏捷里最重要的是选择接下来要作的事，而且当即开展去作。最关键的问题是找出最有价值的事作，而且快速实施。快速开展去作，归结为去作小部分价值高的和快速迭代。若是不这样作，故事成本估算帮助不到什么。

所以，若是估算的存在让管理者把注意力从价值中移开，取而代之的是改善估算，把精力从快速交付真正有价值的东西转移。

这让我以为估算，无论是点仍是时间，都是浪费！

压力

有关估算/实际涉及的是老板们须要"更多"的天然压力。尽管不少团队已经完成了，这是不够的。更多，更多，更多。

交付有价值的东西，最好的方式不是更多、更多、更多，而是频繁的作有价值的东西。若是咱们把故事分解到"足够小"替代估算故事，从而达到一直持续平稳地交付有价值的东西。

聚焦在更多的增值。让团队在愈来愈大的压力下作更多的需求，不可避免地会产生一个坏结果：团队试图更快速地去作，而忽略代码质量和测试。他们瞬间开始承载愈来愈多的缺陷，由于持续返工去修复缺陷，甚至因为代码质量迅速下滑而放慢速度。事情变得愈来愈糟糕，压力持续增加，这将演变成一场灾难的节奏。

因为估算至少被卷入过分压力的投入中，我宁愿避免。

我更深刻点：我宁愿彻底避免迭代或冲刺计划。在接下来几周，咱们不会为去填补预算而工做，而会由于接下来有几项最重要的事情清单而作。

预测完成

一种常见的作法是作个基本特性列表，先想一会，而后决定定义咱们产品的下一次发布。固然，接下来的问题是"这些何时能所有完成？"

没有人知道这个问题的答案。咱们能够作不少工做来改善咱们不知道的事，在某些领域和某些时候，这当中的一些事也是值得作的，譬如当一个大的合同等待投标的时候。可是当咱们正忙于开发内部或外部客户的解决方案时，尽量地频繁提供少许有价值的东西，而不是等到一般会无限期拖延的全功能一块儿发布。

选择临近下一次发布给客户的日期，尽量地挑选好东西到发布中，这样更好。估算故事点或时间阻碍了交付。在我看来，若是可能的话，这最好要避免。

分解（拆分）

那么问题来了，若是你不喜欢故事估算，那你喜欢什么呢？好吧，我喜欢故事分解，它是将大的故事点分解成更小的故事点集合，每一个小故事点尽量高的价值，然而只须要不多的时间就能够完成，理想状况下，少于一天，也许只是几个小时。

如今，我不在意与你争论分解（拆分）时是否必须进行某种估算。若是你或者你团队的估算只是在脑海里，没有告诉任何人，那么，不管是故事点或时间的估算问题，就不太可能提出来。固然，了解故事点"可能足够小"和"可能不够小"之间的差别并不等同于知道"三天"和"一天"的差异。

另外，这有个技巧。我在 Getting Small Stories 和Slicing, Estimating, Trimming有提到。我也是从Neil Killick学的：分解故事直到它只须要一个验收测试。一个好的故事点只须要不多的实践。

固然，还有关于估算主题的其余文章，点击连接会有超乎你想了解的。

预测未来

可是...难道咱们不该该合理的知道一个产品发布须要多长时间和估算是否必要吗？然而也许这不是故事估算。你应该不会把你的需求归结到故事层面，若这么干，貌似是很大程度的浪费。

固然，若是你必需要这么作，那就这么作。不管我作什么或者个人关于你该作什么的理论，只是理念。最终你须要作的是在本身所处的环境下尽一切可能的成功。只是我以为能够有些更好的东西。

• 第一，想一想下一次发布的一个或多个重要功能。讲讲这些功能能够解决什么问题和什么样的软件能够帮助解决这些问题。谈谈能够解决一些问题的最简单功能。咱们没必要要解决全部的问题：一般咱们提供一些解决方案足以推进事情的发展。

• 第二，想一个到那时你以为能够构建出一些好的功能点的时间节点。设置最后的期限并开始着手工做。

• 第三，再分解重要的功能故事点并实现它。你应该可以在一天或更容易地实现。只作下一步最重要的：别试图总是先实现边边角角的功能。你应该尝试这样的思惟框架"若是作了这个小东西，客户Jack就会在实际中使用它"。而后，就作这个小东西而且让客户Jack试用它。咱们想尽量快的持续传递价值。

咱们想把正在作的东西的价值明显化，让产品经理或者其余老板等不及想看到产品。这样...咱们就在有或没有故事估算的状况下作了正确的事。

总结

若是我真发明了故事点，我如今可能有点很是很差意思。个人确以为它常常被误用，致使若是根本不用故事估算的话，就能够避免不少陷阱。若是故事估算没有为你的团队或者公司提供很大的价值，我建议直接弃用，由于它们是浪费。另外一方面来讲，若是你确实喜欢他们，那就继续！

做者：Ron Jeffries
译者：谢谊丹
审校：Bob Jiang

• 用户故事
• 故事点
• 估算

本文首发于 Bob Jiang的博客 ，转载请联系 Bob Jiang