如何向团队添加新开发人员

我经营一家只有2个开发人员的小公司。我们正在为我们的一位客户构建非常大的应用程序。这个项目的开发已经进行了1.5年。

现在，该客户已获得了重要的赞助，他们正在组织与此项目有关的活动。所以现在我们有两个月的截止日期，我们不能错过。

我们正在考虑向团队中添加新的开发人员，我想知道我们能做些什么来帮助他整合。

这种情况：

• 我们正在接近布鲁克斯法则的门槛-添加新的开发人员将适得其反。
• 该应用程序的设计相对较好，但是在某些方面（尤其是较旧的代码）的实现是混乱的。
• 仅对最新代码进行单元测试。这个项目开始时，我们没有定期进行测试。
• 文档和注释不完整。
• 该应用程序既大又复杂。
• 客户以一种非常清晰且“程序员友好”的方式写下了有关其项目的几乎所有细节。

现在添加一个人是个好主意吗？如果是这样，我们应该怎么做才能帮助新开发人员融入团队？

编辑：

赞助商将在明年春季组织基于互联网的体育赛事。它必须在一年中的特定日期开始。我们无法更改。

我们的开发人员（我是两者之一）需要做的是：

• 完成现有的应用程序（大约需要完成的工作的25％）。

• 创建一个新模块，对于组织此次活动至关重要（大约需要完成的工作的75％）。如果不了解主程序的API，就无法开发此新模块。

我无法准确估算时间，但我们处于危险境地。

最好的办法不是将新开发人员扔下火，而是开发一些功能和/或错误修复程序，使开发人员可以轻松上手。找到需要工作的区域，而该区域不需要人们一次了解整个体系结构，需求和代码库。也许让他或她从事文档工作以更快地学习系统。

与其在团队中增加新的开发人员，不如考虑在两到三个月的时间内增加一位经验丰富的顾问来处理公司工作量的临时增加。这样做的想法是让一个可以处理接近零启动时间的人，但同时不一定是您团队中最好的成员。

即使您认为工作负载的增加不是暂时的，但现在可能不是有机地发展团队的最佳时机：即使没有项目截止日期的压力，增加第三位开发人员对于团队来说也是一件压力很大的事情。紧迫的期限只会使过渡变得更糟。

折衷方案是，作为临时帮助的交换，您将获得局外人编写的代码。为了减轻这种风险，请确保你们俩都与他进行所有代码审查。确保您也查看并了解他的所有单元测试。

现在添加一个人是个好主意吗？

不可以。请尽量让客户同意缩小范围。

这么晚才增加一个人会带来很大的风险，而且截止日期无法推（据我所知）。

不要这样

然而。

传统观点

在您的问题中，您引用了《神话人月》中的布鲁克斯定律。

在较晚的软件项目中增加人力会使其变得更晚。

忽视布鲁克定律是有代价的。不要多任务。专注于交付最低可行产品（MVP）。然后将精力集中在招聘，资源配置，培训和管理新团队成员上。

两个月太短了。通过烧录清单计划招聘，您会发现它会很耗时。

拉里·佩奇（Larry Page）和谢尔盖·布林（Sergei Brin）花了两年的时间为Google选择最初的团队。您选择的第三号员工也应该谨慎。

敏捷，新千年观

竞争推动动态团队合作的时间比写《神话人月》（1960年代中期）的时代要多。在一家公司的漫长职业生涯已经一去不复返了。现在，我们经常在项目和公司之间迁移。快速的团队建设创造成功。缓慢的上升是一个严重的限制因素。开源项目，初创企业以及团队项目在计算机科学课程中的使用越来越多，就是很好的例子。

潜在的敏捷团队可能会将约束因素纳入他们的日程安排中。它们不晚，因为它们已针对可用资源进行了优化。整合新员工是另一个制约因素，并且被视为短期和长期目标之间的权衡。敏捷团队不断集成代码，那么为什么人们也不会呢？

新员工的敏捷团队技术和社交整合可以使用：

• 每日混乱
• 配对编程
• 重构
• 添加缺少的单元测试
• 完善精益文档
• 代码审查

牺牲羔羊

James Coplien 在“ 敏捷软件开发的组织模式”中讨论了团队动态和增加新团队成员的成本。他的模式“牺牲羔羊”将所有指导和培训分配给一个人，以保护团队的其他成员免受干扰。

您可能要考虑实施此策略。

另一种策略是分配新的雇用指导者，他们每天在特定的小时内解决新雇用者的问题。如果您只能腾出一个人，则他可能在早上或下午工作不受干扰，并分别在下午或早上回答问题。去年夏天，我所在的小组有10名实习生，所以很多人被打扰了。

目前，指导工作是由一个人完成的，主要是在我们上午的Scrum期间和之后（上午8:30到上午9:15左右，合计），以及下午12点至3:30（他的工作时间是上午7点至3:30）下午）。

我很高兴您提到布鲁克定律。做得很好。添加另一个开发人员的主要问题是使他们快速入门的开销，以及与他们同步项目状态的开销。因此，如果您决定聘请第三位开发人员，则可以尝试以下操作：

• 给新手一个低成本的区域，他可以尽快上手。这将在很大程度上取决于您雇用谁以及他们拥有什么技能。
• 确保此区域与应用程序的其他区域松散耦合，以减少同步开销。派他去做大量的数据库工作和重组表可能太多了。
• 尽力保持士气。正如其他人指出的那样，增加新的团队成员可能会感到压力很大，因此对碳酸饮料的投资可能会有所帮助。

如果您严格遵守布鲁克定律，您将永远无法发展自己的团队。

诀窍是招募新员工，而不会因您当前团队的速度减慢而受到打击。最终，新手将很快掌握，并且您可以克服困难。

在你的情况下？我建议让新人来写所有那些缺少的单元测试。

1. 迫切需要这些作为防止回归错误的保障，这将比任何Brooks减速都更快地烧伤您。
2. 新手将学习您系统的胆量。这有点冒险-但是他们的输出没有进入生产代码，因此风险很小。
3. 严格限制其他团队成员可以花费的时间。例如，让他们排队提问，并且每天只允许30分钟与其他团队成员进行互动，直到达到截止日期为止。

此外，让我们面对现实：无论是否聘请新员工，您都必须管理范围和客户期望。收益将在下一个周期出现。

埃德·尤登（Ed Yourdon）对布鲁克定律发表了很好的评论。他说：当然，增加人员会使您的工作变慢-但是，当项目面临风险时，管理层唯一的机会就是招募新人员。因此，请采取以下措施，最大程度地减少对当前版本的影响，并尽快消除效果不佳的人。这样，随着时间的推移，您可以建立强大的团队。

如果您有其他项目的工作，可以给他，这将腾出时间让两个当前的开发人员专注于可以帮助您的大限期交付。

您说您需要完成原始工作的25％，再加上新工作。您需要在两个月内完成此操作-花费了18个月的时间才能完成75％的工作。直言不讳，这向我表明，对于以代码为中心的程序员来说，您的估计能力大约是平均水平-也就是说，您认为事情会花掉您大约三分之二的时间。

Heroics可能会允许您交付已签约的产品，但不会为您或您的客户带来任何好处。在这种情况下，这将是伪劣和漏洞四伏的，并且您会冒烟。

请记住，您花费在招聘上的时间也会对您的可用性产生重大影响-这不是您周末只能做的事情，要找到合适的有才能的员工确实需要时间。期望至少花费几周的时间进行搜索，面试等。期望您和您现有的员工在搜索时每周会损失大约10个小时的生产时间。

我的建议：

与您的客户坐下来，向您解释您的想法，然后与他一起将范围缩小到最小。

编辑刚刚在这里看到了日期。那么，结果如何呢？（感谢Ars Technica发布了一个为期三个月的问题；）

我可以考虑采用两种不同的调查方法：

1. 推迟雇用新开发人员，直到截止日期过后，这样就可以更轻松地专注于将领域知识传递给新人员。这是我的偏爱，因为在某些方面可能会有些挑战。

2. 引入新的开发人员来处理文档，单元测试和其他不会更改任何现有代码的内容。如果您确实请新来的人尝试将对当前工作负荷的影响最小化，这就是我的建议。

日期已经过去了，但是对于以后阅读的人来说。

要考虑的关键是，在这种情况下，客户的损失比您要多得多。他们已经花了很多钱，并且即将举办一项重要活动，这可能会影响他们的生意。您已经有了钱，失去一个客户不会破坏您的业务。如果确实如此，那么除了可怕的项目管理之外，您还有其他严重的业务问题。

最好的选择是协商功能的重要子集，然后加班以完成它。如果您无法完成较小的任务，或者不愿意在这种情况下加班，那么您可能不应该做生意。这可能意味着搁置其他客户，但是我想您的其他客户还没有花3个人年的时间来支付费用，所以请把您的资源放在金钱上。

如果他们不愿意协商缩小范围，那么您将失败。

没有机会在时间表内完全交付该项目。如果您认为目前为止已花费18个月的项目还剩下25％，那么（至少2个开发人员）还剩下6个月。添加其他人不会对此产生重大影响。

正如已经指出的，招聘需要时间。我的经验是，至少需要一个月的时间。然后增加培训，您的时间用完了。

我希望这对您有用。