布鲁克斯法则

布鲁克斯定律是关于软件项目管理的一项观察，根据该观察，向落后于进度的软件项目增加人力会使其延迟更长的时间。

根据布鲁克斯本人的说法，该法律过于简单化了，但它抓住了一般规则。 Brooks 指出了解释其为何如此运作的主要因素：

• 添加到项目中的人员需要一些时间才能变得富有成效。 布鲁克斯将此称为加速时间。 软件项目是复杂的工程工作，项目的新员工必须首先了解他们之前的工作； 这种教育需要转移已经在项目上工作的资源，暂时降低他们的生产力，而新员工还没有做出有意义的贡献。 每个新员工还需要融入一个由几名工程师组成的团队，这些工程师必须每天在代码库的专业领域内对新员工进行培训。 除了减少有经验的工人的贡献（因为需要培训），新工人甚至可能做出负面贡献，例如，如果他们引入错误使项目离完成更远。
• 通信开销随着人数的增加而增加。 由于组合爆炸，不同通信渠道的数量随着人数的增加而迅速增加。 从事同一任务的每个人都需要保持同步，因此随着更多人的加入，他们会花费更多时间来了解其他人在做什么。
• 为高度可分割的任务添加更多的人，例如在酒店打扫房间，可以缩短总的任务持续时间（直到额外的员工互相妨碍）。 但是，其他任务包括软件项目中的许多专业是不可分割的； 布鲁克斯用另一个例子指出了这种有限的可分性：虽然一个女人需要九个月才能生一个孩子，但九个女人不能在一个月内生孩子。

布鲁克斯法则中有一些关键点允许例外情况并为可能的解决方案打开大门。

首先要注意的是，布鲁克斯法则仅适用于已经延迟的项目。 如果在此过程中更早地添加人员，则可以使项目重新受到（或保持）控制。 确定项目是否真的延迟，或者时间表是否最初过于乐观也很重要。 进度安排错误是造成大量项目延迟的原因。 更正进度表是为项目完成制定有意义且可靠的时间框架的最佳方式。

还必须考虑添加到项目中的人员的数量、质量和作用。 规避超支项目法律的一种简单方法是增加比需要更多的人，这样额外的能力就可以补偿培训和沟通的开销。 可以以更少的培训开销增加优秀的程序员或专家。 可以添加人员来执行与项目相关的其他任务，例如质量保证或文档编制； 鉴于任务是明确的，加速时间被最小化。

良好的细分有助于xxx限度地减少团队成员之间的沟通开销。 较小的子问题由较小的团队解决，xxx团队负责系统集成。

要使这种方法起作用，首先必须正确地进行问题分割； 如果做得不正确，这可能会使问题变得更糟，而不是更好，因为这会阻碍处理实际上紧密耦合的问题部分的程序员之间的沟通，即使项目计划已经规定他们不是。

细分的一个例子是简化工作分配的设计模式，因为整个团队可以在该模式提供的框架内完成自己的工作。 设计模式定义了程序员遵循的规则，通过使用标准语言简化了通信，并提供了一致性和可扩展性。

百慕大计划中，一个项目的大多数开发人员被移除（发送到百慕大），其余的则被留下来完成软件，被建议作为规避布鲁克斯法律的一种方式。