Scrum 團隊的結構與彼此之間的關係，對組織成功運用 Scrum 有重大影響。本章討論不同的團隊結構方式，包括功能團隊與組件團隊的區別，以及多團隊協調的方法。

概述#

如果只有一個小產品，只需建立一個跨功能開發團隊，妥善配置 ScrumMaster 和產品負責人即可。但隨著組織成長或 Scrum 使用擴展，就需要協調多個 Scrum 團隊的工作。

核心問題：如何結構化團隊，使其高效運作且協調良好？

功能團隊 vs. 組件團隊（Feature Teams vs. Component Teams）#

基本定義#

  • 功能團隊（Feature Team）：跨功能、跨組件的團隊，能從產品待辦清單中拉取端到端的客戶功能並完成
  • 組件團隊（Component Team）：專注於開發特定組件或子系統，只能完成客戶功能的一部分

組件團隊有時也稱為 asset team 或 subsystem team。由具有相似專業技能的人組成的實踐社群（community of practice）也常運作得像組件團隊，例如集中式的 UX 部門。

組件團隊的運作方式#

Figure 12.1: One product and multiple component teams

當產品功能跨越多個組件區域時：

  1. 從產品待辦清單頂端選取功能
  2. 將功能拆分為各組件層級的片段
  3. 各片段放入對應的組件團隊待辦清單
  4. 各組件團隊針對自己的組件待辦清單執行 Scrum
  5. 透過 Scrum of Scrums 等技術，將各組件層級的結果整合回完整功能

組件團隊的擴展問題#

Figure 12.2: Two products and multiple component teams

當多個產品共用相同的組件團隊時，問題迅速惡化：

  • 組件團隊的產品負責人需要在多個產品的競爭性需求間排列優先順序
  • 同時還需與其他組件團隊協調，確保各片段在適當時機整合
  • 當組織同時有 10-15 個產品時，排序與協調的物流變得不可管理

使用組件團隊會乘法性地增加功能無法完成的機率，因為現在有多個失敗點（每個組件團隊）而非單一個（一個功能團隊）。常見的狀況是：「除了一個組件團隊之外都完成了，所以功能還沒好。那個團隊說他們有 15 個其他競爭性需求，可能下個 Sprint 才能完成。」

混合模型：功能團隊 + 組件團隊#

Figure 12.3: Combined feature team and component teams

一種過渡方案是同時擁有功能團隊和組件團隊：

  • 功能團隊從產品待辦清單拉取端到端功能，完全負責完成工作
  • 組件團隊繼續維護各組件區域的完整性，其待辦清單通常包含技術性工作（如技術債償還）
  • 組件團隊成員可被指派為功能團隊的成員，扮演雙重角色：
    • 授粉者（Pollinator）：將組件區域的知識帶入功能團隊，促進共享程式碼擁有權
    • 收割者（Harvester）：收集功能團隊對組件區域的變更需求，與組件團隊同事討論，確保變更協調一致

實務建議#

  • 大多數成功的大型 Scrum 組織傾向於以功能團隊為主、偶爾搭配組件團隊的混合模型
  • 功能可能橫跨 50 個系統，但很少需要所有 50 個組件直接互動——可以圍繞高互動性的較小組件叢集建立多個功能團隊
  • 若組件區域只有少數人卻要支援大量產品，解決方案包括：減少同時進行的產品數量、培訓/聘僱更多專業人員、促進共享程式碼擁有權

功能團隊 vs. 組件團隊沒有放諸四海皆準的解決方案。但許多偏好「大量組件團隊、少量功能團隊」的組織，會因頻繁中斷的流動而付出高昂代價。

多團隊協調（Multiple-Team Coordination）#

Scrum 的擴展不是透過增大開發團隊，而是透過擁有多個適當規模的 Scrum 團隊。當團隊超過一個時，就需要協調機制。

Scrum of Scrums（SoS）#

Figure 12.4: Scrum of scrums

Scrum of Scrums 是協調多團隊工作的常見做法：

  • 由各開發團隊的代表組成，根據誰最能代表跨團隊依賴議題來決定出席人選
  • 不一定每天召開，通常一週幾次視需要而定
  • 參與者回答三個問題：
    1. 自上次會議以來，我的團隊做了什麼可能影響其他團隊的事？
    2. 在下次會議之前，我的團隊將做什麼可能影響其他團隊的事？
    3. 我的團隊遇到什麼問題，需要其他團隊協助解決？

有些團隊將 SoS 限定在 15 分鐘內（如同單一團隊的 Daily Scrum），將問題解決延後到會後。另一種做法是延長 SoS，前 15 分鐘回答三個問題，之後繼續進行問題解決。

SoS 理論上可以擴展到多個層級——功能區域內使用傳統 SoS，再加上更高層級的 Scrum of Scrum of Scrums（程式層級的 Scrum）來協調各功能區域之間的工作。

Release Train#

Figure 12.5: Release train structure

Release Train 是一種透過共同節奏來對齊多團隊願景、規劃與相互依賴的方法。

核心規則（Leffingwell, 2011）：

  • 日期固定、品質固定、範圍可變——定期的規劃與發布日期
  • 所有團隊採用相同的 Sprint 長度，Sprint 起止日期對齊
  • 建立中間的全域目標里程碑
  • 在系統層級、功能層級與組件層級實施持續整合
  • 每隔固定 Sprint 數（通常 60-120 天）產出 PSI（Potentially Shippable Increment）
  • 可使用系統強化 Sprint（hardening iteration）來減少技術債並進行系統層級的驗證測試
  • 特定基礎設施組件（介面、SDK、共用安裝工具、UX 框架、資料與 Web 服務等）通常需要超前追蹤

運作方式：

  1. 團隊叢集化：團隊分群到功能區域（feature areas），每個功能區域的團隊從對應的功能區域待辦清單拉取工作
  2. Sprint 同步：所有團隊的 Sprint 起止日期相同，實現跨功能區域的同步
  3. Release 規劃會議：
    • 可能有數百人同時參與的聯合規劃活動
    • 首席產品負責人（Chief Product Owner）主持，提供 PSI 的整體藍圖
    • 各功能區域的產品負責人提供區域概述
    • 各 Scrum 團隊進行 Sprint Mapping，將功能分配到特定 Sprint
    • 團隊成員可隨時走到其他團隊討論跨團隊依賴
  4. PSI 發布點：每固定數個 Sprint 後產出發布增量，組織可選擇部署給客戶或用於內部審查
  5. 檢視與調適：在 PSI 發布點進行 Release Train 層級的 PSI Review 與 Retrospective
flowchart TD
    A["團隊叢集化<br/>分群到功能區域"] --> B["Sprint 同步對齊<br/>統一起止日期"]
    B --> C["Release 規劃會議<br/>聯合規劃與 Sprint Mapping"]
    C --> D["多個 Sprint 開發<br/>跨團隊協調與持續整合"]
    D --> E["PSI 發布點<br/>產出可交付增量"]
    E --> F["檢視與調適<br/>PSI Review 與 Retrospective"]
    F --> C

隨著團隊技能成熟，對強化 Sprint 的需求應該會逐漸減少。

Backward Development Team Managers Forward