2
【编者按】通常来讲，在敏捷开发中，估算是对项目将持续多长时间或花费多少成本的预测，但是在实际开发过程中，进展、结果和估算往往偏差不小，那么这是否意味着估算是完全无用的呢？本文中，来自ThoughtWorks的首席科学家Martin Fowler从估算与决策的关系这一角度进行了探讨。（原文发表于他的个人博客：martinfowler.com）
我第一次与敏捷软件开发的邂逅，是在极限编程刚刚兴起时，跟Kent Beck（最早研究软件开发的模式和重构的人之一，敏捷开发的开创者之一，极限编程和测试驱动开发的创始人）一起工作的经历。其中让我印象深刻的事情之一，就是我们如何做计划的方式。这里面包括一种估算方式，比起我之前见到过的其他方法，它既轻量，还更有效。这样过了十年，现在一些有经验的敏捷实践者，开始了一场关于估算是否值得甚至是否有害的争论。我想，为了回答这个问题，我们必须审视一下估算的目的。
通常的场景是这样的：
开发者被要求给出对于即将开始工作的估算。人们大多是乐观派，即使没有压力的情况下（一般至少也会有点压力），这些估算通常会比较小。
这些任务和估算会被转化成发布计划，然后用燃尽图（burn down chart）跟踪。
接着，人们就会按照这些计划，持续监控着团队为完成任务所投入的时间和资源。结果当实际消耗的时间和资源，超过当初的估算时，每个人都会变得失望。为了迎合当初的估算， 开发者被要求牺牲软件的质量，但这只会让事情变得更糟。
这种情形下，对估算的投入充其量就是一种浪费 —— 因为“估算就是在干净的衬衫上猜测”。只有当估算被当做追逐更多特性的手段时，它才会变成实质上有害的行为。过分追逐特性是一种很糟糕的情形，人们只是始热衷于完成一个又一个特性，而不是追踪项目的真实结果。
估算还会设定期望值，既然估算通常会偏低，所以它们设定的期望值也多是不切实际的。任何时间上的增长，或者软件特性被砍掉，都会被视作是失败。出于对风险的逃避，这些失败的后果往往会被放大。
面对类似这样的情况，我们就很容易看到人们把愤怒对准了估算本身。这样也导致越来越多的人认为，任何沉迷于估算的人并不是真正的敏捷实践者。而批评敏捷的人则说，这意味着敏捷软件开发的本质就是，开发者很快动手开始做，却并不明确要做什么，而且承诺说，该做完的时候肯定会做完它，而且你肯定会喜欢它。
我并不同意估算是天生有害的活动。如果有人问我，估算是不是件糟糕的事情，我的答案会是一名标准咨询师的答案：“不一定”。而接下来的问题就会是“取决于什么”。为了回答这个问题，我们就不得不问，我们为什么要估算 —— 因为我想说：“如果事情值得做好，就值得问清楚，我们到底为什么要做它。”
对于我来说，当你面临重大的决策时，估算就是有价值的。
我的第一个得益于估算决策的例子是：资源的分配。一般来说，组织大多拥有固定数目的钱和人，而且通常有太多值得做的事情。因此人们就面临选择：我们是做A还是B？面对这样的问题，了解A和B分别要涉及多少投入（以及成本）是有必要的。为了做出一个明智的决策，你需要有对成本和收益有个大致的了解。
另外一个例子是估算对协调的帮助。蓝色团队想在他们的网站上发布一个新的特性，但直到绿色团队创建新的服务提供给他们关键数据后才能发布。如果绿色团队估算他们会在两个月后才能完成新的服务，而蓝色团队估算需要一个月去能完成新的特性，那么蓝色团队就知道不值得现在就开始实现这个新特性。他们可以花费至少一个月时间，工作在其他可以早点发布的特性上。
所以任何时候当你想做估算时，你应当非常清楚哪一项决策需要依赖这个估算。如果你找不到这样一项决策，或者那个决策并不是那么重要，这就是一个信号：此时做估算是在浪费时间。当你找到这样一个决策时，那要知道问题的上下文是什么，为什么估算会很重要。同样还要搞清楚期望的精度和准确性。
同时也要明白，有时候为了做决策，可能会是其他替代的方案，而未必需要估算。也许任务A比起B要重要得多，以至于你都不需要一开始把你所有的空闲精力都放在B上。也许有办法让蓝色团队和绿色团队合作，更快地创建出服务来。
类似地，跟踪计划也应该由它如何影响决策来驱动。通常我的意见是，计划扮演的是基线角色，帮助评估变化 —— 如果我们想要添加一个新的特性，我们应该如何把它放进既定的“五磅篮”里呢？估算可以帮我们理解这些取舍，并因此决定如何响应变化。在更大范围下，重新评估整个发布计划，可以帮助我们理解整个项目是否仍然充分有效利用了我们的能力。几年前，我们曾经有一个规模达一年之久的项目，在重估时发现还要多花几个月进去，之后我们取消了这个项目。我们把这视作成功，因为重新估算发现，项目会比我们最初期望的会花费更长时间 —— 早点取消可以让客户把资源转移到更好的目标上。
但跟踪计划的同时，也要记住估算是有适用期限的。我曾经记得有一位经历颇丰的项目经理说过，计划和估算就像是生菜，刚过几天还很新鲜，过了一周有点枯萎了，几个月后就完全看不出来是什么了。
许多团队发现，估算提供了一种有用的机制，可以促使团队成员间彼此交流。估算会议可以帮助大家以不同的方式，对实现即将开始的故事、未来的架构方向和代码库中的设计问题，有更好的理解。在这种情况下，任何输出的估算数字可能都不重要。这样的对话可能以很多方式发生，但如果这些对话没有发生，就可以引入关于估算的讨论。相反地，如果你考虑停止估算，你需要确保估算时会发生的任何有效的对话，在其他地方还能够继续进行。
在任何敏捷相关的会议上，你都会听到很多团队在谈论，没有估算他们也可以工作得很有效。通常这是因为，他们以及他们的客户明白做估算并不会影响重大的决定。举个例子，一支小团队在和业务人员紧密协作。如果广阔的商业前景很乐意分配一些人到那个业务单元，那么就可以按照优先级开展工作；通常这得益于团队把工作拆分成足够小的单元。团队在敏捷流畅度模型中的等级，在这里起到非常重要的作用。在团队前进时，他们首先会纠缠于估算本身，然后开始会做很好的估算，最后达到不再需要估算的境界。
估算本身并无好坏之分。如果你不用估算就可以有效地工作，那就这么干。如果你需要一些估算，那就要确认你很清楚估算在决策时起到的作用。如果估算会影响到重大的决定，那就尽可能做出最好的估算。一定要小心那帮告诉你任何时候都要做估算，或者从来不需要估算的人。任何关于估算用法的争论，都要遵从于敏捷的原则，即针对你特定的上下文，决定你该采用的什么样的方法。
【关于本文】本文所有内容来源于TW洞见，版权均属ThoughtWorks公司所有（微信公众号：ThoughtWorks），任何媒体、网站或个人未经协议授权不得转载、链接、转贴或以其他方式复制发布/发表。
雷峰网原创文章，未经授权禁止转载。详情见转载须知。
