引子
在傳統的開發過程中，往往是一個人從一個模組的需求開始，然後作分析、設計、編碼、單元測試，然後才會交給第二個人（專職測試人員進行其他測試項目），這樣的開發過程會因為開發人員的變動而對項目的進展產生較大的影響，所以有人提出來項目中的編碼人員的重要性遠遠比項目經理大。
而同時，極限編程中的結對編程方式，對於開發人員人手嚴重不足的項目中，領導是不認可這種組織方式的，他們認為這會浪費很多的人力，一加一未必大於二。
“結對編程技術是一個非常簡單和直觀的概念：兩位程式設計師肩並肩地坐在同一台電腦前合作完成同一個設計。同一個算法、同一段代碼或同一組測試、與兩位程式設計師各自獨立工作相比．結對編程往往只需花費大約一半的時間就能編寫出質量更高的代碼，但是，人與人之間的合作不是一件簡單的事情——尤其當人們都早己習慣了獨自工作的時候、實施結對編程技術將給軟體項目的開發工作帶來好處．只是這些好處必須經過縝密的思考和計畫才能真正體現出來。”
——以上內容引自《結對編程技術》，原名為《PairProgrammingIlluminated》，作者：（美）LaurieWilliams,RobertKessler。
下面我們分析一下結對編程的特點。
結對編程在很多項目中得到套用，也作為XP一個非常著名的觀點和做法被很多人大為推崇。
結對編程是兩個人同時做同一件事情的一種方法。表現上，會給人一種浪費一個開發人員的感覺，實質上，這的確是可以提升效率的。
同樣的這個做法，我在2002年在上海進行的一個類ERP項目中用過一次，當時在我做完許可權系統的全部功能後，和一個弟兄合作了一個模組，我們兩個人只用了三四天時間，就完成了這個新的模組的全部功能，這相對於我們此前做的功能模組來說，時間不到那些模組開發時間的十分之一。
正是由於結對編程會讓人感覺到資源被浪費了一半，在2002年的一個項目中，小子提出進行結對編程的時候被領導拒絕了。於是就開始考慮如何才能降低這種表面的浪費，而又能讓大家交流起來，也能提高團隊的穩定性……
產生
2002年小子的項目組在做如下這樣的一個項目：
這是電信MSS系統的核心業務系統部分，包括了規劃、設計、施工、驗收、財務、契約等多個重要環節和多個部門的業務。
當時團隊開發人員數量較少，人員技能較為均衡，沒有水平超出其他人過多的技術人員。這個項目在最初評估的開發周期就是第一個版本在五個月內完成，而整個項目是至少要做上一年以上的，而最後的實際情況是，這個項目隨著不斷的升級和調整一直開發了三年多。
最初的開發團隊是十一個人，後來擴展到二十三個人，主要開發人員總數為十六個人，其中有四個人技術水平相對較高，另外的七個人技術水平相對較低但是也都有三年多的實際項目開發經驗，其中有三個是我2001年帶的三個應屆畢業生。
由於開發團隊中沒有技術水平超出其他人很多的人員存在，因此技術方案的論證過程都是在大家的共同討論中制定下來的，只是在團隊整體控制上，當時我有相對較強的發言權，因此，在權衡了整個項目的實際情況後，我在需求工作完成後，告訴弟兄們一件事情，第二階段設計模型的開發大家交換來做。
剛開始很多弟兄不理解，因為相對而言我的開發經驗比其他人多了幾年，所以，當時我說的一些話，兄弟們還可以接受，於是，我就直接要求大家按照我的計畫進行執行。
在設計模型開發完成後，我再次要求大家進行了一次交換。
兩次交換完成後，保證了每一個模組都有至少兩個人對這個模組十分熟悉，一方面不會因為人員的變動造成團隊的不穩定（這一點考慮相對較少，因為當時的團隊合作時間是比較長的，大家十分熟悉和互相都很了解），另一方面保證每一個模組的開發人員都能找到人進行討論，這增加了團隊內的溝通，方便了協調工作的進行。
因此在那個團隊的開發過程中，我們經常是大呼小叫，十分熱鬧，我們這個團隊無論走到哪裡，都是十分熱鬧的場景。
定義
與結對編程類似，交換編程也是一個非常簡單和直觀的概念：兩位或者多位程式設計師輪流開發同一個軟體系統的同一個模組的不同階段的任務。交換編程的方式更合適的說法應該是交換開發，這種方式不僅僅在軟體項目中可以套用，同樣的事情也可以在其他研究開發型項目中得到套用。
這是一種更容易被人們接受的方法，在前文大家已經看到了它在實際項目中的事實，這裡先分析一下它與結對編程的不同之處，那就是：
1、它仍然採用傳統的一人一機的開發方式，結對編程是兩人一機。
2、它在每個疊代間進行多人交換或者兩兩交換，結對編程沒有交換的概念。
它與傳統的編程方式之間的差別是：
它在每個疊代間進行多人交換或者兩兩交換，傳統編程沒有交換的概念。
建議實施方式
交換編程中的操作會與其他過程有較大的差異，根據經驗，建議在軟體工程實施的各個階段按照如下的方式進行：
需求工程，需求調研和需求分析進行輪流交換，輪流交換至少是三個以上的人進行互換，不是兩兩互換。
概要設計（分析模型）開發中，需求分析到概要設計也進行輪流交換。
詳細設計（設計模型）開發中，概要設計到詳細設計再進行一次輪流交換。
編碼實施啟動後，詳細設計到編碼的交換採用兩兩交換，注意這個時候不再採用輪流交換了。
在全程建模的開發方法下的交換編程套用方式如下圖：
由於目前沒有進行實際數據的度量對比，本文也無法從量化的數據上來說明問題，只能通過一些具體的事實來進行說明和驗證。
當時這個項目的模組從7個擴展到了11個，人員數量從11人擴展到了23人，我們在七個月內滿足了南方11家省級電信公司和集團公司的基本業務需求，從2003年4月到2003年12月期間，基本上完成了這些省公司版本的二次定製開發任務。
在編碼以前全部採用輪流交換的目的就是為了讓更多的人了解項目進展的全部內容，有利於增加團隊內的交流，使更多的人對項目所開發的內容熟悉，並能讓他們提出自己的觀點。也有利於使更多的人從更多的角度來研究某個系統模組所需要實現的功能和用戶需要解決的實際問題，不會因為某個人的定式思維而出現理解偏差造成對需求的理解不到位。
詳細設計到編碼的交換採用兩兩交換，這是因為前期需求已經基本上都穩定下來了，這時候不需要對用戶需求進行更多方面的理解，只需要進行實施，並進行純粹的編碼工作。這時候作輪流交換就不存在任何意義了，相反只能影響開發進度。
優劣分析
這裡所提到的優勢都是和具體的開發方法相關聯的，大部分是相對於XP方法中的結對編程，同時也會分析它與傳統開發方式間的優劣。
開發時間“浪費”不明顯
1) 表現
這個開發時間“浪費”不明顯是相對於結對編程與傳統開發模式而言的。至少讓老闆沒有感覺到人員分配方式帶來了人員的浪費。
結對編程，大家都知道，需要兩個人共用一台計算機，一套鍵盤，做同一個故事。這樣的開發方式往往會給人感覺浪費了一個人，雖然事實上未必如此，但是如果哪個項目經理第一次甚至說前幾次這樣做，估計大多數老闆都會表示反對的，因為他會感覺自己的技術人員只有一個人在做事情。
同樣，在2006年的敏捷中國開發者大會上，thoughtworks的總經理也提到了這個問題，他的解釋是這樣的：當兩個人合作三個月以上，則效率會超過兩個人單獨編程的效率！
注意：這裡有一個時間前提——三個月以上。
三個月這個時間未必是真實確鑿的時間分界線，它只是一個模糊的大概的時間範疇，如果兩個人配合的好，也許只需要兩個多月，如果配合不好，也許需要四五個月的時間，或者更長的時間……
我相信這樣的說法連Martin也不會反對的。
從這個時間界限上，大家可以看看國內公司的項目狀況，然後再繼續我們的討論。
2) 分析
① 項目情況
國內很少有時間限度較長的項目，大多數項目都是在三個月到半年時間內結束的。有些甚至只有一個月。
這樣的時間特性，將使得這個三個月的期限變成了一句空談，也就是說，當兩個人磨合好了的時候，項目已經結束了。
這時候，有人會說，下一個項目還可以繼續合作呀，好，那我們來看看國內項目團隊的人員變動情況，然後再繼續。
② 人員情況
國內大多數的公司都處於一種為了謀生而存在的狀態下，有很多技術人員都有三五個月就跳槽的經歷。
不僅僅是技術人員，往往公司也是這種狀態，很多公司就是為了某一個項目而建立的，老闆在招聘技術人員的時候，都是往最低限壓低技術人員的工資，當一個技術人員對項目了解到一定程度的時候，這個時間往往是在三個月到半年時間之間。
半年，或者一年，是一個人最容易發生跳槽行為的時候，因為這個人了解了公司的實質情況，如果老闆當時騙了人，那么這個人必然要離開公司；如果老闆當時過分的壓低了他的工資收入，那么這時候這個技術人員就希望能夠獲得加薪……除此之外，還有很多很多其他的因素，都會給人帶來未知的行為。
也可以說，國內很少有團隊成員能夠合作時間達到一年以上。
這樣的話，第一個項目磨合好了，第二個項目就是在考慮跳槽，第二個項目未結束，人就走了，這是我們平時很常見的現象。
這個時候做結對編程，效果就不會那么明顯，因為在人員相對成熟的時候，人的心理發生了較大的變化，工作的積極性和配合程度也遠遠不及剛剛進入公司的時候。
那么結對編程在這樣的環境下還能進行下去么？大家不用分析就可以知道了。
有人說，如果配合不好，那就換人結對，不一定非要這兩個人結對。這就要從項目組人數說起了。
③ 項目組人數
在我所開發過的項目中，大概有不到一半的項目有十個人以上的開發團隊。最大的團隊開發人員是不到三十人，這二十多人還要分成幾個組，每個組也就五六個人而已。
在這種情況下，結對的問題就出現了，在組內的你只能和這么三五個人結對，是不是都很容易配合起來呢？這個事情很難說。
配合不好怎么辦？換人？換項目？還是換公司？當然，如果配合了三個月還配合不好，站在公司的立場上，是肯定要考慮開除掉某人了，至少也要將他降薪或者調離這個項目組，因為公司承擔不起這么大的風險，項目經理更是在擔著風險，因為結對編程的事情老闆本來就不太樂意看到，本來老闆就有意見，而項目組如果發生了這樣的配合力度很差的情況，項目經理的處境可能就非常危險了。
綜合上面這三個方面的情況，我們可以得到如下的結論：
結對編程在中國這些短小項目過多的情況下是不太適合的！結對編程其實更適合一些相對人員較為穩定的開發環境，否則，三個月的低效率配合時間會讓老闆將項目經理的腦袋當球踢的。
但是，結對編程還是有其好處的，比如，提高項目組的穩定性，當一個人離開後，另外一個人可以很快地將新人帶到位，項目組不會因為人員變動而發生較大的風險問題。
同時，結對編程提高了程式設計師之間的交流，團結了項目組內成員，同時容易形成人月神話中提到的膠凍團隊的效果。
另外，在三個月後還是有效率提高的情況發生，的確能夠帶來很好的效益的。
這時候，交換編程就帶來了很好的效果，一則，沒有老闆擔心的兩個人做一件事情的風險，同時，增加了項目組內成員的溝通交流，也提高了團隊的穩定性。
那這個問題如何解決？這裡，我們不妨來看看交換編程是如何提高項目組穩定性的。
項目組穩定性提高
1) 表現
在我前面的例子中可以看到，一個模組至少有三個人對他很熟悉，因此在後面的開發過程中，無論哪個人發生變動，都不會影響這個團隊的穩定性，所有的任務都能夠很好的延續下來。
每一個系統的模組都會至少按照階段數量（不同的項目會有不同的開發周期，同時也就有不同數量的人會對這個模組十分熟悉）分給不同的人來進行開發。
如果和結對編程配合起來使用，則將會使得對同一個模組了解的人數達到一般交換編程的兩倍人數。
2) 分析
有了這樣的對每一個模組都很熟悉的人員數量的存在，團隊的穩定性就會表現出來，任何一個人的變動，或者少數人員的變動都不會對團隊和開發進度產生較大的影響。
因為隨時都可以有其他人來接替這個發生變動的人的全部工作，也很容易培養新人進入到團隊內來進行工作。
團隊內沒有絕對高手時交換編程更適合
1) 表現
當團隊內沒有絕對高手存在時，也就是說，系統的架構設計將是更多的人一同討論出來的，並在開發過程中不斷的修改和調整。
2) 分析
沒有絕對高手存在，系統架構設計就不能夠在系統進行分析設計前完成，而同時架構的不穩定，就無法更好的安排任務計畫和制定故事，這些都會影響到整個系統的開發進度和過程，同時，敏捷編程所倡導的很多做法就無法在這個大前提下來進行實施。
國外能夠很好的採用敏捷的做法來實施項目的一個原因是，他們有很多工作在一二十年經驗的開發人員，這些人員的經驗積累是非常重要的，他們可以更好的在項目開始的前期對項目進行整體的控制和把握，同時做好項目計畫，制定好任務故事，而這一點，在國內，尤其是中國的軟體公司中還不具備這個條件，因此，很多項目我們都處於的狀態類似於我前面所舉的電信項目的團隊情況，甚至情況比那個團隊還要差得很多。
團隊內交流增加
1) 表現
前面已經提到：“因此在那個團隊的開發過程中，我們經常是大呼小叫，十分熱鬧，我們這個團隊無論走到哪裡，都是十分熱鬧的場景。”
這種頻繁的交流，無形中使得團隊的凝聚力提高，相互之間的關係和合作也都更為密切。
2) 分析
如果是一個人從頭到尾開發一個模組，他就幾乎不需要和團隊內非管理人員進行交流，甚至在某些情況下他只需要和客戶做好溝通就足夠了。而這時候，及時進行了同行評審，這個技術人員也可能會認為：那么兩三天的時間，這些人不可能了解這個系統模組的內容。這種評審也就容易流於形式而無法得到真正的重視。其他人也會認為評審是浪費自己的開發時間，於是評審到了一定程度就會成為可有可無的狀態。
如果有較多的人參與了這個模組的前後期分析和開發，每一個階段，都可以找到別人來進行討論，同時，在評審時，對這些人提出的意見也就更容易接受——因為他至少會認為這幾個人比他更早的介入這個模組的分析，在某些程度上會比自己了解的更為深入。
深入討論
交換編程的套用方式是有其適用環境的，另外，在小子的實踐和研究中，小子還要建議如果團隊合適，可以考慮與結對編程配合使用。
1) 適用環境
這種開發方法的適應性較強，這裡分為團隊狀況和項目情況兩個部分進行一些說明。
① 團隊狀況
交換編程適用於人數超過兩個人的開發團隊，因為交換一次至少也需要兩個開發人員。
大的團隊也可以套用交換編程的方式，來進行項目開發。
要求團隊內的成員有一兩個具有兩三年以上開發經驗的，就可以採用這種方法進行團隊開發——而對於一般的項目，哪怕沒有什麼技術難度，這也是最最近本的人員技能要求了。
② 項目情況
項目規模不限，開發周期的適應性也較強，對於任何類型的項目都可以適用。
2) 與結對編程配合使用
如果領導比較認可結對編程的開發方式，這個時候，您引入交換編程也會帶來同樣的好處：
① 團隊穩定性：
至少有一點，團隊的穩定性從對系統業務模組熟悉的人數上來看，增加了一倍。
② 團隊凝聚力：
團隊成員之間的交流會更為頻繁，這樣就會更多的降低因為少數人的思想和考慮偏差造成對用戶需求理解不足等問題。
有了上述的情況表現，也使得團隊的規範化操作能力更強，也可以使得很多問題能夠在有效的溝通中的到解決。
總結
由此可見，交換編程的存在是有其道理的，沒有用過的朋友，不妨嘗試一下，至少對您的團隊沒有什麼傷害和大的變動，可以逐漸推進。
交換編程於2006年6月正式提出，2006年8月在《程式設計師》雜誌上首發。
