国内为何很少有做结对编程呢？

我曾经在团队实施过。
选了两对工位挨着的做了下实验，发现这玩意真的和人的性格有关系，一对俩人都是脾气很好的，交流起来非常顺畅，另一对有个个性很强的所以过程中有点不愉快。
最后的结果还不错，两对的代码质量都很好，如果功能模块比较大的话用这种方式其实还可以，开发效率确实非常高，毕竟俩人都不能摸鱼了。
不过这样容易累着，毕竟俩人都高强度的工作一整天，一两周年轻还能扛，多了就容易废了

对公司来说，两个人干一个人的活，血亏。
对个人来说，不能摸鱼了，高强度工作一天，要命。

其实就是成本高。在上家公司几年全程结对，其实挺不错的。主要是可以替代很多培训，文档，小的设计讨论，等等的很多东西，也不怕某些人突然请假或者跑路，仔细想其实总能想到很多其他的好处。个人觉得这个实践比其他的敏捷实践都好使。

首先，结对编程国外也不见得多，楼主最好给出国外流行的证据。至少从各种 Git 工作流和 Scrum 方法论上来说，结对编程不是它们的必要条件。

其次，如果跟先编码后评审相比，那么结对编程是仅限单节点、同步、强事务的，后者是可分布式、异步、若事务的：明显后者的适应度更广。
一般来说说，培训是一个特别难的事情，即使花钱主动搞培训效果都很有限，因为好的老师不了解项目，项目上的人也不是好老师。结对能潜移默化地做到知识传播。

结对编程这个损招不知道是哪个天才想出来的。。。这效率也太尼玛高了。本来划划水做 3 天的事情，两人一起干居然半天就完事了，还没 bug ！！！这就离谱。吓得我赶紧停了这个实验，不然狗老板非疯了不可。

说实在的，一般情况下一个人写代码，平均下来一天下来写不了多少。在设计做好的情况下，我曾经一天写了大概有 3 千行代码，直接就是一个项目干完。

缺点就是贵一些，不过考虑到人月的关系其实并不是 2 倍的成本，因为结对的时候一对 pair 当一个人用。

另外感觉楼上很多同学有一些误解：

一定要水平相当的
我们一般尽量水平不相当的搞，让 Junior 主导，包括和其他角色的各种交流等等，Senior 打辅助。这样 Junior 成长得快，然后有 Senior 不容易太跑偏。

旗鼓相当且合拍的两个人可遇不可求。
发现这玩意真的和人的性格有关系
结对没有固定的 pair，的时候要来回轮换，一般要统一换两次，一个人留在原来的任务上，另外一个人换出去。这样才能达到互相了解设计的目的。

不过感觉这种方式对参与人员的基础要求挺高的，比方说技术能力表达能力和情商都得合格才行
这个确实，至少得有一个人还不错，不过这样也是种锻炼，表达能力不好的 Junior 需要每天要主导交流，一般一段时间下来都不会太差。在团队里面开发软件，这些都是很重要的。这样下来团队里的 Senior 表达能力就都还行。

对个人来说，不能摸鱼了
这个也确实，不过这个就看默契了，有时候能看到两个 Senior 在一起的时候节奏特别好，轮流摸鱼。
而且个人觉得摸鱼是正常工作的一部分，都绷紧了很快筋疲力竭还是影响效率，正常结对的时候也需要插入一些摸鱼进去。一般轮流写测试和实现的时候，别人写代码的时候大概知道写啥就行了，走会神摸会鱼都是可以的，对方发现有坑再一起探讨。还有的人跟番茄差不多，隔一段时间会直接说咱俩歇十分钟。困了趴会也是很有帮助的…

不过说回来，跟敏捷的各种东西一样，比如持续交付不是有个 CI Monitor 做做样子就行，结对最后还是取决于实施的质量，要获得好处，避免坑。不然最后就会变成全员吵架 + 结对摸鱼。