在传统的开发过程中，往往是一个人从一个模块的需求开始，然后作分析、设计、编码、单元测试，接着才会交给第二个人（专职测试人员）进行其他测试项目。这样的开发过程会因为开发人员的变动而对项目的进展产生较大的影响，所以就有人提出项目中编码人员的重要性远比 项目经理大。而同时，极限编程中的结对编程方式，对于开发人员人手严重不足的项目中，领导是不认可这种组织方式的，他们认为这会浪费很多的人力，一加一未必大于二。
“结对编程技术是一个非常简单和直观的概念：两位 程序员肩并肩地坐在同一台电脑前合作完成同一个设计、同一个算法、同一段代码或者同一组测试。与两位程序员各自独立工作相比．结对编程往往只需花费大约一半的时间就能编写出质量更高的代码， 但是，人与人之间的合作不是一件简单的事情——尤其当人们都早己习惯了独自工作的时候。实施结对编程技术将给软件项目的开发工作带来好处，只是这些好处必须经过缜密的思考和计划才能真正体现出来。”（引自《结对编程技术》，原名为《Pair Programming Illuminated》，作者为Laurie Williams, Robert Kessler）。下面我们分析一下结对编程的特点：
◆ 结对编程在很多项目中得到应用，也作为XP（极限编程）一个非常著名的观点和做法被很多人大为推崇。
◆ 结对编程是两个人同时做同一件事情的一种方法。表现上会给人一种浪费一个开发人员的感觉，实质上这的确是可以提升效率的。
同样的这个做法，2002年我在上海进行的一个类 ERP项目中用过一次，当时在我做完权限系统的全部功能后，和一个兄弟合作了一个模块，我们两个人只用了三四天时间，就完成了这个新的模块的全部功能。相对于我们此前做的功能模块来说，时间不到那些模块开发时间的十分之一。但由于结对编程会让人感觉到 资源被浪费了一半，在2002年的一个项目中，我提出进行结对编程的时候被领导拒绝了。这件事以后，我就开始考虑如何才能降低这种表面的浪费，而又能让大家交流起来，同时能提高 团队的稳定性。
产生背景
2002年我的项目组要做如下这样的一个项目：
这是电信MSS系统的核心业务系统部分，包括了规划、设计、施工、验收、财务、合同等多个重要环节和多个部门的业务。当时团队开发人员数量较少，人员技能较为均衡，没有水平超出其他人过多的技术人员。这个项目在最初评估的开发周期就是第一个版本在五个月内完成，整个项目至少要做上一年以上，而最后的实际情况是，这个项目随着不断的升级和调整一直开发了三年多。最初的开发团队是十一个人，后来扩展到二十三个人，主要开发人员总数为十六个人，其中有四个人技术水平相对较高，另外的七个人技术水平相对较低但是也都有三年多的实际项目开发经验，其中有三个是我2001年带的三个应届毕业生。
由于开发团队中没有技术水平超出其他人很多的人员存在，因此技术方案的论证过程都是在大家的共同讨论中制定下来的，只是在团队整体控制上，当时我有相对较强的发言权。因此在权衡了整个项目的实际情况后，完成需求工作我就告诉弟兄们——第二阶段设计模型的开发大家交换来做。
刚开始很多弟兄不理解，因为相对而言我的开发经验比其他人多了几年，所以当时我说的一些话兄弟们还可以接受，于是我就直接要求大家按照我的计划执行。在设计模型开发完成后，我再次要求大家进行交换。两次交换完成后，保证了每一个模块都有至少两个人对其十分熟悉，一方面不会因为人员的变动造成团队的不稳定（这一点考虑相对较少，因为当时的团队合作时间比较长，大家彼此十分熟悉和了解），另一方面保证每一个模块的开发人员都能找到人进行讨论，从而增加了团队内的 沟通，方便了协调工作的进行。
因此在那个团队的开发过程中，我们经常是大呼小叫，无论走到哪里，都是十分热闹的场景。
方法定义
◆与结对编程类似，交换编程也是一个非常简单和直观的概念：两位或者多位程序员轮流开发同一个软件系统的同一个模块的不同阶段的任务。交换编程的方式更合适的说法应该是交换开发，这种方式不仅仅可以应用于软件项目，也适合其他研究开发型项目。相对而言，这更是一种更容易被人们接受的方法，在前文大家已经看到了它在实际项目中的事实，这里先分析一下它与结对编程的不同之处：
◆ 它仍然采用传统的一人一机的开发方式，结对编程是两人一机。
◆ 它在每个迭代间进行多人交换或者两两交换，结对编程没有交换的概念。
它与传统的编程方式之间的差别是在每个迭代间进行多人交换或者两两交换，而传统编程没有交换的概念。
这里说明一下两个概念：
轮轮流交换：三个以上的程序员之间相互交换所开发的工件，不仅限于三个。例如：A1的开发内容交给A2，A2的交给A3，……，An的交给A1。这种方式称为轮流。
两两交换：两个程序员之间相互交换所开发的工件。仅限于两人之间。
建议实施方式
交换编程中的操作与其他过程有较大的差异，根据经验，建议在 软件工程实施的各个阶段按照如下的方式进行：
◆ 需求工程中，需求调研和需求分析进行轮流交换，轮流交换至少是三个以上的人进行互换，不是两两互换；
◆ 概要设计（分析模型）开发中，需求分析到概要设计也进行轮流交换；
◆ 详细设计（设计模型）开发中，概要设计到详细设计再进行一次轮流交换；
◆ 编码实施启动后，详细设计到编码的交换采用两两交换，注意这个时候不再采用轮流交换了。
在全程建模的开发方法下的交换编程应用方式如下图：
由于目前没有进行实际数据的度量对比，本文也无法从量化的数据上来说明问题，只能通过一些具体的事实来进行说明和验证：当时这个项目的模块从7个扩展到了11个，人员数量从11人扩展到了23人，我们在七个月内满足了南方11家省级电信公司和集团公司的基本业务需求，从2003年4月到2003年12月期间，基本完成了这些省公司版本的二次定制开发任务。
在编码以前全部采用轮流交换的目的就是为了让更多的人了解项目进展的全部内容，有利于增加团队内的交流，使更多的人对项目所开发的内容熟悉，并能让他们提出自己的观点，也有利于使更多的人从更多的角度来研究某个系统模块所需要实现的功能和用户需要解决的实际问题，不会因为某个人的定式思维而出现理解偏差，从而造成对需求的理解不到位。
详细设计到编码的交换采用两两交换，这是因为前期需求已经基本上都稳定下来了，这时候不需要对用户需求进行更多方面的理解，只需要进行实施并进行纯粹的编码工作即可。此时做轮流交换就不存在任何意义了，相反只能影响开发进度。
优劣势分析
这里所提到的优势都是和具体的开发方法相关联的，大部分是相对于XP方法中的结对编程，同时也会分析它与传统开发方式间的优劣。
开发时间“浪费”不明显
◆ 表现
这个开发时间“浪费”不明显是相对于结对编程与传统开发模式而言的，至少让老板没有感觉到人员分配方式带来了人员的浪费。大家都知道，结对编程需要两个人共用一台计算机、一套键盘、做同一个故事，这样的开发方式往往会给人感觉浪费了一个人，虽然事实上未必如此。但是如果哪个项目经理第一次甚至说前几次这样做，估计大多数老板都会表示反对的，因为他会感觉自己的技术人员只有一个人在做事情。同样，在2006年的敏捷中国开发者大会上，ThoughtWorks的总经理也提到了这个问题，他的解释是这样的：当两个人合作三个月以后，效率会超过两个人单独编程的效率！但请注意：这里有一个时间前提——三个月以后。
三个月这个时间未必是真实确凿的时间分界线，它只是一个模糊的大概的时间范畴，如果两个人配合的好，也许只需要两个多月，如果配合不好，也许需要四五个月的时间，或者更长的时间……。我相信这样的说法连Martin也不会反对的。从这个时间界限上，大家可以看看国内公司的项目状况，然后再继续我们的讨论。
◆ 分析
项目情况：国内很少有时间限度较长的项目，大多数项目都是在三个月到半年时间内结束，有些甚至只有一个月。这样的时间特性，将使得这个三个月的期限变成了一句空谈，也就是说，当两个人磨合好的时候，项目已经结束了。这时候，有人会说，下一个项目还可以继续合作呀，好，那我们来看看国内项目团队的人员变动情况，然后再继续。
[1] [2]
