一个月后我需要这个孩子-给我送九个女人！

在什么情况下（如果有的话），将程序员添加到团队中实际上会加速已经很晚的项目的开发吗？

确切的情况显然是针对您的项目的特定情况（例如，开发团队，管理风格，流程成熟度，主题难度等）。为了更好地说明这一点，以便我们可以简单地大幅度地简化它，我将重申您的问题：

在什么情况下（如果有的话），可以将团队成员添加到一个运行较晚的软件开发项目中，从而导致实际发货日期的减少，其质量水平是否等于允许现有团队工作直到完成的质量水平？

我认为有许多事情是必要的，但还不足以使事情发生（没有特定的顺序）：

• 建议添加到项目中的个人必须具有：
  • 至少对项目的问题领域有合理的了解
  • 精通项目的语言和他们将用于完成任务的特定技术
  • 他们的能力必须/不应该分别比现有的最弱或最强的成员低或高得多。弱小的成员将使您现有的员工陷入三级问题，而一个过强的新人则会破坏团队的工作方式和做错了事。
  • 有良好的沟通能力
  • 积极进取（例如能够独立地工作而不强迫）
• 现有团队成员必须具有：
  • 高超的交流技巧
  • 出色的时间管理技能
• 项目负责人/管理人员必须具有：
  • 良好的优先级划分和资源分配能力
  • 现有团队成员的高度尊重
  • 高超的交流技巧
• 该项目必须具有：
  • 完善，完整且有据可查的软件设计规范
  • 关于已经实施的事情的良好文档
  • 模块化设计，可以明确明确的职责
  • 足够的自动化过程以保证所需缺陷级别的质量。这些过程可能包括诸如：单元测试，回归测试，自动构建部署等）。
  • 团队当前就位和正在使用的错误/功能跟踪系统（例如，trac，SourceForge，FogBugz等）。

应该讨论的第一件事是是否可以推迟发货日期，是否可以削减功能以及两者的某种组合是否可以使您满意现有员工的放行。很多时候，它的几个功能确实占用了团队的资源，而这些资源无法带来等于投资的价值。因此，在进行其他任何操作之前，请先认真考虑项目的优先事项。

如果以上段落的结果不足，请访问上面的列表。如果您及早发现了进度单，则在适当的时间添加适当的团队成员可能会节省版本。不幸的是，您越接近预期的发货日期，增加人员就可能会出错。在某一时刻，您将跨越“无回报点”，在该点上，没有多少更改（除了交付当前的开发分支）无法保存您的版本。

我可以继续下去，但我想我达到了要点。在项目之外，从您的职业生涯，公司的未来成功等方面来说，您绝对应该做的一件事就是弄清楚为什么迟到了，如果可以做些什么可以提早提醒您，以及您需要采取什么措施以防止将来发生这种情况。由于您是：

• 在您开始之前晚了（比时间更多的东西）和/或
• 在时间1天滑了1小时。

希望有帮助！

仅当您有资源驱动的项目时，它才有帮助。

例如，考虑一下：

您需要画一张大海报，例如4 x 6米。这么大的海报，您可能可以在前面放两个或三个人，并让他们平行绘画。但是，在它前面放置20个人是行不通的。此外，除非您需要a脚的海报，否则您将需要熟练的人员。

但是，如果您的项目是用现成的字母填充信封（例如You MIGHT赢了！），那么添加的人越多，它的运行速度就越快。分配工作量会产生一些开销，因此您无法获得最多一个人的收益。信封，但您可以从2或3个以上的人那里受益。

因此，如果您的项目可以很容易地分成几小部分，并且团队成员可以快速上手（例如...瞬时），那么增加人员可以使它更快上手。

可悲的是，在我们的世界中，没有多少项目像这样，这就是为什么docgnome关于“神话人月”一书的提示是一个非常好的建议。

可能满足以下条件：

1. 新的程序员已经了解了该项目，不需要任何准备时间。
2. 新的程序员已经精通开发环境。
3. 无需管理时间即可将开发人员添加到团队中。
4. 团队成员之间几乎不需要沟通。

我会第一次让您知道所有这些。

根据《神话人月》的说法，将人添加到较晚的项目中会导致其延迟的主要原因是O（n ^ 2）的通信开销。

我经历了一个主要的例外：如果一个项目只有一个人，那几乎注定要失败。添加第二个几乎每次都可以加快速度。那是因为在这种情况下，交流不是开销 -这是一个澄清您的想法并减少愚蠢错误的有用机会。

同样，正如您显然在发布问题时所知道的那样，“神秘人月”的建议仅适用于后期项目。如果您的项目还不算晚，那么添加人员很可能以后就不会完成。当然，假设您做得正确。

如果现有程序员完全没有能力，那么增加有能力的程序员可能会有所帮助。

我可以想象这样一种情况，您有一个非常模块化的系统，而现有的程序员甚至没有 在一个非常孤立的模块上启动。在这种情况下，仅将项目的那部分分配给新的程序员可能会有所帮助。

基本上，《神话人物月》中的引用是正确的，但在像我编造的那样的人为情况下除外。Brooks先生进行了扎实的研究，以证明在一定程度上，将新程序员添加到项目中的网络和通信成本将超过您从其生产力中获得的任何收益。

• 如果新人专注于测试
• 如果您可以隔离不创建新依赖项的独立功能
• 如果您可以正交化项目的某些方面（尤其是非编码任务，例如可视化设计/布局，数据库调整/索引或服务器设置/网络配置），以便一个人可以从事该工作，而其他人则可以处理应用程序代码
• 如果人们彼此了解，并且对技术，业务需求和设计足够了解，就能够在知道何时会踩到对方脚趾以及如何避免这种情况的情况下做事（当然，如果还不是这样，很难安排）

只有当您在后期才有一些尚未解决的独立任务（与项目其他部分的互动几乎为0％）时，您才可以聘请该领域的专家团队。增加团队成员必须最大程度地减少对团队其他成员的破坏。

与其添加程序员，不如考虑添加管理帮助。任何可以消除分心，提高注意力或提高动力的事情都是有帮助的。这包括系统和管理，以及诸如午餐等平淡无奇的事情。

显然，每个项目都是不同的，但是大多数开发工作可以确保在开发人员之间进行一定程度的协作。在这种情况下，我的经验是，新鲜资源实际上会无意间降低他们所依赖的人才的速度，在某些情况下，这可能是您的关键人物（顺便说一句，通常是“关键”人物会教育新手的时间）。当他们是加快速度，也不能保证他们的工作将适应既定的“规则”或“工作文化”与团队的其他成员。同样，这样做弊大于利。因此，在某些情况下可能会有所帮助：

1）新资源的任务很紧，要求与其他开发人员的互动最少，并且已经证明了其技能。（即，将现有代码移植到新平台，从外部重构当前已锁定在现有代码库中的无效模块）。

2）管理项目的方式是，可以与其他更多高级团队成员共享时间，以帮助加快新手的工作并指导他们，以确保他们的工作与已完成的工作兼容。

3）其他团队成员非常耐心。

我认为，在以下情况下，快要结束工作的新增人员可以加快工作速度：

1. 该工作可以并行进行。

2. 通过增加资源节省的数量，比使项目经验丰富的人员向经验不足的人解释事物所浪费的时间要多。

编辑：我忘了提，这种事情不会经常发生。通常，这是相当简单的事情，例如对屏幕执行简单CRUD的管理屏幕。这些天来，这些类型的工具几乎都可以自动生成。

不过，请谨慎从事此类工作的经理。听起来不错，但实际上通常不足以削减项目的任何重要时间。

• 尚未启动的自包含模块
• 缺乏他们可以集成的开发工具（例如自动构建管理器）

首先，我在考虑使他们远离当前发展中的人们的方式的事情。我确实同意《神话人月》，但我也认为所有内容都有例外。

我认为将人员添加到团队中可能比将人员添加到项目本身中来加快项目的速度。

我经常遇到太多并行项目的问题。如果我一个人专注于那个项目，那么任何一个项目都可以更快地完成。通过添加团队成员，我可以过渡到其他项目。

当然，这是假定您已经雇用了有能力，有上进心的开发人员，他们能够继承大型项目并独立学习。:-)

如果额外的资源可以补充您现有的团队，那将是理想的选择。例如，如果您要设置生产硬件并验证数据库是否已真正调优，而不是仅仅返回良好的结果（您的团队称为领域专家），那么您是从一个从事下一步项目工作的优秀dba那里借来时间的您的团队可以加快团队发展，而无需花费太多培训成本

简单的说。归结为比较剩下的时间和您从某人那里获得的生产力，不包括花费额外的资源来加速和提高生产力所花费的时间，并减去了现有资源在教授这些资源上花费的时间。关键因素（按重要性顺序）：

1. 资源在获取方面有多出色。最好的开发人员可以在几乎没有帮助的情况下，立即进入新站点并以高效的方式修复错误。此技能很少，但可以学习。
2. 任务的可分割性。他们需要能够处理对象和功能，而不会绊倒现有的开发人员并使它们变慢。
3. 项目和文档的复杂性。如果这是最佳的ASP.Net应用最佳实践和常见的有据可查的业务场景，那么优秀的开发人员可能会立刻陷入困境。这个因素比任何其他因素都更能决定现有资源在教学上必须投入多少时间，从而决定新资源的最初负面影响。
4. 剩余时间。这也经常被错误地估计。通常，逻辑是我们只剩下x周的时间，需要x + 1周的时间才能使某人达到最快速度。实际上，该项目将要拖延，实际上还有2倍的开发时间可以去，因此早日（而不是晚些）获得更多资源会有所帮助。

如果已经使用团队来进行编程配对，那么添加另一个已经熟练配对的开发人员可能不会减慢项目速度，特别是如果开发是以TDD风格进行的话。

新开发人员会随着对代码库的了解越来越多，他们的工作效率将逐渐提高，并且任何误解都将很早就被他们的团队或在每次签入之前运行的测试套件所捕获（理想情况下应该进行检查）至少每十分钟）。

但是，需要考虑额外通信开销的影响。重要的是不要过多地稀释项目的现有知识。

当其他开发人员贡献的生产力超过培训和管理这些开发人员所损失的生产力时，添加开发人员才有意义。