在傳統的開發過程中，往往是一個人從一個模塊的需求開始，然后作分析、設計、編碼、單元測試，接著才會交給第二個人（專職測試人員）進行其他測試項目。這樣的開發過程會因為開發人員的變動而對項目的進展產生較大的影響，所以就有人提出項目中編碼人員的重要性遠比 項目經理大。而同時，極限編程中的結對編程方式，對于開發人員人手嚴重不足的項目中，領導是不認可這種組織方式的，他們認為這會浪費很多的人力，一加一未必大于二。
“結對編程技術是一個非常簡單和直觀的概念：兩位 程序員肩并肩地坐在同一臺電腦前合作完成同一個設計、同一個算法、同一段代碼或者同一組測試。與兩位程序員各自獨立工作相比．結對編程往往只需花費大約一半的時間就能編寫出質量更高的代碼， 但是，人與人之間的合作不是一件簡單的事情——尤其當人們都早己習慣了獨自工作的時候。實施結對編程技術將給軟件項目的開發工作帶來好處，只是這些好處必須經過縝密的思考和計劃才能真正體現出來�！保ㄒ浴督Y對編程技術》，原名為《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]
