本章探討 Scrum 團隊的最佳結構方式：團隊規模應維持在「兩個披薩就能餵飽」的大小、優先採用 Feature Team 而非 Component Team、自組織不等於隨機組隊、以及避免讓成員同時參與多個專案。

用兩個披薩餵飽他們 (Feed Them Two Pizzas)#

Amazon 創辦人 Jeff Bezos 提出著名的「兩個披薩規則」（Two-Pizza Rule）：如果一個團隊需要超過兩個披薩才能餵飽，那這個團隊就太大了。在 Scrum 中，理想的團隊規模是 5 到 9 人。

小團隊的優勢#

Lawrence Putnam 對超過 490 個專案的研究顯示：

• 每人平均生產力隨團隊規模增大而下降（尤其超過 9 人後急遽惡化）
• 較小的團隊以較少的總開發努力完成同規模的專案
• 5 到 7 人的團隊在最短時間內完成等量工作

Communications of the ACM 上的研究也證實：大團隊（29 人）產生的缺陷是小團隊（3 人）的六倍，花費更多金錢，卻只比小團隊快約 12 天完成同樣的產出。

當團隊超過 9 人時，應考慮拆分為兩個團隊。Scrum 透過「團隊的團隊」（teams of teams）來擴展規模，而非組建一個巨大的團隊。

優先採用 Feature Team (Favor Feature Teams)#

Component Team 的問題#

在傳統企業專案中，團隊經常按照架構層級來組織（例如 rich client 團隊、web client 團隊、middle-tier 團隊、資料庫團隊）。這種 Component Team 會導致：

• 跨層溝通減少
• 產生「介面契約設計就夠了」的錯覺
• Sprint 結束時無法交付可出貨的產品增量

Feature Team 的優勢#

Feature Team 負責端到端交付可運作的（已測試的）功能，跨越架構的所有層級。其優點包括：

• 更能評估設計決策的影響：團隊在 Sprint 結束時建構了端到端功能，最大化了對產品設計與技術決策的學習
• 減少交接造成的浪費：工作在群組或個人間傳遞是浪費的，Component Team 有過多或過少功能被開發的風險
• 確保正確的人在對話：Feature Team 包含從構想到可運行功能所需的全部技能，確保這些技能持有者每天溝通
• Component Team 為排程增加風險：其工作只有在被 Feature Team 整合後才有價值，整合工作難以估算
• 保持對交付功能的聚焦：圍繞功能交付來組織團隊，是 Scrum 聚焦每個 Sprint 交付功能的持續提醒

謹慎使用 Component Team#

雖然應強烈傾向 Feature Team，但在以下情況可考慮組建 Component Team：

• 將建構被多個 Feature Team 使用的東西（如共用元件）
• 能減少專家在團隊間的分散共享
• 多種方法的風險超過 Component Team 的劣勢（避免不同團隊對同一問題採取不一致的解決方案）
• 能讓原本不會交流的人對話
• 能預見 Component Team 的結束時間（不應無限期存在）

Component Team 應只在 Feature Team 需要時才建構元件，而非提前猜測需求。將 Feature Team 的成員暫時派駐到 Component Team，有助於確保產出的可用性。

誰來做這些決定？#

理想上由團隊自己決定結構。但因團隊成員通常缺乏組織團隊的經驗，初期可能需要由功能經理、專案經理或 ScrumMaster 做決定，同時徵求團隊成員的非約束性意見。

今天正確的明天可能是錯的：沒有永恆的團隊結構。如果目前的結構阻礙了團隊使用 Scrum 的能力，應在 Sprint 回顧中提出並加以改變。

自組織不等於隨機組裝 (Self-Organizing Doesn’t Mean Randomly Assembled)#

Agile Manifesto 宣示：「最好的架構、需求和設計來自自組織團隊。」但常見的誤解是自組織意味著不需要領導角色。

自組織不代表把八個隨機挑選的人放在一起就期望產出好結果。負責啟動 Scrum 專案的人應花費大量精力選擇團隊成員。

Takeuchi 和 Nonaka 在描述 Scrum 的原始論文中，將「微妙控制」（subtle control）列為六大原則之一，並將人員配置決策列為關鍵管理職責。

挑選合適的人加入團隊#

選擇團隊成員時應考慮以下因素：

• 涵蓋所有需要的領域：作為跨職能團隊，從構想到完成功能所需的全部技能都應被代表
• 平衡技術技能層級：避免全是資深或全是資淺的程式設計師
• 平衡領域知識：在領域專家與新手之間取得平衡，促進知識在組織中擴散
• 追求多樣性：思考方式、決策風格、所需資訊量等方面的多樣性，比同質團隊更能全面考量所有選項
• 考慮持續性：團隊成員需要時間學習合作，盡量保留過去合作良好的成員組合

讓人專注於一個專案 (Put People on One Project)#

被分配到多個專案的個人，生產力會不可避免地下降。多工（multitasking）是專案團隊績效最大的消耗之一。

任務越多，在工作上的時間越少#

Kim Clark 和 Steven Wheelwright 的研究顯示：

• 同時處理 兩項任務時，在工作上的總時間會增加
• 但超過兩項後，時間急遽下降
• 同時處理 三項任務時，花在工作上的時間甚至比只做一項時還少

多工如此有害的主因是 任務切換成本（task-switching cost）。研究發現軟體開發團隊成員平均每 11 分鐘就被中斷一次。

多工何時可以接受#

• 對大多數團隊成員而言，多工應盡量避免
• 如果一個人無法在單一專案上充分利用時間，多工可能是合理的
• 與其讓所有人都稍微多工，不如讓少數人大量多工，讓其他人專注於單一專案

企業層級的多工#

組織同時進行太多並行專案是企業層級的多工。Harvard Business Review 一項為期八年的研究結論：「如果組織一次承擔較少的專案，專案會更快完成。」

停止多工的策略包括：

• 在能完整配置人員之前，不要啟動新專案
• 在企業計畫中納入啟動和收尾時間
• 建立簡單規則：例如「沒有人可以被分配到超過兩個專案」，60% 似乎是一個神奇的數字，代表「這是最重要的事」
• 循序漸進：先從下一季計畫中移除一個專案，觀察效果

良好團隊結構的指導方針 (Guidelines for Good Team Structure)#

本節提出九個問題形式的指導方針，用於迭代式地評估和調整團隊結構：

1. 結構是否發揮成員優勢、補強弱點、支持動機？ 找到一個能讓最多團隊成員發揮所長的結構
2. 結構是否最小化需要同時在兩個團隊的人數（且避免任何人在三個團隊）？ 如果超過 10-20% 的成員隸屬多個團隊，應考慮替代設計
3. 結構是否最大化團隊維持在一起的時間？ 團隊成員需要時間學習合作，盡量讓團隊結構能超越單一專案
4. Component Team 是否僅在有限且易於合理化的情況下使用？ 大多數團隊應圍繞端到端功能交付來建立
5. 大多數團隊是否能用兩個披薩餵飽？ 團隊應以 5 到 9 人為主
6. 結構是否最小化團隊間的溝通路徑？ 避免一個團隊完成任何工作都需要先與太多其他團隊協調
7. 結構是否鼓勵原本不會溝通的團隊進行交流？ 有效的團隊設計促進應該溝通的團隊或個人之間的交流
8. 設計是否支持清晰的問責理解？ 既有對整體專案成功的共同問責，也有各團隊獨特的問責指標
9. 團隊成員是否參與了團隊設計？ 隨著成員經驗增長，他們應更多參與團隊結構決策