敏捷开发中软件估算的取舍：何时必要，何时是浪费？

周末参加一个项目管理技术沙龙，有个话题引发了激烈讨论：在强调“小步快跑”的敏捷项目中，我们到底还有没有必要花时间去做估算？一些资深实践者甚至认为，估算不仅可能徒劳无功，甚至是有害的。

估算的目的，往往被曲解了

我们得先弄明白，做估算本来是为了什么。

通常的场景是这样的：

1. 开发人员被要求对即将开始的工作给出一个时间估算。大多数人天性乐观，即便在没有外部压力的情况下（实际上多多少少总会有压力），给出的估算值往往偏小。
2. 这些任务和估算会被整合成一个发布计划，然后用燃尽图之类的东西来跟踪进度。
3. 接着，团队就会严格按照这个计划，持续监控投入的时间和资源。一旦实际耗时超过了最初的估算，所有人都会感到失望。为了“赶回”进度，开发人员可能被迫牺牲代码质量，而这通常会让事情变得更糟。

在这种模式下，投入精力做估算最多只是一种形式，甚至是一种浪费，因为“估算本质上是在对未知的需求进行猜测”。

当估算沦为单纯追逐更多功能特性的工具时，它就真正变得有害了。过分关注特性完成度是一种糟糕的状态，团队热衷于划掉一个又一个任务项，却忽略了追踪项目的真实商业成果和用户价值。

估算还会设定一个预期。由于估算常常偏低，它设定的预期也往往不切实际。任何时间的延长，或者某些功能被砍掉，都会被视作项目的失败。出于对风险的逃避，这种“失败”的后果又常常被放大。

正因为看到了太多这样的情形，许多人便把矛头对准了“估算”这个行为本身。这导致一种观点越来越流行：任何痴迷于估算的人都不是真正的敏捷实践者。而批评敏捷的人则会说，这意味着所谓的敏捷开发就是：开发人员很快开始动手，却不知道具体要做什么，只是承诺“到时候一定能做完，而且你一定会喜欢”。

那么，估算真的一无是处吗？

估算天生就是糟糕的吗？不一定，这完全取决于上下文。

在回答这个问题前，我们必须认清一个事实：对于大多数需要做出重大决策的场景，估算是有其核心价值的。

1. 资源的分配

组织拥有的资金和人力资源（统称资源）通常是有限的，而想做的事情却很多。这时我们就面临选择：是做项目A，还是项目B？要做出明智的决策，我们需要对A和B各自的投入成本（估算）和预期收益有一个大致的了解。

2. 跨团队协调

A团队想在产品中上线一个新功能，但这个功能依赖B团队提供的关键数据接口。如果B团队估算新服务需要2个月完成，而A团队估算自己的功能开发只需1个月，那么A团队就能判断，现在投入开发是否值得，或者是否需要调整计划。
任何时候当你打算做估算时，都应该非常清楚：是哪一项具体的决策需要依赖这个估算结果。 如果找不到这样一个决策，或者那个决策本身无足轻重，那么做估算很可能就是在浪费时间。

一旦确定估算服务于某个重要决策，你还需要弄清问题的背景、为什么估算很重要，以及期望的精度是多少。同时也要明白，有时可能存在不需要估算的替代方案。例如，任务A的优先级远高于B，以至于你根本不需要考虑B的投入；或者，可以通过让A团队和B团队紧密协作，来更快地交付服务。

3. 跟踪与调整计划

跟踪计划也应当由它如何影响决策来驱动。计划就像一个基线，帮助我们评估变化——如果我们想增加一个新特性，该如何把它塞进现有的“篮子”里？
估算能帮助我们理解这些取舍，从而决定如何响应变化。 在更大的范围内，重新评估整个发布计划，可以帮助我们判断项目是否仍在有效利用团队能力。

但请记住，估算和计划是有“保质期”的。一位资深项目经理说过，计划和估算就像生菜，头几天很新鲜，一周后开始蔫了，几个月后你就完全认不出它原本的样子了。

4. 促进团队深度交流

许多团队发现，估算过程本身是一种非常有用的机制，能够强制并促进团队成员之间的技术对话。 估算会议可以帮助大家从不同角度，更好地理解即将开始的故事的实现方案、未来的架构方向以及代码库中现存的设计问题。在这种情况下，最终输出的那个数字本身可能并不重要。

这样的对话本可以通过多种方式发生，但如果它们没有发生，引入估算讨论或许就是一个契机。反之，如果你考虑停止估算，也需要确保那些在估算过程中发生的有效技术讨论，能有其他途径继续进行。

在很多敏捷社区的讨论中，你会听到不少团队声称，没有估算他们也能高效工作。这通常是因为他们和客户都明白，估算并不会影响任何重大决策。例如，一个小团队与业务方紧密协作。只要业务前景明朗，资源也充足，团队就可以按照优先级持续交付价值；这通常得益于团队有能力将工作拆分为足够小的单元。
团队在敏捷成熟度模型中的等级在这里起着关键作用。在成长过程中，团队起初可能会纠结于估算本身，然后学会做出较好的估算，最终达到一种“无需估算”的境界——因为协作、拆解和反馈的节奏已经内化，足以支持决策。

核心总结：没有银弹，只有情景

估算本身并无绝对的好坏之分。 如果你不用估算就能有效工作，那就不做。如果你需要估算，那就要明确它是服务于哪个具体决策。如果这个决策足够重要，那就尽力做出你能力范围内最好的估算。

务必警惕那些告诉你“必须永远做估算”或“永远不需要估算”的绝对化言论。任何关于估算实践的争论，都应回归敏捷的核心原则：根据你身处的具体环境，选择最适合的方法。
项目管理和DevOps实践中充满了此类权衡。敏捷不是一套死板的规则，而是一种适应变化的思维模式。关于估算的思考，正是这种思维模式的体现。想了解更多开发流程与团队协作的实战心得，欢迎来云栈社区一起交流探讨。