变化是如何产生的——有关结对编程

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

直接管理者的支持

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

少数的 Early Adopter 及 Coach

每个团队基本都会有一两个人对变化感兴趣，或者更好的情况是本身就很相信包括结对编程在内的敏捷实践，那么这些人在管理者支持的前提下会对整个团队产生持续的影响。与之类似的是我目前从事的角色，Agile Coach，在团队中推广并实践结对编程，解释why、总结how，诸如此类…… 给我印象比较深刻的是，一个原本对结对编程抱怀疑态度的开发者，在和一起结对了几个session之后，明确地告诉我喜欢适当的结对，并在之后团队开会的时候抱怨团队的结对编程不够，这也算是我做 Coach 后感觉比较有成就感的一件事情。这里有个比较重要的原则是， 与其把推动变化的精力平均地分散到每个人身上，不如先关注 Early Adopter，他们会帮你扩大影响。

代码基的大小

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

适当的强迫力及奖励

这简直就是‘胡萝卜加鞭子’，但小心使用也会有不错的效果，尤其对于一些主动性不够强的人来说，强迫至少让他去尝试，奖励也带来了趣味。一些啤酒可乐就容易让可爱的程序员们 high 起来，结对最多的人给个5、6瓶，其他人只有一瓶，或者设定一个团队结对时间总目标，达成了大家就一起分享，都是挺简单有趣的方法。当然大家都不是傻子，前提还是大家基本理解并认同结对编程这种工作方式的价值，强迫或奖励只是帮助去除人天生惰性的辅助手段而已。

看到了一个团队的变化以及结对编程给这个团队带来的受益，我很自然地更推崇这种工作方式了。一些理论上东西我已经在 结对编程地价值及注意点一文中简单讲述，但理论再好也终究只是理论，要相信，体验是必不可少的。也许有人会说，“你作为一个敏捷教练，屁股决定脑袋，自然就推崇结对编程这一敏捷实践”，但这只是表面的，如果自己不亲身实践体验并得到好处，我还真不敢就因为看了几本书就与人大吹特吹，如果自己都说服不了，有什么资格说服别人呢？

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