Pair programming（結對程式設計）與 mob programming（群體程式設計）是在敏捷軟體開發中，常提到的實踐。

直白的講法就是與他人結對（兩人）、或群體（三人以上）一起進行程式設計。但比較有趣的地方是，只會有一組電腦與其週邊（螢幕、鍵盤、滑鼠），而操作電腦的人，就是所謂的 Driver，而說話請 Driver 做事的人，就是 Navigator。

Navigator 可以用一步一指令、較為死板的方式請 Driver 做事，也可以像是對高級人工智慧說話一樣，告訴對方你想做什麼事。

比如說：

• 為這個需求先寫一個最簡單的測試（智慧版）
• 到 /src/composable/__test__ 資料夾底下建立一個 fooTest.ts 的檔案（指令版）

透過這樣的一個合作方式，就會發現彼此的認知落差，進而產生學習的機會，並對齊期望在團隊落實的實踐風格。

這是比較技術層面的，另外在實作待辦事項時，也能趁早去揭露彼此對於需求、驗收條件、測試案例的認知，透過時時的對話與提問，及早發現誤解之處，或是更好的解決方案。

這樣的過程，隨時都在發生前面提及的三本柱——透明、檢視、調適。讓開發過程中能夠更即時的溝通，減少浪費，創造更多的價值。

另外在導入 mob programming 時，團隊也曾困惑過，認為這樣的開發方式反而讓開發速度變慢，不確定效益是什麼。

當時我就畫了下面這張因果循環圖與他們聊聊：

左上是 Mob 造成的開發成本隨時間變化的趨勢圖，右邊則是團隊成熟度提高對開發正向影響隨時間變化的趨勢圖。

這張圖闡釋，Mob 雖然短期內會對開發進度造成影響，但事實上他只是將團隊過往沒有溝通、對齊的事情浮上檯面，讓團隊不得不去交流，進而增加成本。 但隨著時間過去，這些落差越來越小，而團隊的成熟度與技術也越來越像能力比較高的長板靠齊，開發速度也就會增快。

所以別因為短期乍看之下造成負擔就放棄，而應該著眼在長期對整體團隊益處而不斷實踐。畢竟會慢，其實就代表著其實團隊之間存在著知識、技能與實踐的落差。