空泛的估算

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

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

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

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

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

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

重复产生的进度灾难

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

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

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

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

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

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

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

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

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

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

总之,《人月神话》第二章作者通过严谨详实的论证,认为缺乏合理的进度安排是项目延期的主要原因。多少有点偏袒开发人员的意思,造成项目延期的原因肯定不止是估计错误那么简单。

转自 fourn - learnku.com

文章目录