最近团队氛围很紧张，因为我们发现项目无法按时交付了。

发生了什么？

在一周前，客户突然调整了需求的优先级，而我们在估计工作量的时候并没有考虑低优先级的需求。现在，原来低优先级的需求变成了高优先级，且必须在两个迭代后完成。而原来在Backlog中吃灰半年的需求，也要在两个月后完成。这给了我们一个措手不及，犹如晴天霹雳。

我们能做什么？

地球可以毁灭，但项目必须交付。我们想到了两个办法

但这两个方法都是有风险的。

团队需要付出额外的工作量来培训新人，而且新人很难在短时间内有产出。那么在离交付时间还有两个月或两个迭代的时候加人，很可能无法加快项目进度，反而还有可能使进度变慢。

有一种特殊情况可以避免上述风险，那就是新人正好具有当前项目的经验。这样新人在加人团队后便可以立即有产出，会显著加快项目进度。但对于那些新启动的项目来说，它们还没有时间孵化出足够大的人才池，基本无法找到具有当前项目经验的人。

那么问题就变成了，如何减少团队培训新人的工作量？有一种可能性，那就是寻找能力优秀的新人，杀鸡用牛刀，用优秀的能力来抵消当前项目经验的不足。但这也只是一种符合直觉的可能性，是否真的有效还需要实践来检验。如果连新人的能力都无法得到保证的话，那加人就不是一个好的选择。

最后，不管新人是否有当前项目的经验，其数量是有限制的。团队不能出现让新人或没有独立工作能力的团队成员进行独立工作的情况，所以新人数量要满足如下公式

新人的数量 \leq 团队成员的数量 - 没有独立工作能力的团队成员的数量

这样我们才能通过结对编程来保证每个人都能够有产出。

团队会变得脆弱。每个人工作在不同的任务上，无法及时分享上下文，很容易形成知识孤岛，一旦出现人员休假或更换，团队的部分工作将不得不停止。

Tech Lead的压力会增大。因为在团队内部沟通中对Tech Lead的依赖变多了，Tech Lead可能在方案分析，任务划分，代码审查，测试支持等方面成为团队的瓶颈。如果无法合理安排Team Lead的工作，交付速度将无法提升，交付质量也难以保证。

在结对编程时，每份代码和方案都至少会被两个人审查过，这大大减少了代码提交后团队进行代码审查和方案审查的工作量，减少了出错概率。如果放弃结对编程，出错概率将会增加。

我们找不到有当前项目经验的人，不过我们以上面公式中规定的数量找到了一些资深的开发人员，他们都是可以独立带团队的Tech Lead。我们相信，他们能在短时间内理解我们项目的上下文，然后开始独立工作。

我们没有完全放弃结对编程。我们规定在下面的场景下必须进行结对编程

我们加强了代码审查。代码必须在Tech Lead和另外一个高级开发审查过后才能合入主干。

我们没有十足的把握。所有这些办法都是在最大限度的利用(压榨)现有团队成员的能力，希望它们能够发挥杠杆作用来提高交付速度。

我们可以使用各种逻辑来证明这些办法是有效的，但我更愿意把它们理解为对所有人的心理安慰。我更愿意相信其实没有有效的办法，无论我们怎么做，我们都是在以某些东西为代价来换取速度，这些东西可能是质量，员工满意度，可维护性，成本等我们原来认为非常重要的东西。

最好的办法就是不要让这种情况再次出现。下面是我们采取的行动

当疾病缠身时，无论我们请再好的医生，吃再好的药物都无法让身体完好如初。对付疾病最好的办法是不要生病，而不是寻找更好的医疗资源。