背景

最近，我開始重新審視這些融入日常的工程實踐方式，去嘗試找出實際與理論的差距，分析差距成因，基于分析結果，嘗試找出可以逐步彌補差距的實踐方式，從而讓日常軟件交付工作變得更加“順滑”。

本文作為“沉思錄”的第一篇，將列舉實際交付項目中，在結對編程時遇到的幾個實際問題，并針對具體問題給出一些嘗試過的解決方式。

注意：以下話題不在本文的討論范圍中，并且默認讀者已經具備下列問題相關的知識：

• 為什么進行結對編程？（如果想了解，可以參見維基百科(https://en.wikipedia.org/wiki/Pair_programming) 或其他相關郵件）
• 怎樣開始結對編程？（如果想了解，可以參見《7個你需要知道的結對禮儀》(https://insights.thoughtworks.cn/seven-skills-about-pair-programming/)）

工作環境上下文

• 9 人團隊（1 BA， 1 QA， 1 TL， 6 Devs）
• 特殊角色（BA，QA， TL）基本都是 Solo 工作，Dev Pair 工作
• 每對 Pair 同一時間只會工作在一個 User Story 上，直到該 User Story 進入測試階段
• 團隊在 Sprint 開始時進行 Switch Pair 活動，User Story 未完成的 Pair，會有一人留在未完成的 Story 上，以便完成保證卡片上下文充足
• Switch Pair 會按照 Pair 輪換表（如下）進行，以確保所有開發都會有均等的 Pair 機會

Dev輪換表大概是這個樣子（每個周期內團隊采用同一編號的配對組合）：

基于以上的上下文，我們遇到了以下實際問題：

問題 1：Switch Pair時，需要交接的內容過多

Switch Pair 時，需要交接的內容過多時，可能會漏掉一些細節信息。為了補充遺漏，會陷入更多、更深的討論。

具體場景

張三和薛霸經過了一周的結對編程，手頭的一張復雜 User Story （無法進一步拆分）沒有完成，薛霸被留在了當前工作上，準備和阿樂開始工作。

可是，在薛霸向阿樂介紹當前的工作進度時，無法清楚地給阿樂說明之前所寫代碼與 User Stroy 的對應關系和一些必要的上下文。

于是這對 Pair 不得不將張三重新拉回來，進行上下文交接，三人討論時間較長，并且會將之前已經討論過的問題重新討論，降低了工作效率。

分析原因

后來，張三，薛霸，阿樂對這次效率不盡人意的 Switch Pair 進行了回顧，嘗試利用問答的形式進行分析：

對于阿樂的問題，薛霸無法清楚地解答，但在拉回張三后，增加了一些額外的討論時間，就可以解答了。

問： 結對的兩人在當前工作中，理論上應該能夠具備相當信息積累。那么，為什么當前薛霸和張三出現了信息積累差異的情況？ 

答：卡片從 Kick-Off 到當前交接 Switch Pair 的時間跨度較長（7天，含周末），包含內容較多，需要一些討論重新回想起當時的信息。 

另外，薛霸無法解答的問題，基本都是張三在薛霸請假期間完成的。

結對編程理應是有任務拆分（Tasking）作為前提的，以確保 Pair 兩人對于當前的工作進度一致，以盡量減輕請假所帶來的信息不對稱問題。

問：為什么當前的效果并不理想？

答：最初拆分的任務粒度較大，但實際上，在一個大粒度的任務中，會包含一些較小粒度的任務，并且這些任務的完成結果，還會影響后續的任務內容。在工作時，完成了這些較小粒度的任務后，沒有將關鍵工作內容更新到兩人共享的任務列表中，于是造成了信息不對稱情況。

可嘗試的實踐

于是，大家總結出了如下可以實行的行動：

• 初始任務拆分盡量將可能會產生任務分支的關鍵任務（或問題）標出。
• 在完成任務的過程中，保持最初任務列表的更新，特別是上述的關鍵任務，按需記錄任務的產出或關鍵信息。
• Switch Pair 圍繞任務列表進行，以避免出現內容遺漏或花費額外時間討論上下文外的問題。

問題 2：Pair時，其中一人變Solo

• 采用Navigator-Driver Pair 模式時，掌握鍵盤和鼠標的一人（Driver），有時會成兼任 Navigator 角色。
• Pair 過程中，一人會處于高度集中狀態，另外一人可能會因為沒跟上，而從 Pair 中脫出，產生信息斷層。
• Pair 過程中，如果不作 Driver 的角色，可能無法完全掌握當前 User Story 的全貌。

其實上述的問題是有一定的內在邏輯聯系的，可以通過下面的具體場景來進行復現。

具體場景

肖蘭和阿發在結對編程過程中，肖蘭使用自己的筆記本電腦外接顯示器，并通過筆記本的鍵盤和觸控板完成操作，阿發則可以通過外接的顯示器看到肖蘭的操作。

起初，兩人會對著外接顯示器進行一些討論。

但在深入調查代碼時和一些代碼編寫時，肖蘭開始對著自己的筆記本屏幕進行操作，隨著肖蘭逐漸地集中精力，討論和解說停止了。

在連續幾次的進入某個類查看細節代碼，再切換到另外幾個文件中查看配置文件后，肖蘭寫了幾行代碼試了試。

如此反復了幾次后，阿發已經不清楚肖蘭所進行操作的目的了，但他看著肖蘭投入的樣子，欲言又止，不忍心打斷她的操作。

于是阿發又努力了3分鐘嘗試跟上肖蘭的思路，可是猜透一個人的心思何其難也，阿發最終無奈放棄，于是默默轉向自己的電腦（手機），去看看郵件（朋友圈），等待肖蘭等下有了結果再同步給他。

可是，肖蘭在完成的調查整個過程中獲得的信息，卻不一定都能同步給阿發，阿發也就無法掌握當前工作的全貌了。

至此，Pair 終成 Solo...

分析原因

(1) 硬件設施準備不充分。

肖蘭掌控了所有的操作，阿發更多的時候都處于一種“被動”狀態，結對編程的參與感不高，特別是當肖蘭“全情投入”后，阿發的參與感幾乎被全部“剝奪”。

說明：在了解 “如何進行結對編程” 的部分有說明過，結對編程的兩人在硬件準備上，應該盡量平等，至少兩人都有可以各自操作的鍵盤。

(2) 沒有分配、交換角色的活動。

結對編程是兩個人共同合作的活動，那么兩人中每個個體在活動中的體驗感就直接影響這項活動的效果。

在上述例子中，肖蘭一開始就掌握了"操作權”，到了代碼調查階段時，肖蘭又直接“搶奪”了思維的“導向權”，隨著自己的想法去調查、嘗試。

導致阿發在這次結對編程中的參與度極低，體驗感也極差，并最終轉向獨自工作。

說明：為了保證結對兩人的參與度，結對編程存在多種不同的實踐方式（Navigator-Driver 模式、乒乓模式、鍵盤 + 鼠標模式），但無論采用哪種方式，兩人都應在實踐一段時間后，交換角色，從而使每人都有機會從不同的視角分析、解決問題。

(3) 缺少有效溝通。

結對編程與其說是編程方式，不如說更多是一種“社交”活動。那么，在整個過程中，結對兩人需要進行大量，高強度的溝通交流。

在上述場景中，一方面，當肖蘭要開始進行一些深入調查時，沒有說明意圖，從而使阿發開始產生迷茫。

另一方面，當阿發努力嘗試后，依然認為自己跟不上肖蘭的操作時，沒有與肖蘭說明情況，從而使兩人的“信息鴻溝”進一步被擴大。

可嘗試的實踐

針對上述問題，可以：

• 每對Pair中，至少有一人使用從公司申請（自備）的鍵盤和鼠標，確保每個人都有條件能在想要操作的時候進行操作。
• 每對Pair按照拆分的任務列表，每完成 1（X）個任務，交換一次兩人的角色。
• 練習提問。結對的兩人中，任何一人發現兩人的思路不一致時，通過提問的方式，將問題暴露，并解決。

問題 3：Switch Pair頻率高，引發高溝通成本

Pair 過程會產生大量的溝通交流，頻繁的 Switch Pair 會使這種交流的成本擴大，那么如何從這種高頻的 Switch Pair 活動中獲得更高的個人收益呢？

具體場景

團隊最近在嘗試提高 Switch Pair 的頻率，從之前的每兩周提升到現在的每周一次，之后視情況仍有提升的可能。

而這給阿花造成了困擾，因為幾乎每次結對編程，阿花都和搭檔會討論很多問題，而幾乎每次 Switch Pair，阿花都需要花費不少時間將這些討論的結果和新的搭檔解釋。

阿花認為這降低了工作的效率，并且自己也沒從中獲得額外的收益，那為什么還要提升 Switch Pair 的頻率呢？

分析原因

其實，阿花遇到的工作效率降低問題，可以利用問題1中提到的實踐進行嘗試。

另外，隨著頻率的提升，需要傳輸的信息量也會下降，再加上合理的拆卡，工作效率問題的影響應該微乎其微。

可是，阿花提出的另一個問題，“如何從高頻 Switch Pair 中獲得更高的個人收益問題？” 這卻不是一個單靠結對編程技能就能解答的問題。

先拋開 Switch Pair 的初始目標（信息流動）不談，因為這其實是對于團隊的收益（一定程度上降低團隊人員變化帶來的風險）。 

那么，對個人而言，要想從 Switch Pair 中受益，就需要從敏捷軟件工程實踐的相關理論和目的出發，如果能結合“快速反饋，識別變化”，那得出的結論就不難了：

• 更頻繁的搭檔交換，能使反饋的信息源變化，從而使反饋的角度變化，有利于個人從不同視角識別自身的長處與短板。無論是主動通過觀察學習，還是通過收集反饋，都提供了更加豐富的輸入。
• 縮短單一搭檔工作的時間，但保證周期性的輪換，提供了一個適當的時期（大約一個月）去嘗試、應用一些變化，從而在下次輪換到相同的搭檔時，可以收集驗證性的反饋。

可嘗試的實踐

想要在高頻 Switch Pair 的實踐中最大化個人利益，那么就需要充分利用此時的機會和資源，即不同的搭檔的視角，再結合 Feedback 機制，就可以很容易構建個人有目的，有針對性的提升計劃。

那么就從每次 Switch Pair 前，向上一個搭檔收集這段時間合作的反饋開始吧。

注意：Switch Pair 的頻率不必一味求高，只要能夠確保工作所需的關鍵信息在團隊內充分流動即可。

小結

結對編程也只是程序員工作中會用到的一項技能而已，那么只要是技能，通過時間的堆積，去磨煉，去思考，就會有所提升。

穩扎穩打，時間會給予最棒的回饋！