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

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

在文章开头,许晓斌指出一个案例:

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

接下来,他提出问题:

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

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

  • 直接管理者的支持

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

  • 少数的 Early Adopter 及 Coach

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

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

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

  • 代码基的大小

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

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

  • 适当的强迫力及奖励

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

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

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

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

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

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

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

在文章结尾,许晓斌的总结是:

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

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

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

郑柯 郑柯,实用的理想主义者,相信:每天改变一点点,这个世界会更好。

This entry was posted in Agile, Best Practices. Bookmark the permalink.

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s