兩個披薩團隊

🎯 什麼情境該想到我

當你「團隊一變大，光是讓每個人知道現在發生什麼事就耗掉大半時間」的時候。

⚙️ 怎麼用（步驟 / 公式）

意圖：用團隊人數上限，反過來限制跨團隊溝通量與系統複雜度的成長速率。

做法要點：

• 出處與時間：這是 Amazon 從 2002 年起、脫離單體程式碼庫那場轉型倡議的一部分。（L3933–3935）
• 規則：團隊只能大到「兩個披薩餵得飽」——通常約 5 到 10 人。（L3934–3935）
• 為什麼從康威定律推得出來：康威定律幫我們照期望的溝通模式設計團隊邊界，同時也促使我們把團隊規模保持得小，以減少團隊間的溝通量，並讓每個團隊的領域範圍保持小而有界。（L3928–3931）
• 四個效果（L3937–3959）：
  1. 確保團隊對所負責的系統有清楚、共享的理解。團隊一大，讓所有人都掌握狀況所需的溝通量會以**組合方式（combinatorial fashion）**增長。
  2. 刻意限制產品或服務的成長速率。限制團隊大小，就是限制其系統能演進的速率——這也回頭幫助維持共享理解。
  3. 分散權力、實現自主。每個 two-pizza team（2PT）盡可能自治：團隊的 lead 與高層共同決定該團隊負責的關鍵業務指標，這個指標稱為 fitness function，成為該團隊所有實驗的整體評估標準；團隊接著就能自主行動去最大化這個指標。
  4. 低風險的領導練習場。帶一個 2PT，是員工在「失敗不會造成災難性後果」的環境中取得領導經驗的途徑。
• Amazon 策略的關鍵元素，是 2PT 的組織結構與 SOA 的架構取向之間的連結——兩者要一起設計。（L3956–3959）
• Werner Vogels 2005 年對 Baseline 的 Larry Dignan 描述這個結構的好處：小團隊快、不會陷在所謂的 administrivia；每個被指派到某項業務的小組完全對它負責——界定修正範圍、設計、建造、實作、監控後續使用；技術人員與架構師因此能從使用其程式的業務人員身上直接得到回饋。（L3960–3968）

原文：「Amazon used the two-pizza rule to keep team sizes small—a team only as large as can be fed with two pizzas—usually about five to ten people.」（L3934–3935）

原文：「The team’s lead, working with the executive team, decides on the key business metric that the team is responsible for, known as the fitness function, which becomes the overall evaluation criteria for the team’s experiments.」（L3949–3952）

🧪 我實際套用的紀錄

• （待填）

⚠️ 注意 / 什麼時候不適用

• 前提是鬆耦合架構。書中把這條規則放在「建立鬆耦合架構」之後：服務要能獨立在生產環境更新、彼此以及與共享資料庫解耦、只透過 API 互動（bounded contexts）。沒有這個前提就把團隊切小，只會製造更多跨團隊協調。（L3898–3918、L7060–7068）
• 效果 2 是刻意的取捨，不是副作用：你是拿「產品演進速率」換「共享理解」。如果現在最需要的是爆發式擴張單一產品的功能面，要清楚自己在犧牲什麼。
• 沒有 fitness function 的 2PT 只是「小團隊」，不是自治團隊——關鍵業務指標由 lead 與高層共同決定，這一步不能省。

🔗 相關工具

• 康威定律作為設計工具（團隊大小是康威定律的直接推論）
• 演進式架構（讓 2PT 能各自獨立部署所需的架構條件）
• 專責轉型團隊（轉型團隊本身也適用這個規模上限）
• 工具-降低在製品WIP（限制團隊規模與限制 WIP 都是用「上限」換流動）
• DevOps手冊