團隊的本質#

作者以運動隊伍為隱喻開場：想像一支球隊在推進球的過程中，某位球員絆倒了，但比賽繼續——其他球員會調整位置來填補缺口，保持球繼續前進。這就是團隊的行為方式。

程式設計團隊也應如此：當 Bob 倒下時，最近與 Bob 合作過的人可以填補空缺。要實現這一點，團隊需要協作，讓系統的知識在團隊中流通傳播。

協作程式設計的形式與實踐#

協作程式設計（Collaborative Programming） 是指兩個或以上的人同時在同一段程式碼上工作：

時間分配與節奏#

• 協作不應佔 100% 的工作時間（雖然有些團隊這麼做且樂在其中）
• 建議範圍：團隊工作時間的 20% 到 70%，取決於團隊的成熟度、技能、地理位置與人員組成
• 每次協作會議持續 10 分鐘到 1-2 小時——太短或太長都不太有幫助

作者最喜歡的協作策略是使用 Pomodoro Technique（番茄工作法）——將時間分成約 20 分鐘的「番茄」單元，中間穿插短休息。一次協作會議應持續 1 到 3 個番茄。

會議的運作方式#

• 協作會議的壽命遠短於程式設計任務——個別程式設計師負責特定任務，然後不定期邀請協作者幫忙
• 沒有人主導會議或會議中操作的程式碼——每位參與者都是程式碼的平等作者與貢獻者
• 負責任務的程式設計師在出現分歧時擔任最終仲裁者
• 所有人的眼睛注視螢幕、心思投入問題——鍵盤座位可以在會議中頻繁輪換
• 可以把會議同時視為即時程式碼練習和程式碼審查

協作會議非常密集，需要大量的心智和情緒能量。平均而言，一到兩小時的高強度協作就是程式設計師能忍受的極限，之後需要轉移到較不消耗的活動。

生產力的數據#

你可能擔心協作是人力的低效使用——獨立工作的人是否能完成更多？研究顯示並非如此：

後兩項數據暗示，產出的程式碼結構顯著優於獨立工作時可能產生的程式碼。這不只是效率的問題，更是品質的問題。

作者表示沒有看過群組程式設計的正式研究，但軼事證據令人鼓舞。

不同組合的考量#

資深 + 資淺#

• 資深者在會議期間會被資淺者拖慢
• 但資淺者會因此被加速一輩子——所以這是一筆好交易

資深 + 資深#

• 確保房間裡沒有武器（作者的幽默）

資淺 + 資淺#

• 資深者應密切觀察這類會議
• 資淺者通常偏好與其他資淺者合作——如果這種情況發生得太頻繁，資深者應介入

個人偏好與技能培養#

• 有些人就是不喜歡這種協作方式，有些人獨自工作效果更好
• 不應強迫他們超越合理的同儕壓力，也不應貶低他們的偏好
• 這類人通常在群組（mob）中比在結對（pair）中更自在
• 協作是一項需要時間和耐心才能習得的技能——不要指望在練習多時之前就能做得好
• 但這是一項對整個團隊和每位參與者都非常有益的技能