說到結對編程，大家腦海中第一個浮現出來的是什麼？兩個大老粗？還是男女搭配幹活不累？讓我們先看兩張圖了解一下吧。
理想中的結對編程
現實中的結對編程
其實現實往往是痛苦的，結對編程來源於極限編程的最佳實踐之一，試想一下，如今軟體行業競爭如此激烈的情況下，女程式設計師是多麼稀缺的資源，更何況願意跟你結對的女程式設計師。
其實對於結對編程，大家褒貶不一，有說好的，好處不言而喻，相互彌補，減少程序缺陷，促進程式設計師之間的共同進步，對於不同模塊都有對應的Backup；當然也有一定人吃反對意見了，比如，太貴，本身一個人可以完成的現在成本直接Double，因此其實在實際運用中其實真正把結對編程運用起來的並不多。
舉兩個慄子
既然對於成本要求那麼高，我們為什麼還要用"結對編程"呢？當然這裡的結對編程與極限編程中的結對有了許多變化。讓我們先感受下現實工作中發生的一些情況。
曾經接觸過一個端產品，技術上複雜度不高，但是業務複雜度非常高，特別是計算，各種表達式，各種業務數據處理，可以說，如果你懂業務，那麼你看代碼基本上沒有任何難度，但是如果你不懂業務，或者對業務理解沒有個五六年的積累，那你就會一臉懵……情況介紹到此，於是乎我也進入了這個產品的研發組，有一天，我們的一個元老級開發生病了，但是急著發一個功能補丁版本，問了一圈，那個功能居然沒有一個人了解。老闆急了，畢竟這個會直接影響到用戶的使用，並且已經有多個用戶反饋軟體的問題。最後你猜怎麼著？那個元老級開發在醫院吊著點滴，連著公司的VPN，把那個功能的調整代碼給寫完了。
再來聊聊現在待著的產品組發生的一個事情。每個迭代總結，很多人都會提出，需求驗收反覆太多，單周迭代中，每次由於需求驗收的修改，導致一個用戶故事無法按時交付測試，最終導致迭代中故事完成率不足六成。
結對的目標
1、 提高產能（通過減少需求驗證的反覆、測試修改BUG的反覆）
2、 保障質量（減少BUG）
3、 構建T型團隊（後備力量存儲）
開發測試強結對
1個開發哥哥配一個測試妹妹，除了弘揚男女搭配幹活不累的幹事幹事方針之外，主要通過兩者角色不同，對於一個任務的理解不同，從而使得在面對一個任務的時候可以做到互補。
其次開發測試的強結對，形成團隊內的最小單元，同時解決的任務內的關聯性問題，降低了耦合性。以前總是開發一波人，測試一波人，測試埋怨開發周期長，影響他們的測試任務，開發埋怨測試不合理等等。但是一旦將這種組織架構打破後，兩者同時承擔一個任務的時候，通過一些手段就可以使他們拽著一根繩子，朝著一個目標，共同前進。
故事認領到完成的流程圖如下：
通過這樣一種開發測試的強結對後，久而久之讓兩個不同角色間的矛盾弱化了，並且同化他們彼此的目標，讓他們始終以故事的交付為最終目標，而不是單單的對他們各自的任務負責。其次通過驗證點的共識、測試與自測用例的互補，直接減少了需求驗收的往復性以及軟體功能的完善性，大大的提升了產品的質量。
開發"老帶新"師徒結對
雖然說傳統的結對開發對於成本有著一種天生的浪費，但是不得不承認，在一個團隊中，如果失去了後備力量的儲備，一旦有一些不穩定因素，就會對產品或者版本造成一定程度上的影響。敏捷的自主認領，雖然可以對單一功能單一開發的局面有些許的改觀，但是對於複雜程度較高的子系統來說，往往對於後備的儲備還是比較重要的。因此團隊內也調整了一下開發間結對的方式。
每一名資深開發配一名團隊新人開發，日常進行相關學習、指導以及代碼審查工作，如果新人認領任務的複雜度超過其承受範圍，則由師父做相關的培訓，並且審查徒弟相關的開發設計以及代碼實現，保障新人對於該功能的理解完整，保障其開發質量，並能夠在後期對於不同功能都一定的後備力量儲備。
相同的名字，不同的意義
雖然都叫Pair Working結對編程，但是實際操作卻可以有千萬種變化，為了滿足團隊不同情況下的使用，其實也可以有各自的特性擴展，這裡我只是提出了我們團隊的實踐，可能能適應某一部分的團隊，而其他的團隊應該需要進行自己團隊實際情況的分析，不斷的改進調整，畢竟這個方案也不是我們通過幾天想出來的，而是通過不斷的迭代，調整、改進、檢視再調整而實踐出來的。