软件的“估算”，这个有年头的老大难问题，最近在敏捷社区内引起了有趣的讨论。J.B. Rainsberger 、Arlo Belshee、Josh Kerievsky、David Anderson和其他人提出这样一个问题：“估算真的有必要吗？”

著名的敏捷专家J.B. Rainsberger在Yahoo的XP讨论组中发起了一个有趣的讨论，质疑在敏捷软件项目中做估算的必要性。J.B. Rainsberger与2008 Gordon Pask两位中奖者之一Arlo Belshee对这个话题有过谈话，他是这样详细讲述的：

［Arlo］对我讲了一些他完成的研究和实践，主要是关于成本估算的，关键在于他的研究和实践中不做这些估算。他的观点是，或者是我领悟到的是，在做出和管理成本估算上付出的精力要超出拥有这些估算带来的好处。

Mike Hill加入了讨论并指出，Industrial Logic公司的家伙们在开发自己的敏捷eLearning产品时，已经开始朝不做估算的方向转变了：

对我们自己的工作来说，纯粹的“拉”模式就已经很好用了。客户会将需求按优先级排序，并放到“需求栈”中。我们从栈中“拉”出位于顶端的故事并进行实现。规划会议的规模越来越小，大家都把精力放在最重要的任务之上。

Industrial Logic的创始人Josh Kerievsky在Agile 2008大会中作了题为“被认为是浪费的估算”的演讲，并涉及很多细节。他解释了大家是如何通过交付更小、更频繁的“微发布版本”来取得成功的，这样大家可使用“点数和速度”方式时积累下来的“直觉”来更高效地开发，而且不必再花时间去在卡片上写数字，做算术题。

不久前，Amit Rathore接触了类似的想法。Rathore描述了这样一个流程，接下来要开发的最重要的需求，将被打散成同样大小的故事（大概耗时几天），并会在下个迭代中按照优先级顺序展开开发：

诀窍在于：每个故事的工作量不应该超过1-3天。对下一个需求也做同样的事情，一直这样做，直到这些故事把两周内的时间都安排满。

Rathore解释了为什么这样做不只减少了“浪费”，而且在很多方面都增加了价值：

这种做法带来了节省时间和精力的有益副作用。能够真正掌控开发流程，是真正的价值所在。小故事允许在必要时做出改变，在需要时可以从待办事项列表（backlog）中拉出来，任何时候有业务需求都可添加新的小故事。它也可以让团队以更快的速度前进，因为开发小块增量代码很容易，测试也方便，将小的版本发布给用户也变得轻松。

最后，强制要求每个故事必须保持小规模，大家就会在开始编程之前深入思考需求。这也可以强制团队将需求拆分成一个个可以进行增量开发的小片段，并且完全可以避免出现总是剩个小尾巴开发不完的故事。

David Anderson在很长时间之前就做出了类似的评论，并且从那时起就非常积极地参与了“软件的看板”运动。这项运动与Belshee、Kerievsky和Rathore讨论的想法有非常密切的联系。

从多个角度观察，也许有人会问：“真的没有进行估算吗？”这也是J.B.曾经思考过的问题。Kerievsky和Anderson认为这种过程其实近乎于“直觉”，Rathore认为故事的“大小相当”。也许不是，但是这样做是好是坏？问题真的应该是“没有估算？”，还是“没有数字？”还是别的什么？

查看英文原文：Is Estimating A Wasteful Practice?