估算实践是浪费吗？

作者 Mike Bria 译者 郑柯 发布于 2008年8月15日

领域

过程 & 实践

主题

敏捷技术 ,

敏捷

标签

Agile2008

软件的“估算”，这个有年头的老大难问题，最近在敏捷社区内引起了有趣的讨论。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认为故事的“大小相当”。也许不是，但是这样做是好是坏？问题真的应该是“没有估算？”，还是“没有数字？”还是别的什么？

哪位读者有不进行估算做敏捷项目的经验？不管你估算与否，可以在这里或是Yahoo的XP讨论组上加入讨论。

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

---

InfoQ英文站的读者和编辑在文后进行了热烈的讨论。Agile社区首席编辑Deborah Hartmann介绍说最近开始使用T恤的大小来估算产品待办事项列表。她说道：

……这样做的结果是：当不再需要用数字时，人们会觉得估算起来更加自如。我们都知道，这种级别上的估算讲“准确性”只能是幻觉，可使用数字估算也难逃此劫吧。

她还建议开发工具的人提供将T恤估算转换成数字的功能，供版本发布预测使用。

Christian Gruber更喜欢Amit规范故事大小的方式，认为这样可以让预测更容易，并进一步说到：

这样的做法实际上与排队理论是一致的。队列中的单位越规整，如果相对于队列的宽度来说单位的尺寸越小，为了得到最优的有效产出而需要留出的闲置资源就越少，也就是说队列越有效率。经验告诉我，这样做在管道系统、高速公路等方面都是可以的，而且在软件团队中同样可以发挥作用。

文中提到的Amit Rathore这样回复：

当然不是不做任何估算了。这与结对编程的精神是一样的，有了结对编程就不必做代码复查了。这更像是“禅”的方式，是通过做得更多来达成目的的——一对开发人员总是在做代码复查，时时刻刻。

将故事们打散成小块是好事情（排队理论）。如果几乎所有的故事都可以拆分到这种程度，就会带来很多好处（正如上面多个博客中提到的）。还有一个好处：要得到这种同质性，相关人员必须要经常估算。
只不过是关注点上的差异。提升有效产出，而不是做无意义的预测，这才是到达目标的简单方式。

其他更多相关讨论，请查看英文原文。

译者 郑柯 InfoQ中文站总编。做过开发，当过PM，干过销售，搞过市场，最终还是回到媒体。实用的理想主义者，相信：每天改变一点点，这个世界会更好。

• 更早的 >