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