[转载]为什么开发人员不能估算时间?

| 分类 网文  | 标签 编程 

Ashley Moran 是一名软件开发人员,最近在其关注的邮件列表中看到了一些有趣的观点,所以他做出了相应回应。(以下是全文)一些有趣的观点出现在我所关注的邮件列表中。下面是其中的一些。原始评论将以蓝色字体显示,下面是我的回应。这不是对相关问题的彻底看法,只是我所想到的一些相关的回应。注:我已加以编辑,以改善流程(flow),并加以阐述。

在软件开发中,我们不能对任何单独的任务作出时间的估算,是由于工作性质是创造新知识。

  软件开发的目标是实现流程(Process)自动化。只要一个流程实现了自动化,便可以针对大多数情况在可预期的时间内反复运行。源代码就好像生产蓝 图,而电脑就好像生产工厂,输入(数据)好像原材料,输入(数据)就像制成品。而使用另一种类比,星巴克可以重复迅速地制作咖啡的原因就在于他们花费很多 时间在流程的设计上,使得该流程成为了一个复杂且昂贵的作业。星巴克的个人经营者不必再去重新研究该流程,只需买下此蓝图便可。我会让各位读者练习推断我 对COSTA咖啡制作过程的意见。

  事实上,不可预期的开发时间并不总是坏事,因为它所带来的价值也是如此。一款成功的软件可以制造或节省的价值远超过其成本。Tom DeMarco之所以赞成关注高成本项目,正是基于这个原因。能注意到这点,需要一种价值增长的理念,而不是广泛而又普遍的成本控制理念。这是很重要的问 题。

  目前为止,Don Reinertsen的《Principles of Product Development Flow / 产品开发流程原理》,是我所看过的对可变性与为价值而开发的最好解释,该原理在日常流程管理中大量使用PatchSpace Bible。我所说的“目前为止最好的”是指超越我所看过的其他解释一个档次,不包括约束理论(Theory of Constraints)的著作。

  这就是我的最近开发项目的数据。直方图中的R表示5个小时的量:横轴表示的是User Case 的持续时间——0-5小时,5-10小时,等等;纵轴表示的是占此时续时间的User Case数量。我以90分钟为间隔,工作并将其记录在Wave上,这样我们就能清楚地知道任务持续时间。

  我们这么做既为了与客户沟通,又为了账单。结果是:我们的开发时间的可预知程度跟放射性衰变一样,但却是始终如一的辐射。可估计的相关数据少得可怜,我拒绝估计个别任务的的时间,因为这会产生误导,但是我们有足够数据进行合计。

  经验法则:接受开发人员的估算意见,但是要在两倍的基础上再加一点时间

  两倍加一点法则很有趣。经理开始运用此法则时,多长时间他会提前完成一次?我们通常太过注重超支。如果一个团队未能提前完成任务的一半。他就要增加估 计时间,这意味着拿开发周期与项目进度做交易。周期往往比可预测性更重要,因为它意味着更早地进入市场。同样看看Reinertsen的作品,数字会以与 数量级不同的规律出现。

  并且,这是关键链(Critical Chain)项目管理的基础,这会将项目估计时间二等分,把剩余时间(添补单独项目)放在最后,作为“项目缓冲时间”。这就意味着帕金森定律不会导致单独 任务无规律地扩张。尽管我不觉得关键链是软件行业的一个合适的方法,但作为开发工作的内容,它可作为反馈与学习提高的工具,可明显改善计划。

  通常人们只是估计时间

  不仅开发人员估计不好。每个人都会遇到临场发挥(即兴应付)的问题,因为那是他们没从未做过的事,所以在完成之前,他们无法准确地作出判断。

  作为一个群体,我们应避免这一点。不知道就是不知道,一定要说出来。相比于无法估计,那些能够定期了解任务进度,从而意识到风险(并选择继续投资)的 客户,会给予团队更多的信任。这是事实!我是认真的,不用只相信我的话,看看David Anderson的《Kanban》一书吧。

  估算是一个很重要的技能,应该在初级开发人员中广泛教学

  我提出了一个替换方案:我们需要教给初级开发人员的是完成的意义。如果估计问题已经够糟糕了,在一些不确定的点找出未完成的某些东西(也许是匆忙地兑 现承诺…我的意思是估计判断!)不仅会打乱时间的估计,还会打乱所进行的工作的日程。这是常有的事,并且会给一个开发团队的地位造成重大损失。

  译文出处:伯乐在线 - 职场博客 - 程序员
  译文链接:http://www.jobbole.com/entry.php/689
  原文:Ashley Moran  文章推荐:关关  翻译:伯乐在线 敏捷翻译 - 高志翔

转自:http://www.cnbeta.com/articles/141947.htm
点评:在理。


上一篇     下一篇