引言

当你要雇一位漆工来装饰你的房子，或者一位修理工来修你的车时，你会要他们先给个估算，对吗？你需要知道大概会花多少钱，需要多长时间。这是常识。

然而经验告诉我们什么？初始的估算和最终的账单有多大差距？很有可能漆工会发现有松动的石膏需要铲除，墙面需要修补和重新粉刷；修理工一定会发现要让你车子重新上路还有些其它的问题要解决。在1951年的《纽约客》杂志中有这样一幅漫画，Syd Hoff画了一个修理工对他的客户说：

“当然，那不过只是个估算，实际的花费一定会更多”

如果漆工或修理工告诉我们的这些问题还不是非常紧迫，我们可以选择暂时不处理…… 然而，通常的情况是，我们会觉得不得不修复那些额外的问题。谁会想住在一个可能墙面受潮的房子里，或者开着一辆有可能方向盘失灵的车呢？

那我们怎么解决这样的问题呢？常见的做法就是我们坚持要工人给一个全面的、确定最终价格的估算，也就是通常我们叫的“报价单”，这样工人就会花更多心思用更长的时间来进行更准确的估算。然而现实中，无论他们如何用心努力，终究还是无法预知到那些意想不到的问题。

在项目中，我们面临同样的问题

传统上，项目经理往往会致力于创建很详细的估算，这个估算从财务的角度要经得起推敲。当然这样的估算是基于能够预见的情况再加上针对“已知的未知因素”所设的应急预算…… 然而就像Donald Rumsfeld的名言所说“有一些我们未知的未知因素——有些事情我们根本不知道我们不知道”。就像上面那些商人，我们永远无法预知那些意想不到的情况。

我们花越长的时间来创建详细的估算，麻烦却越多。我们可以把详细的估算看作是一个绑定报价，一个不同于真正交付价值的目标，它使得我们的注意力都放到能在协议的日期和成本内交付一些东西——任何东西，无论它的价值高低。

在每次实施后的回顾评审中，初始估算和实际之间的差距总是让我们备受打击，然后告诉我们自己下次再努力些。爱因斯坦曾经说过，所谓神经错乱就是“一遍又一遍地做同样的事情，却期望得到不同的结果”。因此事情不应该这样，一定有其它更好的方法。

捷项目显然就不是这样？我们何不就从一个大概的需求范围开始，然后在做的过程中逐渐理清细节？嗯，对，但也不全对。在敏捷项目中我们不会去创建详细的估算来束缚自己，但是对将要进行的工作量的大小有一个认识还是很重要的，这就是为什么……

为什么我们需要估算

忘掉那些传统的估算，那些漂亮的精心制作的甘特图，那些图表迫使我们的注意力都放在要进行的任务上，而不是要交付的成果。在项目中有三种活动需要我们进行一些粗略的估算。

1. 当我们在考虑一个新提议项目的合理性时，我们需要提前知道大概的成本，这样才能决定是否值得投入。
2. 当我们正在将新的或改进的产品推向市场时，我们需要知道那些重要的特性大概什么时候可以发布，这样我们才能安排相关的活动。
3. 当我们在为工作排优先级时，产品负责人需要知道每个故事（或待办清单项）的成本，而团队需要知道每个故事的价值。

有件事很有意思，只要整个团队都一起参与进来共同协作，估算本身也可以变成一种很有意义的活动。它有助于团队增进理解，并保证团队每个人都对要交付的需求范围和价值达成共识。

然而对“估算”这个词的传统理解可能会让我们偏离这个方向。

使用“大小”而不是“估算”

为了避免让人误会我们讨论的是对成本和时间的估算，当我们评估一个故事的复杂程度时，有些人喜欢用“大小”而不是“估算”来描述。在90年代当我第一次使用Scrum和XP时——那时它们都还没有被称为敏捷实践——我们是使用T-shirt尺寸来评估故事的大小（S，M，L，和XL）。

现在我们使用故事点数——一种评估故事之间相对大小的方法——因此我们先找到可能最简单的故事，将它的点数设为1点，接下来用其他的故事与它进行比较，如果另一个故事比这个更复杂，那个故事可能就是3点。

让评估变得更有趣的是，我们不采用简单连续的数列，比如1，2，3，4，5等——而是采用一种近似菲波拉契数列的形式，像1，2，3，5，8，13等（就如《达芬奇密码》里面看到的）。这样当数字越大相邻数之间的间隔也越大，使得我们更容易区分哪个故事更小哪个更大。

尽管这不是一种精确的科学，但对上面提到的三种需要估算的情况这种方法已经足够好了。像John Maynard Keynes所说，“粗略的正确好过精确的错误”。这也意味着，我们仍然需要将故事点数转换成粗略的时间和成本估算。

另一个主要用于敏捷项目的实践是建立“完成标准”，就是对一个故事要能够标注为完成并可发布所需要满足的所有条件进行全面的理解，包括各种项目，比如用户文档、翻译、广告等等。

假如我们有清晰的完成标准，就可以拿几个样例故事来计算所需要的工作量。基于这种计算我们就能为投资决策进行粗略的成本估算，为版本计划进行粗略的时间估算，让我们对故事有更充分的认识以便能协助产品负责人进行故事优先级的设置。

然而有些人仍然认为即使以故事的方式进行估算也会让我们从真正的价值交付上分心。针对这一点，有一个围绕着#NoEstimates的讨论。

什么是#NoEstimates讨论

如果你在Twitter上关注了任何一位敏捷方面有影响力的人，你可能已经注意到他们有些人参与了#NoEstimates 标签的讨论。看起来这是要我们完全停止进行估算，其实它是要我们不再进行故事点数的评估，而是立即开始开发。

这个讨论自从出现后已经有了一个迅速发展的势头，因为那些在大项目中工作的人他们感觉无论是用故事点数进行评估还是仅仅统计故事的个数，团队产量的跟踪结果基本是相同的。

一定程度上这可能是因为那些有经验的交付团队每个迭代会将故事实时地（Just-in-time）以一致的标准拆分成更小的故事——这样的拆分使得团队每个迭代能产出更多潜在可交付的增量——无论项目在迭代里是采用的非常小的故事，还是适度大一些的故事，最终每个迭代的产能报告看上去都差不多。

#NoEstimates这种方式使得故事的优先级设置更简单了，使得交付团队能够更快地开始工作。然而可怜的产品负责人和项目投资方他们仍然需要知道项目大概要花费多少成本，需要多长时间。好消息是我们还可以基于故事个数的统计来进行粗略的估算，只要项目能够建立起足够有效的度量指标来让这样的估算可行。

对于任何刚开始敏捷之旅的新团队来说，无论如何我都强烈建议你们采用故事点数进行估算，直到你具有了和那些团队一样的丰富经验和成熟度。

结论

作为总结，引用General Dwight D. Eisenhower的一句名言：“在准备开始一个项目时，我总是发现估算的数字是没有用的，但估算的过程却必不可少”。我们仍然需要进行估算，不管这样的活动叫什么名字，不管在这样的活动中我们如何进行计算。

我要感谢Esther Derby（估算成为目标），Mike Cohn（为发布计划和优先级设置进行估算），Ahmed Sidky（全员估算），Martin Fowler（故事点数），Ian Mitchell（完成标准），Vasco Duarte（故事个数vs.故事点数），Stephen Forte（度量与估算），Neil Killick（有经验的团队定义更小的故事），和其他很多人，感谢他们在这个话题上给我的分享——以及我上面对他们各自论文的链接引用。