敏捷咨询师许晓斌指出结对编程顺利推行的四个原因

作为敏捷诸多实践中资格最老的实践之一，结对编程也可以算是最富争议的实践了。去年 10 月，InfoQ 中文站发表了一篇新闻《结对编程成为主流，但反响冷淡》，里面提到众多开发人员对于结对编程的负面看法。最近，敏捷咨询师、持续集成专家许晓斌在自己的博客上撰写了一篇文章——《变化是如何产生的——有关结对编程》，指出了结对编程顺利推行的四个原因，也许这些原因能够从一个侧面说明为什么前者不能成功。

在文章开头，许晓斌指出一个案例：

一个十多人的团队，十个月前，每个人都习惯在自己的一块自留地代码上劳作，当管理层推结对编程时，大部分人反应冷漠甚至抵触。今天，这个团队的几乎所有人都愿意接受结对编程这种工作方式，各个人对整个系统的了解更好了，遇到不熟悉的地方都很自然地想到找个熟悉的人来结对。

接下来，他提出问题：

同样的公司，不是所有的团队都有这样的变化，自留地式的工作方式在一些团队非常普遍，这是为什么？

在他看来有 4 个主要原因：

• 直接管理者的支持

  直接管理层就是大家直接的老板，如果是再上一层，就算他支持，如果和直接管理者的理念不一致，那也比较麻烦。管理者的理念差别很大，有人喜欢微管理，事无巨细都要了解并把握方向，为了短期效率让每个人专注在一小块代码；有人喜欢放手让团队自己思考协作，让大家多花点时间去了解别人在干什么，以让知识留到更多人的脑子里。……更偏后者的，自然也就更支持大家结对编程；如果偏前者，那就算有开发人员想结对，也会承受一些压力。因此很可能出现这样的现象：高层推敏捷转型，底层积极性也很高，中间被卡了一下，进展就变得磕磕绊绊。

• 少数的 Early Adopter 及 Coach

  每个团队基本都会有一两个人对变化感兴趣，或者更好的情况是本身就很相信包括结对编程在内的敏捷实践，那么这些人在管理者支持的前提下会对整个团队产生持续的影响。与之类似的是我目前从事的角色，Agile Coach，在团队中推广并实践结对编程，解释 why、总结 how，诸如此类……

  一个原本对结对编程抱怀疑态度的开发者，在和一起结对了几个 session 之后，明确地告诉我喜欢适当的结对，并在之后团队开会的时候抱怨团队的结对编程不够。

  这里有个比较重要的原则是：与其把推动变化的精力平均地分散到每个人身上，不如先关注 Early Adopter，他们会帮你扩大影响。

• 代码基的大小

  代码基越大，推行结对编程就越难，这是因为更难看到成果。

  为什么大家喜欢结对编程？因为它能帮助我们高速地从他人学到知识，并且在日后使用这些知识并很直接地体现我在这个团队中的价值。当知识点不大的时候，和人一起结对一两天就能基本掌握的时候，获得成就感非常容易！可是，当一块知识牵扯的代码动不动就成千上万行的时候，学习起来就不是一两天，甚至不是一两个礼拜的事情，这样，还没等你能够使用这些知识去体现价值的时候，很多人就已经对你失去了耐心，甚至你自己也感到沮丧。这也侧面印证了另一个道理，只要是软件项目，代码是一切之本，如果代码写不好，再好的流程也没太大的用处。

• 适当的强迫力及奖励

  这简直就是‘胡萝卜加鞭子’，但小心使用也会有不错的效果，尤其对于一些主动性不够强的人来说，强迫至少让他去尝试，奖励也带来了趣味。……当然大家都不是傻子，前提还是大家基本理解并认同结对编程这种工作方式的价值，强迫或奖励只是帮助去除人天生惰性的辅助手段而已。

此前，许晓斌在另一篇文章中，指出了结对编程的价值和注意点：

• 价值：
  • 显著提高代码质量
  • 促进知识分享及学习
  • 帮助团队信任及合作
  • 形成压力和专注
• 注意点
  • 注意休息和负荷
  • 注意倾听
  • 警惕沉默

除了上面的优点之外，QCon 杭州 2012 大会明星讲师陈皓在一篇博文中曾指出结对变成的缺点：

• 对于有不同习惯的编程人员，可以在起工作会产生麻烦，甚至矛盾。
• 有时候，程序员们会对一个问题各执己见（代码风格可能会是引发技术人员口水战的地方），争吵不休，反而产生重大内耗。
• 两个人在一起工作可能会出现工作精力不能集中的情况。程序员可能会交谈一些与工作无关的事情，反而分散注意力，导致效率比单人更为低下。
• 有些时候，程序员们在一起滋生不良气氛也很快。比如，合伙应付工作，敷衍项目。
• 面对新手，有经验的老手可能会觉得非常烦躁。不合适的沟通会导到团队的不和谐。
• 新手在面对有经验的老手时会显得非常得紧张和不安，甚至出现害怕和焦虑，从而总是出现低级错误，而老手站在他们后面不停地指责他们导致他们更加紧张，出现恶性循环。最终导致项目进展效率低下，并且团队貌合神离。
• 有经验的人更喜欢单兵作战，找个人来站在他背后看着他可能会让他感到非常的不爽，最终导致编程时受到情绪影响，反而出现反作用。

一名国外的敏捷专家 Gil Zilberfeld 在自己的博客中，提到自己再次捡起结对编程后的一些体会：

• 氛围很重要
• 耐心很重要
• 聆听很重要
• 提问很重要
• 态度很重要
• 搭档很重要
• 协商很重要
• 鼓励新人很重要

在文章结尾，许晓斌的总结是：

看到了一个团队的变化以及结对编程给这个团队带来的受益，我很自然地更推崇这种工作方式了。

理论再好也终究只是理论，要相信，体验是必不可少的。

推而广之，敏捷也是，大家都在谈，有人切切实实实践了，有人纯粹是转发而已。