背景
今年，我开始了使用敏捷软件交付工程实践的第五个年头，在编程知识满足工作需求之余，我开始重新审视这些融入日常的工程实践方式，去尝试找出实际与理论的差距，分析差距的成因，基于分析的结果，尝试找出可以逐步弥补这些差距的实践方式，从而让日常软件交付工作变得更加“顺滑”。
本文作为“沉思录”的第一篇，将列举 实际交付项目中，在结对编程时遇到的一些实际问题，并针对问题给出一些我正在尝试的解决方式。如有其他更好的建议，欢迎共同讨论👏🏻
注意：以下话题不在本文的讨论范围中，并且我会默认读者已经具备下列问题相关的知识:
- 为什么进行结对编程？（如果想了解，可以参见维基百科）
- 如何进行结对编程？（如果想了解，可以参见《7个你需要知道的结对礼仪》）
Pair Programming
我当前的工作环境上下文
- 9 人团队（1 BA， 1 QA， 1 Tech Lead， 6 Devs），我是 Dev 之一
- 特殊角色（BA，QA， TL）基本都是 Solo 工作，开发（Dev）Pair 工作
- 团队采取 Scrum 项目管理方式，每两周为一个 Sprint 交付周期，周三为 Sprint 的起止点
- 交付的 Feature 功能大小不定，有些可能会需要多个 Sprints，大多数情况下，在一定周期内，团队只会工作在一个 Feature 上，直到 Feature 被完整交付
- 基于 JIRA 的工作流程 ，一个 Feature 最终可以被拆分成多个 User Story，每对 Pair 同一时间只会工作在一个 User Story 上，直到该 User Story 进入测试阶段。
- 每个 User Story 都会经过 Kick-off （澄清需求），Developing（功能开发），Deck Check（快速验收校验），Testing（手工测试），Deployment（部署发布）阶段
- 通常，团队在每周三下午进行 Switch Pair 活动，User Story 未完成的 Pair，会将一人留在当前工作上，另一人离开当前卡片和其他同事工作在另一张卡片上，从而产生信息流动
- Switch Pair 会按照已有的 Pair 轮换表（如下）进行，以确保所有开发都会有均等的 Pair 机会
轮换表大概是这个样子（每个周期采用一种结对模式）：
| 小红 | 大黄 | 小蓝 | 二黑 | 阿白 | 阿花 | |
|---|---|---|---|---|---|---|
| 小红 | X | X | X | X | X | X |
| 大黄 | 结对模式1 | X | X | X | X | X |
| 小蓝 | 结对模式4 | 结对模式3 | X | X | X | X |
| 二黑 | 结对模式2 | 结对模式5 | 结对模式1 | X | X | X |
| 阿白 | 结对模式5 | 结对模式2 | 结对模式4 | 结对模式3 | X | X |
| 阿花 | 结对模式3 | 结对模式4 | 结对模式2 | 结对模式5 | 结对模式1 | X |
基于以上的上下文，我们遇到了以下实际问题：
实际问题：
Switch Pair 时，需要交接的内容过多时，可能会漏掉一些细节信息。为了补充遗漏，会陷入更多、更深的讨论。
具体场景
小红和大黄经过了一周的结对编程，手头的一张复杂 User Story 没有完成，大黄被留在了当前工作上，准备和 二黑 开始工作。可是在大黄向二黑 介绍当前的工作进度时，大黄无法清楚地给二黑说明新写的代码与 User Stroy 的对应关系和一些必要的上下文。于是这对 Pair 不得不将小红重新拉回来，进行上下文交接，三人讨论时间较长，并且会将之前已经讨论过的问题重新讨论，降低了工作效率。
分析原因
后来，小红，大黄，二黑对这次效率不尽人意的 Switch Pair 进行了 回顾和复盘，尝试利用问答的形式进行分析：
-
问： 对于二黑的问题，大黄无法清楚地解答，但在拉回小红后，增加了一些额外的讨论时间，就可以解答了。结对的两人在当前工作中，理论上应该能够具备相当信息积累。那么，为什么当前大黄和小红出现了信息积累差异的情况？
- 答：卡片从开始（Kick-Off）到当前交接（Switch Pair）的时间跨度较长（7天，含周末），包含内容较多，由于个体记忆力差别，小红和大黄都记不太清，需要一些讨论重新回想起当时的信息。另外，大黄无法解答的问题，基本都是与小红在周四完成的工作相关的，而那天大黄请假了。
-
问：结对编程理应是有 任务拆分（Tasking）作为前提的，以确保 Pair 两人对于当前的工作进度一致，以尽量减轻请假所带来的信息不对称问题。为什么当前的效果并不理想？
- 答：最初拆分的任务粒度较大，但实际上，在一个大粒度的任务中，会包含一些较小粒度的任务，并且这些任务的完成结果，还会影响后续的任务内容。在工作时，完成了这些较小粒度的任务后，没有将工作内容更新到两人共享的任务列表中，于是造成了信息不对称情况的产生。
可尝试的实践
于是，大家总结出了如下可以改进的实践：
- 初始任务拆分尽量将可能会产生任务分支的关键任务（问题）列出。
- 在完成任务的过程中，保持最初任务列表的更新，特别是上述的关键任务，需要记录任务产出及其原因。
- Switch Pair 围绕任务列表进行，以避免出现内容遗漏或花费额外时间讨论上下文外的问题。
实际问题：
- 采用Navigator-Driver Pair 模式时，掌握键盘鼠标的一人（Driver），有时会成兼任 Navigator 角色。
- Pair 过程中，有人会一直处于高度集中状态，另外一人可能会因为没跟上，而从 Pair 中脱出，从而在两人沟通的过程中产生信息断层。
- Pair 过程中，如果不是一直 Driver 的角色，可能无法完全掌握当前 User Story 的全貌
其实上述的问题是有一定的内在逻辑联系的，可以通过下面的具体场景来进行复现。
具体场景
小蓝和阿白在结对编程过程中，小蓝使用自己MacBook Pro外接显示器，使用 MacBook 的键盘和触控板完成操作，阿白则可以通过外接的显示器看到小蓝的操作。
起初，两人会对着外接显示器进行一些讨论。
但在深入调查代码时和一些代码编写时，小蓝开始对着自己的 MacBook Pro 的屏幕进行操作，随着小蓝逐渐地集中精力，讨论和解说停止了。
在连续几次的进入某个类查看细节代码，再切换到另外几个文件中查看配置文件后，小蓝写了几行代码试了试。
如此反复了几次后，阿白已经不清楚小蓝所进行操作的目的了，但阿白看着小蓝投入的样子，欲言又止，不忍心打断他的操作。于是阿白又努力了3分钟尝试跟上小蓝的思路，可是猜透一个人的心思何其难也，阿白最终无奈放弃，于是默默转向自己的电脑（手机），去看看邮件（朋友圈），等待小蓝等下有了结果再同步给他。
可是，小蓝在完成的调查整个过程中获得的信息，却不一定都能同步给阿白，阿白也就无法掌握当前工作的全貌了。
至此，Pair 终成 Solo...
分析原因
-
硬件设施准备不充分。小蓝掌控了所有的操作，阿白更多的时候都处于一种“被动”状态，结对编程的参与感不高，特别是当小蓝“全情投入”后，阿白的参与感几乎被全部“剥夺”。
- 说明：在了解“如何进行结对编程”的部分，有说明过，结对编程的两人在硬件准备上，应该尽量平等，至少两人都有可以各自操作的键盘。
-
没有分配、交换角色的活动。结对编程是两个人共同合作的活动，那么两人中每个个体在活动中的体验感就直接影响这项活动的效果。在上述例子中，小蓝一开始就掌握了"操作权”，到了代码调查阶段时，小蓝又直接“抢夺”了思维的“导向权”，随着自己的想法去调查、尝试。导致阿白在这次结对编程中的参与度极低，体验感也极差，并最终去向独自工作。
-
说明：为了保证结对两人的参与度，结对编程存在多种不同的实践方式（如下），但无论采用那种方式，两人都应在实践一段时间后，交换角色，从而使每人都有机会从不同的视角分析、解决问题。
- 领航员 + 驾驶员（Navigator-Driver）模式
- 乒乓模式
- 键盘 + 鼠标 模式
-
说明：为了保证结对两人的参与度，结对编程存在多种不同的实践方式（如下），但无论采用那种方式，两人都应在实践一段时间后，交换角色，从而使每人都有机会从不同的视角分析、解决问题。
- 缺少有效沟通。结对编程与其说是编程方式，不如说更多是的一种“社交”活动。那么，在整个过程中，结对两人需要进行大量，高强度的沟通交流。在上述场景中，一方面，当小蓝要开始进行一些深入调查时，没有说明意图，从而使阿白开始产生迷茫。另一方面，当阿白努力尝试后，依然认为自己跟不上小蓝的操作时，没有与小蓝说明情况，从而使两人的“信息鸿沟”进一步被扩大。
可尝试的实践
针对上述问题，可以：
- 每对Pair中，至少有一人使用从公司申请（自备）的键盘和鼠标，确保每个人都有条件能在想要操作的时候进行操作。
- 每对 Pair 按照拆分的任务列表，每完成一（X）个任务，交换一次两人的角色。
- 练习提问。结对的两人中，任何一人发现两人的思路不一致时，通过提问的方式，将问题暴露，并解决。
实际问题：
Pair 过程会产生大量的沟通交流，频繁的 Switch Pair 会使这种交流的成本扩大，那么如何从这种高频的 Switch Pair 活动中获得更高的个人收益呢？
具体场景
团队最近在尝试提高 Switch Pair 的频率，从之前的每两周提升到现在的每周一次，甚至以后还想提升到每三天。而这给阿花造成了困扰，因为几乎每次结对编程，阿花都和搭档会讨论很多问题，而几乎每次 Switch Pair，阿花都需要花费不少时间将这些讨论的结果和新的搭档解释。阿花认为这降低了工作的效率，并且自己也没从中获得额外的收益，那为什么还要提升 Switch Pair 的频率呢？
分析原因
其实，阿花遇到的工作效率降低问题，可以利用第一个 实际问题 中提到的实践进行尝试。
可是，阿花提出的另一个问题，“如何从高频 Switch Pair 中获得更高的个人收益问题？” 这却不是一个单靠结对编程技能就能解答的问题。
抛开 结对编程 和 Switch Pair 的初始目标---知识流通。这其实是对于团队的收益，会在一定程度上，降低团队人员变化带来的风险。 那么，对个人而言，要想从 Switch Pair 中受益，就需要从敏捷软件工程实践的相关理论和目的出发，如果能结合“快速反馈，识别变化”，那得出👇🏻的结论就不难了：
- 更频繁的搭档交换，能使反馈的信息源变化，从而使反馈的角度变化，有利于个人从不同视角识别自身的长处与短板。无论是主动通过观察学习，还是通过收集反馈，都提供了更加丰富的输入。
- 缩短单一搭档工作的时间，但保证周期性的轮换，提供了一个适当的时期（大约一个月）去尝试、应用一些变化，从而在下次轮换到相同的搭档时，可以收集验证性的反馈。
可尝试的实践
想要在高频 Switch Pair 的实践中最大化个人利益，那么就需要充分利用此时的机会和资源，即不同的搭档的视角，再结合 反馈（Feedback）机制，就可以很容易构建个人有目的，有针对性的提升计划。
- 那么就从每次 Switch Pair 前，向上一个搭档收集这段时间合作的相关反馈开始吧。
小结
结对编程 也只是程序员工作中会用到的一项技能而已，那么只要是技能，通过时间的堆积，去练习，去思考，就会有所提升。基于德雷福斯技能模型， 找到自己当前的这项技能定位，去制定合适的技能提升计划，稳扎稳打，时间会给你最棒的回馈！
网友评论