是时候停止用户故事估算了吗？

大多数新的敏捷团队在从基于小时数估算过渡到基于故事点的相对估算，但我们真的需要估算吗？

Michael Dubakov 提示以下你需要停止使用用户故事估算的原因:

1. 你不要在估算上浪费时间
2. 你不需要对更高的管理者解释为什么需要这么久
3. 你不用给出难以达到的承诺
4. 你不用给开发团队额外的压力
5. 你可以专注于真正重要的事情

Stephan Schwab, 担心时间估算可能会导致团队分裂并且会成为团队解决问题的障碍:

想象一下一个组织期望通过团队给出 backlog 的完全估算来决定项目成本的情形，乍一看，这种做法似乎是一个好主意，将要做该工作的人会提供估算，而且由此基于他们所说的可以了解真正的工作成本。

但项目的真正成本就真的就这样可以了解吗？当一组聪明人开始解决问题的时候会有什么发现呢？对于一个 6 个月的项目，针对一些小的故事卡片，在几周内数位分析师能够分析问题并给出好的解决方案似乎不大可能，他们或许在几周内能够创造超过 500 个故事卡片，但我认为这都是基于最初的假设，如果问题能够在几个星期内被解决，那就不需要整个团队付出超过 6 个月的工作了。

所以对我来说，这似乎更像是预测未来，创建一个计划并按计划来管理。

一个团队被要求提供充分估算并且足够详细的 backlog 会导致拘泥于规定的行为，并阻碍技术团队成员从分析师、用户体验师和 Product Owner 得到信息做出解决方案，最后，如果由此产生的“解决方案”的质量低于预期应该是毫无疑问的，因为团队被阻碍做出优秀的工作。

质量也会成为这所谓虚假的可预见性的代价，尽管一些利益相关者期望高质量产品，但同样来自于他们的要求很可能会导致这种情况发生。

比“计算”的成本更重要的是构建有价值的东西。那些可以使用并且最终使利益相关者想扩展或有新的想法的时候还想要找同样的人来完成的东西。

Mike Cottmeyer 则坚持估算也有好处:

因为我们不喜欢经理和我们不喜欢死亡行军 ，我们就断定创造软件是一个不可预知的过程中，估算是不好的，所以我们绝不能进行估算。有没有可能我们并不是真地遇到估算的问题呢？是否有可能，这是一个管理不善的问题呢？

我看不出有任何理由停止估算。事实上，除非你的商业模式支持完全的自然成果，否则你的某些目标和商业成果的机会是和一些事先定义好的交付物捆绑在一起的，这些机会意味着你已经向客户卖出了东西现在你必须实现这一承诺。

我们可以整天辩论这种商业模式，但如果这是现实，你是需要估算的。

估算得有范围和可能性。你需要管理好假设条件并降低风险。我们必须能够衡量我们的估算有多大的误差，这样我们就可以开始提前预测误差。

我们忽视了数据告诉我们的信息，我们忽略了团队相对于估算的实际绩效。我们有很大的交付竞争压力；有要在下月末之前增加额外的功能，这样我们就可以提高销售的巨大压力；有交付那些我们销售团队为赢得大生意而承诺的功能的巨大压力。在如此大的压力之下，使得我们都脱离了现实。

真正的问题是，我们过于频繁地吹嘘组织的交付能力。真正的问题在于“你必须不惜一切代价，提供”的文化不尊重团队做出经过测试可工作软件的实际能力。

面对不合理的期望、死板的项目进度和承诺时，在不愿意向交付低头的压力下，错误的估算会成为问题，管理不善也成为一个问题。

Bob Marshall: 对同一篇文档做如下评论

此外，我经常不得不问：“为什么要做估算？”。除非到了人们对需求的估算彻底心领神会，否则谁又能有任何把握说估算是有价值的呢？

许多人认为看板已经废弃了估算， Karl Scotland 澄清了这种情况 :

看板团队不只是因为做起来很难才避开估算。有些团队选择不做估算，因为他们可以得到同样的效果而付出低于估算所需的成本。老笑话对此仍然适用（“医生，我这样做会很痛”，“那就不要做了”）。如果估算有害那就找到其他方法鼓励整个团队的互动和合作，了解过去的能力和预测未来的能力。另一方面，如果估算无害，或成本不太高的话，那么它可能在你所处环境中是应该做的正确的事情。

当我们在计划的时候，我们应该把工作分解为可理解的部分，而不是调整工作本身。

Jeff Anderson 给出了另一种在看板中使用估算的情况:

随着团队的发展，接受的工作通常会归类到更好理解的工作类型，这些类型很少变化。比如 A 团队的工作可能通常基于 Java 的增强功能、紧急的缺陷和固定格式的报告。

估算最重要的部分是把工作分解成小块的。一旦你做到了这点，唯一关注小范围差异的理由就是想要引起讨论。

虽然看起来估算成果的价值可能会有疑问，似乎估算的真正好处是整个团队一直对于这一点产生各种交流。您对于此有哪些经验呢？

查看英文原文： Is it Time to Stop Estimating User Stories?