开发时间“浪费”不明显
l 表现
这个开发时间“浪费”不明显是相对于结对编程与传统开发模式而言的，至少让老板没有感觉到人员分配方式带来了人员的浪费。大家都知道，结对编程需要两个人共用一台计算机、一套键盘、做同一个故事，这样的开发方式往往会给人感觉浪费了一个人，虽然事实上未必如此。但是如果哪个项目经理第一次甚至说前几次这样做，估计大多数老板都会表示反对的，因为他会感觉自己的技术人员只有一个人在做事情。同样，在2006年的敏捷中国开发者大会上，ThoughtWorks的总经理也提到了这个问题，他的解释是这样的：当两个人合作三个月以后，效率会超过两个人单独编程的效率！但请注意：这里有一个时间前提——三个月以后。
三个月这个时间未必是真实确凿的时间分界线，它只是一个模糊的大概的时间范畴，如果两个人配合的好，也许只需要两个多月，如果配合不好，也许需要四五个月的时间，或者更长的时间……。我相信这样的说法连Martin也不会反对的。从这个时间界限上，大家可以看看国内公司的项目状况，然后再继续我们的讨论。
l 分析
项目情况：国内很少有时间限度较长的项目，大多数项目都是在三个月到半年时间内结束，有些甚至只有一个月。这样的时间特性，将使得这个三个月的期限变成了一句空谈，也就是说，当两个人磨合好的时候，项目已经结束了。这时候，有人会说，下一个项目还可以继续合作呀，好，那我们来看看国内项目团队的人员变动情况，然后再继续。
人员情况：国内大多数的公司都处于一种为了谋生而存在的状态下，有很多技术人员都有三五个月就跳槽的经历。不仅仅是技术人员，往往公司也是这种状态，很多公司就是为了某一个项目而建立的，老板在招聘技术人员的时候，都是往最低限压低技术人员的工资，当一个技术人员对项目了解到一定程度的时候，这个时间往往是在三个月到半年时间之间。半年，或者一年，是一个人最容易发生跳槽行为的时候，因为这个人了解了公司的实质情况，如果老板当时骗了人，那么这个人必然要离开公司；如果老板当时过分地压低了他的收入，那么这时候这个技术人员就希望能够获得加薪等等，除此之外，还有很多很多其他的因素，都会给人带来未知的行为。也可以说，国内很少有团队成员能够合作达到一年以上的时间。这样的话，第一个项目磨合好了，第二个项目就是在考虑跳槽，第二个项目未结束人就走了，这是我们平时很常见的现象。
这个时候做结对编程，效果就不会那么明显，因为在人员相对成熟的时候，人的心理发生了较大的变化，工作的积极性和配合程度也远远不及刚刚进入公司的时候。那么结对编程在这样的环境下还能进行下去吗？估计不用分析就可以知道了。这时有人会说，如果配合不好，那就换人结对，不一定非要这两个人结对。那这就要从项目组人数说起了。
项目组人数：在我所开发过的项目中，大概有不到一半的项目有十个人以上的开发团队。最大的团队开发人员是不到三十人，这二十多人还要分成几个组，每个组也就五六个人而已。在这种情况下，结对的问题就出现了，在组内的你只能和这么三五个人结对，是不是都很容易配合起来呢？这个事情很难说。配合不好怎么办？换人？换项目？还是换公司？当然，如果配合了三个月还配合不好，站在公司的立场上，是肯定要考虑开除掉某人了，至少也要将他降薪或者调离这个项目组，因为公司承担不起这么大的风险。项目经理更是在担着风险，因为结对编程的事情老板本来就不太乐意看到，本来老板就有意见，而项目组如果发生了这样配合力度很差的情况，项目经理的处境可能就非常危险了。
综合上面这三个方面的情况，我们可以得到如下的结论：
结对编程在中国这些短小项目过多的情况下是不太适合的！结对编程其实更适合一些相对人员较为稳定的开发环境，否则，三个月的低效率配合时间会让老板将项目经理的脑袋当球踢的。但是，结对编程还是有其好处的，比如，提高项目组的稳定性，当一个人离开后，另外一个人可以很快地将新人带到位，项目组不会因为人员变动而发生较大的风险问题。同时，结对编程提高了程序员之间的交流，团结了项目组内成员，同时容易形成人月神话中提到的胶冻团队的效果。另外，在三个月后还是有效率提高的情况发生，的确能够带来很好的效益的。
这时候，交换编程就带来了很好的效果，一是没有老板担心的两个人做一件事情的风险，同时增加了项目组内成员的沟通交流，也提高了团队的稳定性。但如何提高团队的稳定性？
项目组稳定性提高
l 表现
在我前面的例子中可以看到，一个模块至少有三个人对他它很熟悉，因此在后面的开发过程中，无论哪个人发生变动，都不会影响这个团队的稳定性，所有的任务都能够很好的延续下来。每一个系统的模块都会至少按照阶段数量（不同的项目会有不同的开发周期，同时也就有不同数量的人会对这个模块十分熟悉）分给不同的人来进行开发。如果和结对编程配合起来使用，则将会使得对同一个模块了解的人数达到一般交换编程的两倍人数。
l 分析
有了这样的对每一个模块都很熟悉的人员数量的存在，团队的稳定性就会表现出来，任何一个人的变动或者少数人员的变动都不会对团队和开发进度产生较大的影响。因为随时都可以有其他人来接替这个发生变动的人的全部工作，也很容易培养新人进入到团队内来进行工作。
更适合没有绝对高手的团队
l 表现
当团队内没有绝对高手存在时，也就是说，系统的架构设计将是更多的人一同讨论出来的，并在开发过程中不断的修改和调整。
l 分析
没有绝对高手存在，系统架构设计就不能够在系统进行分析设计前完成，而同时架构的不稳定，就无法更好地安排任务计划和制定故事，这些都会影响到整个系统的开发进度和过程，同时，敏捷编程所倡导的很多做法就无法在这个大前提下来进行实施。
国外能够很好地采用敏捷的做法来实施项目的一个原因是，他们有很多有一二十年工作经验的开发人员。这些人员的经验积累是非常重要的，他们可以更好地在项目开始的前期对项目进行整体的控制和把握，同时做好项目计划和制定好任务故事，而这一点在国内尤其是软件公司中还不具备这个条件，因此，很多项目我们都处于的状态类似于我前面所举的电信项目的团队情况，甚至情况比那个团队还要差得多。
团队内交流增加
l 表现
前面已经提到,“因此在那个团队的开发过程中，我们经常是大呼小叫，无论走到哪里，都是十分热闹的场景。”这种频繁的交流，无形中使得团队的凝聚力提高，相互之间的关系和合作也都更为密切。
l 分析
如果是一个人从头到尾开发一个模块，他就几乎不需要和团队内非管理人员进行交流，甚至在某些情况下他只需要和客户做好沟通就足够了。而这时候，即使进行了同行评审，这个技术人员也可能会认为两三天的时间内这些人不可能了解这个系统模块的内容。这种评审也就容易流于形式而无法得到真正的重视。其他人也会认为评审是浪费自己的开发时间，于是到了一定程度评审就会成为可有可无的状态。如果有较多的人参与了这个模块的前后期分析和开发，每一个阶段都可以找到别人来进行讨论，在评审时对这些人提出的意见也就更容易接受——因为他至少会认为这几个人比他更早介入这个模块的分析，在某些程度上会比自己了解的更为深入。
唯一可能的劣势
l 表现
由于存在多人之间的交换，在某一个具体工件的开发的时间上会比一个程序员一直做下来略有延长。
l 分析
由于在任何一次交换之间都需要前一阶段开发者队后一阶段开发者进行关于业务和技术方面的沟通和交流，因此会延长项目在初期的开发时间。尤其当团队成员相互之间的熟悉程度不够或者配合不协调的时候，这个问题会表现得较为突出，甚至可能影响一些项目的进度以及开发工作的进展。
但是，这个影响会在相应的程度上促进团队内人员之间更快地相互熟悉，这个周期要比结对编程短很多，一般来说，不会超过一个月的时间就可以让团队成员之间相互熟悉（由于不是坐在一起开发，这个熟悉的程度比结对编程的要求低很多，因此时间也相应会缩短很多）。
深入讨论
交换编程的应用方式是有其适用环境的，另外在我的实践和研究中还建议如果团队合适，可以考虑与结对编程配合使用。
适用环境：这种开发方法的适应性较强，这里分为团队状况和项目情况两个部分进行一些说明。
团队状况：交换编程适用于人数超过两个人的开发团队，因为交换一次至少也需要两个开发人员。大的团队也可以应用交换编程的方式，来进行项目开发。要求团队内的成员有一两个具有两三年以上开发经验的，这是对于一般的项目（哪怕没有什么技术难度）的最基本要求。
项目情况：项目规模不限，开发周期的适应性也较强，对于任何类型的项目都可以适用。
与结对编程配合使用：如果领导比较认可结对编程的开发方式，这个时候，您引入交换编程也会带来同样的好处，比如团队稳定性，至少从对系统业务模块熟悉的人数上来看增加了一倍，以及团队凝聚力，因为频繁的交流，从而更多地降低因为少数人的思想和考虑偏差造成对用户需求理解不足等问题。
有了上述的情况表现，也使得团队的规范化操作能力更强，也可以使得很多问题能够在有效的沟通中的到解决。
由此可见，交换编程的存在是有其道理的，没有用过的朋友不妨尝试一下，至少对您的团队没有什么伤害和大的变动。
作者介绍：白慧冬，网名青润，独立软件咨询师，《软件工程之全程建模实现》一书作者，CSDN软件工程/管理版块大版主，一个在不断摸索实践的国内软件工程方法和技术的亲历者。2004年底开发完成了一套软件度量概算产品，并对一些行业应用软件进行了较为成功的度量分析。2006年完成了全程建模方法中需求与代码影射关系的分析与实践探索。个人Blog为：http://blog.csdn.net/qingrun。
京公网安备 11010802021500号