《人月神话》（P3）越加人进度越慢

空泛的估算

编程人员有时和厨师一样&＃xff0c;某项任务的计划进度&＃xff0c;受限制与客户要求的紧迫程度&＃xff0c;然而紧迫程度并不能控制实际完成的情况。

例如&＃xff0c;约定两分钟内煎完一个鸡蛋&＃xff0c;看上去简单&＃xff0c;但实际上它无法在两分钟内完成&＃xff0c;顾客只能选择等待或者吃生鸡蛋。厨师的另一个选择是把火开大&＃xff0c;不过结果常常是得到一个更糟糕的煎蛋。

为了满足顾客期望而造成的不合理进度安排&＃xff0c;在软件领域中非常普遍。不科学的估算方法&＃xff0c;少的可怜的数据支持&＃xff0c;完全凭借产品经理直觉的判断&＃xff0c;这样的方式很难得出有力、可靠、低风险的评估。

显然&＃xff0c;我们有两种解决方案&＃xff1a;

采用科学的方法&＃xff0c;例如生产率图表、缺陷率图表、估算规则等
项目经理挺直腰杆&＃xff0c;坚持他们的估计&＃xff0c;确信自己的经验比客户期望进度要强得多

可是&＃xff0c;我们对自己的估计不确定&＃xff0c;因此在管理和客户的压力下&＃xff0c;我们常常缺乏坚持的勇气。

重复产生的进度灾难

当一个周期4个月的项目&＃xff0c;在第2个月的节点上进度没有达到要求&＃xff0c;此时项目经理可以做些什么呢&＃xff1a;

假设任务必须按时完成&＃xff0c;整体进度估算合理&＃xff0c;那么就指派更多的人手
假设任务必须按时完成&＃xff0c;整理进度估算偏少&＃xff0c;那么指派更多更多的人手
不削减任务&＃xff0c;确保工作能彻底完成&＃xff0c;重新安排进度
削减任务&＃xff0c;仔细认真的调整项目&＃xff0c;重新安排进度

前两种情况是灾难性的&＃xff0c;因为增加人手从三方面增加了项目必要的总体工作量&＃xff1a;

任务重新分配本身和所造成的工作中断
培训新人员
额外的相互沟通

而且毫无疑问的是&＃xff0c;增加人手所开发出的产品&＃xff0c;比没有增加人手而是重新安排进度所生产出的产品更差。向进度落后的项目中增加人手&＃xff0c;只会使得项目更加落后。

以上内容就是《人月神话》第二章——人月神话&＃xff0c;后两节所讲述的内容

作者反复论证了软件项目延期最主要的原因——缺乏合理的进度安排。读者不忍发问了“没有按时完成任务是因为时间太短”这难道不是诡辩吗&＃xff1f;

其实&＃xff0c;作者想要提醒的是那些制定项目进度的人。进度估算作为软件工程中十分重要的一环&＃xff0c;常常得不到应有的重视&＃xff0c;不全面的、不科学的、不负责任的进度安排时常发生。项目经理总会有意无意的犯下各种错误&＃xff0c;例如忽略测试阶段、盲目自信、缺少方法、缺乏勇气等等。这么说来&＃xff0c;软件项目延期的主要责任人也就是制定项目进度的人。

放到现实中来说&＃xff0c;作者的观点其实是有前提假设的&＃xff0c;那就是所有的程序员都拒绝加班&＃xff0c;所有项目都会指派一名项目经理&＃xff0c;所有客户都知道自己要什么。说不定国外的环境确实是这样的&＃xff0c;但是这三点假设在我们身边都是不成立的。

首先&＃xff0c;程序员无条件的加班让项目经理更加盲目自信&＃xff0c;为了能够接收到项目&＃xff0c;不断地妥协于进度紧张的客户。其次&＃xff0c;人员安排的混乱和欠缺&＃xff0c;大多数项目是不存在项目经理的&＃xff0c;甚至是由商务人员直接规划进度。最后&＃xff0c;也是最可怕的事情&＃xff0c;客户不清楚自己需要的是什么。

这些问题都发生在进度估算阶段之前&＃xff0c;但由于不是本书重点所以不再赘述&＃xff0c;以后会在其他书籍的导读中再来讨论这几个问题。

总之&＃xff0c;《人月神话》第二章作者通过严谨详实的论证&＃xff0c;得出了这样的结论&＃xff0c;多少有点偏袒程序员的意思&＃xff0c;难道项目延期的问题只在于安排进度的人吗&＃xff1f;