當軟體專案規模變大，挑戰不僅是人數增多，更在於專案受到更嚴格的審視、更大的時程壓力、更容易產生人際衝突，且更可能分散在多個地點。Scrum 面對大型專案的第一道防線是使用多個兩個披薩團隊（two-pizza team，約五到九人），而非一個龐大團隊。本章探討如何在大型多團隊專案中成功運用 Scrum，涵蓋擴展 Product Owner 角色、管理大型 Product Backlog、主動管理依賴關係、協調團隊間工作、擴展 Sprint Planning 會議，以及培養實踐社群。

Scaling the Product Owner#

Product Owner 角色在單一團隊時已足夠吃力，需要同時應付內部導向（參與規劃會議、Sprint Review、管理 Product Backlog、回答團隊問題）與外部導向（與用戶溝通、管理利害關係人期望、制定產品策略、分析競爭對手）的任務。在多團隊專案中，這個角色對一個人來說太過沉重，必須找到擴展的方法。

Product Owner 階層架構#

當專案成長為多個團隊時，理想上每個團隊都有一位 Product Owner。若無法做到一對一配置，每位 Product Owner 最多負責兩個團隊。隨著專案規模進一步擴大，可以引入協作式的 Product Owner 階層架構：

• Chief Product Owner：負責整體產品願景與策略定位，會親自參與 daily scrum、走訪團隊區域、提供支持與回饋，但將產品細節委託給下層
• Product Line Owner：負責產品套件中的個別產品（如文書處理器、試算表等）
• Product Owner：直接與一到兩個團隊合作，處理日常優先順序與需求細節

共享責任、劃分功能#

雖然功能沿著產品線劃分，但所有 Product Owner 必須對完整產品保持共同責任感，並將這種感覺傳遞給團隊。Chief Product Owner 可以同時兼任 Product Line Owner，Product Line Owner 也可以兼任其中一個團隊的 Product Owner。

「Chief Product Owner」和「Product Line Owner」只是作者偏好的名稱，實務上也有人使用 Program Owner、Super Product Owner、Area Owner、Feature Owner 等稱呼。在多層架構中，直接與團隊合作的 Product Owner 往往是職稱為「Business Analyst」的人。

Working with a Large Product Backlog#

大型專案團隊通常會使用商業化的敏捷工具來管理 Product Backlog。無論使用何種工具，有兩條重要指導原則：

One Product, One Product Backlog#

一個產品只應有一個 Product Backlog。如果團隊從多個 backlog 工作，就必須在 backlog 之間進行優先順序比較，這會造成混亂。即使多個團隊專注於系統的不同區域，也應維持單一 Product Backlog。

不同團隊可以透過**檢視（view）**來過濾出與自己相關的項目，而某些項目可能同時出現在多個檢視中，表示該功能可能需要多個團隊協作。

將 Product Backlog 維持在合理大小#

根據作者的經驗，當 Product Backlog 超過 100-150 個項目時，事情會迅速惡化。這個數字源自 Dunbar’s Number（鄧巴數）：人類大腦大約只能維持 150 個社會關係，同理，我們也只能在腦中維持約 100-150 個 backlog 項目及其關係。

管理 backlog 大小的兩種方法：

• 善用 Epic 和 Theme：透過撰寫大型故事（epic）並將小故事分組為主題（theme），即使龐大專案也能控制在 150 個項目以內
• 提供 Product Backlog 的檢視：Chief Product Owner 看到的是主題層級的彙整，個別團隊看到的是具體的 user story

Proactively Manage Dependencies#

在多團隊專案中，團隊間的依賴關係是 sprint 失敗的最常見原因之一。良好的團隊結構和持續整合可以大幅減少但無法完全消除依賴。以下是幾種主動管理依賴的技術：

Do Rolling Lookahead Planning#

滾動式前瞻規劃讓團隊在每個 sprint 結束時花幾分鐘，利用歷史平均 velocity 粗略規劃接下來兩個 sprint 的工作內容。這不是詳細的任務分解，通常只需約十分鐘即可完成。

建議前瞻兩個 sprint 的原因：如果只看一個 sprint，當你發現需要另一個團隊的協助時，對方可能已經規劃完畢；前瞻兩個 sprint 則給對方足夠的時間來計劃和準備。

Hold a Release Kickoff Meeting#

在新專案或新 release cycle 開始時，召集所有人舉行 Release Kickoff Meeting，可以降低大型專案中各團隊各行其是的風險。每個團隊的 Product Owner 分享未來約三個月的粗略計劃，讓所有人了解整體方向。

Salesforce.com 更進一步，在同一週舉辦 Release Open Space，採用 Open Space Technology 方式，讓團隊自發地識別並討論與 release 相關的議題。

Share Team Members#

當依賴關係難以預先識別或需要快速解決時，共享團隊成員是有效的做法。讓一位成員同時在兩個團隊兼職工作，橫跨已知或可能的依賴兩端。

Use an Integration Team#

在十個或更多團隊的專案中，有時需要建立專門的整合團隊（Integration Team）。整合團隊處理開發團隊之間的「縫隙」，主要關注兩類介面問題：

• Unidentified interfaces：尚未被任何人發現的介面
• Unattended interfaces：已被發現但無人處理的介面

整合團隊每天早上檢查夜間建置結果，確保系統正確編譯且所有測試通過。他們也會開發自動化測試來驗證整合點。整合團隊的成員需要具備良好的分析能力與廣泛的技術知識，不應被視為低績效者的「流放地」。新進員工短期加入整合團隊則是認識整體系統和建立人際網絡的好方法。

有人反對說「如果專案真的是敏捷的，就不需要整合團隊」。但在真正的大型專案中，整合的「黏合劑」可能非常龐大。整合團隊不是團隊能力不足的標誌，而是大型複雜專案的合理需求。不過，只在必要時才使用整合團隊。

Coordinate Work Among Teams#

當多個小團隊取代一個大團隊時，如何協調各團隊的工作成為關鍵問題。在多團隊專案中，「整個團隊」不只是一個兩個披薩團隊及其 Product Owner 和 ScrumMaster，而是所有團隊、所有 Product Owner 和所有 ScrumMaster 的總和。

The Scrum of Scrums Meeting#

Scrum of Scrums 是協調多團隊工作的普遍做法。每個團隊指派一位代表（通常是技術貢獻者而非 ScrumMaster 或 Product Owner）參加跨團隊會議。代表的選擇不是終身職，應該根據專案階段選擇最能理解和評論當前議題的人。

Scrum of Scrums 可以遞迴式擴展：如果產品由多個團隊群組建構，每個群組的 Scrum of Scrums 再派一位代表參加更高層級的會議。

頻率：與 daily scrum 不同，Scrum of Scrums 有三個重要差異：

• 不需要每天召開（每週二到三次通常足夠）
• 不需要限制在 15 分鐘（建議預留 30-60 分鐘）
• 它是問題解決會議，不是同步會議

議程：每位與會者回答三個問題：

1. 自上次會議以來，我的團隊做了什麼可能影響其他團隊的事？
2. 在下次會議之前，我的團隊將做什麼可能影響其他團隊的事？
3. 我的團隊遇到什麼問題需要其他團隊的幫助？

討論時應避免提及個人姓名，以保持在適當的抽象層級，並避免人們將發言時間等同於重要性。

回答完三個問題後，與會者針對提出的問題和 issues backlog 上的既有問題進行討論和解決。Scrum of Scrums 群組不進行正式的 sprint planning 或 sprint review。

Synchronize Sprints#

作者早期嘗試將不同團隊的 sprint 開始日期錯開一週，結果發現是個糟糕的主意：

重疊 sprint 的最大缺陷是：除了專案結束時，永遠沒有所有團隊都完成的時間點，很難將完整系統交給客戶回饋或部署。

同步化 sprint 不代表所有團隊的 sprint 長度必須相同。透過巢狀式 sprint（nested sprints），不同團隊可以使用不同的 sprint 長度，只要起止時間在一兩天內同步即可。Sprint 結束時間允許在兩三天的區間內，也能方便身兼多個團隊的成員參加所有的 review 和 planning 會議。

Scaling the Sprint Planning Meeting#

當多團隊參與時，Sprint Planning Meeting 受到的影響最大。常見問題包括：

• 某些人需要同時出現在多個規劃會議中
• 團隊發現對其他團隊的依賴時，對方可能還沒完成規劃
• 多個團隊從同一 Product Backlog 取工作項目時，需要預先分配

Stagger by a Day#

將規劃會議錯開一天：例如三分之一的團隊在週二規劃、三分之一在週三、三分之一在週四。這解決了共用 Product Backlog 和需要共享資源（Product Owner、架構師等）的問題，但代價是這些共享資源需要連續參加多天的規劃會議。此方法適用於最多九個團隊的專案。

The Big Room#

在大房間方式中，所有團隊集合在一個大房間。Chief Product Owner 先分享總體資訊，然後各團隊（包括各自的 Product Owner 和 ScrumMaster）分散到房間的不同角落各自規劃。當團隊發現跨團隊依賴時，可以直接跑到對方的區域協調。

共享資源（Product Owner、架構師等）可以在房間中自由移動。為了讓共享資源知道誰需要幫助，有些團隊使用航海信號旗作為信號裝置：

大房間方式要成功運作，Product Owner 必須事先做好準備。Chief Product Owner 需要與其團隊在會前舉行一系列短會議，確保每一層的 Product Owner 都理解產品願景。

Cultivate Communities of Practice#

在多團隊專案中，個人容易被孤立在自己的團隊中。好的想法傳播緩慢，類似功能被不同團隊以不同方式實作。實踐社群（Community of Practice）是一群志同道合或擁有相似技能的人，因為對某項技術、方法或願景的熱情和承諾而自發聚集。

實踐社群可以圍繞專案角色（程式設計師社群、測試社群、UI 社群、ScrumMaster 社群）、技術（Ruby 社群、.NET 社群）或共同興趣（mock objects、AI、測試自動化）形成。它們可以跨越多個專案，甚至包含來自完全不相關專案的成員。

一個好的範例是 Salesforce.com 的 Virtual Architecture Team (VAT)：由每個 Scrum 團隊的開發人員組成的「虛擬」團隊，每週兩次用兩小時審查各團隊正在建構的技術實作，關注可擴展性和效能等議題。

Formal or Informal#

實踐社群可以是正式或非正式的。Etienne Wenger 等人根據組織的認可程度區分五種類型：

這五種類型不代表階層關係，也不代表社群的生命週期。每種類型各有優缺點，許多社群可能朝反方向移動或完全解散。

創造讓社群形成與茁壯的環境#

最有效的實踐社群是自然形成而非管理層指令成立的。Wenger 等人提出七項支持社群演化的原則：

• Design for evolution：承認社群會隨時間變化
• Open a dialogue between inside and outside participants：社群不能閉門造車
• Invite different levels of participation：鼓勵不同程度的參與
• Have both public and private events：兼有公開和私密的活動
• Focus on value：越能提供價值，越能獲得支持
• Combine familiarity with excitement：在例行活動中偶爾加入新鮮元素（如邀請外部講者、舉辦 open space 活動）
• Create a rhythm for the community：建立適合社群的固定節奏，不一定要跟隨 sprint 週期

Participation#

大多數正式認可的實踐社群會指定一位 community coordinator，其角色類似 ScrumMaster，負責安排會議和活動、聯繫成員、發展社群的實踐。擔任 coordinator 通常每月需要 5-20 小時，在被組織正式賦予責任的社群中甚至可能是全職工作。

管理層必須讓團隊成員知道，跨團隊的非正式社群不僅被允許，而且是受到鼓勵的。作者遇到過一些團隊，被給予高度自組織的自由，卻以為跨團隊的非正式群組會被管理層反對，因此從未形成實踐社群。

Scrum Does Scale#

早期敏捷作者都非常謹慎地表示 Scrum 只適用於小型專案，這不是因為不適合大型專案，而是因為他們當時尚未在大型專案上實踐過。多年來的經驗證明，敏捷開發的原則和實踐可以被擴展並應用於大型專案，儘管需要相當程度的額外開銷。

只要大型組織善用本章描述的技術 – 擴展 Product Owner 角色、使用共享的 Product Backlog、注意依賴關係管理、協調團隊間工作、培養實踐社群 – 就能成功地擴展 Scrum 專案。