布鲁克斯定律:
人月=人*月,月≠人月/人
极端情况下,Brooks定律会出现这样的情况:“投入更多的人到一项延迟的工作上,可以导致该项工作更加延迟”。
Barry Bohem:可以将软件开发进度压缩25%,但是不能再多了
200/20/6X现象:
–人数增加1倍,工期缩短20%,缺陷增加6倍
反思:
–1 在实践中,我们是否经常通过给项目组增加人手的方式加快进度?
–2 有哪些合理的加快进度的措施?
定律分析
布鲁克斯定律(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现象:
–人数增加1倍,工期缩短20%,缺陷增加6倍
反思:
–1 在实践中,我们是否经常通过给项目组增加人手的方式加快进度?
–2 有哪些合理的加快进度的措施?
问题解答:
如果用一个例子来解释这种增加人手的方法。个人倾向于用篮球比赛。比如几年前的丹佛掘金,招来了AI,但是两个得分王并没有 把掘金的战绩提升上去。一个新人和已有团队的磨合,存在很大的风险点。
在实践中,增加老人和增加新人的区别在上文已经论述过,在此不再赘述。针对常规的情况,我们可以把四个维度的事情作为一个四个坐标点:时间(快)、成本(省)、目标(多)、质量(好)。
如何合理的加快项目进度?
在通常的情况下,项目出现延期,或者要提前完成。在投入更多人力无效的情况下。还有哪两种选择?
1、放弃质量,带着很多问题发布版本。
2、减小目标,调整需求范围,规划跟多的迭代版本,分期实现功能。
正常的选择就是“砍需求”,调整需求范围,能在短期内提供版本,供客户使用。
当面对deadline时,怎么操作项目,能一目了然的看出团队的成熟度,当然,更重要的是看出老板对软件行业的理解度。
关于项目进度:可以理解完成90%就等同于完成50%。即:90%的工作等于一半。