跌跌撞撞地敏捷之路——怀念那段结对的日子

现在，如果有人问我要不要在项目中实施结对编程，我会第一个站出来大声地说：“坚决要实施结对”。

这个项目初次尝试走敏捷，从一开始对敏捷的不了解，团队成员的点滴摸索，到中间的渐入佳境，到最后的打回类CMM的原点，这种在一个项目中“大起大落”的经历使我倍加爱上敏捷，倍加怀念结对走过的日子。

项目启动初期，没有尝试结对编程，还是走CMM的老路子，一个人分配一个任务，然后各自拿着领到的任务，开始“孤零零”地在自己的电脑前埋头苦干：造代码、做测试、改问题，还好是项目初期，大家心情都比较轻松，不觉得枯燥无味，不觉得累，就这样走过了敏捷的摸索阶段。

到了第二个迭代，由于有了前期的摸索、经验教训，大家知道如何划分story、task，知道一个task必须控制在一两天就能完成的范围内，然后就有人提出尝试结对编程的想法，就这样揣着“先尝试下，不行再按老路子走”的策略开始走上了结对的路子。不试不知道，一试整个团队都爱上了这种开发模式。

和很多XP书上介绍的一样，两个人一台电脑，两个人一起讨论实现的细节，然后就编码，一个人在敲键盘，一个人在旁边“盯”着。负责“盯人”的人发现敲出的代码有问题，就立即指出来并讨论，然后“盯人”的操作鼠标选中有问题的代码，敲键盘的开始改选中的代码，有时“盯人”的人直接夺过鼠标键盘直接操刀写代码。敲码人在编码过程中，盯人的人也有时间去进一步思考细节，如边界情况是否处理了等，当然敲码人也经常会在敲码过程中提出疑问。就这样两个人边编码，边讨论，一起解决问题，质量提高了，整个过程大家也很愉悦，因为不再是“孤零零”一个了。结对也让人更加高效，更加专注，没有了经常间歇性的查看邮件的功夫。

实施结对，结合合理的task周期的制定，更能提高团队成员的战斗力，因为每天或每两天就能有一个任务、功能完成，这使得大家每天都很有成就感，大家都喜欢上了这样的韵律与节奏。

虽然中间实施结对使团队的效率高了很多，但由于在前期摸索过程中欠了一些“债”（一些本该在前面完成却没有完成的工作），感觉有点“一着错，满盘皆错”的感觉，这些债一点点的拖到了后面几个迭代中，外加对测试工作投入的不充分等等因素，项目到了后面一两个迭代，不再实施结对，又走回了单兵作战的路子，大家又是“孤零零”的作战单位，我自己觉得效率低了不少，编码过程中由于没有人“盯”，经常出现一些低级的问题，而且也没有了那种一两天就能完成一个任务，有功能出的节奏，所以现在我深深地怀念那些结对的日子。

我倡导项目中自始至终都实施结对，不管是编码、还是解决问题，我认为都可以结对，两个人的智慧绝对比一个人的大，考虑的问题绝对比一个人全面。从我们这个项目的实施中看，结对绝对不会是效率的瓶颈，结对只会提高效率、提高质量。而且通过结对，可以提高团队的技能，在结对的过程中，结对双方可以互相学习、分享设计、编码经验。

不过，结对的过程也要注意配合方式，否则就有可能会出现“怠工”的现象，尤其是那种对系统中原有功能进行扩展或者改造，且结对的两个人中有一个人对该功能比较熟悉，而另一个没有接触过该功能的情况，这时如果光顾实现的话，那么熟悉的人就会在电脑面前猛敲代码，另一个人在旁边只能干瞪眼，这样子就失去了结对的意义了。在这种情况下，实施结对的过程更应该注重“互动”，可以由熟悉该功能的人先讲解下该功能的已有实现以及后面打算如何进行扩展、改造，双方订下实施方案后，由不熟悉该功能的另一个人来编写测试用例（UT），这样可以增加它对该功能的了解，然后由熟悉该功能的人来实施编码，最后由写测试用例的人来跑测试代码，通过这种方式，一来达到完成任务的目的，二来也培养了可以维护该功能的后备人员，一举两得。

 

 

 

评论

12 楼 airlink 2009-12-07  

“敏捷就是对程序员进行最深程度的压榨” 这个观点令人毛骨悚然。不如改为：

“敏捷就是对程序员的效率进行最深程度的挖掘”

虽然客观上是一件事儿，但主观愿望不一样，感受不一样，体验也不一样。

11 楼 Hotpepper 2009-06-27  

“敏捷就是对程序员进行最深程度的压榨”
我不太赞同这样的说法哦。如果你赞同这种说法，那么其它所有用于提高效率、提高质量的流程你应该也不会认可的，你应该先问问自己是否喜欢开发这个工作，或者喜欢现在所处的公司？
^_^

10 楼 不是流氓 2009-06-27  

正在进行着结对，结对能带来的就是解决困难问题的速度提升很多；
敏捷：记得某人曾经对我说过“敏捷就是对程序员进行最深程度的压榨”
不知道LZ认同不认同这个说法?

9 楼 xieye 2009-06-27  

hanjiangit 写道

by5739 写道

对于那些有人看着就真的写不出代码的人...你打算怎么弄?我还真遇到过这种人.......

确实  这个真的很难  结对的人一定要心诚 而且技术实在不能差太远。。。

既然这样，那就找心诚而且技术差不太远的同事 共事不是一件很愉快的事情吗？

8 楼 hanjiangit 2009-06-26  

by5739 写道

对于那些有人看着就真的写不出代码的人...你打算怎么弄?我还真遇到过这种人.......

确实  这个真的很难  结对的人一定要心诚 而且技术实在不能差太远。。。

7 楼 myseo 2009-06-26  

LZ的团队确实不错
不过结队的前提条件是团队成员的性格相符合，不然很难开展。
没听过一个中国人是一条龙，三个中国人一盘沙吗？

6 楼 Hotpepper 2009-06-25  

结对，并不单单只是两个人在一起把代码写完而已，抛开我说的效率提升不说，我目前体会最深的还有两点：
1）结对可以拉升项目组整体的战斗力，通过合理的搭配，最好是高低搭配，比如技能强的和技能稍差的，业务能力强的和业务能力差的搭配，通过这种搭配方式，搭配的双方在开发过程中可以互相学习，互相讨论，从而提高项目组成员的能力水平。如果在多个项目组中，甚至同一个项目中的不同迭代中，呼唤结对的人员，时间长了，这种能力提升的效果就会更强；
2）通过结对，可以为项目组培养模块后备人员。在对旧模块进行功能改造或者扩展时，可以让一个熟悉该模块的人和一个不熟悉该模块的人进行结对，不过在结对过程中不能只是为了完成任务而由熟悉该模块的人狂造代码，如果这样就失去了结对的意义，而应该象我上面说的，进行互动，熟悉该模块的人要把另一个人培养起来。通过这种方式既可以完成任务，也可以培养模块后备人员，而且可以把一些熟悉系统的人释放出去去开发新功能。

以上两点，对于项目管理人员来说应该是很有吸引力，目前我们的项目组就这样实施着，效果也还可以。

对于上面有人说，“那些有人看着就真的写不出代码的人”，如果真的有这种人在项目中，对于项目管理人员来说，不管是不是结对都是一样的效果，既然他写不出代码，而又得把他用起来，那么为什么不考虑让他去“打打杂”，比如说搭集成环境、写测试用例，做测试等等。具体问题，要具体解决，不要拿着些极端的事来否决一个“新生”事物。

引用

我很不喜欢两个人一起写代码,记东西必须要脑,手一起行动.才能记得更快.

如果个人能力很强，又不喜欢和别人分享的人，只好例外安排了，不过，在一个项目中不提倡个人英雄主义，一个项目是要靠所有团队成员的共同努力才能成功的，既然个人能力强，为什么不能Open点，把自己的知识贡献出来呢？个人再强，也不可能把自己把一个产品开发出来呀。

从长远来看，结对绝对不会效率的瓶颈。不过，结对肯定是要讲究技巧的，另外，也要求大家要Open点，在实施过程中，对问题有疑问等，应该Open点，实时指出，藏着耶着，只会让问题沉淀下去，只会提高后期维护的工作量。

5 楼 flyfan 2009-06-25  

写代码还有人看着……心寒

4 楼 swen00 2009-06-25  

没尝试过，但持怀疑态度...

3 楼 by5739 2009-06-23  

对于那些有人看着就真的写不出代码的人...你打算怎么弄?我还真遇到过这种人.......

2 楼 1314520ln 2009-06-22  

那是你自己工作的效率有问题,单元测试你自己不会用吗


我很不喜欢两个人一起写代码,记东西必须要脑,手一起行动.才能记得更快.

1 楼 langyu 2009-06-22  

大学时有过这样的经历，很有感触。
盯人的那个人，一直在思考整个逻辑，写代码的只关注实现。写一会就换人，所以两个人对整体逻辑和实际有共同的认识，编程是非常开心的。