截止日期近在眼前，工作却积压了一大堆时，几乎每个人都会有类似的想法：多加几个人，工作是不是就能早点完成？毕竟，像搬家搬行李或耕田这样人手越多就完成得越快的情况，确实是存在的。
然而在软件开发中，常常发生的却恰恰相反：给已经延期的项目再增加人手，进度反而会更加延误。这一经验法则以最早总结出它的人的名字命名，称为“布鲁克斯定律（Brooks's Law）”。
本文将循序渐进地梳理布鲁克斯定律产生的背景、“人月”这一单位中隐藏的错觉、增加人手也无法加快进度的原因与沟通路径成倍增加的算法，以及规避该定律的方法和其局限。
布鲁克斯定律的原理与运用
定律的诞生与人月的错觉
弗雷德里克·布鲁克斯（Frederick P. Brooks Jr.）是一位计算机科学家，20世纪60年代在美国IBM领导了大型计算机System/360及其操作系统OS/360的开发。OS/360在当时是数一数二的大型软件项目，虽然投入了大量开发人员，但进度却一再拖延。
布鲁克斯以这段经历为基础，于1975年出版了《人月神话》（The Mythical Man-Month）一书。他在书中写下了“向进度落后的软件项目增加人手，只会使它更加落后（Adding manpower to a late software project makes it later）”这句话，这句话后来被称为布鲁克斯定律。
人月（Man-Month）是表示一个人一个月工作量的单位。按照这种算法，一项10人月的工作，可以由一个人用十个月、或由十个人用一个月完成。布鲁克斯指出，这种计算只有在工作可以均等分配、彼此无需沟通的情况下才成立，而认为人和月可以相互替换的想法本身就是一种错觉。
半个世纪后的今天，这本书仍被视为软件工程的经典。1995年出版的20周年纪念版中，还收录了《没有银弹》（No Silver Bullet）一文，其内容是：不存在能一举大幅提高生产力的神奇方法。布鲁克斯因对计算机体系结构和软件工程的贡献，于1999年获得了图灵奖（Turing Award）。
为什么增加人手也快不起来
给延期的项目加入新人，眼下看起来像是人手增加了。但实际上，由于以下原因，进度往往会拖得更久。
（1）熟悉需要时间
新来的人必须熟悉项目的结构、迄今为止的决策和工作方式，才能独当一面。在此期间，原有成员不得不停下自己的工作去教新人，因此最初几周整体速度反而会下降。
（2）有些工作无法分割
有些工作无论增加多少人，都必须按既定顺序进行。布鲁克斯用这样一句话来说明：“生一个孩子需要九个月，不管安排多少位女性都一样。”
（3）协调工作增加
工作分得越细，把分出的各部分重新拼接起来、确认彼此是否吻合、统一想法的工作就越多。人越多，花在这种协调上的时间增长得越快。
这三点叠加在一起，原有的进度会在新人开始独当一面之前就先崩溃。所以，试图用人数来弥补延误的做法，结果往往会造成更大的延误。
沟通路径成倍增加的算法
最能说明布鲁克斯定律的是沟通路径的数量。如果团队成员之间都需要相互沟通，那么设人数为n，沟通路径就有n(n-1)/2条。人数虽然是一个一个地增加，路径数却增长得快得多。
- 3人团队（Team of 3）：沟通路径为3条。
- 5人团队（Team of 5）：沟通路径增加到10条。
- 10人团队（Team of 10）：沟通路径达到45条。
- 20人团队（Team of 20）：沟通路径多达190条。
也就是说，人数翻一倍，路径就增加近四倍。会议、消息和确认工作随之增加，而真正用于编写程序的时间却在减少。到了某个时刻，就会出现人越多、整体生产力反而越低的情况。
规避定律的方法与局限
布鲁克斯定律并不是说不要增加人手，而更接近于说要慎重决定何时以及如何增加。在实际开发现场，人们会用以下方法来避开这个陷阱。
- 小团队（Small Team）：让每个团队保持较少人数，以减少沟通路径。亚马逊的“两个披萨团队”原则就是著名的例子。
- 模块化（Modularity）：把工作分成彼此独立的部分，并明确规定各部分之间的约定，减少团队之间需要交流的内容。
- 尽早增员（Early Staffing）：如果需要人手，不要等到进度延误之后，而是在项目初期就加入，以确保有熟悉的时间。
- 调整范围（Scope Cut）：如果已经延期，与其增加人手，不如削减功能或重新安排进度，这样往往更好。
不过，这一定律也有局限。布鲁克斯本人后来也承认，这一定律是过度简化的说法。对于测试或编写文档这类容易细分的工作，或者已经很了解项目的人加入时，增加人手确实也能加快进度。在协作工具和自动化高度发达的今天，沟通所需的精力比过去减少了，因此该定律作用的强弱取决于团队和工作的性质。
归根结底，布鲁克斯定律提醒我们：工作的速度不仅仅由人数决定。在增加人手之前，先看看工作如何划分、人与人之间如何衔接，这正是按期完成开发的第一步。
