Pair （结对）已经不是什么新鲜的事情。工作中我们进行 Pair。但是也会经常发现一个问题：“两个人单纯的坐在一起工作或者被领导命令坐到一起工作，并没有什么工作效率提升的“。工作中许多人对 Pair 这个词的理解多于 Pair 应该怎么做的理解。这篇文章将详细描述关于 Pair 的中的详细细节，主要设计内容如下：
什么是 Pair Programming？
为什么我们要做 Pair Programming？
Pair Programming 过程中经常遇到的问题（14 个常见问题）
Pair 的扩展。
这篇文章并不涉及到具体的代码，但是了解清楚 Pair Programming 之后能够让我们在工作中事半功倍。
91 什么是 Pair programming？
先回顾一段历史，1999 年《解析极限编程-拥抱变化》中提出了XP（极限编程），而 Pari Programming 是 XP 的核心实践之一。XP的信条是：如果一个实践有价值，我们就把它做大极致。Pair Programming 随着 20 多年的实践一样已经拥有了多种形式和多种工具。
关于 Pair Programming 的理解分为广义的理解和狭义理解：
（1）广义理解：两名 Dev / BA / QA 等 坐在一台电脑前开发软件；
（2）狭义理解：两名 Dev 坐在一台电脑前开发软件。
上面描述的是 Pair Programming（结对编程），经过20多年，我们做很多事情都可以都可以采用 Pair （结对）的形式，而不仅仅在局限在写代码上。
Pair Programming 的形式：
（1）键盘/鼠标式。如果在 YouTube 上搜索 Pair Programming 会搜索到两名小朋友坐在电脑前，一个人操作鼠标、一人操作键盘。现实工作中我至今没有使用过这种方式。
（2）Ping-Pong 形式。经常使用的一种方法。比如 TDD 过程就可以采用 Ping-Pong 形式完成，A 编写测试，B 编写实现，B 编写测试，A 来完成实现。在 Ping-Pong 形式中会遇到两人抢键盘的问题，这个使用我们可以使用 switch 方法，轮流交换，确保一个时间只有人来操作。
（3）Navigator-Driver 式。 领航员-驾驶员模式，看过汽车拉力赛的朋友会注意到一辆车上会坐着两人，一名领航员，一名驾驶员。领航员聚焦在实现宏伟目标，Driver 聚焦如何实现。比如前往弯道领航员和驾驶员都期望过弯，领航员会发出指令，前方 200 米发卡弯，下坡，路面有碎石头，驾驶员来控制油门、档位、方向来过弯。Pair Programming 使用这种方式，两人需要首先针对问题达成共识，然后 Driver 开始编写代码，处于观察状态的 Navigator 思想会比较活跃，思想也会领先 Driver。因此会发现 Driver 的诸多问题，在 Pair 过程中，Navigator 不要轻易打断 Drvier 的思路，有些问题 Devier 有可能已经发现，只是处理问题的时间点不相同，所以Navigator 此时应该不发言，保持 Driver 的连贯性思路。当 Navigator 发现对方没有意识到某个问题时，再进行提醒。
（4）其他形式。 工作中能够解决问题的那些 Pair 才是最好的，因此形式并非是一成不变的，评估 Pair 形式最直接的就是结果，结果说明一切，如果对 Pair Programming 不熟悉，可以先从上面 2 中方式进行尝试，当对 Pair Programming 熟悉并了解其目的性之后，可以针对特定问题，进行形式、频率的改进。
Pair Programming 过程中有几点需要注意：
（1）多沟通。沟通的目的是达成共识、找到解决方法。先达成共识在行动。避免没想后或者思路 不一致就开始动手了。
（2）定期交换小伙伴。团队中不建议一直都是相同两个人进行 Pair，原因后面会详细讲解。采用机制定期交换 Pair Programming 的对象。
（3）勇敢。勇敢的提出解决问题或者提升效率的反馈。勇敢的接受反馈，承认自己没有做好的地方，对伙伴真诚的反馈给出回应。
（4）先确认任务列表。沟通的目的是达成共识，因此 Pair Programming 之前需要先确定任务列表，Tasking 的过程除了任务拆分的过程也是 达成共识的过程。
（5）可持续的结对工作。如果参与到结对之后，会发现时间久了由于大脑高速长时间运转结对非常累，一次建议每天结对时间可以保持 5 - 6 小时，最多不超过 8 小时。
（6）反馈。勇敢的给出正面反馈，即使觉得没有必要进行 Pair 也是应该清晰的阐述清楚为什么不。
92 为什么我们要做 Pair Programming？
很多团队项目上采用 Pair Programming 并不只是一种形式，而是通过实践能够得到收益。
下面是通过采用 Pair Programming 之后获得收益的几点：
（1）更专注。一名开发者日常开发时间有限，这已经是一个尝试，所以很多人改善环境、方法来提升专注。实践的结果是 Pair Programming 能够在这方面提升专注能力。
（2）提升解决问题的效率。 两个人解决问题时，思维更加开放，同时减少问题被卡住而浪费的时间。当然有些时候 Pair Programming 并不提升效率，那也是应该避免的。
（3）减少错误。质量内建，错误发现的越早，修复成本就越小。
（4）知识传递。 信息很多场景下都是不对称的，通过 Pair Programming 能够消除信息瓶颈，特别是在了解业务上下文、技术上下文时。
（5）增加团队友谊。 通过 Pair Progamming 能使团队内的同事相互了解、彼此熟悉。
上面的描述涉及到的只是部分收益。现实工作时 Pair Programming 中也会遇到各种各样的问题，了解这些问题并解决才能得到刚才上面讲到的这些收益。
93 Pair Programming 中常见的问题（14 个常见问题）
（1）“原本我自己写的好好的，现在多一个人我还要给他讲一遍，多浪费时间啊”，“我也讲不明白，我就是喜欢写代码而已，别逼我。”
站在个人角度，上面两句话挺有道理。
但是“设计和编程都是人的活动，忘记这一点，将失去一切。”
这句话的意思是，现在软件开发是一个团队的事情，而不单单是一个人的问题。很多团队已经注意到这一点，并不团队成员分开工作就一定高效，遇到问题时需要的话，多人同时解决能过突破很多团队的瓶颈问题。例如时间持续集成的团队往往会有一条规则“红不过夜”，及持续集成的时候遇到问题立即全体关注并解决。
所以上面的问题，只是站在个人角度的表述，并不一定是团队真正的诉求。清楚团队的目的，在考虑当时的上下文有助于帮助我们更清晰的判断和做出决定。
（2）两个人坐在一台电脑前不是浪费一个人吗？
不管是在创业还是持续改进上，我们不担心直觉，担心的是不去验证直觉。所以担心浪费一个人的时间时很正常的感受，但是实际是否真的这样，取决于很多因素。
不 Pair 不代表就不浪费时间。
可以在一定的时间周期内实施 Pair ，并统计团队产出在一段时间后是否增加了。处看 Pair 关注的是团队长期收益，熟练应应用后短期同样能够带来效率非常高的收益。
（3）一般建议能力高低配还是按领到任务来配置？
可以根据实际上下文来执行，这里按照新同事和老同事来决定 Pair 对象。Switch Pair 指的选择 Pair 对象。
（a）新同事来 Switch Pair，对新同事来说能够了解业务上细纹，switch 指的就是定期更换 Pair 对象，针对需求来更换 Pair 对象。
（b）老同事来 Switch Pair，能够即时同步信息，在处理新领域的问题上能够相互弥补知识。
（4）两个人开发习惯不同怎么办？
两个人的开发习惯不同是好事情，能够在 Pair 过程中发现彼此的对自己有帮助的地方。如果两者技术上差别不大，在单纯的技术上也不提倡 Pair，因为往往收益不大。
只有 Pair 两人上下文、技术差别比较大时，熟练应用 Pair 后的收获才越大。
（5）如何判断可以在 Team 中引入 Pair Progamming？
Team 是有长期规划的，首选确定 Team 的建设的目的，并针对已经了解的上下文，决定先引入实践，再引入什么实践。
另外了解团队内对业务、技术上是否有差距。如果差距不大那么引入 Pair 效果也不会非常大。只有 Pair 两人能力、业务上差距大的时候受益才明显。
还可以参考一下因素：
（a）团队成员接受新事物的能力
（b）项目进展压力
（c）老板的认可度
（d）提升项目质量
（f）增加项目稳定性，避免单点依赖的问题。
（6）是否推荐新手和新手 Pair？
不推荐。
因为两者都不清楚怎么做。新手分为业务上的新手、技术上的新手，如果解决的问题两者差距不大，那么就不建议 Pair。这里的差距不大有两种情况：
（a）两者都是刚接触某方面，都不清楚;
（b）两者都非常熟悉，也不推荐 Pair。
两者差距不大的时候 Pair 的收益效果可能不如分开工作。
（7）两人讨论没有结果怎么办？
Pair 是常见的问题就是思路不统一、没有思路。
思路不统一的时候：
（a）可以选择分开时间，各自出来结果的时候再 Pair 总结比较。
（b）也可以选择选择仲裁，一般会找 TL 来作出决定，如果无决定可以采用（1）
没有思路的时候：
（a）确定是否可以收集信息后再 Pair，
（b）更换 Pair 对象来解决问题。
（8）Pair Programming 的成本和收益是什么？
成本就是两个人的时间用在解决一个问题上，信任成本。
收益是团队实际效率的提升。
（9）如何让 Pair Programming 产生作用？
明确成本和收益。如果刚接触 Pair Programming，那么肯定是有学习成本的，实践过程中也会遇到不少问题，同时还可能在知识、技能上面相互带来变化（改进）。
让 Pair Programming 产生作用就需要明白，什么时候用 Pair Programming，下面是常用的判断。
（a）两个人技术上下文、业务上下文相差不大----------不建议 Pair
（b）两个人业务上或者技术上相差比较大 -------------- 建议 Pair
（c）两个人都不懂 Pair --------------------------------------不建议 Pair
（10）如何衡量 Pair Progamming 的效果？
效果看两方面。
一是看团队总体产出变化，而不是盯着个人的产出变化。
二是看实际结果，可以引入 Pair Programming 的记录，并定期统计团队产出增加多少，缺陷减少多少。
即使决定长期时间 Pair Programming，上面的记录也是对团队效率改进有帮助的。
（11）结对编程几小时比较好？
上面对 Pair Programming 介绍的时候已经提到了实践。建议 5 - 6小时/天，最多不超过 8 天。具体时间根据项目团队而定，Pair Programming 应该在连续的时间内进行，不应该一项任务被时间打散完成，如果跟时间有关系的话，打散时间的 Pair 有可能效率平平。
（12）项目紧，结对是否会降低效率？
项目紧并不是长期，而且并没有什么项目时间不紧张。思考更多的是如何在项目时间紧张的前提下，采用何种实践方式。Pair Progamming 是一种实践活动，熟练掌握之后并不会降低开发效率。关键是在刚刚接触 Pair Programming 时总是会有学习成本的，但是就如同学习曲线一样，效率短暂降低后会回升到比现在更加高效。所以如何选择取决于团队是否当时应该引入实践上的变化，以及长期收益的目的。
简单的认为并行效率就高并不能让团队真的高效，另外可以参考 TOC 理论了解瓶颈制约法。
（13）如果不接受新事物，那么如何引入 Pair Progamming？
首先接受新事物肯定是会有成本的，不引入新的实践技术团队可以获得短期的利益但是长远的看也会被逐渐接近淘汰的边缘。
可以尝试阶段性引入 Pair Programming。但是不建议都不清楚 Pair Progamming 怎么做的时候就引入，因为谁都不清楚的时候，遇到问题往往不了了之。
（14）如何远程 Pair Progamming？
远程 Pair Progamming 时，我们可以借助 IM 视频功能，比如 Zoom，共享屏幕来共同完成一个问题。
同时也开始通过 tmate（Terminal 工具）、Live Share Extension Pack（VS Code 的 Plugin ）。
94 Pair 的扩展
（1）上面就是关于 Pair Programming 的所有问题吗？
不是。因为还缺少一点：“持续改进“。从提出 Pair Programming 到现在已经 20 多年了，在这些年中，开发者根据当下自己使用的工具、了解的业务、方法论。
所以停下来是不是问问自己：
（a）它是否提供了我们期望的效果和质量收益？
（b）团队中的每个人都开心吗？
（c）是否尝试了一些事情，让它更有效果？
通过这些问题，团队能够反思和改进从而获取更好的工作效率。
（2）Pair 还可以应用在其他场景
上面的场景主要是围绕开发进行的，工作还 Pair 还可以应用在很多场合，比如人才的培养过程、人员替换过程、新员工入职之后、新领域问题研究。
