背景
最近但惶，我開始重新審視這些融入日常的工程實(shí)踐方式，去嘗試找出實(shí)際與理論的差距樱衷，分析差距成因，基于分析結(jié)果酒唉，嘗試找出可以逐步彌補(bǔ)差距的實(shí)踐方式矩桂，從而讓日常軟件交付工作變得更加“順滑”。
本文作為“沉思錄”的第一篇痪伦，將列舉實(shí)際交付項(xiàng)目中侄榴，在結(jié)對編程時(shí)遇到的幾個(gè)實(shí)際問題，并針對具體問題給出一些嘗試過的解決方式网沾。
如有其他更好的建議癞蚕，歡迎共同討論。
注意：以下話題不在本文的討論范圍中辉哥，并且默認(rèn)讀者已經(jīng)具備下列問題相關(guān)的知識:
- 為什么進(jìn)行結(jié)對編程桦山？（如果想了解攒射，可以參見維基百科 或其他相關(guān)郵件）
- 怎樣開始結(jié)對編程？（如果想了解恒水，可以參見《7個(gè)你需要知道的結(jié)對禮儀》）
工作環(huán)境上下文
- 9 人團(tuán)隊(duì)（1 BA会放， 1 QA， 1 TL钉凌， 6 Devs）
- 特殊角色（BA鸦概，QA， TL）基本都是 Solo 工作甩骏，Dev Pair 工作
- 每對 Pair 同一時(shí)間只會工作在一個(gè) User Story 上，直到該 User Story 進(jìn)入測試階段
- 團(tuán)隊(duì)在 Sprint 開始時(shí)進(jìn)行 Switch Pair 活動先慷，User Story 未完成的 Pair饮笛，會有一人留在未完成的 Story 上，以便完成保證卡片上下文充足
- Switch Pair 會按照 Pair 輪換表（如下）進(jìn)行论熙，以確保所有開發(fā)都會有均等的 Pair 機(jī)會
Dev輪換表大概是這個(gè)樣子（每個(gè)周期內(nèi)團(tuán)隊(duì)采用同一編號的配對組合）：
基于以上的上下文福青，我們遇到了以下實(shí)際問題：
問題 1：Switch Pair時(shí)，需要交接的內(nèi)容過多
Switch Pair 時(shí)脓诡，需要交接的內(nèi)容過多時(shí)无午，可能會漏掉一些細(xì)節(jié)信息。為了補(bǔ)充遺漏祝谚，會陷入更多宪迟、更深的討論。
具體場景
張三和薛霸經(jīng)過了一周的結(jié)對編程交惯，手頭的一張復(fù)雜 User Story （無法進(jìn)一步拆分）沒有完成次泽，薛霸被留在了當(dāng)前工作上，準(zhǔn)備和阿樂開始工作席爽。
可是意荤，在薛霸向阿樂介紹當(dāng)前的工作進(jìn)度時(shí)，無法清楚地給阿樂說明之前所寫代碼與 User Stroy 的對應(yīng)關(guān)系和一些必要的上下文只锻。
于是這對 Pair 不得不將張三重新拉回來玖像，進(jìn)行上下文交接，三人討論時(shí)間較長齐饮，并且會將之前已經(jīng)討論過的問題重新討論捐寥，降低了工作效率。
分析原因
后來祖驱，張三上真，薛霸，阿樂對這次效率不盡人意的 Switch Pair 進(jìn)行了回顧羹膳，嘗試?yán)?strong>問答的形式進(jìn)行分析：
-
對于阿樂的問題睡互，薛霸無法清楚地解答，但在拉回張三后，增加了一些額外的討論時(shí)間就珠，就可以解答了寇壳。
問： 結(jié)對的兩人在當(dāng)前工作中，理論上應(yīng)該能夠具備相當(dāng)信息積累妻怎。那么壳炎，為什么當(dāng)前薛霸和張三出現(xiàn)了信息積累差異的情況？
答：卡片從 Kick-Off 到當(dāng)前交接 Switch Pair 的時(shí)間跨度較長（7天逼侦，含周末）匿辩，包含內(nèi)容較多，需要一些討論重新回想起當(dāng)時(shí)的信息榛丢。
另外铲球，薛霸無法解答的問題，基本都是張三在薛霸請假期間完成的晰赞。 -
結(jié)對編程理應(yīng)是有任務(wù)拆分（Tasking）作為前提的稼病，以確保 Pair 兩人對于當(dāng)前的工作進(jìn)度一致，以盡量減輕請假所帶來的信息不對稱問題掖鱼。
問：為什么當(dāng)前的效果并不理想然走？
答：最初拆分的任務(wù)粒度較大，但實(shí)際上戏挡，在一個(gè)大粒度的任務(wù)中芍瑞，會包含一些較小粒度的任務(wù)，并且這些任務(wù)的完成結(jié)果褐墅，還會影響后續(xù)的任務(wù)內(nèi)容啄巧。在工作時(shí)，完成了這些較小粒度的任務(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)額外時(shí)間討論上下文外的問題选酗。
問題 2：Pair時(shí)，其中一人變Solo
- 采用Navigator-Driver Pair 模式時(shí)岳枷，掌握鍵盤和鼠標(biāo)的一人（Driver）芒填，有時(shí)會成兼任 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)查代碼時(shí)和一些代碼編寫時(shí)钳榨，肖蘭開始對著自己的筆記本屏幕進(jìn)行操作，隨著肖蘭逐漸地集中精力纽门，討論和解說停止了薛耻。
在連續(xù)幾次的進(jìn)入某個(gè)類查看細(xì)節(jié)代碼，再切換到另外幾個(gè)文件中查看配置文件后赏陵，肖蘭寫了幾行代碼試了試饼齿。
如此反復(fù)了幾次后，阿發(fā)已經(jīng)不清楚肖蘭所進(jìn)行操作的目的了蝙搔，但他看著肖蘭投入的樣子缕溉，欲言又止，不忍心打斷她的操作吃型。
于是阿發(fā)又努力了3分鐘嘗試跟上肖蘭的思路证鸥，可是猜透一個(gè)人的心思何其難也，阿發(fā)最終無奈放棄勤晚，于是默默轉(zhuǎn)向自己的電腦（手機(jī)）枉层，去看看郵件（朋友圈），等待肖蘭等下有了結(jié)果再同步給他赐写。
可是鸟蜡，肖蘭在完成的調(diào)查整個(gè)過程中獲得的信息，卻不一定都能同步給阿發(fā)挺邀，阿發(fā)也就無法掌握當(dāng)前工作的全貌了揉忘。
至此跳座，Pair 終成 Solo...
分析原因
-
硬件設(shè)施準(zhǔn)備不充分。
肖蘭掌控了所有的操作癌淮，阿發(fā)更多的時(shí)候都處于一種“被動”狀態(tài)躺坟，結(jié)對編程的參與感不高，特別是當(dāng)肖蘭“全情投入”后乳蓄，阿發(fā)的參與感幾乎被全部“剝奪”咪橙。
說明：在了解 “如何進(jìn)行結(jié)對編程” 的部分有說明過，結(jié)對編程的兩人在硬件準(zhǔn)備上虚倒，應(yīng)該盡量平等美侦，至少兩人都有可以各自操作的鍵盤。
-
沒有分配魂奥、交換角色的活動菠剩。
結(jié)對編程是兩個(gè)人共同合作的活動，那么兩人中每個(gè)個(gè)體在活動中的體驗(yàn)感就直接影響這項(xiàng)活動的效果耻煤。
在上述例子中具壮，肖蘭一開始就掌握了"操作權(quán)”，到了代碼調(diào)查階段時(shí)哈蝇，肖蘭又直接“搶奪”了思維的“導(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í)踐一段時(shí)間后峭拘，交換角色汽煮，從而使每人都有機(jī)會從不同的視角分析、解決問題棚唆。
-
缺少有效溝通暇赤。
結(jié)對編程與其說是編程方式，不如說更多是的一種“社交”活動宵凌。那么娃圆，在整個(gè)過程中昭齐，結(jié)對兩人需要進(jìn)行大量近哟，高強(qiáng)度的溝通交流。
在上述場景中译株，一方面，當(dāng)肖蘭要開始進(jìn)行一些深入調(diào)查時(shí)挺益，沒有說明意圖歉糜，從而使阿發(fā)開始產(chǎn)生迷茫。
另一方面望众，當(dāng)阿發(fā)努力嘗試后匪补，依然認(rèn)為自己跟不上肖蘭的操作時(shí)，沒有與肖蘭說明情況烂翰，從而使兩人的“信息鴻溝”進(jìn)一步被擴(kuò)大夯缺。
可嘗試的實(shí)踐
針對上述問題，可以：
- 每對Pair中甘耿，至少有一人使用從公司申請（自備）的鍵盤和鼠標(biāo)踊兜，確保每個(gè)人都有條件能在想要操作的時(shí)候進(jìn)行操作。
- 每對 Pair 按照拆分的任務(wù)列表佳恬，每完成 1（X）個(gè)任務(wù)捏境，交換一次兩人的角色。
- 練習(xí)提問毁葱。結(jié)對的兩人中垫言，任何一人發(fā)現(xiàn)兩人的思路不一致時(shí)，通過提問的方式头谜，將問題暴露骏掀，并解決鸠澈。
問題 3：Switch Pair頻率高柱告，引發(fā)高溝通成本
Pair 過程會產(chǎn)生大量的溝通交流，頻繁的 Switch Pair 會使這種交流的成本擴(kuò)大笑陈，那么如何從這種高頻的 Switch Pair 活動中獲得更高的個(gè)人收益呢际度？
具體場景
團(tuán)隊(duì)最近在嘗試提高 Switch Pair 的頻率，從之前的每兩周提升到現(xiàn)在的每周一次涵妥，之后視情況仍有提升的可能乖菱。
而這給阿花造成了困擾，因?yàn)閹缀趺看谓Y(jié)對編程蓬网，阿花都和搭檔會討論很多問題窒所，而幾乎每次 Switch Pair，阿花都需要花費(fèi)不少時(shí)間將這些討論的結(jié)果和新的搭檔解釋帆锋。
阿花認(rèn)為這降低了工作的效率吵取，并且自己也沒從中獲得額外的收益，那為什么還要提升 Switch Pair 的頻率呢锯厢？
分析原因
其實(shí)皮官，阿花遇到的工作效率降低問題脯倒，可以利用問題1中提到的實(shí)踐進(jìn)行嘗試。
另外捺氢，隨著頻率的提升藻丢，需要傳輸?shù)男畔⒘恳矔陆担偌由虾侠淼牟鹂ㄉ闫梗ぷ餍蕟栴}的影響應(yīng)該微乎其微悠反。
可是，阿花提出的另一個(gè)問題缺狠，“如何從高頻 Switch Pair 中獲得更高的個(gè)人收益問題问慎？” 這卻不是一個(gè)單靠結(jié)對編程技能就能解答的問題。
先拋開 Switch Pair 的初始目標(biāo)（信息流動）不談挤茄，因?yàn)檫@其實(shí)是對于團(tuán)隊(duì)的收益（一定程度上降低團(tuán)隊(duì)人員變化帶來的風(fēng)險(xiǎn)）如叼。
那么，對個(gè)人而言穷劈，要想從 Switch Pair 中受益笼恰，就需要從敏捷軟件工程實(shí)踐的相關(guān)理論和目的出發(fā)，如果能結(jié)合“快速反饋歇终，識別變化”社证，那得出如下的結(jié)論就不難了：
- 更頻繁的搭檔交換，能使反饋的信息源變化评凝，從而使反饋的角度變化追葡，有利于個(gè)人從不同視角識別自身的長處與短板。無論是主動通過觀察學(xué)習(xí)奕短，還是通過收集反饋宜肉，都提供了更加豐富的輸入。
- 縮短單一搭檔工作的時(shí)間翎碑，但保證周期性的輪換谬返，提供了一個(gè)適當(dāng)?shù)臅r(shí)期（大約一個(gè)月）去嘗試、應(yīng)用一些變化日杈，從而在下次輪換到相同的搭檔時(shí)遣铝，可以收集驗(yàn)證性的反饋。
可嘗試的實(shí)踐
想要在高頻 Switch Pair 的實(shí)踐中最大化個(gè)人利益莉擒，那么就需要充分利用此時(shí)的機(jī)會和資源酿炸，即不同的搭檔的視角，再結(jié)合 **Feedback **機(jī)制涨冀，就可以很容易構(gòu)建個(gè)人有目的填硕，有針對性的提升計(jì)劃。
- 那么就從每次 Switch Pair 前蝇裤，向上一個(gè)搭檔收集這段時(shí)間合作的反饋開始吧廷支。
注意：Switch Pair 的頻率不必一味求高频鉴，只要能夠確保工作所需的關(guān)鍵信息在團(tuán)隊(duì)內(nèi)充分流動即可。
小結(jié)
結(jié)對編程也只是程序員工作中會用到的一項(xiàng)技能而已恋拍，那么只要是技能垛孔，通過時(shí)間的堆積，去磨煉施敢，去思考周荐，就會有所提升。
穩(wěn)扎穩(wěn)打僵娃，時(shí)間會給予最棒的回饋概作！
相關(guān)參考
文/Thoughtworks 何疆樂
原文鏈接：https://insights.thoughtworks.cn/pair-programming-anti-patterns/
