说不清的Brooks法则

布鲁克斯法则，据说是经典的管理定律之一。

布鲁克斯法则，据说是北卡罗来纳大学计算机科学教授Frederick P. Brooks，Jr.提出的经典理论！

为什么用个“据说”，因为这都是别人和我说的，所以我加上了这两个字！

“为推迟的软件增加人力将使得软件时间发布更晚。 这是因为后来者需要加快速度，同时还要与前任进行沟通，从而使得开发团队增加了更多的开发时间，这个时间超过了新增程序员所做的贡献。从理论上说，软件发展陷入僵局是可能的，此时开发团队极其庞大，以致所有时间都来互相沟通和重新决定，这样项目永远也不会完成。”

以上内容就是布鲁克斯法则的内容。 

说的对么？

答：非常对。

 

假定，一个项目两个人，可以在三天内完成，按照传统思想来考虑，如果项目变成三个人在做，那么只要两天就可以完成。

理论上是的！但可能么？

 

我们进行一些极端的假设，同样是两个人在三天内可以完成的项目，如果变成六个人的话是不是可以在一天内完成？依此类推，我们进行一个极端的假设，如果有六百人同时在做这个工作，是不是不到一小时的时间就可以完成？

理论上是的！但可能么？

 

肯定不可能！只有一把指甲刀，怎么能让两个人同时剪指甲？

当然，或许很多人要说，我以上的假设钻牛角尖，但我说的却是一个实际存在的情况。

 

在我之前的博文中提到了“抽风式管理”和“形象代言人”这两个概念，一旦我们的团队在“抽风式管理”的压榨之下，那么以上情况是很可能发生的！

在极端的情况下，我们不可能用两个程序员同时修改一个程序！双胞胎也不行！而且，也正如布鲁克斯法则中提到的，很多时候向一个已经在进行的项目中添加人手，并不意味着加快速度！如果新加入的人手一直处在候补状态，对进行中的项目有不亚于其他人的认识和了解，那么对加快开发进度或许是有帮助的！但除此之外，一个新人的加入，必然会推迟项目的进展，即便这个“新人”有一千年的开发功力也不行！因为“老人”们必须付出更多的时间和精力向“新人”介绍目前的开发状况，开发规约，以及一些细节，那就意味着更多的沟通成本将加入到项目之中。

 

以windows NT的开发团队做例子，NT的领头羊戴夫一直认为自己的团队可以胜任NT的开发，而且他觉得自己带一支20-30人的团队很好，因为大家完全可以坐在一个办公室里，用争吵的方式完成沟通！但当他的团队增加到250人的时候，发生了什么？团队中的每一个人都将更多甚至是绝大多数的精力用在了沟通上，人与人之间的沟通，小组与小组之间的沟通。

当然，我不是在说团队项目人手多，或者不断的添加人手就是错的。布鲁克斯法则所阐述的内容中，存在着一个最适合的点！就是一个项目在可实现的开发期限内，到底有多少成员组成合适！最理想的状态是“多一分则胖，少一分则瘦”！

 

很难！毕竟历史上的美女就那么几个，完美的团队也是！

换言之，一个软件开发团队的领导人，是不是明白布鲁克斯法则的意义，是一个关键，是不是能够看出其中的最适合的点，是另外一个关键！理所当然，“形象代言人”肯定不行！

 

自此以上，我都是在说布鲁克斯法则的优点，但它也存在着一个缺点！而这个缺点的关键就在于“人”：

 

“人”是根本，我国的伟大领导人们，都在阐述“以人为本”的硬道理。“人”是根本，也自然是一个开发团队中最重要、最根本的因素。

布鲁克斯法则中的理论，应该都是一种比较理想的状态，而忽略了人！试想，如果我们向一个已经延期的项目中添加的人手是臭皮匠，当然会延期，但如果我们向其中加入一个诸葛亮呢？

诸葛亮同志未出茅庐而知天下三分，所以成就了刘备！所以，向团队中添加人手更关键的一点是加入的人，是谁！

 

常言道，三个臭皮匠，顶个诸葛亮！集思广益是对的，但三个臭皮匠是顶不了诸葛亮的！永远不要妄想，三个水货就能写出一个高手水准的代码，三百个也不行。否则历史上也不会有纸上谈兵的赵括，也不会有老当益壮的廉颇。

这里，我想不需要对程序员这个聪明的群体做任何解释！

 

布鲁克斯法则，说不清！它是正确的，但人却是其中最大的影响因素，所以，布鲁克斯法则没有绝对，所以，我说不清！