最近，我重新审视了日常工程实践，试图找出实际与理论之间的差距，分析其原因，并提出逐步弥补这些差距的实践方法，从而使软件交付过程更加顺畅。
本文作为“沉思录”的第一篇，将列举在实际项目交付过程中，结对编程时遇到的几个问题，并针对这些问题提供一些尝试过的解决方案。
如果您有更好的建议，欢迎共同讨论?。
注意：以下话题不在本文讨论范围内，并且默认读者已经具备下列相关知识：
为什么进行结对编程？（如需了解，请参见维基百科（https://www.php.cn/link/2c97470b88a7147de0853a9b6ba8d0ce）怎样开始结对编程？（如需了解，请参见《7个你需要知道的结对礼仪》（https://www.php.cn/link/2b20b3682e832df224a5c404d8f9f365））
工作环境上下文
团队由9人组成（1名业务分析师（BA），1名质量保证（QA），1名团队领导（TL），6名开发人员（Devs））。BA、QA、TL基本都是独立工作，开发人员则采用结对工作。每对结对同一时间只会处理一个用户故事（User Story），直到该用户故事进入测试阶段。团队在Sprint开始时进行Switch Pair活动，未完成的用户故事的结对中，会有一人留下来完成，以确保卡片上下文充足。Switch Pair将按照结对轮换表进行，以确保所有开发人员都有均等的结对机会。
基于以上上下文，我们遇到了以下实际问题：
问题1：Switch Pair时，需要交接的内容过多
Switch Pair时，如果需要交接的内容过多，可能会遗漏一些细节信息。为了补充这些遗漏，会陷入更多、更深入的讨论。
具体场景：张三和薛霸经过一周的结对编程，处理一个无法进一步拆分的复杂用户故事，但未完成，薛霸被留下来继续工作，并准备与阿乐开始新的结对。
然而，薛霸在向阿乐介绍当前工作进度时，无法清楚地说明之前编写的代码与用户故事的对应关系及必要的上下文。
于是，这对结对不得不将张三重新拉回来进行上下文交接，三人讨论时间较长，并且会重新讨论之前已经讨论过的问题，降低了工作效率。
分析原因：张三、薛霸、阿乐对这次效率不尽人意的Switch Pair进行了回顾，尝试通过问答形式进行分析：
对于阿乐的问题，薛霸无法清楚解答，但在拉回张三后，通过额外的讨论时间就可以解答。问：结对的两人在当前工作中，理论上应该能够积累相当的信息。那么，为什么当前薛霸和张三出现了信息积累差异的情况？答：从卡片启动到Switch Pair的时间跨度较长（7天，含周末），包含内容较多，需要一些讨论来回想起当时的信息。另外，薛霸无法解答的问题，基本都是张三在薛霸请假期间完成的。
结对编程理应以任务拆分（Tasking）为前提，以确保结对两人对当前工作进度一致，尽量减轻请假带来的信息不对称问题。问：为什么当前的效果并不理想？答：最初拆分的任务粒度较大，但实际上，一个大粒度的任务中会包含一些较小粒度的任务，这些任务的完成结果还会影响后续任务内容。在工作时，完成这些较小粒度的任务后，没有将关键工作内容更新到两人共享的任务列表中，从而导致信息不对称。
可尝试的实践：大家总结出以下可以实行的行动：
初始任务拆分时，尽量将可能会产生任务分支的关键任务（或问题）标出。在完成任务的过程中，保持最初任务列表的更新，特别是上述的关键任务，按需记录任务的产出或关键信息。Switch Pair围绕任务列表进行，以避免出现内容遗漏或花费额外时间讨论上下文外的问题。
问题2：Pair时，其中一人变Solo
采用Navigator-Driver结对模式时，掌握键盘和鼠标的一人（Driver）有时会兼任Navigator角色。结对过程中，一人会处于高度集中状态，另一人可能会因为跟不上而从结对中脱出，产生信息断层。如果不担任Driver角色，可能无法完全掌握当前用户故事的全貌。上述问题有一定的内在逻辑联系，可以通过下面的具体场景来复现。
具体场景：肖兰和阿发在结对编程过程中，肖兰使用自己的笔记本电脑外接显示器，并通过笔记本的键盘和触控板完成操作，阿发则可以通过外接的显示器看到肖兰的操作。
起初，两人会对着外接显示器进行一些讨论。
但在深入调查代码和编写代码时，肖兰开始对着自己的笔记本屏幕操作，随着肖兰逐渐集中精力，讨论和解说停止了。
在连续几次进入某个类查看细节代码，再切换到其他几个文件中查看配置文件后，肖兰写了几行代码试了试。
如此反复几次后，阿发已经不清楚肖兰所进行操作的目的了，但他看着肖兰投入的样子，欲言又止，不忍心打断她的操作。
于是阿发又努力了3分钟尝试跟上肖兰的思路，但猜透一个人的心思何其难也，阿发最终无奈放弃，于是默默转向自己的电脑（手机），去看看邮件（朋友圈），等待肖兰有了结果再同步给他。
然而，肖兰在完成调查整个过程中获得的信息，却不一定都能同步给阿发，阿发也就无法掌握当前工作的全貌了。
Delphi语言参考 中文WORD版
本文档主要讲述的是Delphi语言参考；Delphi是一种结构化、面向对象，类型强健，编译执行的高级语言,其object pascal的语法规范具有易读性好、编译快速、多单元的模块化程序设计等优点。 Delphi技术Borland的组件框架和快速开发环境。大多数情况下，本语法指引假设你使用的是Borland的开发工具。希望本文档会给有需要的朋友带来帮助；感兴趣的朋友可以过来看看
0 查看详情
至此，结对终成Solo…
分析原因：硬件设施准备不充分。肖兰掌控了所有的操作，阿发更多的时候都处于一种“被动”状态，结对编程的参与感不高，特别是当肖兰“全情投入”后，阿发的参与感几乎被全部“剥夺”。说明：在了解“如何进行结对编程”的部分有说明过，结对编程的两人在硬件准备上，应该尽量平等，至少两人都有可以各自操作的键盘。
没有分配、交换角色的活动。结对编程是两个人共同合作的活动，那么两人中每个个体在活动中的体验感就直接影响这项活动的效果。在上述例子中，肖兰一开始就掌握了“操作权”，到了代码调查阶段时，肖兰又直接“抢夺”了思维的“导向权”，随着自己的想法去调查、尝试。导致阿发在这次结对编程中的参与度极低，体验感也极差，并最终转向独自工作。说明：为了保证结对两人的参与度，结对编程存在多种不同的实践方式（Navigator-Driver模式、乒乓模式、键盘+鼠标模式），但无论采用哪种方式，两人都应在实践一段时间后，交换角色，从而使每人都有机会从不同的视角分析、解决问题。
缺少有效沟通。结对编程与其说是编程方式，不如说更多是一种“社交”活动。那么，在整个过程中，结对两人需要进行大量、高强度的沟通交流。在上述场景中，一方面，当肖兰要开始进行一些深入调查时，没有说明意图，从而使阿发开始产生迷茫。另一方面，当阿发努力尝试后，依然认为自己跟不上肖兰的操作时，没有与肖兰说明情况，从而使两人的“信息鸿沟”进一步被扩大。
可尝试的实践：针对上述问题，可以：
每对结对中，至少有一人使用从公司申请（自备）的键盘和鼠标，确保每个人都有条件能在想要操作的时候进行操作。每对结对按照拆分的任务列表，每完成1（X）个任务，交换一次两人的角色。练习提问。结对的两人中，任何一人发现两人的思路不一致时，通过提问的方式，将问题暴露，并解决。
问题3：Switch Pair频率高，引发高沟通成本
结对过程会产生大量的沟通交流，频繁的Switch Pair会使这种交流的成本扩大，那么如何从这种高频的Switch Pair活动中获得更高的个人收益呢？
具体场景：团队最近在尝试提高Switch Pair的频率，从之前的每两周提升到现在的每周一次，之后视情况仍有提升的可能。
而这给阿花造成了困扰，因为几乎每次结对编程，阿花都和搭档会讨论很多问题，而几乎每次Switch Pair，阿花都需要花费不少时间将这些讨论的结果和新的搭档解释。
阿花认为这降低了工作的效率，并且自己也没从中获得额外的收益，那为什么还要提升Switch Pair的频率呢？
分析原因：其实，阿花遇到的工作效率降低问题，可以利用问题1中提到的实践进行尝试。
另外，随着频率的提升，需要传输的信息量也会下降，再加上合理的拆卡，工作效率问题的影响应该微乎其微。
可是，阿花提出的另一个问题，“如何从高频Switch Pair中获得更高的个人收益问题？”这却不是一个单靠结对编程技能就能解答的问题。
先抛开Switch Pair的初始目标（信息流动）不谈，因为这其实是对于团队的收益（一定程度上降低团队人员变化带来的风险）。
那么，对个人而言，要想从Switch Pair中受益，就需要从敏捷软件工程实践的相关理论和目的出发，如果能结合“快速反馈，识别变化”，那得出?的结论就不难了：
更频繁的搭档交换，能使反馈的信息源变化，从而使反馈的角度变化，有利于个人从不同视角识别自身的长处与短板。无论是主动通过观察学习，还是通过收集反馈，都提供了更加丰富的输入。缩短单一搭档工作的时间，但保证周期性的轮换，提供了一个适当的时期（大约一个月）去尝试、应用一些变化，从而在下次轮换到相同的搭档时，可以收集验证性的反馈。
可尝试的实践：想要在高频Switch Pair的实践中最大化个人利益，那么就需要充分利用此时的机会和资源，即不同的搭档的视角，再结合Feedback机制，就可以很容易构建个人有目的，有针对性的提升计划。
那么就从每次Switch Pair前，向上一个搭档收集这段时间合作的反馈开始吧。注意：Switch Pair的频率不必一味求高，只要能够确保工作所需的关键信息在团队内充分流动即可。
小结
结对编程也只是程序员工作中会用到的一项技能而已，那么只要是技能，通过时间的堆积，去磨炼，去思考，就会有所提升。
稳扎稳打，时间会给予最棒的回馈！
相关参考
德雷福斯技能模型（https://www.php.cn/link/f126a36acc1144ddade56fca3cd710f5）结对编程（https://www.php.cn/link/c1dad158473d599736ffe74624b615b1）结对编程的正确姿势，你会了吗？（https://www.php.cn/link/66c20ea00d1b74e934d5935f8a3d1413）7个你需要知道的结对礼仪（https://www.php.cn/link/2b20b3682e832df224a5c404d8f9f365）
本文版权属Thoughtworks公司所有，如需转载请在后台留言联系。
以上就是结对编程踩坑指南的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/812991.html
微信扫一扫 
支付宝扫一扫 
