布鲁克斯法则(Brook's Law)也叫Brooks法则是指一种实践，应用全面、严密的方法来描述组织之流程、信息系统、人员和组织子单元的当前或未来结构，以便其与组织的核心目标和战略方向保持一致。
目录 |
布鲁克斯法则是指投入更多的人来开发一个紧急的项目只会让进度更慢。更多并不意味着更好，有些事最好是一个人来干。
布鲁克斯法则是由被认为是“IBM 360系统之父”的Frederick P. Brooks，Jr提出的，他认为：向进度落后的项目中增加人手，只会使项目更加落后。例如“三个和尚没水吃，厨师太多做坏汤。”
Frederick P. Brooks，Jr.是北罗莱纳大学Kenan-Flagler商学院的计算机科学教授。Brooks被认为是“IBM 360系统之父”，他担任了360系统的项目经理，以及360操作系统项目设计阶段的经理。凭借在上述项目的杰出贡献，他、Bob Evans和Erich Bloch在1985年荣获了美国国家技术奖（National Medal of Techology）。早期，Brooks曾担任IBM Stretch和Harvest计算机的体系结构师。
在查布尔希尔，Brooks博士创立了计算机科学系，并在1964至1984年期间担任主席。他曾任职于美国国家科技局和国防科学技术委员会。Brooks目前的教学和研究方向是计算机体系结构、分子模型绘图和虚拟环境。
布鲁克斯是上世纪60年代IBM System/360的操作系统OS/360的开发负责人，这之后基于当时的经验写了人月神话一书。
这是描述大规模软件开发难度的一本划时代的书。看下面的示例。有这样一个项目需要12个人月，那么3个人4个月就能完成该任务。然后，在每个月设定观测点A/B/C/D。
但是一个月就需要结束的A结果花了两个月完成。这相比于预估时已经是两个月之后了。怎么办？管理者有下面的对策。
那么，应该采用什么方法呢。最开始的二个方法，不修改工作目标和工作进度表的话最初4个月完成目标的期望就破灭了。
假如追加2个人，这两人的培训成本，3人完成的工作用5个来做，就需要重新安排工作，这些成本没有被追加到估算中，结果的话最终期限无法完成。追加6个人的情况，这种成本加的更多。
这就是布鲁克斯法则：追加人员到延迟的项目更会影响项目的进度。如布鲁克斯所写的那样，无法按进度完成工作的话，只能降低工作目标作业。
首先，我们对估算技术缺乏有效的研究，更加严肃地说，它反映了一种悄无声息，但并不真实的假设——一切都将运作良好。
第二，我们采用的估算技术隐含地假设人和月可以互换，错误地将进度与工作量相互混淆。
第三，由于对自己的估算缺乏信心，软件经理通常不会有耐心持续地进行估算这项工作。
第四，对进度缺少跟踪和监督。其他工程领域中，经过验证的跟踪技术和常规监督程序，在软件工程中常常被认为是无谓的举动。
第五，当意识到进度的偏移时，下意识（以及传统）的反应是增加人力。这就像使用汽油灭火一样，只会使事情更糟。越来越大的火势需要更多的汽油，从而进入了一场注定会导致灾难的循环。
第二点中提到的关于人月不可互换。举个例子就是说:有一个10人月工作量的项目不能单纯的分配个5个人用2个月的时间来完成。因为程序员在工作当中还需要交流的时间，各子项目间还可能会有依赖关系，因此本来10人月的项目分配给5个人之后，它的实际成本就提升了。
有人可能会说一个人做就可以了，但为了节省时间，在规定的时间里完成项目，还是需要团队合作的。
第三点:为了更有效的实施这一点，我们需要使用一个版本控制工具，比如说:SVN。还需要设置检查点，里程碑，以及基线，从而准确的跟踪项目进度。
第五点:当项目延后而增加人手，导致的结果却是负面的。为了按期完成任务而增加新人，你需要从原来的项目组中调配人员来培训新人，而且根据第二点，人员的增多，无形中也加大了任务开销，最后导致项目难以控制。
A：“离系统上线只有3个月时间了，还有这么多功能没有做，怎么办？”
B：“可以从隔壁团队抽调一个工程师来帮忙吗？领导对这个项目很重视。”
A：“好，应该可以抽调两个来，他们都是经验丰富的程序员，争取在1个月内完成。”
最后他们成功地把项目拖延了4个月，比没有添加人手的预计还要晚。
——《人月神话》