在敏捷軟件開發的各種實踐中，結對編程（Pair Programming，下文簡稱Pair）是特別有爭議的。Pair有一個特點，那就是還沒有進行過任何Pair實踐前，你很可能對它已經有了“喜歡” 或者是“討厭”的印象。如果有人問你，你喜歡持續集成嗎？你多半會回答：不是很肯定，需要試試看。但如果有人問你，你喜歡Pair嗎？我猜你會馬上給予明確的肯定或否定的回答。喜歡它的人會覺得好處多多而成本低低，不喜歡它的人會覺得討厭得難以想象。喜歡與不喜歡都可以形成強大的陣營，兩邊都不乏重量級的高手。Pair的優點說起來都很明顯，比如：快速反饋，更好的設計，甚至更高的效率等等。但據我瞭解，不喜歡Pair的人基本上都承認Pair有優點，只是他們通常會提出反對意見，比如：Pair要求兩個人協調一致，每個人的作息時間需要同步，如果一個人請假，那另一個人怎麼辦？等待就太浪費時間了，如果自己一個人做那就不是Pair了；或者也有很多人感覺到Pair的時候特別累，不像一個人工作那樣自主，寫一小時程序，上十分鐘微博，兩個人同一臺電腦工作自由就小多了。
我所在的公司是Pair的實踐者，對於喜歡Pair或者不喜歡Pair的各種原因和心態我都有切身的體會。在實踐中，我們並沒有完全一成不變地照搬Kent Beck在《Extreme Programming Explained》書中所定義的Pair模式（Driver Observer模式）。因爲，Pair畢竟是一種實踐方法，可以供我們在軟件開發中參考，而不必像對待科學理論一樣教條。另外，我認爲要讓這種實踐方法發揮它的威力，消除人們心中的討厭甚至是恐懼情緒是首先要解決的問題，甚至我們可以爲此修改一些Pair的傳統做法。下面我先來大致描述一下我們的實踐模式（Owner
Supporter模式）：
<階段1-Pair形成>
Team 在接到一個大的Story後經過討論並分解任務形成一個個粒度適中的Task。Task的粒度一般在幾小時到一兩天這種級別，涉及的代碼規模大約是幾行到幾個類/函數。每一個Task，都有一個Owner作爲責任人，這是和傳統單兵開發模式相同的。不過，Owner的產生一般不是由ScrumMaster 來分配指定，而是Team成員自發地去協商選擇適當的任務。Owner拿到Task以後會從Team中找一個Supporter，形成Pair。這也是一個自發協商過程，沒有強制指定，也沒有固定的搭檔，這樣形成的Pair一般會是配合最默契也最適合相應Task的。
<階段2-初始討論>
Pair 形成以後， 一般是由Owner先分析需求，設計測試，並初步分析思考得出初步的設計思路。這時，Supporter可以暫時先不瞭解需求。然後Owner邀請 Supporter一起，向Supporter介紹需求和自己的設計思路。Supporter這時需要幫助Owner理解需求，設計測試，對設計方案提出反饋意見，或者提出新的設計。討論的理想結果是兩人達成一致形成最終的設計方案，如果兩人分歧嚴重不能達成一致則需要更多的人蔘與，比如：可以舉行一個小型的技術討論會議把討論擴大到整個Team。
<階段3-具體實現>
<階段4-Review>
具體實現完成以後，Owner又會邀請Supporter來review自己的工作。這個過程一般是藉助版本控制工具對比代碼改動，Supporter從實現的角度來審查實現是否符合設計，有沒有可以直接觀察到的bug和潛在的問題。如果發現問題並討論確認，Owner再做相應的改動，再Review。最終 Supporter不能review出問題了，Owner提交代碼。
<階段5-維護>
雖然經過了討論和review， 但在後續的測試或者上線後仍然會陸續發現問題，這時就涉及到維護工作。維護工作依然是由Owner牽頭，分析log，看代碼，重現，修正；但是，Owner也可以隨時邀請Supporter參與分析討論，至少在Owner準備修改原先的代碼時應該要告訴Supporter“原先我們某個地方沒有考慮周全，有什麼什麼問題，我打算怎麼怎麼改動”。這個過程好像又回到了階段2，然後階段3，階段4 ... 開發中還有一種可能是，原先的Supporter或Owner已經不在Team內了，這時就需要加入一個新人形成Pair，有經驗的人應該向自己的新搭檔介紹Task的相關背景。當然，還很有可能碰到根本沒有熟悉該模塊的人了，這時就必須形成一個新的Pair，把維護作爲一項新Task。
上面基本上就是我們的Pair實踐模式了。這種模式基本上還是保留了大部分經典Pair模式的要點，主要的區別在於：
1. 把Pair的形成納入Scrum框架的任務劃分過程。Scrum通常會在Sprint的計劃會議中將大的User Story拆分成許多小的Task，每個Task一般對應幾小時到一兩天的工作量。Task列表出來以後，Team自發協商每個Task形成一個 Pair，整個過程一般沒有管理者的直接干預。Story的背景需要Team中的每個人都瞭解，Task的細節由Pair負責。Pair的效果通常也依賴於Task的合理劃分。
2. 避免全程Pair。因爲，全程Pair在實踐和心理上會遇到很多問題，比如：時間同步問題，並行工作問題，不自在感問題。避免全程Pair可以使得 Owner和Supporter的時間安排更加靈活，增加並行性，減少不自在感。大部分不喜歡Pair的人基本上都是尤其不喜歡全程Pair，所以這項改動對於吸引更多的人採用Pair具有重要的意義。
3. 區分Owner和Supporter的職責。經典Pair模式中Driver和Observer角色是隨時交換的，也就是說對於一個Task來講兩個人的職責是相同的，這樣可以減小每一個人的壓力，但又容易造成缺乏責任感。Owner Supporter模式是單兵模式和經典Pair模式之間的一種妥協，試圖在責任和壓力之間找到一種平衡。Owner是驅動整個過程的主導，並且是主要的具體實現者；Supporter以輔助爲主，在討論和review的時候可以站在不同的角度幫助Owner。Supporter並非沒有責任，熟悉Task的所有細節是Supporter的責任。當Owner由於請假或忙於其他事物時，Supporter應該立即可以代替Owner處理Task的實現或維護。如果Supporter做不到完全的backup，這就是Supporter的失職，在整個Team和領導的心中應該有這樣的認識。
最後，除了顯而易見的“引入反饋，提高質量”等很“官方”的優點外，我從管理者和開發人員的角度分別總結一下Owner Supporter模式的“不爲人知”卻真正很有價值的優點。
管理者角度：
1. 應對人員變動：每個模塊至少兩個人熟悉，這樣在有人請假的時候都有backup，不會造成嚴重的耽誤工作進度。如果有人要離職，交接工作通常也會非常輕鬆，幾乎沒有什麼需要特別交接的。很多項目都缺乏文檔，只有實現的人知道怎麼回事，而即使有文檔也總有不清楚的地方，所以留住熟悉的人就是留下了活文檔。
2. 增加對質量的信心：相比單兵作戰模式，即使是不懂技術的管理者，Pair也可以自然地增加他們對於軟件質量的信心，畢竟“三個臭皮匠頂個諸葛亮”。另外，需要特別提到的是安全性問題。我曾經聽說過一個電信計費項目，一個開發人員故意留了一個漏洞，把錢自動打入自己的銀行卡，最終爲公司帶來了麻煩。如果採用 Pair方式，這種情況就不那麼容易發生。
3. 過程透明，增加反饋：信息反饋是敏捷方法的重要支柱，而及時準確的反饋又依賴於過程的透明。在Pair模式下，整個軟件開發過程是透明的，開發人員不容易有意或無意的隱藏項目的細節和風險，因而管理者更容易獲得及時準確的反饋。另外，對於同一個事物，不同的人也會有不同的看法，這是很正常的現象。比如，在對問題進行估計時一個人樂觀，一個人悲觀，這時管理層可以同時參考他們的意見，對問題掌握得更加全面。
4. 代替培訓：相比傳統課程或講座式培訓，Pair能讓新員工更快地適應項目。Pair方法也和一些公司採用的導師制有明顯的區別。導師制更強調師傅帶徒弟，而Pair則不然。在實踐中，我們更鼓勵基礎比較好的新員工多做Owner，老員工作爲Supporter支持；只對基礎比較差的新員工先從 Supporter做起，然後逐步過渡到Owner。這樣做是因爲新員工一般積極性比較高，適合承擔更多的具體工作，而老員工則應該避免重複勞動，而是以輔助和指導爲主。另外，新員工也可能帶來一些新的思想、方法和技能，這些反而是老員工應該學習的。
開發人員角度：
1. 分擔壓力，增加默契：Task依然具有明確的責任人，但Supporter可以分擔Owner的壓力，即使是Team內的技術高手有一個人做backup也是有益的。有人討論有人支持更容易達到良好的工作效果，而大家相互Support也可以讓團隊更加默契。
2. 消除經典Pair的不自在感： Owner Supporter模式與經典Pair的Driver Observer模式相比更少存在不自在感，因爲整個過程是Owner主導的，他有更多的自由安排什麼時候討論，什麼時候獨立工作。
3. 分享知識和技能：在Pair的過程中Owner和Supporter會自然地相互傳播和分享知識和技能，有助於學習提高。
4. 培養組織能力和表達能力： Owner相當於一個微型團隊的leader，在Pair過程中可以鍛鍊組織能力和表達能力。這個過程可以讓一些不善於交流和組織的技術人員逐漸改善交流和組織能力。
Owner Supporter模式在我們的實踐中收到了良好的效果，而且成本很低，值得推薦！