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

作者 Ben Hughes 译者 乔梁 发布于 2007年5月22日

领域

过程 & 实践,

架构 & 设计

主题

质量交付 ,

质量 ,

交付价值 ,

软件工匠 ,

值和度量 ,

企业级敏捷 ,

精益 ,

敏捷技术 ,

敏捷 ,

生产力 ,

简单性

分享到

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?

译者 乔梁 有十多年软件开发及项目管理经验，专注于提高软件企业提高交付能力。现任百度项目管理部高级架构师。

相关厂商内容

保持某些系统的高可用性，是一些企业的重中之重，如何设计？

海量数据处理，海量视频分发，架构热点难点，尽在架构师峰会！

相关赞助商

ArchSummit全球架构师峰会报名启动！7折优惠，5月31日截止！