BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

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

| 作者 Ben Hughes 关注 0 他的粉丝 ,译者 乔梁 关注 7 他的粉丝 发布于 2007年5月23日. 估计阅读时间: 2 分钟 | 如何结合区块链技术,帮助企业降本增效?让我们深度了解几个成功的案例。

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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT