背景最近开始重新审视这些融入日常工程实践的方式，试图找出实践与理论的差距，分析差距的原因，并根据分析结果，尝试找出可以逐步弥合差距的实践方式，让日常的软件交付工作变得更加“顺畅”。本文作为《沉思录》的第一篇，将列举在实际交付项目中结对编程遇到的几个实际问题，并针对具体问题给出一些尝试过的解决方案。注意：以下主题超出了本文的范围，并假设读者已经了解以下问题：为什么要结对编程？（如果想了解可以参考维基百科（https://en.wikipedia.org/wiki/Pair_programming）或其他相关邮件）如何开始结对编程？（想了解可以参考《7个你需要知道的结对礼仪》(https://insights.thoughtworks.cn/seven-skills-about-pair-programming/)）工作环境背景9人团队（1个BA，1个QA,1TL,6Devs)特殊角色(BA,QA,TL)基本都是Solowork,DevPairwork,每对一次只会在一个UserStory上工作，直到UserStory进入测试阶段，团队才会Sprint一开始switchPair活动，UserStoryUnfinishedPair，一个人会留在未完成的Story上，为了完成保证cardcontext足够SwitchPair会按照Pair轮换表（下图）保证alldevelopmentswillhaveequalopportunitiesforPairDevrotationtable大概是这样的（团队在每个循环中使用相同的pairing组合）：基于以上背景，我们遇到了以下实际问题：问题1：切换pairs时，有太多的内容要移交。切换pair的时候，需要交什么东西当内容太多的时候，可能会遗漏一些细节。为了填补遗漏，将涉及更多更深入的讨论。具体场景张三和学霸经过了一周的结对编程，一个复杂的UserStory（无法进一步拆分）没有完成，学霸就留在了现在的工作岗位上，准备和阿乐一起开始工作。但是，学霸在向阿乐介绍目前的工作进展时，并不能向阿乐解释清楚之前编写的代码与UserStroy的对应关系，以及一些必要的上下文。于是，两人不得不将张三带回来进行上下文传输。三人讨论了很久，把之前讨论过的问题重新讨论，降低了工作效率。分析完原因后，张三、学霸、阿乐回顾了不尽如人意的SwitchPair，并尝试以问答的形式进行分析：学霸无法明确回答阿乐的问题，但在拉回后给张三加了一些讨论时间，答题即可。Q：理论上，两人搭档应该可以在目前的工作中积累相当多的信息。那么，为什么学霸和张三在信息积累上会有差异呢？答：从Kick-Off到目前SwitchPair交接的时间跨度比较长（7天，包括周末），内容比较多。需要一些讨论才能回忆起当时的信息。另外，学霸答不上来的问题，基本都是在学霸休假的时候张三完成的。结对编程应该以任务拆分（Tasking）为前提，保证结对在当前工作上有相同的进度，从而最大限度地减少因请假造成的信息不对称问题。Q：为什么目前效果不理想？A：最初拆分任务的粒度较大，但实际上一个大粒度的任务会包含一些较小粒度的任务，这些任务的完成结果也会影响后续任务的内容。工作时，在完成这些更小粒度的任务后，关键的工作内容并没有更新到两人共享的任务列表中，从而造成信息不对称。可以尝试的做法于是，大家总结了以下可以实施的动作：初始任务拆分尝试标记可能导致任务分支的关键任务（或问题）。在完成任务的过程中，不断更新原有的任务清单，尤其是上面提到的关键任务，并根据需要记录任务的产出或关键信息。SwitchPair围绕任务列表展开，以避免遗漏内容或花费额外时间讨论断章取义的问题。问题2：在成对时，其中一个成为独奏。使用Navigator-DriverPair模式时，控制键盘和鼠标的人（Driver）有时会成为Navigator角色。在配对的过程中，一个人会处于高度集中的状态，而另一个人可能因为没有跟上而掉出配对，造成信息落差。在Pair过程中，如果你不扮演Driver的角色，你可能无法完全掌握当前的UserStory。其实以上问题有一定的内在逻辑联系，可以通过以下具体场景进行复现。在具体场景中，在小兰和阿发结对编程的过程中，小兰使用笔记本电脑连接外接显示器，通过笔记本的键盘和触摸板完成操作，而阿发通过外接显示器可以看到小兰的操作。监视器。起初，两人会在外接显示器上进行一些讨论。但是就在小蓝正在深入研究代码，写一些代码的时候，小蓝开始在自己的笔记本电脑屏幕上操作起来。随着萧澜逐渐集中注意力，议论和解释也就停止了。连续几次进入某个类查看详细代码，又切换到其他几个文件查看配置文件后，小岚写了几行代码试了一下。这样重复了几次，阿发已经不知道小兰做手术的目的了，但看到小兰一脸投入的模样，犹豫着要不要开口，又不忍心打断她的手术。于是阿发又努力了3分钟，试图跟上小岚的思路，但是想猜一个人的心思太难了，阿发终于放弃了，默默地打开电脑（手机）查看邮件（朋友圈），等小蓝有结果再同步给他。不过，整个调查过程中，小岚所获得的信息，未必会同步到阿发身上，阿发无法掌握当前工作的全貌。至此，Pair终于变成了Solo...原因分析(1)硬件设施准备不足。小蓝控制所有操作，阿发更多时候处于“被动”状态，结对编程的参与感不高，尤其是小蓝“一心一意”的时候，阿发的参与感几乎被压倒.全部“剥夺”。说明：在理解“如何进行结对编程”部分已经解释过，结对编程的两个人在硬件准备上要尽量做到对等，至少双方都有可以独立操作的键盘。(2)没有分配或交换角色的活动。结对编程是两个人的联合活动，所以每个人在活动中的经验直接影响到活动的效果。上面的例子，小岚一开始就掌握了“操作权”，到了代码调研阶段，小岚直接“抢”了思维的“方向权”，按照自己的想法去调研尝试.结果阿发在这次结对编程中的参与度极低，经验极差，最后转而单打独斗。注：为保证两人结对参与，结对编程有多种不同的练习方式（Navigator-Driver模式、乒乓模式、键盘+鼠标模式），但无论采用哪种方式，两者的他们应该练习一段时间，最后转换角色，让每个人都有机会从不同的角度分析和解决问题。(3)缺乏有效沟通。结对编程与其说是一种编程风格，不如说是一种“社交”活动。然后，在整个过程中，配对两个人需要大量的高强度交流。上面这一幕，一方面是萧岚想要展开深入调查的时候，却没有说明来意，这让阿发开始有些摸不着头脑了。另一方面，当阿发努力尝试，但还是觉得自己跟不上萧岚的操作时，却没有向萧岚说明情况，进一步拉大了两人的“信息鸿沟”。可以尝试的做法针对以上问题，可以：每对至少有一个人使用公司申请的键盘和鼠标（自备），保证每个人想操作就操作的条件.根据拆分任务列表，每完成1（X）项任务，每对将交换角色。练习提问。当两个配对的人中的任何一个发现他们的思维不一致时，他就会暴露问题并通过提问来解决问题。问题三：SwitchPair频率高，通信成本高。Pair过程会产生大量的交流。频繁的SwitchPair会增加这种通信的开销。那么如何从这种高频的SwitchPair活动中获得更高的收益呢？个人收入呢？具体场景团队近期正在尝试提高SwitchPair的频率，从之前的两周一次，到现在的一周一次，看情况还有可能增加。而这也给阿花造成了困扰，因为几乎每一次结对编程，阿花都会和他的搭档讨论很多问题，而几乎每一次SwitchPair，阿花都需要花费大量的时间去和新的搭档整合这些讨论的结果。解释。阿花觉得这样降低了工作效率，而且她并没有从中得到额外的好处，为什么要增加SwitchPair的频率呢？分析原因其实，阿花可以用问题1中提到的做法来试探阿花遇到的工作效率降低的问题。另外，随着频率的增加，需要传输的信息量也会减少。再加上合理的排卡，工作效率问题的影响应该是最小的。不过，阿华提出的另一个问题，“高频SwitchPair如何获得更高的个人收益？”这不是仅靠结对编程技巧就能回答的问题。先把SwitchPair（信息流）的初衷放在一边，因为这其实是对团队有好处（一定程度上降低团队人员变动的风险）。所以，个人来说，要想从SwitchPair中受益，需要从敏捷软件工程实践的相关理论和目的入手。如果能结合“快速反馈和识别变化”，那么不难得出结论：更频繁的伴侣交流可以改变反馈信息的来源，从而改变反馈的角度，有利于个体识别自己的优势和优势。不同角度的弱点。无论是通过观察主动学习还是通过收集反馈，都提供了更丰富的输入。与单个合作伙伴合作的时间较短，但保持定期轮换，提供了适当的时间（大约一个月）来尝试和应用一些更改，以便下次轮换同一合作伙伴时可以收集验证反馈。可以尝试的做法如果想在高频SwitchPair的实践中最大化个人利益，需要充分利用此时的机会和资源，即不同小伙伴的视角，结合反馈机制，您可以轻松构建个人Purpose，有针对性的改进计划。然后，在每个SwitchPair之前，先收集上一个合作伙伴在这段合作期间的反馈。注意：SwitchPair的频率不一定要高，只要能保证工作需要的关键信息在团队内部充分流动即可。结对编程只是程序员在工作中会用到的一种技能，所以只要是一种技能，都会通过时间、训练和思考的积累来提高。稳扎稳打，时间会给出最好的回馈！
