准确估算——这个名称根本就是语义矛盾的？

Amit Rathore在自己Blog上一篇分为两个部分的贴子中，通过基于时间的任务估算对软件生产过程产生的影响，论述了一个极端精益方法（an extreme lean approach）——估算的艺术，及其在软件开发过程中的价值。他虚构了一个Web 2.0创业公司作为例子，认为质量是无法协商且无需协商的，就产生了一些关键性的问题：

• 将专家的内在感觉转化成硬性的估算，会产生什么样的价值？
• 传统的项目计划是以变化因素很少为前提，而现实（就像天气一样）却复杂得多。
• 对基于时间的估算产生的价值产生置疑，因为这些估算用的时间毫无价值的加在了客户或这个软件的头上。

大家还需要注意一件事情，那就是：如果我们花时间去做详细估算（即在Sprint中，对每个Story的任务级别进行估算），那么我们每个迭代就会多花费半天或一天的时间，而且还没有产出。的确我们此时可以说我们有数据，而这些数据说明我们开发团队的估算是多么准确呀，但仅此而已。它无法缩短开发工作的时间，却浪费了真正做软件开发的时间的5~10%。因此，我想您可以做出一个不让开发更慢的决定啦！

Amit仍就打算使用速率作为项目交付时间的度量——举了某个总部在Redmond的软件制造商（译注：指微软）为例揶揄……

毕竟，哪些软件团队又对外宣称他们按估计发布日期准时发布了呢？近来，很多公司将他们的产品名称后冠之以年份，如Office 2007、Windows 2003、Pocket PC 2006。他们已经不打哑谜了，而只是说他们将在某一年交付产品，不再说到具体的发布日期。

总而言之，根据给出的这种精益方法以及敏捷对质量和可交付的价值的关注，作者提出了一些有关基于时间的任务级别估算能带给当事人多大价值的观点，并置疑它们的有效性。

查看英文原文：Accurate Estimates - the ultimate oxymoron?

译者简介：乔梁， BJUG成员，在IT领域工作多年，先后从事过软件开发、架构设计、技术管理等工作，目前从事项目管理工作。关心软件技术领域发展，对软件生命周期管理及过程改进方面的内容很感兴趣，对敏捷方法论亦有所了解。他的个人Blog为： http://blog.csdn.net/tony1130。为InfoQ中文站贡献内容，请邮件至 china-editorial[at]infoq.com。