關於結對程式設計

駕駛和領航員

這些經典的結對程式設計角色定義可以以某種方式應用於許多配對方法。

駕駛是坐在方向盤後的人，也就是鍵盤。她專注於完成手邊的小目標，暫時忽略較大的問題。駕駛在執行時應始終說明她在做什麼。

領航員在駕駛打字時處於觀察者位置。她隨時檢閱程式碼，提供指示並分享想法。領航員還會關注較大的問題、錯誤，並記錄潛在的下一步或障礙。

這種角色劃分的目的是對程式碼有兩種不同的觀點。駕駛的思維應該更具策略性，思考細節，手邊的程式碼行。領航員在他們的觀察角色中可以思考得更具策略性。他們心中有全局觀。

常見流程如下

• 從一個定義良好的任務開始
• 一次同意一個小目標。這可以用單元測試、提交訊息或寫在便利貼上來定義。
• 定期切換鍵盤和角色。共同的積極參與可以保持能量水平，我們可以更好地學習和理解事物。
• 作為領航員，避免「策略性」的思考模式，將編碼的細節留給駕駛 - 您的工作是退後一步，並以中期思考來補充您的配對的更策略性模式。將下一步、潛在障礙和想法停放在便利貼上，並在完成小目標後討論它們，以免打斷駕駛的流程。

乒乓球

此技術採用 測試驅動開發 (TDD)，當您有一個可以透過測試驅動方式實作的明確定義任務時，此技術非常完美。

• 「Ping」：開發人員 A 編寫一個失敗的測試
• 「Pong」：開發人員 B 編寫實作讓測試通過。
• 然後，開發人員 B 開始下一個「Ping」，也就是下一個失敗的測試。
• 每個「Pong」也可以接著一起重構程式碼，然後再進行下一個失敗的測試。這樣您就能遵循「紅 - 綠 - 重構」方法：撰寫一個失敗的測試（紅色）、使用必要的最低手段讓測試通過（綠色），然後 重構。

強式配對

這是一種特別適用於知識傳遞的技術，由 Llewellyn Falco 在 此處 有更詳細的說明。

規則：「要讓一個想法從你的腦袋進入電腦，它必須經過別人的手」。在此風格中，領航員通常是對設定或手邊任務更有經驗的人，而駕駛員是新手（對語言、工具、程式碼庫等）。經驗豐富的人大多擔任領航員的角色，並指導新手。

此方法的一個重要面向是，駕駛員完全信任領航員，並且應該「對不完全了解感到自在」。在實作階段後，應討論「為什麼」的問題以及對解決方案的挑戰。在一個人完全是新手的設定中，這可以讓配對更有效率。

雖然此技術接近微觀管理，但它可以成為一個有用的入門工具，可以優先採用主動的「邊做邊學」方式，而不是被動的「邊看邊學」。此風格非常適合最初的知識傳遞，但不要過度使用。請記住，目標是在一段時間後能夠輕鬆切換角色，並擺脫微觀管理模式。這將表示知識傳遞成功。

配對開發

「配對開發」不只是配對的特定技術，更是一種關於配對的心態。（我們第一次在 Sarah Mei 的 Twitter 帳戶上的 此討論串 中看到這個術語。）開發 使用者故事 或功能通常不僅需要編碼，還需要許多其他任務。作為一個配對，你們要負責所有這些事情。

為了幫助你進入這種心態，以下是故事生命週期中一些非編碼活動的範例，這些活動可以從配對中受益。

設定

對於遠端結對，你需要一個螢幕分享解決方案，它不只能讓你看到，還能控制另一個人的機器，這樣你才能切換鍵盤。現今許多視訊會議工具已經支援這個功能，所以如果你在一家有商業 VC 工具授權的公司工作，先試試看那個。也有開放原始碼的視訊通話工具支援遠端控制，例如 jitsi。對於在較低頻寬下運作的解決方案，試試像 ssh with tmux 或 Visual Studio Code 的 Live Share 擴充功能。

秘訣

• 使用視訊：由於人們透過手勢和面部表情進行大量溝通，因此同時看到共享螢幕和你的結對夥伴的視訊很好。有些視訊會議解決方案附帶這個功能；如果你的沒有，考慮開啟額外的通話以看到彼此。
• 規劃和設計：使用協作線上視覺化工具，以重現紙上或白板上繪製草圖的體驗。
• 音訊體驗：尋找一個安靜的區域，並使用一副好的耳機，甚至配備指向性麥克風。如果你無法遠離噪音，「按鍵通話」功能也有幫助。為避免你這方的干擾，抗噪耳機是你的好朋友。
• 處理網路延遲：當網路延遲時，在遠端電腦上工作一段時間可能會很累人。所以務必定期切換電腦，這樣你們每個人都有機會在自己的機器上無延遲地工作。當你捲動檔案時，網路延遲也可能會很煩人，因為很難跟上。避免在長檔案中捲動有幫助，試著使用鍵盤快速鍵開啟檔案的不同部分，或改用展開/收合功能。

人為因素

如果您在一個並非整個團隊都分散，而只有您其中一、兩位是遠距工作的環境中，請嘗試讓遠距夥伴參與所有在辦公室中發生的討論。我們往往會忘記，光是坐在同一個房間中，我們會無意間分享多少資訊。

與您未曾見過且不認識的人遠距工作會產生額外的挑戰。一方面，配對是讓遠距團隊彼此更親近的機會。另一方面，有時很容易忘記協作的這部分。如果您沒有機會親自見面，請考慮其他方式來更深入地了解彼此，例如嘗試一起遠距喝咖啡。

最後，雖然遠距配對可能會帶來挑戰，但它也可以讓您比在現場配對時更容易專注，因為戴上耳機後可以更輕鬆地消除干擾。

漸行漸遠

配對時，請避免閱讀電子郵件或使用手機。這些干擾可能會讓您的配對夥伴感到不尊重，而且會讓您分心，無法專注於正在處理的任務。如果您真的需要查看某些內容，請公開說明您在做什麼，以及為什麼這麼做。確保每個人都有足夠的時間閱讀電子郵件，方法是安排足夠的休息時間，並每天保留一些個人時間。

微觀管理模式

注意微觀管理模式：它沒有給對方思考的空間，而且如果有人不斷給您指示，例如

• 「現在輸入『System, dot, print, "...
• 「現在我們需要建立一個名為...的新類別」
• 「按下 command shift O...」

不耐煩

應用「5 秒規則」：當領航員看到駕駛員做了一些「錯誤」的事情，並且想要評論時，請在說出任何話之前至少等待 5 秒鐘 - 駕駛員可能已經想到這一點了，然後您就會不必要地打斷他們的思緒。

作為領航員，不要立即指出任何錯誤或即將發生的障礙：稍等一下，讓駕駛員自己修正或寫下便利貼，以便稍後記住。如果您立即介入，可能會打斷駕駛員的思考過程。

霸佔鍵盤

注意您是否「霸佔了鍵盤」：您是否一直控制著鍵盤，不讓您的配對夥伴也打字？

對於您的配對夥伴來說，這可能會是一個非常令人惱火的事情，並且可能會因為「積極參與」受限而讓他們難以專注。請嘗試使用前面描述的方法之一，以確保您頻繁切換鍵盤。

每天配對 8 小時

真正致力於讓結對程式設計發揮作用的團隊，有時會每天配對 8 小時。根據我們的經驗，這並不可持續。首先，這實在太累了。其次，這在實務上甚至行不通，因為除了編碼之外，還有許多其他事情要做，例如查看電子郵件、進行一對一會議、參加會議、研究/學習。因此，在規劃一天時請記住這一點，不要假設它會是 100% 一起編碼。

實用技巧

當你們對所涉及的技術或領域一無所知時，不要迴避配對任務。如果你們持續在最擅長的領域工作，你們將錯失學習新事物並最終在團隊中傳播知識的機會。

如果你們注意到團隊成員傾向於始終處理相同的主題，請要求他們混合搭配以傳播他們的專業知識。建立團隊技術和商業主題的技能矩陣，以及每個成員在每個領域的優勢和差距，也有助於此。如果你們將其放在團隊區域的牆上，你們可以共同努力獲得良好的知識傳播。

實用技巧

這需要你們兩者之間的信任，才能創造一個讓你們都感到自由發問，並對你們不理解的事情公開討論的氛圍。這就是為什麼當你們配對時，在團隊內建立關係變得更加重要。花時間進行定期的一對一和回饋會議。

實用技巧

一起制定計畫！討論手邊的任務，並思考需要採取哪些步驟才能達成目標。將每個步驟寫在便利貼上（或如果遠端，則寫在你的工作單管理系統中的子任務），按順序排列，然後逐一執行。嘗試結合 番茄工作法，並嘗試在一個番茄鐘內完成其中一個目標。

永遠不要忘記溝通是關鍵。討論你在做什麼，並要求彼此提供解釋。

實用技巧

互相提問！提問是了解你在做什麼並找到更好解決方案最有力的工具。如果其中一方無法輕鬆閱讀和理解程式碼，請嘗試另一種更容易理解的方法。

如果你覺得需要對配對編寫的程式碼進行更多程式碼檢閱，請想想是否可以改善你的配對。你是否無法在配對過程中提出所有問題和疑慮？為什麼會這樣？你需要改變什麼？

實用技巧

請記得定期切換鍵盤，並因此定期切換角色。這有助於你更新思維、避免感到無聊，並練習兩種思考方式。

作為導航員，請避免「戰術」思考模式，將編碼的細節留給駕駛員 - 你的工作是退後一步，並用中期的思考方式來補充你的搭檔的較戰術性的模式。

實用技巧

配對程式設計本身並不能保證你達成集體程式碼所有權。你需要確保你也在不同的配對和程式碼區域中輪換人員，以防止知識孤島。

實用技巧

將你的團隊的 WIP 限制在你團隊中的開發人員配對數量，並在你的團隊空間中（或如果你遠端工作，則在你的線上專案管理工具中）讓它可見。在選取新任務之前，請注意限制。WIP 限制紀律可能會自然而然地迫使你養成配對習慣。

實用技巧

僅將新加入者放入配對中是不夠的，然後他們就會「神奇地」被納入和導入。請務必在他們第一次配對會議之前提供全貌和更廣泛的背景，並為導入預留一些額外時間。這將使他們更容易在配對期間追蹤和貢獻，並充分利用它。配對時請務必使用新加入者的機器，以確保他們也能自己設定工作。

制定一個導入計畫，其中列出要涵蓋的主題清單。對於某些主題，你可能想要安排專門的會議，對於其他主題，新團隊成員可以帶著導入計畫從一對配對到另一對配對。如果在配對會議中涵蓋了某個主題，你可以將其從清單中勾選。這樣一來，導入進度對團隊中的每個人都是可見的。

應對方法

充分休息是應對這項挑戰的關鍵。如果你發現你忘記定期休息，請嘗試使用鬧鐘安排休息時間，例如每小時 10 分鐘。或使用時間管理技術，例如 番茄工作法。不要跳過你的午餐休息時間：離開螢幕並真正休息一下。無論是否結對，休息都很重要，並且可以提高生產力。

防止筋疲力盡的另一件重要事情是不要每天結對 8 小時。將其限制在每天最多 6 小時。定期在駕駛和領航員之間切換角色也有助於保持能量水平。

應對方法

在結對會議開始時進行對話可以幫助你了解你們風格之間的差異，並計畫適應這些差異。從以下問題開始你的第一次會議：「我們希望如何一起工作？」、「你比較喜歡如何結對？」。請注意你喜歡如何工作以及如何提高效率，但也不要對其他方法封閉起來 - 也許你會發現一些新事物。

配對一天結束後，彼此進行一輪回饋。如果你覺得給予回饋的想法令人望而生畏，可以把它當成一個小型回顧。想想你們在配對過程中各自的感覺。你警覺嗎？你累了嗎？什麼讓你感到自在，什麼讓你感到不自在？你們夠頻繁地切換鍵盤嗎？你們達成目標了嗎？下次有什麼想嘗試的嗎？養成這個例行公事很好，這樣當事情出錯時，你可以練習給予回饋。

有一些優秀的訓練和書籍可以幫助你處理人際衝突和困難，例如關於困難對話的書籍。

團隊合作面對挑戰，不要把衝突留給個人。你可以透過組織配對會議來做到這一點，在會議中討論如何共同應對困難。會議一開始先收集配對的好處，這樣你們就知道所有人都想從中得到什麼。接著收集每個人在配對時遇到的挑戰。現在小組可以思考哪些行動可能有幫助。你也可以收集團隊成員的熱門按鈕觸發因素：配對時什麼會讓你立即感到不自在？

應對方法

一種方法是限制會議發生的時段，例如透過定義沒有會議的核心配對時段，或透過「中午後不開會」等規則來封鎖沒有會議的時間。

思考會議長度和整體數量也很有價值。你真的需要哪些會議？它們有什麼目標？你可以如何透過適當的準備、促進和明確的議程來提高它們的品質？

但有一件事是肯定的：永遠都會有會議。那麼，作為一對搭檔該如何應對？在配對會議開始時一起查看你們的行事曆，確保你們有足夠的時間開始配對。如果你們有任何會議，請考慮以一對搭檔的身分參加。依賴你的產品負責人或其他非配對團隊成員，在核心配對時段讓團隊遠離中斷。

應對方法

如果你的搭檔在這個主題上有更多經驗：不要假設他們最了解。也許需要解釋他們為什麼以這種方式做事，這會為他們帶來新的見解。詢問如何和為什麼的問題，可能會導致富有成效的討論和更好的解決方案。

如果你的搭檔在這個主題上的經驗較少：不要假設他們無法對解決方案做出太多貢獻。你可能戴著眼罩，而不同的觀點可以幫助你找到更好的解決方案。此外，請記住，必須解釋一個概念是一個很好的機會，可以測試你是否真的理解它並徹底思考過它。

了解不同的學習階段也有助於理解從新手到專家的學習過程如何運作。丹·諾斯在他的演講中很好地描述了這一點，有效團隊的模式。他介紹了德雷福斯技能習得模型，作為理解不同學習階段的方法，以及將它們結合起來在配對的背景下意味著什麼。

應對方法

解決此問題的第一步是處於權力動態上升一方的人承認並承認自己的地位。只有這樣，你才能誠實地反思與配對夥伴的互動，以及權力動態如何影響它們。試著思考你自己的位置和處境。你積極做些什麼來消除權力失衡？

認識到這些類型的差異並調整我們的行為以改善協作可能很困難。這需要大量的自我反省。有一些培訓可以幫助個人或團隊做到這一點，例如「反偏見」或盟友技能培訓。

應對方法

當有許多未知數時，例如你使用一項新技術，請考慮執行尖峰來探索主題並在實際開始工作之前了解技術。別忘了與團隊分享你的發現，也許你可以舉辦知識交流會議，並繪製一些可以張貼在團隊空間的圖表。

在這些情況下，請記住採用配對開發的心態，而不是配對程式設計。分頭進行研究是可以的，也許在同意需要共同回答的問題集後。

應對方法

再次強調，不要一天配對 8 小時，與你的團隊同意核心編碼時間，並將其限制在每天最多 6 小時。也許你還想分配幾個小時的自學時間。

當一對搭檔覺得他們沒有足夠的知識來解決問題時，請分頭閱讀並分享，然後繼續實作。

應對方法

在輪替頻率和新的配對夥伴有足夠背景來適當地做出貢獻的可能性之間取得平衡。不要為了輪替而輪替，想想分享某個背景是否重要以及為什麼重要，並給它足夠的時間以發揮效果。

應對方法

展現脆弱性需要勇氣，並創造一個環境，讓人們可以更安全地展現他們的脆弱性。同樣地，這一切都與建立團隊有關，在團隊中，人們彼此信任（定期 1:1、回饋、人們可以提問的文化等）。

對於在團隊中擁有更多權威的人來說，表現出脆弱性更容易、風險也更低，無論是自然的（例如，因為他們已經很受尊敬）或制度性的（例如，因為他們擁有「技術主管」等頭銜）。因此，重要的是，那些人開始並成為這種行為的榜樣，讓它成為常態，並因此讓其他人也能更安全地表現出脆弱性。

應對方法

沒有簡單的配方來說服他人配對程式設計的效用。然而，一個關鍵要素應該是花時間先討論它，並確保每個人都有相同的理解（例如，閱讀這篇文章 :-) ）。然後找到一種方法來嘗試它，無論是從一對分享他們經驗的人開始，或提出團隊實驗，例如「讓我們在接下來的 2 個衝刺中預設配對」。務必建立回饋和回顧的機會，以分享進行順利的事項和遇到困難的事項。

最終，你無法強迫人們採用某種做法，而且它並不適用於所有人。你最終可能只與團隊的一部分人配對 - 至少在開始時。根據我們的經驗，說服人們的最佳方式是定期接觸這種做法，體驗配對時團隊成員獲得的好處和樂趣。

在這種情況下最常出現的問題是實務經濟效益：結對程式設計是否會讓成本增加一倍，而增加的品質和團隊效益是否值得額外的成本？有幾項關於這個主題的研究，最著名的就是 這篇，被引用來提供結對程式設計值得執行的證據。不過，我們對於「科學證明」結對程式設計有效性的嘗試持保留態度。軟體開發是一個充滿變動和不確定性的過程，除了程式碼之外，還有許多難以比較和衡量的成果，例如分析、測試或 品質。結對程式設計的堅定反對者總能找到方法，對任何用來證明開發生產力的「科學」實驗的可重複性提出質疑。最後，你需要證明它對你有效，而唯一的方法就是在你的環境中嘗試看看。