人月神话

乐观主义

创造性活动分为三个阶段: 构思、实现和交流

只有在实现的过程中,才能发现构思的不完整性和不一致性

由于编程的高可控性,我们会认为实现很顺利,因此造成了乐观主义的弥漫,而构思是有缺陷的,因此总会有bug

大型的编程工作,或多或少包含了很多任务,某些任务间还具有前后的次序,从而一切正常的概率变得非常小,甚至接近于无

人月

用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话

编程中近乎不可能存在人员数量和时间可以相互替换

  • 任务次序上的限制不能分解

Resize icon

  • 子任务之间需要相互沟通和交流的任务,沟通所增加的负担由两个部分组成,培训和相互交流,培训随人员的数量呈线性变化,相互之间交流按照 n(n-1)/2 递增

Resize icon

所增加的用于沟通的工作量可能会完全抵消对原有任务分解所产生的作用,甚至会导致延长

系统测试

项目排期占比

  • 1/3 计划
  • 1/6 编码
  • 1/4 构件测试和早期系统测试
  • 1/4 系统测试,所有的构件已完成

很少项目允许为测试分配一半的时间,但大多数项目的测试实际上是花费了进度中一半的时间

不为系统测试安排足够的时间简直就是一场灾难因为延迟会发生在项目快完成的时候,坏消息没有任何预兆,很晚才出现,此时的延迟具有不寻常的、严重的财务和心理上的反应,甚至会导致活动延误,付出相当高的商业代价,远远高于其他开销。因此,在早期进度策划时,允许充分的系统测试时间是非常重要的

空泛的估算

现状: 受限于顾客要求的紧迫程度,非阶段化方法的采用,少得可怜的数据支持,加上完全借助软件经理的直觉

解决方案:

  • 开发并推行生产率图表、缺陷率、估算规则等
  • 在基于可靠基础的估算出现之前,项目经理需要挺直腰杆,坚持他们的估计, 确信自己的经验和直觉总比从期望派生出的结果要强得多

重复产生的进度灾难

避免小的偏差(Take no small slips) 在新的进度安排中分配充分的时间,以确保工作能仔细、彻底地完成,从而无需重新确定时间进度表

重复生成的工作量 不论在多短的时间内,聘请到多么能干的n个新员工,都需要接受一位有经验的职员的培训。如果培训需要一个月的时间,那么n+1个人月会投入到原有进度安排以外的工作中。原先划分的任务要重新拆分某些已经完成的工作必定会丢失,系统测试必须被延长

向进度落后的项目中增加人手,只会使进度更加落后。(Adding manpower to a late software project makes it later)

项目的时间估算 任务顺序和子任务的数量产生的人员数量,推算出进度时间表,该表安排的人员较少,花费的时间较长(唯一的风险是产品可能会过时)。分派较多的人手,计划较短的时间,将无法得到可行的进度表

在众多软件项目中,缺乏合理的时间进度是造成项目滞后的最主要原因,它比其他所有因素加起来的影响还要大