Brooks法则“向进度落后的项目中增加人手只会使进度更加落后”A“离系统上线只有3个月时间了还有这么多功能没有做怎么办”B“可以从隔壁团队抽调一个工程师来帮忙吗领导对这个项目很重视。”A“好应该可以抽调两个来他们都是经验丰富的程序员争取在1个月内完成。”最后他们成功地把项目拖延了4个月比没有添加人手的预计还要晚。向进度落后的项目中增加人手只会使进度更加落后。——《人月神话》里面提到的Brooks法则软件项目的特征软件项目的估算和进度安排一直是个难题无论多么努力都很难保证精确总需要在过程中不断调整要么重新安排进度要么削减任务但追加人手要慎之又慎。首要原因还是软件项目团队需要高强度的沟通和协助不是单纯的工作组。沟通接口增加。每增加一个人就会增加n个接口。如果项目中有n个工作人员则有(n2-n)/2个项目交流的接口团队组织的目的是减少所需的交流和合作的数量清理交流障碍。培训时间和额外的测试。不培训是灾难性的。无论多么能干员工都需要接受一位或者多位项目中原有员工的培训还需要重新划分任务安排系统测试更别提刚刚上手的员工所带来的必不可少的混乱沟通摩擦、代码上的bug和原有员工填补混乱的时间。项目估算的原则小心使用人月人数和时间是两个独立要素不能互相替代你不能把“2个人花2个月”变成“4个人花1个月”。人数和时间可以互换仅仅适用于如下情况如果某个任务可以分解给参与人员并且他们之间不需要相互交流——在软件项目中这几乎不可能。对项目经理而言仍然存在很强的诱惑去添加更多人手如果非要这样做请在早期做而不是等到进度落后才添加。