Brooks法则:“向进度落后的项目中增加人手只会使进度更加落后”

Brooks法则:“向进度落后的项目中增加人手只会使进度更加落后”_第1张图片

A:“离系统上线只有3个月时间了,还有这么多功能没有做,怎么办?”

B:“可以从隔壁团队抽调一个工程师来帮忙吗?领导对这个项目很重视。”

A:“好,应该可以抽调两个来,他们都是经验丰富的程序员,争取在1个月内完成。”

最后他们成功地把项目拖延了4个月,比没有添加人手的预计还要晚。

向进度落后的项目中增加人手只会使进度更加落后。

——《人月神话》里面提到的Brooks法则

软件项目的特征

软件项目的估算和进度安排一直是个难题,无论多么努力都很难保证精确,总需要在过程中不断调整,要么重新安排进度,要么削减任务,但追加人手要慎之又慎。首要原因还是软件项目团队需要高强度的沟通和协助,不是单纯的工作组。

Brooks法则:“向进度落后的项目中增加人手只会使进度更加落后”_第2张图片

沟通接口增加。每增加一个人,就会增加n个接口。如果项目中有n个工作人员,则有(n2-n)/2个项目交流的接口,团队组织的目的是减少所需的交流和合作的数量,清理交流障碍。

培训时间和额外的测试。不培训是灾难性的。无论多么能干员工,都需要接受一位或者多位项目中原有员工的培训,还需要重新划分任务,安排系统测试,更别提刚刚上手的员工所带来的必不可少的混乱(沟通摩擦、代码上的bug)和原有员工填补混乱的时间。

项目估算的原则

小心使用人月,人数和时间是两个独立要素,不能互相替代,你不能把“2个人花2个月”变成“4个人花1个月”。人数和时间可以互换仅仅适用于如下情况:如果某个任务可以分解给参与人员,并且他们之间不需要相互交流——在软件项目中这几乎不可能。

对项目经理而言,仍然存在很强的诱惑去添加更多人手,如果非要这样做,请在早期做,而不是等到进度落后才添加。


文章转自我的公众号,欢迎关注:


你可能感兴趣的:(Brooks法则:“向进度落后的项目中增加人手只会使进度更加落后”)