背景
最近，我開始重新審視這些融入日常的工程實(shí)踐方式，去嘗試找出實(shí)際與理論的差距，分析差距成因，基于分析結(jié)果，嘗試找出可以逐步彌補(bǔ)差距的實(shí)踐方式，從而讓日常軟件交付工作變得更加“順滑”。
本文作為“沉思錄”的第一篇，將列舉實(shí)際交付項(xiàng)目中，在結(jié)對編程時遇到的幾個實(shí)際問題，并針對具體問題給出一些嘗試過的解決方式。
如有其他更好的建議，歡迎共同討論。
注意：以下話題不在本文的討論范圍中，并且默認(rèn)讀者已經(jīng)具備下列問題相關(guān)的知識:
- 為什么進(jìn)行結(jié)對編程？（如果想了解，可以參見維基百科 或其他相關(guān)郵件）
- 怎樣開始結(jié)對編程？（如果想了解，可以參見《7個你需要知道的結(jié)對禮儀》）
工作環(huán)境上下文
- 9 人團(tuán)隊(duì)（1 BA， 1 QA， 1 TL， 6 Devs）
- 特殊角色（BA，QA， TL）基本都是 Solo 工作，Dev Pair 工作
- 每對 Pair 同一時間只會工作在一個 User Story 上，直到該 User Story 進(jìn)入測試階段
- 團(tuán)隊(duì)在 Sprint 開始時進(jìn)行 Switch Pair 活動，User Story 未完成的 Pair，會有一人留在未完成的 Story 上，以便完成保證卡片上下文充足
- Switch Pair 會按照 Pair 輪換表（如下）進(jìn)行，以確保所有開發(fā)都會有均等的 Pair 機(jī)會
Dev輪換表大概是這個樣子（每個周期內(nèi)團(tuán)隊(duì)采用同一編號的配對組合）：
基于以上的上下文，我們遇到了以下實(shí)際問題：
問題 1：Switch Pair時，需要交接的內(nèi)容過多
Switch Pair 時，需要交接的內(nèi)容過多時，可能會漏掉一些細(xì)節(jié)信息。為了補(bǔ)充遺漏，會陷入更多、更深的討論。
具體場景
張三和薛霸經(jīng)過了一周的結(jié)對編程，手頭的一張復(fù)雜 User Story （無法進(jìn)一步拆分）沒有完成，薛霸被留在了當(dāng)前工作上，準(zhǔn)備和阿樂開始工作。
可是，在薛霸向阿樂介紹當(dāng)前的工作進(jìn)度時，無法清楚地給阿樂說明之前所寫代碼與 User Stroy 的對應(yīng)關(guān)系和一些必要的上下文。
于是這對 Pair 不得不將張三重新拉回來，進(jìn)行上下文交接，三人討論時間較長，并且會將之前已經(jīng)討論過的問題重新討論，降低了工作效率。
分析原因
后來，張三，薛霸，阿樂對這次效率不盡人意的 Switch Pair 進(jìn)行了回顧，嘗試?yán)?strong>問答的形式進(jìn)行分析：
-
對于阿樂的問題，薛霸無法清楚地解答，但在拉回張三后，增加了一些額外的討論時間，就可以解答了。
問： 結(jié)對的兩人在當(dāng)前工作中，理論上應(yīng)該能夠具備相當(dāng)信息積累。那么，為什么當(dāng)前薛霸和張三出現(xiàn)了信息積累差異的情況？
答：卡片從 Kick-Off 到當(dāng)前交接 Switch Pair 的時間跨度較長（7天，含周末），包含內(nèi)容較多，需要一些討論重新回想起當(dāng)時的信息。
另外，薛霸無法解答的問題，基本都是張三在薛霸請假期間完成的。 -
結(jié)對編程理應(yīng)是有任務(wù)拆分（Tasking）作為前提的，以確保 Pair 兩人對于當(dāng)前的工作進(jìn)度一致，以盡量減輕請假所帶來的信息不對稱問題。
問：為什么當(dāng)前的效果并不理想？
答：最初拆分的任務(wù)粒度較大，但實(shí)際上，在一個大粒度的任務(wù)中，會包含一些較小粒度的任務(wù)，并且這些任務(wù)的完成結(jié)果，還會影響后續(xù)的任務(wù)內(nèi)容。在工作時，完成了這些較小粒度的任務(wù)后，沒有將關(guān)鍵工作內(nèi)容更新到兩人共享的任務(wù)列表中，于是造成了信息不對稱情況。
可嘗試的實(shí)踐
于是，大家總結(jié)出了如下可以實(shí)行的行動：
- 初始任務(wù)拆分盡量將可能會產(chǎn)生任務(wù)分支的關(guān)鍵任務(wù)（或問題）標(biāo)出。
- 在完成任務(wù)的過程中，保持最初任務(wù)列表的更新，特別是上述的關(guān)鍵任務(wù)，按需記錄任務(wù)的產(chǎn)出或關(guān)鍵信息。
- Switch Pair 圍繞任務(wù)列表進(jìn)行，以避免出現(xiàn)內(nèi)容遺漏或花費(fèi)額外時間討論上下文外的問題。
問題 2：Pair時，其中一人變Solo
- 采用Navigator-Driver Pair 模式時，掌握鍵盤和鼠標(biāo)的一人（Driver），有時會成兼任 Navigator 角色。
- Pair 過程中，一人會處于高度集中狀態(tài)，另外一人可能會因?yàn)闆]跟上，而從 Pair 中脫出，產(chǎn)生信息斷層。
- Pair 過程中，如果不作 Driver 的角色，可能無法完全掌握當(dāng)前 User Story 的全貌。
其實(shí)上述的問題是有一定的內(nèi)在邏輯聯(lián)系的，可以通過下面的具體場景來進(jìn)行復(fù)現(xiàn)。
具體場景
肖蘭和阿發(fā)在結(jié)對編程過程中，肖蘭使用自己的筆記本電腦外接顯示器，并通過筆記本的鍵盤和觸控板完成操作，阿發(fā)則可以通過外接的顯示器看到肖蘭的操作。
起初，兩人會對著外接顯示器進(jìn)行一些討論。
但在深入調(diào)查代碼時和一些代碼編寫時，肖蘭開始對著自己的筆記本屏幕進(jìn)行操作，隨著肖蘭逐漸地集中精力，討論和解說停止了。
在連續(xù)幾次的進(jìn)入某個類查看細(xì)節(jié)代碼，再切換到另外幾個文件中查看配置文件后，肖蘭寫了幾行代碼試了試。
如此反復(fù)了幾次后，阿發(fā)已經(jīng)不清楚肖蘭所進(jìn)行操作的目的了，但他看著肖蘭投入的樣子，欲言又止，不忍心打斷她的操作。
于是阿發(fā)又努力了3分鐘嘗試跟上肖蘭的思路，可是猜透一個人的心思何其難也，阿發(fā)最終無奈放棄，于是默默轉(zhuǎn)向自己的電腦（手機(jī)），去看看郵件（朋友圈），等待肖蘭等下有了結(jié)果再同步給他。
可是，肖蘭在完成的調(diào)查整個過程中獲得的信息，卻不一定都能同步給阿發(fā)，阿發(fā)也就無法掌握當(dāng)前工作的全貌了。
至此，Pair 終成 Solo...
分析原因
-
硬件設(shè)施準(zhǔn)備不充分。
肖蘭掌控了所有的操作，阿發(fā)更多的時候都處于一種“被動”狀態(tài)，結(jié)對編程的參與感不高，特別是當(dāng)肖蘭“全情投入”后，阿發(fā)的參與感幾乎被全部“剝奪”。
說明：在了解 “如何進(jìn)行結(jié)對編程” 的部分有說明過，結(jié)對編程的兩人在硬件準(zhǔn)備上，應(yīng)該盡量平等，至少兩人都有可以各自操作的鍵盤。
-
沒有分配、交換角色的活動。
結(jié)對編程是兩個人共同合作的活動，那么兩人中每個個體在活動中的體驗(yàn)感就直接影響這項(xiàng)活動的效果。
在上述例子中，肖蘭一開始就掌握了"操作權(quán)”，到了代碼調(diào)查階段時，肖蘭又直接“搶奪”了思維的“導(dǎo)向權(quán)”，隨著自己的想法去調(diào)查、嘗試。
導(dǎo)致阿發(fā)在這次結(jié)對編程中的參與度極低，體驗(yàn)感也極差，并最終轉(zhuǎn)向獨(dú)自工作。
說明：為了保證結(jié)對兩人的參與度，結(jié)對編程存在多種不同的實(shí)踐方式（Navigator-Driver 模式、乒乓模式、鍵盤 + 鼠標(biāo)模式），但無論采用那種方式，兩人都應(yīng)在實(shí)踐一段時間后，交換角色，從而使每人都有機(jī)會從不同的視角分析、解決問題。
-
缺少有效溝通。
結(jié)對編程與其說是編程方式，不如說更多是的一種“社交”活動。那么，在整個過程中，結(jié)對兩人需要進(jìn)行大量，高強(qiáng)度的溝通交流。
在上述場景中，一方面，當(dāng)肖蘭要開始進(jìn)行一些深入調(diào)查時，沒有說明意圖，從而使阿發(fā)開始產(chǎn)生迷茫。
另一方面，當(dāng)阿發(fā)努力嘗試后，依然認(rèn)為自己跟不上肖蘭的操作時，沒有與肖蘭說明情況，從而使兩人的“信息鴻溝”進(jìn)一步被擴(kuò)大。
可嘗試的實(shí)踐
針對上述問題，可以：
- 每對Pair中，至少有一人使用從公司申請（自備）的鍵盤和鼠標(biāo)，確保每個人都有條件能在想要操作的時候進(jìn)行操作。
- 每對 Pair 按照拆分的任務(wù)列表，每完成 1（X）個任務(wù)，交換一次兩人的角色。
- 練習(xí)提問。結(jié)對的兩人中，任何一人發(fā)現(xiàn)兩人的思路不一致時，通過提問的方式，將問題暴露，并解決。
問題 3：Switch Pair頻率高，引發(fā)高溝通成本
Pair 過程會產(chǎn)生大量的溝通交流，頻繁的 Switch Pair 會使這種交流的成本擴(kuò)大，那么如何從這種高頻的 Switch Pair 活動中獲得更高的個人收益呢？
具體場景
團(tuán)隊(duì)最近在嘗試提高 Switch Pair 的頻率，從之前的每兩周提升到現(xiàn)在的每周一次，之后視情況仍有提升的可能。
而這給阿花造成了困擾，因?yàn)閹缀趺看谓Y(jié)對編程，阿花都和搭檔會討論很多問題，而幾乎每次 Switch Pair，阿花都需要花費(fèi)不少時間將這些討論的結(jié)果和新的搭檔解釋。
阿花認(rèn)為這降低了工作的效率，并且自己也沒從中獲得額外的收益，那為什么還要提升 Switch Pair 的頻率呢？
分析原因
其實(shí)，阿花遇到的工作效率降低問題，可以利用問題1中提到的實(shí)踐進(jìn)行嘗試。
另外，隨著頻率的提升，需要傳輸?shù)男畔⒘恳矔陆?，再加上合理的拆卡，工作效率問題的影響應(yīng)該微乎其微。
可是，阿花提出的另一個問題，“如何從高頻 Switch Pair 中獲得更高的個人收益問題？” 這卻不是一個單靠結(jié)對編程技能就能解答的問題。
先拋開 Switch Pair 的初始目標(biāo)（信息流動）不談，因?yàn)檫@其實(shí)是對于團(tuán)隊(duì)的收益（一定程度上降低團(tuán)隊(duì)人員變化帶來的風(fēng)險）。
那么，對個人而言，要想從 Switch Pair 中受益，就需要從敏捷軟件工程實(shí)踐的相關(guān)理論和目的出發(fā)，如果能結(jié)合“快速反饋，識別變化”，那得出如下的結(jié)論就不難了：
- 更頻繁的搭檔交換，能使反饋的信息源變化，從而使反饋的角度變化，有利于個人從不同視角識別自身的長處與短板。無論是主動通過觀察學(xué)習(xí)，還是通過收集反饋，都提供了更加豐富的輸入。
- 縮短單一搭檔工作的時間，但保證周期性的輪換，提供了一個適當(dāng)?shù)臅r期（大約一個月）去嘗試、應(yīng)用一些變化，從而在下次輪換到相同的搭檔時，可以收集驗(yàn)證性的反饋。
可嘗試的實(shí)踐
想要在高頻 Switch Pair 的實(shí)踐中最大化個人利益，那么就需要充分利用此時的機(jī)會和資源，即不同的搭檔的視角，再結(jié)合 **Feedback **機(jī)制，就可以很容易構(gòu)建個人有目的，有針對性的提升計(jì)劃。
- 那么就從每次 Switch Pair 前，向上一個搭檔收集這段時間合作的反饋開始吧。
注意：Switch Pair 的頻率不必一味求高，只要能夠確保工作所需的關(guān)鍵信息在團(tuán)隊(duì)內(nèi)充分流動即可。
小結(jié)
結(jié)對編程也只是程序員工作中會用到的一項(xiàng)技能而已，那么只要是技能，通過時間的堆積，去磨煉，去思考，就會有所提升。
穩(wěn)扎穩(wěn)打，時間會給予最棒的回饋！
相關(guān)參考
文/Thoughtworks 何疆樂
原文鏈接：https://insights.thoughtworks.cn/pair-programming-anti-patterns/
