最主要的观点在第二章人月神话。
就是Brooks法则:向进度落后的项目中增加人手,只会使进度更加落后。
Adding manpower to a late software project makes it later.
一、缺乏进度安排是造成项目滞后最主要的原因,容易出现问题的点:
- 错误的估计了项目进度。没有预估可能的风险,假设一切顺利的情况下,过于乐观的估计了项目进度。
- 错误地假设人和月可以互换,将进度和工作量互相混淆。 作者认为“用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话”。
- 项目经理通常不会有耐心持续地估计工作。
- 对进度缺乏跟踪和监督。
- 当意识到进度偏移时,下意识(以及传统)的反应是增加人力。这就像火上浇油一样,让事情会变得糟糕。
二、人月(容易出问题的第二点)。
人月可以互换仅存在于以下情况: 某个任务可以分解给参与人员,并且他们之间不需要相互交流。
项目沟通的负担主要有两部分: 培训和相互的交流。每个成员都需要进行技术、项目目标、总体策略以及工作计划的培训。
相互交流经常需要几个人一起开会协商,一同解决问题,沟通的时间会抵消任务量分解所产生的作用。
从而,添加更多的人手,实际上是延长了而不是缩短了时间进度。
三、其他
作者认为软件开发过程中要给系统测试留足够的时间,作者建议给测试留出进度一半的时间。因为实际的缺陷会比预料中多的多。
项目的进度可能会受限顾客要求的紧迫程度。可能会为了满足顾客期望的日期而造成不合理的进度安排。
项目经理要坚持自己的估计,确信自己的经验和直觉比从期望中派生的结果要强。