双人编程意味着每个开发人员的成本加倍。这样的钱值得吗？

首先，对于配对编程的第一个假设是一个故事卡需要花费两倍的时间来开发。这个假设是错误的。以下是原因：
- 提高质量：两个活跃的程序员一起工作在同一个故事卡上，将会以更少的缺陷完成该卡。 - 提高生产力：一对人在解决问题时不太可能被拖延或完全阻塞。此外，当你与合作伙伴一起工作时，很难进行电子邮件或网络度假...你不想让合作伙伴失望。当成对工作时，你将用更干净的设计和更少的代码行来解决问题。 - 消除知识孤立：通过轮换配对，您将在团队中学习应用程序和领域业务知识。如果 Sue 在度假期间没有其他人了解她的代码，团队就不太可能被阻止。 - 知识传递：轮换配对可以让彼此教授新技能（工程和领域）。整个团队的水平都会提高，知识也会在团队中传播。 - 团队自我选择：团队了解彼此的技能，并迅速淘汰表现不佳的人。
根据实际经验，我们看到缺陷显著下降。新团队成员可以加入而不会拖慢团队（尝试在非配对团队中做到这一点）。为了试用，一个团队估计了一组故事卡的工作量，就好像六个单独的开发人员将分别完成代码。然后告诉这六位开发人员进行配对。他们按时高质量地完成了工作。如果不进行配对，你会花费太多时间来提供较低的质量，你没有扩展的方式，并且你有太多的专业知识孤立。
在第二个例子中，我们估计完成所需的工作需要将团队从4对增加到7对。我们给自己一个月的时间来接纳新的配对。我们将新开发人员与经验丰富的开发人员配对，并在故事卡之间轮换配对。团队按计划按时交付了所有交付物并保证了质量。如果不进行配对，您无法将6个开发人员添加到8个开发人员的团队中并达到目标！
总之，配对编程可以节省金钱。你将花费大约相同的时间，以更高的质量交付，提高团队的绩效、技能和知识，并淘汰无用的人。您的节约将来自可持续的步伐和显著减少阻碍团队的缺陷。

Pair programming并不会增加成本——它只是减少了打字的量。打字并不等同于编程，完成软件功能就是编程，它是问题求解的过程。你不能仅以敲入的代码行数来衡量。一些程序员会使用更好的算法，因此最终需要键入的代码更少。
您如何定义物有所值？也许是从编码开始到在实际环境中完成工作功能的总时间吗？
不进行配对的成本通常被错误地计算：问题在于大多数人并不测量缺陷数量或修复未正确完成的工作所需的额外时间，他们只测量第一次“扔掉工作”所花费的时间。
有一些尝试在配对时测量生产力的方法，但不幸的是，它会与“交付代码行数”的指标混淆，这是一个虚假的度量标准。
您可能会发现这项研究相关：http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF

当我在朋友的船上编程时，我们并不总是有时间，因为其中一个人正在驾驶船只，而另一个人则在编码。然而，当我们停泊或在平静的水域时，我们可以进行配对编程，这样也很有效。

前提是你的生产力将翻倍以上。其中一部分增益会立即实现（例如，在代码提交之前），另一部分则在之后实现，因为会出现更少的错误和故障。

当我教授有两个学期经验的学生时，对于大多数团队，因为他们互相提问、学习和完成得更快，他们的生产力都翻了倍以上。但并非普遍适用；一个配对不当的团队可能需要更长时间，并且做得比半数技能更高的人还要差。

来自其他许多行业的质量管理经验告诉我们，缺陷预防长期来看比缺陷检测（也称为QA）和随后的修复更加划算。他们还发现，在大多数情况下，长期范围为1到2年，这意味着您的投资在此之后会得到回报。考虑到通常希望在4年后达到盈亏平衡，这非常不错！
问题是，其他行业需要几十年时间才能积累足够的数据，以便能够证明这对他们来说是正确的。您可以轻松地找到支持其结论并类比于软件的数据，但截至今天，尚无关于软件业务的证据。
话虽如此，我相信类比的结论是有效的：一对开发人员和一个测试人员比一个开发人员和两个测试人员更具生产力。
如果您无法向管理层证明两个昂贵的开发人员坐在一台电脑前的必要性，那么有许多其他有助于缺陷预防但对管理层不太明显（因此令人烦恼）的事情。

不行啊！我工作的公司经常进行双人编程！这样可以快速且高效地完成任务！你可以试试看，以后你会珍视它的！

NC州立大学的劳瑞·威廉姆斯教授是关于编程伙伴制有效性方面学术界的主要权威，她对此进行了大量研究。

如果您想要“官方说法”，请访问她的出版物列表。

她的文章：“加强编程伙伴制的案例”非常有名。

这取决于开发人员。不幸的是，您不能只是把两个开发人员放在一起，然后期望及时、高质量的结果。并不是每个人都适合配对编程，甚至适合在敏捷开发环境下工作。我认为配对编程有两个值得注意的地方：（1）开发人员之间的交叉培训；和（2）实时同行评审。交叉培训将有助于加强团队整体技能，并且实时同行评审可以消除形式化同行评审的需要。多年来，我从我的同行身上学到的东西比我在技术培训中学到的还要多。

编程中的概念并不是非黑即白，也不是什么万能的解决方案，这就是“配对编程”。

从各种角度来看，“配对编程”通常都非常高效，但如果做得不好，它也会非常耗费精力（至少在我看来是这样）——这意味着一个好的配对可能每天只进行几个小时的编程。当然，这应该被鼓励，但不应该成为强制性的，特别是不应该占用100%的时间，因为这似乎很难管理（无论是否有啤酒）。

因此，“配对编程”只是解决问题的一种方式，我发现很难从问题的角度来看待它。这并不像你需要雇用两倍的开发人员来完成这项工作。这就像想知道是否值得雇用信使男孩/女孩让同一部门的两名员工互相交流...而明显的解决方案是让他们直接互相交流，而不需要额外的信使。

除非你是一个非常小的商店，否则你可能已经支付了两个程序员的薪水。配对编程只是一种理论上可以在同样的时间内获得更多调试和工作软件的方法。