XP推崇极限编程。为了让领导跟更容易接受，以及避免“表面上的浪费”，出现了“交换编程”。

关于“交换编程”的起源，一种说法是：

交换编程是引自《结对编程技术》的技术。

结对编程在很多项目中得到应用，也作为XP一个非常著名的观点和做法被很多人大为推崇。
　　结对编程是两个人同时做同一件事情的一种方法。表现上，会给人一种浪费一个开发人员的感觉，实质上，这的确是可以提升效率的。
　　同样的这个做法，我在2002年在上海进行的一个类ERP项目中用过一次，当时在我做完权限系统的全部功能后，和一个弟兄合作了一个模块，我们两个人只用了三四天时间，就完成了这个新的模块的全部功能，这相对于我们此前做的功能模块来说，时间不到那些模块开发时间的十分之一。
　　
　　正是由于结对编程会让人感觉到资源被浪费了一半，在2002年的一个项目中，小子提出进行结对编程的时候被领导拒绝了。于是就开始考虑如何才能降低这种表面的浪费，而又能让大家交流起来，也能提高团队的稳定性……
　　
　　产生
　　2002年小子的项目组在做如下这样的一个项目：
　　这是电信MSS系统的核心业务系统部分，包括了规划、设计、施工、验收、财务、合同等多个重要环节和多个部门的业务。
　　当时团队开发人员数量较少，人员技能较为均衡，没有水平超出其他人过多的技术人员。这个项目在最初评估的开发周期就是第一个版本在五个月内完成，而整个项目是至少要做上一年以上的，而最后的实际情况是，这个项目随着不断的升级和调整一直开发了三年多。
　　最初的开发团队是十一个人，后来扩展到二十三个人，主要开发人员总数为十六个人，其中有四个人技术水平相对较高，另外的七个人技术水平相对较低但是也都有三年多的实际项目开发经验，其中有三个是我2001年带的三个应届毕业生。
　　
　　由于开发团队中没有技术水平超出其他人很多的人员存在，因此技术方案的论证过程都是在大家的共同讨论中制定下来的，只是在团队整体控制上，当时我有相对较强的发言权，因此，在权衡了整个项目的实际情况后，我在需求工作完成后，告诉弟兄们一件事情，第二阶段设计模型的开发大家交换来做。
　　刚开始很多弟兄不理解，因为相对而言我的开发经验比其他人多了几年，所以，当时我说的一些话，兄弟们还可以接受，于是，我就直接要求大家按照我的计划进行执行。
　　在设计模型开发完成后，我再次要求大家进行了一次交换。
　　两次交换完成后，保证了每一个模块都有至少两个人对这个模块十分熟悉，一方面不会因为人员的变动造成团队的不稳定（这一点考虑相对较少，因为当时的团队合作时间是比较长的，大家十分熟悉和互相都很了解），另一方面保证每一个模块的开发人员都能找到人进行讨论，这增加了团队内的沟通，方便了协调工作的进行。
　　因此在那个团队的开发过程中，我们经常是大呼小叫，十分热闹，我们这个团队无论走到哪里，都是十分热闹的场景。
　　
　　定义
　　与结对编程类似，交换编程也是一个非常简单和直观的概念：两位或者多位程序员轮流开发同一个软件系统的同一个模块的不同阶段的任务。交换编程的方式更合适的说法应该是交换开发，这种方式不仅仅在软件项目中可以应用，同样的事情也可以在其他研究开发型项目中得到应用。
　　
　　这是一种更容易被人们接受的方法，在前文大家已经看到了它在实际项目中的事实，这里先分析一下它与结对编程的不同之处，那就是：
　　1、它仍然采用传统的一人一机的开发方式，结对编程是两人一机。
　　2、它在每个迭代间进行多人交换或者两两交换，结对编程没有交换的概念。
　　它与传统的编程方式之间的差别是：
　　它在每个迭代间进行多人交换或者两两交换，传统编程没有交换的概念。
　　
　　建议实施方式
　　交换编程中的操作会与其他过程有较大的差异，根据经验，建议在软件工程实施的各个阶段按照如下的方式进行：
　　需求工程，需求调研和需求分析进行轮流交换，轮流交换至少是三个以上的人进行互换，不是两两互换。
　　概要设计（分析模型）开发中，需求分析到概要设计也进行轮流交换。
　　详细设计（设计模型）开发中，概要设计到详细设计再进行一次轮流交换。
　　编码实施启动后，详细设计到编码的交换采用两两交换，注意这个时候不再采用轮流交换了。