现在，如果有人问我要不要在项目中实施结对编程，我会第一个站出来大声地说：“坚决要实施结对”。
这个项目初次尝试走敏捷，从一开始对敏捷的不了解，团队成员的点滴摸索，到中间的渐入佳境，到最后的打回类CMM的原点，这种在一个项目中“大起大落”的经历使我倍加爱上敏捷，倍加怀念结对走过的日子。
项目启动初期，没有尝试结对编程，还是走CMM的老路子，一个人分配一个任务，然后各自拿着领到的任务，开始“孤零零”地在自己的电脑前埋头苦干：造代码、做测试、改问题，还好是项目初期，大家心情都比较轻松，不觉得枯燥无味，不觉得累，就这样走过了敏捷的摸索阶段。
到了第二个迭代，由于有了前期的摸索、经验教训，大家知道如何划分story、task，知道一个task必须控制在一两天就能完成的范围内，然后就有人提出尝试结对编程的想法，就这样揣着“先尝试下，不行再按老路子走”的策略开始走上了结对的路子。不试不知道，一试整个团队都爱上了这种开发模式。
和很多XP书上介绍的一样，两个人一台电脑，两个人一起讨论实现的细节，然后就编码，一个人在敲键盘，一个人在旁边“盯”着。负责“盯人”的人发现敲出的代码有问题，就立即指出来并讨论，然后“盯人”的操作鼠标选中有问题的代码，敲键盘的开始改选中的代码，有时“盯人”的人直接夺过鼠标键盘直接操刀写代码。敲码人在编码过程中，盯人的人也有时间去进一步思考细节，如边界情况是否处理了等，当然敲码人也经常会在敲码过程中提出疑问。就这样两个人边编码，边讨论，一起解决问题，质量提高了，整个过程大家也很愉悦，因为不再是“孤零零”一个了。结对也让人更加高效，更加专注，没有了经常间歇性的查看邮件的功夫。
实施结对，结合合理的task周期的制定，更能提高团队成员的战斗力，因为每天或每两天就能有一个任务、功能完成，这使得大家每天都很有成就感，大家都喜欢上了这样的韵律与节奏。
虽然中间实施结对使团队的效率高了很多，但由于在前期摸索过程中欠了一些“债”（一些本该在前面完成却没有完成的工作），感觉有点“一着错，满盘皆错”的感觉，这些债一点点的拖到了后面几个迭代中，外加对测试工作投入的不充分等等因素，项目到了后面一两个迭代，不再实施结对，又走回了单兵作战的路子，大家又是“孤零零”的作战单位，我自己觉得效率低了不少，编码过程中由于没有人“盯”，经常出现一些低级的问题，而且也没有了那种一两天就能完成一个任务，有功能出的节奏，所以现在我深深地怀念那些结对的日子。
我倡导项目中自始至终都实施结对，不管是编码、还是解决问题，我认为都可以结对，两个人的智慧绝对比一个人的大，考虑的问题绝对比一个人全面。从我们这个项目的实施中看，结对绝对不会是效率的瓶颈，结对只会提高效率、提高质量。而且通过结对，可以提高团队的技能，在结对的过程中，结对双方可以互相学习、分享设计、编码经验。
不过，结对的过程也要注意配合方式，否则就有可能会出现“怠工”的现象，尤其是那种对系统中原有功能进行扩展或者改造，且结对的两个人中有一个人对该功能比较熟悉，而另一个没有接触过该功能的情况，这时如果光顾实现的话，那么熟悉的人就会在电脑面前猛敲代码，另一个人在旁边只能干瞪眼，这样子就失去了结对的意义了。在这种情况下，实施结对的过程更应该注重“互动”，可以由熟悉该功能的人先讲解下该功能的已有实现以及后面打算如何进行扩展、改造，双方订下实施方案后，由不熟悉该功能的另一个人来编写测试用例（UT），这样可以增加它对该功能的了解，然后由熟悉该功能的人来实施编码，最后由写测试用例的人来跑测试代码，通过这种方式，一来达到完成任务的目的，二来也培养了可以维护该功能的后备人员，一举两得。