为什么要在一个较晚的项目中增加更多的人会使其变得更晚？

这是一个很普遍的谚语，那就是在后期的项目中增加更多的程序员会使情况变得更糟。为什么是这样？

介绍费用

必须向每个新开发人员介绍代码库和开发过程，这不仅需要新人花费时间，而且还需要[一名]高级开发人员的帮助（指导他们完成构建过程，解释测试过程，帮助他们）以及代码库中的陷阱，更详细的代码审查等）。

因此，您添加到项目中的新开发人员越多，花费的时间就越多，这样他们才能真正为项目做出贡献。

除了其他答案：另一个要考虑的因素是沟通。

完整的图表对于团队中的交流渠道数量（最常见的情况）是最坏的情况。可以想象，仅增加一名开发人员就可以大大增加沟通渠道。有了更简化的沟通方式，影响就更少了……但是它仍然会加总。

最初颁布该法的书中引用的问题，《神话人月》是交流。他首先说：

只有当任务可以在许多工人之间分配且彼此之间没有通信时，人和月份才是可互换的商品。收割小麦或采摘棉花是正确的。甚至对于系统编程也不是正确的。

他确实提到培训是问题的一部分：

交流的额外负担由两部分组成：培训和交流。必须对每个工人进行技术，工作目标，总体策略和工作计划方面的培训。该培训不能划分，因此这部分工作随工人人数线性变化。

...但是请注意，互通是更大的因素：

由于软件构建本质上是系统工作-在复杂的相互关系中进行的练习-通信工作量很大，并且它很快支配了由分区带来的单个任务时间的减少。增加更多的人会延长而不是缩短时间表。

还值得注意的是，Fred Brooks（作者）确实有背景知道他在说什么。这本书的大部分内容基于他管理IBM OS / 360项目的经验。尽管数十年来坚持不懈地倡导各种方式的“改进”管理方法，并且有些人甚至在起步时甚至提出了很酷的名字（eXtreme，Agile，Scrum等），但从那时起本质¹似乎并没有改变。

¹对于“本质”的定义，见同一作者的“没有银弹：根本和次要软件工程”，包括在20 ^日的周年纪念版人月神话。

这不仅仅是格言。这是可验证的。看看布鲁克斯的《神话人月》。

这是关于这个问题的一些想法...

• 需要使用当前资源来加快新资源的使用，以加快项目的进度。
• 新资源可能不熟悉代码库，因此需要更多时间来适应代码。

现在，添加新的测试资源可能不是一个坏主意……这可能会加快测试过程（如果您的测试用例编写得很好），是的，使用测试工具也将有所帮助。

因为编程不是基本的生产线工作。加快软件项目的进度需要时间。新人需要问很多问题，这会导致生产力下降（例如，新人学习，老人教他们->没有完成任何实际工作）。

为了简化它，请设想一个相对简单的单人项目，该项目计划进行1周：在星期四，您意识到它不会按时完成，相反，一个程序员需要6-7天才能完成之5。如果此时添加另一个程序员，则他们将需要与Programmer1一起工作至少几个小时或一天左右，询问许多问题以加快速度，等等。您可能不会一周剩余时间内的任何净正生产率。新的程序员可能还会引入一些额外的错误（因为他们将不像程序员1那样了解现有代码），因此将使实现和测试周期再推迟一两天。该项目将轻松完成整整两个工作周，而不是原来的一周！

弗雷德·布鲁克斯（Fred Brooks）回答了这个问题，写了一整本书《神话人月》。

这是快速n脏的版本：

1）您可以将一个项目分解为不同的部分以分配给更多的程序员是有限制的。

2）将项目划分给更多的人，可以增加协调应用程序所有部分所需的通信量。更多的交流=更多的工作。

3）对于您添加到项目中的每个人，您都添加了多个必须导航到团队的沟通渠道。此数字呈几何增长，并增加了必须进行的通信量。更多的交流=更多的工作。

4）添加每个团队成员时，会有一个“ J曲线”。就是说，现有的生产资源必须花时间让新人们加快他们原本可以花在项目上的速度。最终，您可能会增加容量，但是这会暂时降低项目速度。在项目中越晚，必须学习的内容越多，因此效果越明显。

我没有提到的另一个因素是某些任务需要按特定的顺序完成。在完成任务3之前，您不能执行任务4，因为它依赖于3。雇用某人同时执行任务3来同时执行任务4并没有好处。通常是在项目结束时，那些需要先完成其他任务的任务就是剩下的任务。

它们通常也是一些需要完成的最复杂的任务，正是这些任务需要对整个设计有最好的了解，以避免破坏已经完成的工作。他们通常还需要最广泛的业务领域知识。经过几个月的工作，我也许可以在一周或更短的时间内完成任务。一个新来的人会花一个多星期的时间来加快速度（并把我从我的任务中拉出来，以便有足够的时间来回答问题），即使非常熟练的人也可能花更长的时间来完成任务。不是因为他或她不称职，而是因为对项目或数据库后端的实际结构不熟悉。

对我一直有用的格言是，一个月内不能让九个女人生一个孩子。

我还建议使用DeMarco和Lister的“ Peopleware”。

DeMarco的“ The Deadline”以轻松愉快且易于阅读的方式介绍了此问题以及其他许多软件项目管理的谬论和谬论。

它还深入研究了从事项目/团队工作的人员的动态，并详细介绍了诸如沟通和介绍之类的工作方式如何消耗了团队的可用工作时间。

这些书非常便宜，我建议您拿起它们（Amazon或The Book Depository拥有它们）并阅读。简短的回答无法真正解决所提出的问题。

因为没有人花时间对以下方面进行深思熟虑，计划性的，经过测试的过程：雇用，培训，开发和监督程序员，更不用说使他们适应特定项目了。

如果您正在管理一个开发人员团队，那么您现在应该与想要招聘的人员建立多个联系人。加入开发人员组。

您能以多快的速度安装全新的开发机器并准备就绪？

您是否曾经通过向其他项目的开发人员展示过您的项目文档和规范来进行测试？他们是否看过它并确定他们可以在必要时开始从事该项目？

最新的项目进度如何？

节省雨天，因为当项目落后时，更像是飓风。

除了交流问题（我认为其他所有答案都在讨论）之外，添加到项目中的人也很可能创建错误，因为他们还不太了解代码。

每当我被添加到项目中时，我总是非常努力地避免破坏事物。这意味着我一开始修复起来要慢得多。

我想指出到目前为止，其他答案完全忽略了某些内容。

当人们被添加到一个较晚的项目中时，整个组织通常都出了很多问题。管理层和客户都不满意。人们承受着继续前进的压力。事情很紧张。

现在想象您在那个团队中。显然，这都不是您的错。规划（没有一个是您的）过于乐观。所有错误的决定都是在没有咨询您的情况下做出的。您正在尝试最好地利用它，突然有一群新人涌入。这传达了什么信息？

楼上的人显然对你失去了信心。他们叫大个子男孩来弥补你的麻烦。

您还会继续努力取得成功吗？还是……您会更沮丧，还是宁愿看到整个事情崩溃？

慢慢来 ：-）。