在什么情况下，增加程序员加入团队实际上会加速已经很晚的项目的开发？

解决方案

回答

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

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

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

回答

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

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

回答

可能满足以下条件：

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

我会在第一次看到所有这些时让我们知道。

回答

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

例如，考虑一下：

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

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

因此，如果项目可以轻松地分为几小块，并且团队成员可以快速上手(例如...即时)，那么增加人员可以使它更快上手。

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

回答

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

回答

只有当我们在后期才有一些尚未解决的独立任务(与项目其他部分的互动几乎为0％)时，我们才可以聘请该领域的专家来工作。增加团队成员必须将对团队其他成员的破坏降到最低。

回答

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

• 该工作可以并行进行。
• 通过增加资源节省的数量，比使有项目经验的人向没有经验的人解释事情所浪费的时间还多。

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

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

回答

确切的情况显然是针对项目的特定情况(例如，开发团队，管理风格，流程成熟度，主题难度等)。为了更好地确定范围，以便我们可以简单地大幅度地谈论它，我将重申问题：

Under what circumstances, if any, can adding team members to a software development project that is running late result in a reduction in the actual ship date with a level of quality equal to that if the existing team were allow to work until completion?

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

• 精通项目的语言和他们将用于完成任务的特定技术
• 他们的熟练程度必须分别小于或者大于现有的最弱或者最强的成员。弱小的成员将使现有员工陷入三级问题，而一个太坚强的新人则会破坏团队的工作方式和做错了事。
• 有良好的沟通能力
• 具有高度的积极性(例如，能够独立工作而不强迫他人)
• 出色的时间管理技能
• 现有团队成员的高度尊重
• 高超的交流技巧
• 良好的文档记录已实施的内容
• 模块化设计，可以明确明确的职责
• 足够的自动化过程来保证所需缺陷级别的质量，这些过程可能包括诸如：单元测试，回归测试，自动构建部署等)
• 团队当前就位和正在使用的错误/功能跟踪系统(例如，trac，SourceForge，FogBugz等)。

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

如果以上段落的结果不足，请访问上面的列表。如果我们及早发现了进度表失误，则在适当的时间添加适当的团队成员可能会节省发布时间。不幸的是，我们越接近预期的发货日期，增加人员就可能会出错。有时，我们会越过"无回报点"，在该点上，没有多少更改(除了交付当前的开发分支)无法保存版本。

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

• 在我们开始之前晚了(比时间更多的东西)和/或者
• 滑倒了1小时，时间是1天。

希望对我们有所帮助！

回答

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

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

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

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

回答

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

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

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

回答

我认为将人员添加到团队中可能比将人员添加到项目本身中更快地提高了项目速度。

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

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

回答

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

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

回答

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

回答

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

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

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

回答

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