培训真的没用吗？

在我跟同事聊起培训的时候，他们对培训的认知大概是这样子：”我们团队成员的架构能力不足，没法落地微服务，你们来给我们上一个DDD的课吧…” 诚然，这种模式在培训市场是普遍存在的，组织斥巨资邀请大牌培训师，上个几天的课，培训师拿钱走人，然后呢，可能就没有然后了。

团队之所以需要一个培训，无非是因为面临自身无法有效解决的问题，亦或识别出潜在的风险（以花钱为目的另当别论）。问题通常源于流程和人两方面，流程的问题最终也能归结到人身上，人的问题又很容易被定义为能力的问题，如此一来团队便寄希望于借助外部力量来提升团队的能力。这种想法没毛病，毛病在于培训往往无法有效解决能力问题，除非培训能够回答以下两个问题：

1. 如何让学员的认知发生实质性的转变？
2. 如何让学员将知识有效地转化成技能？

实践证明，单纯的培训很难给出答案，从而产生了培训无用论[1] 的观点。然而，培训真的没用吗？如果没用，为什么一些大厂都在大力推行员工培训呢？

能力建设的团队自治观

思沃内训[2]是ThoughWorks中国区负责人员能力建设的团队，我们同样面临着跟外部培训相似的困惑：培训之后无法保证团队发生实质性的提升。 要改变现状，我们必须要比培训做的多一点，站在更高的视角去看团队对培训的诉求，不难发现团队是希望通过有效的能力提升去解决实际问题，这便升级为一个复杂的能力建设问题。

最理想的能力建设活动应该由团队内部自发组织，一来具备更好的On-Boarding土壤，二来更符合自组织的敏捷团队特征。在ThoughtWorks不乏这样的学习小组。然而，随着公司业务的扩张，新老同事快速更替，能力建设遭遇瓶颈，内训团队便承担起特殊的外部教练角色。

教练本身不会直接着手解决团队面临的问题，教练的主要职责是帮助团队自己解决问题，最终还是要依靠团队自身发力，取之于团队、用之于团队。知易行难，做好这一点呢？带着这些思考，我们落地了一场超越培训的训战。

超越培训的训战模式

训战模式的核心思想是培训 + 实战，该模式需要统筹规划培训前、中、后三个阶段，做到训前瞄准、训中调整、训后复审，将单纯的培训变成一个有效的能力建设活动，实现价值闭环。

与传统培训方式不一样的是，我们在训前做得更加充分精确，为训中留有足够的时间和空间，实现课程快速迭代，后期结合至关重要的训后复审，通过实战来内化知识。该模式的核心指导原则是：跟团队保持紧密连接。基于这些创新的想法，辅以4个关键步骤来完成训战：

教练在前期深入团队，分析团队现状，准确定义问题，为团队量身定制解决方案。培训交付期间，通过教练引导技巧深度激发团队成员的思考和讨论来颠覆或加强他们固有的认知。最后，围绕训战计划来促进团队的知识转换。

下文我将通过实践案例对训战模式做一个全面的阐述。这是一个服务于海外知名大企业的业务团队，前期高质量交付赢得客户的信任，促成了更多业务合作机会，团队规模亟需扩充。此时，原本新人占比大的现状伴随着扩充继续加剧。如何提升团队开发人员能力、保证敏捷技术实践的良好落地成为团队即将面临的一大难题。

定义问题 – 深入团队

问卷或访谈的方式呈现出来的很可能是冰山上半部分的景观。为了探索下半部分，我在前期深入团队内部获取团队日常工作状态、技术栈选型以及人员的相关情况，并出了一个初步的分析报告：

基于分析报告，跟TL达成初步方案是上OOBootcamp五抓手（OO、Clean Code、Simple Design、Refactoring、TDD）。有了五抓手这把枪，不能着急开火，我需要弄清楚团队对这些实践的实际的落地情况。通过参加团队的代码评审以及详细的代码库扫查，我果然收到了惊喜 — 代码库测试覆盖率高达90%，代码分层、模块化都不错（似乎已经做的很好了）。

当前代码库的良好状态离不开团队的对Clean Code的重视，再加上团队刚刚对原本业务代码量不大的代码库做了较大规模的重构。即便状况良好，团队依然非常渴望掌握工程技术实践的最佳姿势，尤其是TDD。

基于这些调研分析，我对问题域重新划重点：

1. 团队成员Second Tier入职时间偏短，相关敏捷技术实践掌握深度不够，担心影响后期交付质量。
2. 技术实践在后期Ramp-up保持最佳姿势一致性有难度，存在辜负客户期望、降低客户信任度、难以保持标杆形象的风险。

设计方案 – 量身定制

不难看出此次能力建设活动属于风险预防性质的。虽然没有太紧迫的痛点，但团队已经暴露出一个关键的信号 — 团队已经在尝试的过程中产生困惑，渴望得到解答，并通过实践掌握最佳姿势。该信号给了我一个方向：借助大量的实践操练和充分的思维碰撞来加强训战的效果。基于此，我搬出了承载了五抓手的法宝OO Bootcamp[3]，并一切为8，每周3次，每次晚上2~3小时，形成了非常6+1的两周拉锯战模式。

依赖于口口相传的OO Bootcamp在课件标准化上沉淀颇少，这也给了我充分的空间让我去设计训战方案，对于训的设计，我重点兼顾了两点：

1. 定制化调整。针对团队的真实情况做适当的定制化，并做好在交付的过程响应变化的准备。
2. 螺旋化共创。在课程中能够不断激发思考，试图让大家经历困惑、解惑、疑惑、再解惑的螺旋化过程。做到学员共创 Over 讲师讲解。

交付培训 – 认知转变

本环节的核心目标是：通过持续调整，辅以螺旋化共创过程，诱发认知转变。 要引发螺旋式的认知转变，最重要的一点是：放慢步伐，以学员讨论、答疑解惑为核心宗旨。因为参与这次训战的成员特殊性（TL & Second Tier），讨论的焦点主要被我引导向价值层面（Why），通过操作层面（How）的冲突来激发讨论，并在How与Why之间螺旋交替冲击，最终回归到Why上，讨论的重点也大多聚焦在团队日常工作中面临的问题上。

有意思是，当大家对价值层面理解达成一致后，在操作层面的最佳实践往往都是无果而终（By Experience），我们对最佳实践虽然未曾有明确的定义，经过这样频繁的思维碰撞，团队往往能找到一些方向。比如TDD，做Story的时候，第一步是从业务视角去做Tasking，将Tasking可视化作为一个DoD[4]，严格根据Task来编写测试用例，做到测试先行，并通过Pair来刻意练习。

铺设好明线，我在辅线上也做了一些必要的工作 — 跟团队做深入交流，了解他们当前面临的痛点，设计新的案例，尝试抛出一些引子，引发团队成员共同思考。比如如何在后端MVC架构下做TDD。

部署计划 – 技能转换

我认为一场好的训战应该由体验、反思、抽象、行动四个部分组成，相辅相成，并且能够形成一个闭环。在培训过程中，需求驱动、编码实践就是一种体验，在体验的过程中引发思考和讨论，最理想的情况下是学员自己能够从思考和讨论中抽象总结得出结论，并将结论付诸行动得以验证。

在文章一开始我就提到，能力建设最终要靠团队自身发力，主动权必须交还给团队，否则一旦教练离场，打回原形的风险很大。通过培训颠覆认知只完成了一半的工作，另一半的工作是将这些新的认知在实践中去验证。要打好下半场，就需要搬出核心法宝 — 训战计划。
训战计划类似于一个计划，它具备三个重要特征：

1. 符合SMART[5]原则，难度适中
2. 跟项目工作内容息息相关
3. 学员自己拟定并认可签字

作为教练，我协助团队成员去制定有效的训战计划。有了训战计划，就一定能够兑现吗？理想情况下，团队成员的能够足够自我管理，并落实好计划。必要的时候，借助一些轻量的管理机制和有效的激励机制，比如，组建分队、队长责任制、公开承诺发布等，另外对计划完成后进行奖励等。
作为特殊的外部教练，我需要持续重点做的事情有：

1. 培养团队内部教练，保证后期的可持续发展。
2. 训战计划执行期间，响应团队的诉求，帮助团队解决执行过程面临的阻碍。
3. 定期回访，跟踪训战计划的落实情况，了解团队的困难，并记录团队的变化。

训战的核心要素

训战的复杂度远超越了培训，既要大处着眼，用全局的视角统筹训和战，也要小处着手，紧抓各个环节，尤其是训战计划的落地跟踪。一场优秀的训战，除了方案设计、课程内容和呈现形式上的创新，还需要借助团队管理和激励的手段。综合来看，决定训战成功与否的几大核心要素有：

1. 一致的期望
2. 专业的培训
3. 承诺的计划
4. 严格的跟踪

一致的期望

在训前方案设计阶段，一项至关重要的举措是跟Stakeholder和团队成员对训战模式的期望达成一致 — 不仅仅是一场讲完就散的培训课程：

1. 对于学员，要做出源于追求卓越的自我Commitment。
2. 对于Stakeholder，要提供资源来促成训战计划落地，比如识别潜在内部教练，提供训练道场支持等。

专业的培训

教练需要对领域知识具备一定的深度，深刻理解正、反模式的利弊，拥有丰富的实战经验。同时对于教练引导能力也提出了较高的要求，推荐实施以学员为中心的共创式教学。另外，还需要具备对实时反馈的响应力，能够快速调整优化设计。

承诺的计划

学员基于培训的内容，结合实际项目中遇到的问题，亲自挂帅拟定恰当可行的训战计划，并立下”军令状”，最终做出公开承诺、告示”天下”，若能借助管理激励机制形成彼此轻量的竞争态势会取得不一样的效果。

严格的跟踪

训战的效果取决于训战计划是否合理以及能否有效执行落地，后期严格的跟踪尤为关键。首先，可以在团队内部培养教练，来帮助成员解决执行过程中遇到的问题，同时敦促计划的推进。其次，在流程管理和奖惩机制上，Stakeholder的关注、必要的激励以及恰当的惩罚技巧都会影响跟踪效果。至于如何操作，团队因地制宜即可，推荐正向激励。

写在最后

训前瞄准、训中调整、训后复审这种基于业务团队的训战模式，通过4个看似很平凡的关键步骤，围绕着训战计划来促进行动学习，帮助团队将知识转换成技能，有效地实现价值闭环。

培训到底有没有用，我们给不出一个标准的答案，我们能做的是探索更高效的能力建设模式，尝试比培训多做一点点。

注释

1. 培训无用论，参考文章《然而培训并没有什么用》
2. 思沃内训团队，ThoughWorks中国区负责人员能力建设的团队，相比于其他外部培训机构，内训团队的优势在于深耕ThoughtWorks，充分理解ThoughtWorks文化。
3. OO Bootcamp，全名为“面向对象训战营”
4. DoD, Definition of Done
5. SMART
   • Specific
   • Measurable
   • Attainable
   • Relevant
   • Time-bound

---

更多精彩洞见，请关注微信公众号：ThoughtWorks洞见

结对编程远远不是两个程序员坐在一起写代码那么简单。 — 鲁迅（没有说过）

结对编程

结对编程可能算是比测试驱动开发更具有争议的敏捷实践了，事实上，仅有很少的团队可以很好的实施它并从中受益，对于更多的团队来说，即使在践行敏捷的团队中，也常常会分为旗帜鲜明的两个阵营。提倡者往往会强调结对编程在“传递领域知识”，“减少潜在缺陷”，“降低信息孤岛的形成”等方面的作用；而反对者则认为结对编程在很多时候都是在浪费时间：开发者在实践中很多时候都难以聚焦，容易产生分歧，另外个人的产出往往也难以度量。

这篇文章不打算讨论结对编程对效率的影响，也不讨论要不要进行结对编程，当然也不会涉及以何种力度来执行结对。这里的假设是团队决定采用结对编程，但是对于如何实施存在一些疑虑；或者已经在采用结对编程的团队里，发现很多时候结对编程并没有很好的发挥作用，需要一些更有实践意义的指导。

结对编程远远不是两个开发者坐在一起写代码那么简单。作为一种科学且充满趣味性（才不是）的工程实践，事实上它是有一些基本原则的，团队里的开发者需要正确的实施这些原则，结对编程才有可能为团队带来实际的受益。

假设你找到了另一个程序员，并且已经准备好一起来编码实现一个具体的业务需求。在开始着手开始结对之前，你首先需要setup环境。

硬件设置

工欲善其事，必先利其器。首先你和你的peer需要一个大的外接显示器和有一个可以调节高度的桌子（当然也可以用纸箱子DIY一个低配版）。这一点往往被初学者忽视，而事实上它可以直接决定结对能不能作为一个可持续的团队工程实践。如果你的颈椎长时间处于不舒服的状态，你的注意力很快会退散，精神会变得难以集中，而一个处于病态的身体是无法支撑长时间的编码工作的。

在开始之前，请将屏幕调整到舒适的高度，以不仰头不低头为度（身高不一样的两个人可以通过调整椅子的高度达到基本一致）。此外还要注意看屏幕的角度，如果你需要抻着脖子才能看清楚屏幕，那么当时间稍长一点时，你的颈椎也会非常吃力。因此，如果条件允许的话，你和你的peer可以使用双屏来进行结对。

当然，还有一些常见的其他关于硬件准备的细节，比如：

• VGA/HDMI转接头
• 充足的电源
• 键盘/鼠标转接头
• 便签和笔

纸和笔永远是你（们）的好朋友，在实际动手写代码之前，请拿出纸笔来将要做的事情划分成更细粒度，可以验证的任务列表，贴在显示器的下边缘。最后，另外记得将手机调成震动模式，利人利己。

软件设置

硬件准备好之后就可以进行软件的配置了。软件问题远比硬件复杂，因为大部分开发者都有自己钟爱的工具集，小到curl/wget，大到Vim/Emacs，不要期望在这个问题上和peer达成一致，这是可遇而不可求，可望而不可即的。

根据我自己的经验而言，高级一些的IDE比如JetBrains出品的Intellij，WebStorm等都可以随意切换快捷键集合（keymap）。如果你和peer就快捷键的使用上无法达成一致，在轮到你输入代码的时候，你可以切换到自己熟悉的Keymap，反之亦然。

在Intellij/WebStorm里，你可以通过ctrl+来切换各种设置，比如选择3就可以切换不同的Keymap，然后在下一步的窗口中按照自己的喜好进行切换预设的Keymap。某项目的王晓峰（Vim党）和张哲（Emacs党）尤其擅长此技，他们两人结对时，可以做到在抢键盘的瞬间将keymap切换到自己的挚爱而对方无察觉的地步。

这种技法事实上仅仅对于结对双方都有很高超的键盘操作能力的前提下，也唯有这种场景下，双发可以互不妥协。对于另一种场景（可能在实际中更为常见），比如结对一方键盘技巧和操作效率低下，影响结对流畅程度的场景，则需要效率低下的一方自己摒弃陋习（使用鼠标而不是键盘），快速赶上。

和别人结对之前，你需要至少熟悉一个IDE/编辑器，比如通过纯键盘的操作完成

• 按照名称查文件
• 按照内容搜索
• 定位到指定文件的指定行/指定函数
• 选中变量，表达式，语句等
• 可以快速执行测试（可以在命令行，也可以在IDE中）

熟常基本Shell技能和常用命令行工具的使用，可以完成诸如

• 文件搜索
• 网络访问
• 正则表达式的应用
• 查找替换文件中的内容

等操作，这样在结对时可以大大提高效率。这些都是稍加练习就可以掌握的技能，并没有多少技术含量在内，而且学会了可以收益很久。

当知识不对等时

好了，铺垫了这么多，终于到了正题部分。最理想的结对状态是，双方的技能水平相当，知识储备基本类似，可以非常流畅的进行交流，在结对过程中可以完全专注在需要解决的问题本身上，讨论时思想激烈碰撞，编码时键动如飞，不知日之将夕。这种场景下完全不需要任何技巧，随心所欲，自由发挥即可。与此对应的另一种场景是双方都没有任何储备，技能也无法胜任，这种情况我们需要在项目上完全避免。

这两种极端的情况之外，就是不对等的场景了，这也是现实中最为常见的case：很多时候，结对双方会有一个人比较有经验，而另一个人则在某方面需要catchup。比如一个老手带一个新手，或者一个擅长业务的开发和另一个该领域的新人结对等。

一般而言，需要双方有一个人来做主导，另一个人来观察，并在过程中交互，答疑解惑，共同完成任务。与传统的教与学不同的是：结对需要的是两个智慧头脑的碰撞，而不是单方面的灌输。因此观察者不是单方向的被动接受，主导者也并非完全讲述。事实上结对是一个会有激烈交互的过程。

主导者

对于主导者来说，千万不要太投入，而无视peer的感受。这种场景非常常见，我自己有时候也会不自觉的忽略掉peer，自顾自的写代码，很多时候把peer当成了小黄鸭。这时候你的peer会有强烈的挫败感，也很难跟上你的节奏，从而影响结对的效果。作为主导者，需要更耐心一些，不断的和自己的peer交互。

另一个极端是，主导者太热心的coach，而忽视了给新人实际锻炼的机会。这时候需要主导者给peer更多的实践机会：比如在带着新人编写了一个小的TDD循环（红绿重构）之后，可以抑制住自己接着写的冲动（我知道这个非常困难），然后将键盘交给你的peer，让他模仿你刚才的做法来完成下一个。

有时候，当你看到peer正在用一个不好的做法来完成任务时，你可以即使让他停下来，并通过问问题的方式来启发他：

• 还有更好的做法吗？

如果peer仍然在迟疑的话，你可以进一步提示：

• 你觉得XXX会不会更好？

一个实际的例子是，你们在写一段JS代码来迭代一个列表，你的peer正在用for循环来操作一个数组，而你可以提议使用Array.map。有些时候，你的peer会给你一些惊喜的回答！他的回答甚至比你预想中的更加出色，你也可以通过这种方式来向他学习。

观察者

另一方面，作为观察者而言，结对毋庸置疑是一种特别好的学习机会，你应该抓住一切可能的机会来向你的peer学习。包括快捷键的使用，命令行工具参数的应用，良好的编程习惯等等。保持你的专注力和好奇心，比如你看到peer神器的通过快捷键删除了花括号（block）中的所有代码，或者将curl的返回值以prettify过的样式打印到控制台，或者通过命令行merge了一个PR等等。

在实践的时候，可以采取Ping-Pong的方式来互换主导者和观察者的角色。比如，A写一个测试，B来写实现，A来重构，然后换B来写测试，A来实现，B来做重构等等。开始时，可能会由一个人来主导，随着合作越来越顺畅，你们可以提高交换的频次。

保持专注

在选定了要两人一起解决的问题之后，你们需要一起完成任务划分。这样可以确保你们可以永远关注在单一任务上，避免任务切换带来的损耗。

在做完一项任务后，用mark笔轻轻将其从纸上划掉（或者打钩）。千万不要小看这个小动作的威力，它既可以将你们的工作进度很好的表述出来，也可以在任何时候帮助你们回到正在做的事情上（特别是在吃完午饭之后），另外这个微小的具有仪式感的动作是对大脑的一个正向反馈，促进多巴胺的分泌（代码写的这么开心，还要什么女朋友？）。

很多时候，我们需要暂时搁置争议，保持前行。

无法统一的意见

如果你遇到了一个固执己见的同事，而不凑巧的是你也是一个难以被说服的人，那么如何处理那些无法避免的争论呢？特别是那些没有对错之分的技术问题。比如那种编程语言更适合Web开发，比如如何践行TDD（比如自顶向下的TDD和自底向上的TDD）等等。

有时候，我们会非常坚持自己觉得对的东西，觉得那就是真理。挑战这个真理的不是傻就是二，但是用不了多久，我们就会发现，换个角度好像也说得通，特别是在和其他人结对，并突然意识到以前的那个完全无法接受的做法似乎还是有几分道理的。

在我刚做完的一个前端项目中，做技术选型时我自然的选了更早项目中使用的scss module，而团队里的另一个同事则提议使用styled-component。我们谁也没有说服谁，最后写代码的时候就有两种风格。直到有一天，我在代码库里看到了用styled-component写的很漂亮的组件，我自己尝试着把相关的scss重写成styled-componet，结果发现确实比单独的scss文件要更好维护一些，而且也不影响既有的测试。

我突然意识到，我所坚持的只是一个假的“真理”，先前的坚持和做技术选型时的理由就变得很可笑：那只不过是为了使用自己熟悉的技术而编造的理由而已。保持open mind是一件知易行难的事情，希望大家在争辩时能念及这个小例子，可能会少一些无谓的争辩。

对于这种难以统一意见的场景，我建议可以将其搁置，先按照某一种提议进行，知道发现明显的，难以为继的缺陷为止。往往你们会发现一条比较折中的路，或者一个人被另一个人说服。

棘手的任务

即使很有经验的程序员也会遇到新的领域，或者在熟悉的领域遇到新的困难。有些情况下，作为结对的两个人都对要完成的主题没有头绪。这时候非要挤在一起反而会降低速度，无助于问题的解决。

一个好用的实践是，两人分头研究，并严格控制时间。比如Time box 30分钟。不过很可能在30分钟后，你们中至少有一个人已经对要怎么做有了头绪，如果30分钟还没有头绪，则可以求助团队其他成员。

比如我在最近项目上遇到了Kerberos认证的问题，我和peer都没有接触过，在经过20分钟的独立spike之后，我发现了一篇细节很丰富的，看起来很靠谱的技术博客，而我的peer则在内部github上找到了另一个团队的可以工作的代码（虽然代码质量不是很好）。我们最终决定copy+paste，然后做重构的方式继续前进。而那篇技术博客则是一个很好的课后学习的资料。

张弛有度

注意力是一种非常稀缺的资源，普通人很难全神贯注在某件事情上超过30分钟。一旦超过这个时间，大脑就开始偷懒，开小差。这时候一个短暂的break可以让大脑得到很好的休息。人类的大脑有一个非常有趣的特性，就是它的后台任务处理能力 — 而且后台处理能力好像远远强大于前台。你可能会在去冲咖啡的路上，突然灵光一闪，那个困扰你多时的问题有了思路，而此时此刻的你的大脑明明在想如何用咖啡机冲一份拿铁。

如果遇到一个难以理解的bug，或者在设置测试环境是遇到了困难，休息一下很可能帮助你找到解决问题的新角度。为了避免长时间纠缠在冥思苦想中，你和你的peer可以采取比如番茄工作法之类的时间管理工具：

1. 从Todo列表中找出下一个任务
2. 设置一个不可中断的25分钟，开始工作
3. 时间到了之后，休息5分钟
4. 重复2-3，4次之后休息15分钟

这里有一个在线工具可以直接使用 ，你也可以用手机的闹铃工具。

结对轮换

如果结对的对象长期固定的话，pair本身又会变成新的信息孤岛。比如A和B长期负责订单模块，而C和D则一直在写门店管理，那么毫无疑问，一段时间后，A和B就不知道C和D在做什么了，不论是领域知识还是技术实践，都很难得到有效的知识传递。当一个团队规模变成10+之后，这还可能演化成更为严重的项目问题。

因此需要定期或者不定期的轮转，比如一周轮换一到两次，A和C来写订单，B和D来写门店管理，这样可以保证领域知识，工程实践，工具的使用等等知识都很好的在团队内部共享。

在一些场景下，团队采取前后端分离的方式进行开发。前端和后端的技术栈选择大相径庭，每一端都有不同的约定和复杂的配置，这会对结对轮换的实施造成障碍，而且短期来看还会影响开发效率。如果团队再大一些，DevOps可能会独立出一个小组来负责，这将导致结对的轮换更加困难。

在实践中，我发现让不同角色的团队成员轮换结对所带来的好处（伴随着短期阵痛的）远胜过知识的隔离带来的坏处。团队中的前端开发如果花费一些时间和DevOps一起结对，他会对系统的整个架构更加清楚；而后端开发和DevOps结对则可能让他意识到代码中的潜在缺陷和解决方法（比如会话外置，缓存策略等）。

尊重

作为一个最小单位的团体活动，你常常要站在你的peer的角度来看问题。如果你不愿意和某一特性的人结对，那么首先不要让自己成为那样的人。比如你讨厌只闷头写代码，不理会peer有没有跟上的那种结对方式；又或者你不喜欢和用鼠标完成又低效又别扭操作的人一起写代码（我在和这样的人结对的时候，都需要费很大力气抑制自己，才不会从peer的手中把鼠标抢过来扔掉），那么首先让自己不是那样的人。

除此之外，尊重还体现在很多其他细节中。当你不得不中断结对而去做其他事情时，务必让你的peer知道。而且在离开之前，你应该表示歉意，不要凭空消失，然后若干分钟后又凭空出现，没有人喜欢和一个不靠谱的人工作。比如10点30分的水果时间到了，你看到有人拿着你喜欢吃的桃子从厨房方向走了回来。你可以示意peer暂停一会，然后去厨房拿点水果，记得给你的peer也带上一些。

另一方面，当你的peer回来之后，你需要及时和他catchup，告诉他你正在做什么，已经做到了哪一步等等。快速的将他带入到上下文中。

控制情绪

情绪是一件非常微妙的事情，它具有很强的传染性。当你们的工作任务收到各种blocker，被各种其他事情干扰而导致进度难以推进时，一定要注意自己情绪的控制。如果你的peer一直在旁边唉声叹气，或者抱怨连连，你会变得非常沮丧，并且很难集中精力在积极解决问题上。

你可以通过积极的寻求外部帮助，或者将blocker更快的可视化出来，让团队了解，并提供可能的帮助。

课后练习

和你的peer完成了充实而卓有成效的一天之后，你需要总结一下自己记录的知识点，这是一个绝佳的提升自己能力的方法。通过实战，发现自己的缺点，并通过近距离观察别人如何解决该问题，最终会以很深刻的印象记录下来，这时候针对性的查漏补缺是可以取得非常好的效果。

比如你已经习惯使用grep来做搜索，结果你的peer娴熟的awk技巧使你打开眼界，你可以在课后专门学习一下这个工具的各种选项，并尝试熟练应用。或者你们在代码库中探索到webpack的一些特殊配置，它可以良好工作，但是你不是很明白背后的原理，这些都可以放在结对结束之后自己消化。花一些额外时间来更新你的技能可以让你在第二天的结对中更加得心应手，也可以更好的融入到结对编程带来的快乐中。

这些结对的基本礼仪，都是一些微小的细节，做好了可以让和你一起工作的人比较舒服，也会帮助你自己建立一个更加高效的工作环境。

小结

在这篇文章中，我总结了一些有关结对编程的常见的问题和解决方法。在开始进行结对之前，首先需要确保硬件设施正确setup，这样可以保证大家可以在很轻松舒适的环境中工作。在软件设置上，保证效率的前提下，可以有不同的偏好设置。当能力不对等时，恰恰是结对编程最能发挥作用的场景，不但对于观察者来说是绝好的学习过程，对于主导者而言，也可以从coach过程中看到一些不同的东西。

在结对编程过程中，你们需要始终保持专注，可以通过任务拆分的方式来帮助一直关注在单一事项上。此外，应该有定期的休息，让紧张的情绪得到缓解。为了避免大尺度上的信息孤岛，团队还需要定期的进行Pair的轮换。

总而言之，通过这些方法的使用，可以有效的促进工作效率，促进个人成长为前提，并和可以形成很好的团队氛围。

---

更多精彩洞见，请关注微信公众号：ThoughtWorks洞见