我一个月需要这个宝贝 – 给我九个女人！

在什么情况下（如果有的话）增加程序员到一个团队实际上是加速已经迟到的项目的发展？

Answer 1

确切的情况显然是非常具体的（如开发团队，pipe理风格，stream程成熟度，主题难度等）。 为了使这个范围更好一点，所以我们可以在任何事情上谈论这个问题，但是过分简单化，我要重申你的问题：

在什么情况下，如果增加团队成员到迟到的软件开发项目，导致实际发货date的减less，质量水平等于现有团队被允许工作直到完成的水平。

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

• build议添加到项目中的个人必须具有：
  • 至less对项目的问题领域有一个合理的理解
  • 熟练掌握项目的语言和他们将用于完成任务的具体技术
  • 他们的熟练程度必须分别小于或大于现有最弱或最强大的成员。 如果一个新人过于强大，他们会把现有的工作人员排除在第三位，而他们所做的一切都是错误的。
  • 有良好的沟通技巧
  • 高度的动力（例如，能够独立工作，无需刺激）
• 现有的团队成员必须拥有：
  • 高超的交stream技巧
  • 优秀的时间pipe理技能
• 项目主pipe/pipe理人员必须具备：
  • 良好的优先级和资源分配能力
  • 来自现有团队成员的高度尊重
  • 高超的交stream技巧
• 该项目必须具备：
  • 一个良好的，完整的，文件化的软件devise规范
  • 对已经实施的事情有很好的logging
  • 采用模块化devise，可以清除大块的责任
  • 为所需的缺陷级别提供了质量保证的足够自动化stream程这些可能包括诸如：unit testing，回归testing，自动构build部署等）
  • 一个目前正在使用和由团队使用的错误/特征追踪系统（例如trac，SourceForge，FogBugz等）。

首先应该讨论的一件事情是，是否可以将发货date下滑，function是否可以削减，以及两者的组合是否允许您满足现有员工的发布要求。 很多时候，它的一些function确实占用了团队的资源，不能提供与投资相等的价值。 因此，在任何其他事项之前，先对您的项目进行严肃的审查

如果上述结果不够，请访问上面的列表。 如果您提前收到日程安排表，在正确的时间添加正确的小组成员可能会节省发布时间。 不幸的是，越接近您预期的发货date，添加人员越会出错。 在某一时刻，你将跨越“不归零点”的地步，除了运送当前的开发分支以外，没有任何变化可以保存你的发布。

我可以继续下去，但我认为我打的重点。 除了项目和职业，公司未来的成功之外，你应该做的一件事情就是明白为什么你迟到了，如果早些时候有什么事情可以提醒你的，以及你需要采取什么措施今后要采取预防措施。 后期项目通常会发生，因为您是：

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

希望有所帮助！

Answer 2

如果你有一个资源驱动的项目，它只会有所帮助。

例如，考虑一下：

你需要画一个大的海报，比如说四六米。 一个大的海报，你可能会把两三个人放在它的前面，并且让它们平行地画。 然而，放在前面的20人将无法工作。 此外，你需要熟练的人，除非你想要一个蹩脚的海报。

但是，如果你的项目是用已经打印好的信件来填充信封（比如你可能赢了！ ），那么你添加的人越多，就越快。 在开展一堆工作时有一些开销，所以你不能得到好处，直到你有一个人的公关。 信封，但你可以从2到3人以上获得好处。

所以如果你的项目可以很容易地分成小块，并且团队成员可以快速起步（比如……瞬间），那么增加更多的人将使得它更快，达到某一点。

可悲的是，在我们的世界里没有很多项目是这样的，这就是为什么Docgnome关于“神话人月”这本书的提示是一个非常好的build议。

Answer 3

也许如果以下条件适用：

1. 新的程序员已经了解了这个项目，并且不需要任何加速时间。
2. 新的程序员已经精通开发环境。
3. 将开发人员添加到团队中不需要pipe理员时间。
4. 团队成员之间几乎不需要沟通。

我第一次看到所有这些，我会让你知道的。

Answer 4

根据神话人月，人们join后期项目的主要原因是后来的O（n ^ 2）通信开销。

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

另外，正如你在发布你的问题时显然知道的那样，“神话人月”的build议只适用于后期项目。 如果你的项目还没有迟到，那么添加人员很可能不会晚点。 假设你正确地做了，当然。

Answer 5

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

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

基本上，“神话人月”的引用是正确的，除了像我编写的那种做作的情况。 布鲁克斯先生做了扎实的研究，certificate在某个点之后，将新程序员添加到项目中的networking和通信成本将超过您从他们的生产力中获得的任何收益。

Answer 6

• 如果新人注重testing
• 如果您可以隔离不会创build新的依赖关系的独立function
• 如果您可以使项目的某些方面（尤其是非编码任务，如可视化devise/布局，数据库调整/索引或服务器设置/networkingconfiguration）正交化，以便一个人可以处理该事件，而其他人则可以继续处理应用程序代码
• 如果人们彼此了解，技术，业务要求和devise，就足以能够知道什么时候彼此踩脚趾，怎样避免这样做（这样，如果还不是这样的话，那当然是很难安排的）

Answer 7

只有当你在那个晚期阶段有人独立（与项目其他部分几乎0％的互动）任务还没有被任何人解决，你可以把这个领域的专家带到这个团队中。 团队成员的join必须尽量减less团队其他成员的干扰。

Answer 8

可以考虑添加pipe理帮助，而不是添加程序员。 任何能够消除分心，提高注意力或改善动机的东西都可能有所帮助。 这包括系统和pipe理，以及像午餐更平淡的事情。

Answer 9

显然，每个项目都是不同的，但是大多数开发工作可以保证在开发人员之间有一定的协作。 在这种情况下，我的经验是，新鲜的资源实际上可能会无意中拖慢了他们所依靠的人的速度，在某些情况下，这可能是您的关键人物（顺便说一下，这通常是“关键”教育一个新手的时间）。 当他们加快速度时，他们的工作就不能保证他们的工作能与队伍中的既定“规则”或“工作文化”相适应。 再一次，它可以做更多的伤害，而不是好的。 所以，在这些情况下，这可能是有益的：

1）新的资源有一个紧凑的任务，要求与其他开发人员的最小互动和一个已经被certificate的技能。 （即将现有代码移植到新的平台上，从外部重构当前locking在现有代码库中的死亡模块）。

2）该项目的pipe理方式使得其他更高级的团队成员可以共享时间，协助新手加快速度，并一路指导他们，确保他们的工作与已经完成的工作兼容。

3）其他队员非常耐心。

Answer 10

如果有下列情况，我认为在工作结束时增加人员可能会加快速度：

1. 这项工作可以并行进行。

2. 通过增加资源节省的金额比通过让项目经验丰富的人向那些经验不足的人解释所浪费的时间要多。

编辑：我忘了提及，这种事情不会经常发生。 通常这是相当直接的东西，就像pipe理屏幕，做一个简单的CRUD表。 无论如何，现在这些types的工具大都是自动生成的。

尽pipe如此，请谨慎对待这类工作的经理人。 这听起来不错，但实际上通常还不足以削减项目的重要时间。

Answer 11

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

我主要想到的是让他们远离目前正在发展的人们的方式。 我同意神话人月，但我也认为有一些例外。

Answer 12

我认为将人员join团队可能会加快项目的速度，而不是将其添加到项目本身。

我经常碰到有太多并发项目的问题。 如果我只专注于这个项目，那么这些项目中的任何一个都可以更快完成。 通过增加团队成员，我可以转换其他项目。

当然，这里假设你已经雇佣了能干的，自我激励的开发者，他们能够inheritance大项目并独立学习。 🙂

Answer 13

如果额外的资源可以补充你现有的团队，那么这可能是理想的。 例如，如果您要设置您的生产硬件，并validation数据库实际上已经过调整，而不是仅仅返回好的结果（您的团队认为是领域专家），那么借用下一个在项目中工作的好dba的时间对你来说可以加速团队，而不需要太多的培训成本

Answer 14

简单的说。 归结起来，比较剩下的时间和你从某人那里得到的生产力，不包括额外资源需要花费的时间和生产力，并减去现有资源教给他们的时间。 关键因素（按重要性排列）：

1. 这个资源在捡起来有多好。 最好的开发人员可以走到一个新的网站，并且几乎可以立即提供帮助，从而提高生产力。 这个技能很less见，但是可以学习。
2. 任务的离散性。 他们需要能够处理对象和函数，而不会绊倒现有的开发人员并放慢速度。
3. 项目和文件的复杂性可用。 如果这是一个香草最佳实践ASP.Net应用程序和常见的良好文档logging的业务情景，那么一个好的开发人员可以直接卡住。 这个因素比任何因素都要决定现有资源在教学上投入多less时间，从而决定新资源的初始负面影响。
4. 剩下的时间。 这也经常被误判。 通常情况下，我们只剩下x周的时间，需要x + 1个星期才能让某人加速。 事实上，这个项目正在滑落，事实上已经有两个星期的时间了，而且越来越多地获得更多的资源将会有所帮助。

Answer 15

如果一个团队已经习惯了配对编程，那么添加另一个已经熟练配对的开发人员可能不会减慢项目速度，特别是在开发采用TDD风格的时候。

新的开发人员会越来越多地了解代码库，因此任何误解都会很快由他们或者在每次登记之前运行的testing套件抓住（最好是检查至less每十分钟一次）。

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

Answer 16

当额外的开发者贡献的生产力超过了培训和pipe理这些开发者的生产力时，添加开发者是有道理的。