浅谈软件开发定律系列之布鲁克斯定律

  布鲁克斯定律：

     人月=人*月，月≠人月/人

     极端情况下，Brooks定律会出现这样的情况：“投入更多的人到一项延迟的工作上，可以导致该项工作更加延迟”。

Barry Bohem：可以将软件开发进度压缩25%，但是不能再多了
200/20/6X现象：
�C人数增加1倍，工期缩短20%，缺陷增加6倍

 

反思：
�C1 在实践中，我们是否经常通过给项目组增加人手的方式加快进度？
�C2 有哪些合理的加快进度的措施？

 

 

定律分析

 

    布鲁克斯定律（Brooks’Law）里面用了几个字眼“人、月”。是的，此布鲁克斯就是彼布鲁克斯，《人月神话》的作者。

 

    投入更多的人到一项延迟的工作上，可以导致该项工作更加延迟！这句话一笔点破IT行业的项目延期情况，以及项目经理为之头疼的项目计划进度。希望更多的老板能知道此类的道理。

    但是为什么这句话项目经理会有不同的意见？

    这就是投入的是新人还是老人的问题。如果一个团队10个人，在某一个阶段10个人分组，扩建为两个团队分别做不同的模块，那么，在某优先级高的项目中，一个组5个人搞不定，临时从另外一个组凑掉2个人来做事。

 

    因为实际上是老员工做老的模块，所以会给人一种增加人手就能快速推进工作的印象。

    但是增加新员工，实际上对软件开发来说，是非常失败的东西，新人进团队，常见的问题如下：

1、新人需要上手学习
2、一开始的时候，需要老手去指导他，这个阶段，老手的工作效率实际上是降低的
3、如果没有代码规范，你要重新交给他，在此之前，他的工作输出是负面的。
4、各个模块的设计思路，空手借过来的代码，需要重读、在别人的思路上继续工作，甚至重构。
5、组内沟通成本会呈几何级数增大：四个人可能只需要开碰头会，十个人就要正儿八经的填写日报、周报――因为一个ltm的精力有限，跟控不过来。

6、项目经理分心在管理事务上：人数多了，可是现在可以让他们做的工作一下子没有这么多，项目经理得要想办法安排工作给这些人都有事做。以免出现部分人闲置部分人牢骚的现象。这样子反倒会让项目经理没有心思在真正该做的事情上。
7、如果有人没事做，就会很害怕自己被裁员，就会做一些看起来像是工作的事情。戒是做一些抵销工作进度的事情。

    以上很多观点总结自《人月神话》：『Adding manpower to a late software Project makes it later.』引自The Mythical Man-Month.Chapter2 page25)

 

    所以，增加新人的做法是失败的。增加原团队中的人，是比较流行的方法，同时，也给人很多错觉：增加人手，是可以缩短项目周期的！

 

200/20/6X现象：
�C人数增加1倍，工期缩短20%，缺陷增加6倍
反思：
�C1 在实践中，我们是否经常通过给项目组增加人手的方式加快进度？
�C2 有哪些合理的加快进度的措施？

 

 问题解答：

 

     如果用一个例子来解释这种增加人手的方法。个人倾向于用篮球比赛。比如几年前的丹佛掘金，招来了AI，但是两个得分王并没有 把掘金的战绩提升上去。一个新人和已有团队的磨合，存在很大的风险点。

    在实践中，增加老人和增加新人的区别在上文已经论述过，在此不再赘述。针对常规的情况，我们可以把四个维度的事情作为一个四个坐标点：时间（快）、成本（省）、目标（多）、质量（好）。
 

    如何合理的加快项目进度？
    在通常的情况下，项目出现延期，或者要提前完成。在投入更多人力无效的情况下。还有哪两种选择？

1、放弃质量，带着很多问题发布版本。
2、减小目标，调整需求范围，规划跟多的迭代版本，分期实现功能。

    正常的选择就是“砍需求”，调整需求范围，能在短期内提供版本，供客户使用。

    当面对deadline时，怎么操作项目，能一目了然的看出团队的成熟度，当然，更重要的是看出老板对软件行业的理解度。

    关于项目进度：可以理解完成90%就等同于完成50%。即：90%的工作等于一半。