《人月神话》(P3)越加人进度越慢

空泛的估算

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

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

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

显然,我们有两种解决方案:

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

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

重复产生的进度灾难

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

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

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

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

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

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

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

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

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

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

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

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

上一篇:Robot Framework之创建变量和执行用例


下一篇:触屏网站如何实现返回并刷新