如果我们每天轮换结对编程伙伴会怎么样？
通过实验揭示频繁轮换结对伙伴的好处
结对编程的好处已被广泛接受，但关于结对轮换的建议仍然存在争议。团队成员应该何时以及多久轮换一次结对伙伴？以及……如果我们每天都轮换结对伙伴会怎么样？我们与三个团队合作进行了一项每日轮换结对伙伴的练习。我们开发了一种轻量级的方法，帮助团队反思结对编程的优缺点以及如何解决这些问题。最初的恐惧被克服，团队发现了频繁轮换结对伙伴的好处。我们了解到，频繁更换结对伙伴可以极大地增强结对编程的好处。在这里，我们分享了我们开发的方法、我们的观察结果，以及参与团队成员分享的一些常见恐惧和见解。
2024 年 3 月 6 日
Gabriel Robaina 是 Thoughtworks 巴西公司的高级顾问，担任技术主管和开发人员。目前正在攻读应用计算硕士学位，专注于无服务器技术，他对结对编程技术和分布式系统充满热情。Gabriel 认为强大的开发实践和创造力是为客户提供创新和高效解决方案的关键。
Kieran Murphy 是 Thoughtworks 的首席顾问，常驻芝加哥。Kieran 是一位经验丰富的 XP 实践者、软件开发人员、技术主管和教练。Kieran 热衷于帮助人们在出色的软件交付中找到乐趣。
大多数开发人员都是独自工作的。任务通常分配给个人，这种做法被称为“单独编码”。进行单独编码的开发人员通常被隔离在孤岛中，这阻碍了团队内部的知识共享。这些孤岛也使得团队成员难以建立联系和个人关系，尤其是在远程工作环境中。新团队成员的入职培训很复杂，而代码审查等质量关卡的设立会导致交付效率的瓶颈。此外，将工作绑定到单个团队成员也会在该成员离开团队时（例如休假或病假）带来风险。最后，个人最终会成为系统某些区域的所有者，以及特定功能知识的咨询对象。
结对编程是单独编码的可 viable alternative。 关于结对编程 探讨了它的优点和挑战。在结对开发时，人们可以紧密合作，目标是不断共享知识和信息。这会导致更好的故事细化，因为每个人都将拥有必要的背景信息来做出贡献。此外，不需要特定的代码审查流程，因为所有代码都在动态审查。结对编程为人们相互了解和发展个人关系创造了更多机会，从而增强了团队的凝聚力。结对编程过程应伴随定期的结对轮换仪式，以便进行结对伙伴的更换。这使人们能够体验与团队中每个人合作的机会。仪式结束后，开发人员应与新伙伴分享当前任务的背景和进度，以便交付流程能够继续进行。
结对轮换的频率因团队而异。尽管为了最大限度地发挥结对编程的优势，人们更喜欢频繁的结对轮换，但一些团队报告说，频繁的结对轮换会产生摩擦。有一种看法认为，每天或每隔一天轮换一次结对伙伴，比每周轮换一次成本更高，也更困难。另一方面，也有一些团队每月轮换一次结对伙伴。这意味着一个人至少需要 5 个月的时间才能与团队中的其他 5 个人至少配对一次，假设在此期间没有重复配对。另一种惯例是在完成一项任务时才轮换结对伙伴，这使得频率不确定。在任务完成后轮换结对伙伴也不切实际，因为其他结对伙伴不太可能同时完成任务。
我们开始注意到，结对轮换不频繁的团队往往会出现与单独编码团队类似的症状。长期存在的配对开始变成“犯罪同伙”。上下文共享变得越困难，结对伙伴更换所需的时间就越长：在每月轮换的情况下，开发人员需要与新伙伴分享前一个月的所有上下文。我们有证据表明，我们的结对伙伴更换实践并没有产生预期的结果，因此我们决定进行一项实验，目标是通过最佳结对编程实践来提高团队绩效。
我们的实验
我们决定挑战那些不经常轮换结对伙伴的团队，将轮换频率大幅提高，作为实验的一部分。如果我们连续两周每天都轮换结对伙伴会怎么样？在这段时间内遇到了哪些困难，我们可以做些什么来解决这些困难？在这段时间内，我们是否获得了结对编程的好处？展望未来，团队是希望继续每天轮换结对伙伴，还是回到以前的频率？
我们设计了一项练习，旨在帮助团队探索频繁的结对轮换，并对其影响进行批判性分析。练习从一个小时的引导式白板会议开始，在此期间，团队成员将写下并讨论他们对以下三个问题的想法
- 为什么结对编程很有价值？
- 是什么让结对编程变得困难？
- 是什么让结对编程变得容易？
这些问题按顺序提出。团队有 3 分钟的时间在白板上张贴每个问题的答案，并有 7 分钟的时间讨论他们分享的内容。
图 2：Mural 白板，显示了结对轮换实验期间团队的反馈
在接下来的练习中，团队继续处理他们的积压工作，同时每天轮换结对伙伴。对于任何正在进行的任务，配对中的一名成员作为“锚点”留在任务中，而另一名成员则轮换到另一个任务。“锚点”每隔一天轮换一次，确保任何团队成员都不会连续两天以上处理同一项任务。
团队每天早上都会在白板会议上开会 30 分钟，讨论以下三个问题
- 是什么让结对编程变得困难？
- 是什么让结对编程变得容易？
- 今天我们应该尝试哪些实践，才能使我们的结对编程更容易、更有效？
这些问题按顺序提出，每个问题有 3 分钟的时间在白板上张贴想法，并有 5 分钟的时间进行讨论。完成后，团队会确定正在进行的每项任务的“锚点”，并协助分配新的配对。
我们每天都使用同一块白板来促进这种每日回顾，每天使用不同颜色的便利贴。这使得团队成员能够看到每天在每个领域提出的观点，从而直观地了解团队在一周内的学习和批判性思维。
在练习的最后一天，我们组织了最后一次白板会议，然后要求团队决定继续使用的结对轮换频率。然后，我们鼓励团队在未来的团队回顾中继续重新审视他们的结对轮换频率。
实验结果
在 2022 年至 2023 年期间，我们邀请了三个独立的团队分别进行为期一周的实验。这些团队都是完全分布式的，在线上合作，但从未见过面。其中两个团队分别位于美国和巴西。
每个团队在实验开始时都提出了类似的担忧。在下面的第一部分中，我们分享了其中的一些担忧，并描述了团队在实验过程中的立场是如何演变的。第二部分介绍了一些反馈，这些反馈显示了结对编程和频繁轮换结对伙伴的实际好处。
所有参与我们实验的团队都使用 Jira 或 Trello 等系统来记录和跟踪工作项，并且都使用术语“卡片”来描述这些系统中的记录。以下反馈和结果中使用的“卡片”一词就是这个意思。
是什么让结对编程变得困难，以及观念是如何改变的
“缺乏同理心、目标一致性和沟通会使结对编程变得困难”
频繁的结对轮换是建立更强大的团队动力的一种强大工具。最初，缺乏同理心和目标一致性会使结对编程变得具有挑战性，尤其是当团队成员不熟悉彼此的工作模式、节奏和专业领域时。然而，通过频繁地更换结对伙伴，团队成员有机会更好地、更快地了解彼此。这种熟悉度使得更容易产生同理心并与彼此保持一致，最终促进团队内部更牢固的联系。此外，频繁轮换结对伙伴的做法鼓励反馈文化。我们建议团队成员在结对编程结束时的简短会议上有意分享反馈，从而促进持续改进和更好的协作。
“结对编程时间经常被打断”
团队报告说，由于缺乏长时间的不间断工作时间，频繁的中断给结对编程带来了挑战。为了解决这个问题，团队制定了下午的核心工作时间，在此期间尽量减少中断。因此，会议被改到早上或一天结束时举行。此外，团队内的配对利用番茄工作法或其他明确的时间盒方法，以最大限度地提高他们在有限工作时间内的效率和生产力。
“每天更换结对伙伴会让我们变慢”
有一种观点认为，增加轮换频率会导致产品团队认为交付绩效下降。他们倾向于认为，更多的轮换会导致效率降低和产出放缓。
开发人员也有一种看法，认为频繁的轮换会带来额外的开销，从而减缓团队的速度。这归因于需要不断共享正在进行的工作的不断变化的背景，而这被认为是一个耗时的过程。
然而，更频繁轮换的支持者认为，随着频率的增加，共享上下文变得更加高效。这归因于这样一个事实，即如果频繁地交换配对，通常需要传达的上下文信息更少。此外，当每个团队成员都对正在进行的任务有更全面的了解时，共享上下文的效率会进一步提高。此外，频繁的配对切换为团队成员创造了建立流程以促进上下文共享的机会。
随着时间的推移，频繁轮换的做法变得更容易管理和精简。随着团队习惯于这种方法，与频繁轮换相关的初始挑战会减少，从而使流程逐渐变得更容易和更有效。
频繁轮换结对伙伴的经验效益
“当你更频繁地进行上下文共享时，它会变得简单快捷”
我们从所有三个团队那里听到的一个担忧是，在进行中的工作中交换配对成员会导致与新配对成员共享上下文的问题。事实上，对于每个团队来说，这似乎是长期配对的最强烈动机。
在每个团队的看板中，我们发现这种担忧会在最初几天被提出。团队成员会建议一些常见的方法来简化上下文共享，到实验结束时，这就不再是一个问题了。每个团队都出现了一种做法，即让配对在结束一天的工作时在卡片本身上添加注释，简要记录当天完成的工作和决策。他们还可以从卡片中维护的待办事项列表中添加或删除项目。这些简单的做法有助于卡片本身承载正在进行的工作的上下文，而不是让这些上下文驻留在特定的团队成员那里。
我们发现每个团队都发现了与卡片相关的新做法。在我们每天的讨论中，团队成员会要求在卡片中保留更多上下文、更小的卡片以及卡片中的持续评论。
“信息在团队中流动”
这是我们听到的更令人兴奋和有见地的评论之一。团队发现，在实践中，锚定人员在编码会话开始时与新配对共享上下文并不需要很长时间。没有太多新的上下文需要共享。此外，团队发现，在处理了团队积压的许多其他卡片之后，更容易理解任何卡片。频繁的配对轮换加速了这种经验的获得，因为团队成员能够每周处理更多种类的任务。
“知识孤岛无法维持”
每个团队都包括具有不同经验水平和专业领域的成员。团队最初认为这种多样性对频繁的配对轮换来说是一个挑战。在实验之前，每个团队都在组织配对以及分配给配对的卡片时考虑了谁是初级或高级团队成员，谁是前端、后端或开发运维专家，谁有在代码库的特定领域工作的经验，等等。维护这个复杂的矩阵使得频繁切换配对变得困难，并加强了团队中的知识孤岛。
在实验的每日配对轮换中，不可能维持这些规则。随着配对每天轮换，团队成员被迫在代码库的不熟悉领域工作。此外，任何团队成员在不熟悉的领域工作，风险都要小得多，因为该成员只会在卡片上停留一两天，然后将其传递给其他人。
我们的团队发现，频繁的配对轮换可以平衡经验对卡片的影响。长期团队成员可以为新成员消除障碍，并分享知识，帮助他们加速对代码库和开发工具的增长和学习曲线。
实验几个月后，一个团队给了我们一些有趣的反馈：他们发现，当生产中出现问题时，他们不需要仅仅依靠一个人来调查和修复它。团队可以指派任何人来解决问题。此外，另一个反馈提到，即将到来的配对轮换带来了新的背景，改变了实施方向，并帮助在功能开发的早期阶段解决了问题，从而为团队节省了大量时间和返工。这些都突出了知识在团队中传播的好处。
“工作在团队成员之间流动”
团队成员发现，每个人都开发了与所有进行中的卡片相关的上下文，甚至在处理每张卡片之前。这提高了每日站立会议的效率：团队成员将分享见解，提前识别风险，并互相帮助消除障碍。只有当所有开发人员对所有正在进行的卡片都有足够的上下文和所有权时，这才有可能。任何一项工作都没有单个人拥有，团队中的每个人都对任务的整体进度负责。
结论
尽管实验涉及每天轮换配对，但三个参与团队最终都没有选择继续以这种频率进行。一个团队决定每 3 天轮换一次，而另外两个团队决定每 2 天轮换一次。我们注意到，频繁的轮换揭示了团队开发过程中的瓶颈和摩擦点。选择每 3 天轮换一次而不是每天轮换一次与解决这些障碍有关。
通常情况下，团队成员每天只有几个小时（通常是零散的）进行配对。团队成员觉得他们需要不止一天的时间才能获得有意义的配对体验。反过来，这也可能表明开发时间在几天内高度碎片化。这是团队选择比实验中实践的频率更低的原因之一。
实验过程中遇到的许多挑战都不是绝对的，而是会在迎难而上时减少（反之，如果回避则会增加）。该实验为参与者提供了一个每天反思配对挑战并讨论替代解决方案的机会，以便团队共同解决。在实验仪式中投入的时间和精力获得了很高的投资回报。
总的来说，进行实验极大地提高了这些团队中配对轮换的频率。其中一个团队从每月轮换一次改为每 3 天轮换一次。这种频率的增加是团队认识到短期配对的好处（例如更好的知识共享和团队建设）的结果。在实验过程中，团队成员还报告说，参与实验让他们更多地了解了配对最佳实践。此外，进行配对回顾和反馈交流会议促进了团队中的反馈文化。