过早的快速增长

软件的一大好处是人们似乎想要它，而且想要它很快。组织通常要求团队加快软件生产速度，有时组织会以真正体现其承诺的方式提供帮助——通过花钱为团队增加更多人员。

现在，关于为软件团队增加人员的真正益处，已经有过很多争论。在我看来，你不会得到线性收益，将团队规模翻倍并不会使生产力翻倍，因为沟通和协调成本会随之而来，削弱了增长。我完全不科学的经验法则是在任何生产力增长可能与人员增长平方根成正比，因此将团队规模翻倍将使生产力大约提高 50%。但在实践中，这将根据个体因素而有很大差异。我认识一些人，他们可能仅仅凭借一己之力就能使一个相当大的团队的生产力翻倍，我们也遇到过会降低团队生产力的人。

但我要在这里强调的是人员增长问题。你有一个工作良好的小型团队，但你想要更多软件，并且你准备花钱来获得它。你很乐意支付四倍甚至六倍的费用来使进度翻倍。一个重要但鲜为人知的因素是你可以安全地向团队添加人员的速度。

不止一次，我遇到过项目过快地添加了太多人员。这会表现为代码库本身的凝聚力崩溃。重复代码泛滥，我的几个朋友都知道一个项目，该项目在一个应用程序中使用了三个对象关系映射框架。这种崩溃发生是因为新加入的人员不了解代码库当前的工作方式，因此他们做了一些与之不符的事情，比如添加一个竞争框架。如果周围有太多新加入的人员，团队领导无法跟踪所有事情，代码库就会出现问题。然后这些问题会相互加强，因为没有人能找到一致的做事方式，破窗效应开始发挥作用，你就会得到一个正反馈循环。（正反馈循环通常是一件坏事。）

除此之外，过快的增长会导致人际沟通机制的崩溃。人们需要时间来适应彼此的工作方式，而过快的增长会阻止一个大型团队形成成功所需的合作关系。

那么，你可以安全地进行多少增长呢？很难给出任何具体的建议，因为我问过的任何有经验的项目经理都会正确地指出，必须考虑许多变量。我向乔·泽内维奇（Joe Zenevitch）施压，他是我的最值得信赖的项目经理来源之一，他表示他永远不想一次性将团队规模翻倍。即使是翻倍也是一个冒险的决定，如果现有团队已经拥有 12 人或更多人，或者有相当数量的初级人员，风险就会增加。

如果你要大幅增加规模，你不应该在新人融入团队之前再添加更多人员。这需要几周时间。开发人员需要了解代码库和领域，业务分析师需要熟悉领域专家，每个人都需要相互了解。在 Thoughtworks，我们期望人们能够快速上手，毕竟我们聘用的是聪明、积极主动、学习能力强的人。但即使如此，也仍然需要一两周时间。对于大多数团队来说，你应该允许更长的时间。

当你向团队添加人员时，你不会立即获得能力提升。人们需要时间才能在一个新项目中变得高效。更糟糕的是，现有员工必须花时间帮助他们快速上手，因此你的 速度 最初可能会下降。乔·Z 对 Thoughtworks 团队的观察是，在最初的几周内，新人的加入和现有员工的损失会相互抵消，不会产生净效应。[1] 大多数 Thoughtworks 员工都喜欢指出，结对编程是更快速地帮助新人入职的一大推动力。Pat Kua 还有一些关于如何有效地将新人引入团队的 良好建议。

另一件需要注意的事情是不要在项目早期过早地增长。我从从事大型项目（超过 50 人）的人那里听到的最坚定的一条建议是，项目应该从小规模开始，也许只有 12 个左右的开发人员。他们应该通过构建系统的早期部分来找出系统的主要设计元素和交互。只有在设计稳定下来之后，你才应该考虑将团队规模增加到其最大规模。作为稳定设计的一部分，花时间移除你认为不应该复制的任何设计元素。人们会自然地复制已经存在的东西，因此你应该确保存在的东西都将为进一步开发提供一个良好的平台。这是在代码整洁方面过分关注的时候。

最后，在考虑增长时，认真考虑一下是否值得。我很少遇到过一个大型团队，他们没有感觉到可以显著裁员而不会降低生产力。正如我曾经说过的那样，"扩展敏捷是你最不想做的事情"。

进一步阅读

我的同事 Francisco Trindade 谈论 了他在几周内一次性引入几个开发人员的良好经验。