为什么开发人员不能估算时间？

编者按：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》一书吧。

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

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