本章提供 Scrum 框架的全貌概覽，聚焦於其實踐（practices），包括角色、活動與產出物。後續章節將深入探討每個實踐背後的原則。

概覽#

Scrum 不是一套標準化流程，不會保證按時、按預算產出令客戶滿意的高品質產品。Scrum 是一個用來組織與管理工作的框架（framework），基於一組價值觀、原則與實踐，團隊在此基礎上加入自己的工程實踐與具體做法，形成獨一無二的 Scrum 版本。

建築比喻： 把 Scrum 框架想像成建築的地基與牆壁。價值觀、原則、實踐是關鍵結構元件，不能忽略或根本性地改變，否則有崩塌風險。但你可以在結構內部自由裝修，直到建立出適合自己的流程。

Scrum 是一個以人為本的簡潔框架，核心價值觀包括：誠實、開放、勇氣、尊重、專注、信任、賦權、協作。

Scrum 的實踐體現在三大面向：

  • 角色（Roles）：Product Owner、ScrumMaster、Development Team
  • 活動（Activities）：Sprint、Sprint Planning、Daily Scrum、Sprint Execution、Sprint Review、Sprint Retrospective、Product Backlog Grooming
  • 產出物（Artifacts）：Product Backlog、Sprint Backlog、Potentially Shippable Product Increment
  • 規則（Rules）：貫穿全書描述

Figure 2.1: Scrum practices

Scrum 角色#

每個 Scrum 開發工作由一個或多個 Scrum 團隊（Scrum Team）組成，每個團隊包含三個角色：

Figure 2.2: Scrum roles

Product Owner（產品負責人）#

  • 是產品領導的賦權中心點（empowered central point of product leadership）
  • 唯一權責決定要建造哪些功能（features）以及其優先順序
  • 維護並傳達清晰的產品願景（vision）給所有參與者
  • 對整個解決方案的成功負最終責任
  • 必須積極與 ScrumMaster 及開發團隊協作，並在問題提出後迅速回應

ScrumMaster#

  • 幫助所有人理解並擁抱 Scrum 的價值觀、原則與實踐
  • 擔任教練（coach）角色，提供流程領導力
  • 幫助團隊與組織發展出高效能的、組織特定的 Scrum 方法
  • 協助組織度過 Scrum 導入時的變革管理挑戰
  • 身為促進者（facilitator），協助團隊解決問題並移除障礙（impediments）
  • 沒有權力控制團隊——是領導者（leader），不是管理者（manager）

Development Team（開發團隊）#

  • 由多元、跨職能的人員組成（架構師、程式設計師、測試員、DBA、UI 設計師等）
  • 負責設計、建造與測試產品
  • 自組織（self-organize）以決定最佳工作方式
  • 典型規模為 5 至 9 人
  • 大型開發工作應拆分為多個 Scrum 團隊，而非組建一個超大團隊

管理者去哪了？ 「Manager」並未出現在 Scrum 角色中，但管理者在 Scrum 組織中仍扮演重要角色（詳見 Chapter 13）。Scrum 框架只定義 Scrum 特有的角色，並非定義組織中所有角色。

Scrum 活動與產出物#

下圖呈現 Scrum 活動與產出物如何組合運作：

Figure 2.3: Scrum framework

整體流程摘要：

  1. Product Owner 有一個產品願景（大方塊）
  2. 透過 Grooming 活動將願景拆解為功能，收集到排序後的 Product Backlog
  3. Sprint 以 Sprint Planning 開始，經過 Sprint Execution，以 Review 和 Retrospective 結束
  4. 開發團隊在每個 Sprint 開始時決定能完成的 Product Backlog 子集
  5. 完成後產出 Potentially Shippable Product Increment
  6. 透過 Sprint Review 與 Sprint Retrospective 進行檢視與調適（inspect and adapt）
  7. 循環重複，直到產品願景實現

Product Backlog（產品待辦清單）#

Product Backlog 是一份排序後的工作清單，確保團隊永遠優先處理最有價值的工作。

Figure 2.4: Product backlog

  • 新產品開發：Product Backlog 項目（PBI）主要是實現願景所需的功能
  • 持續產品開發：可能包含新功能、既有功能變更、缺陷修復、技術改善等
  • Product Owner 與內外部利害關係人合作，蒐集並定義 PBI
  • 依據價值、成本、知識、風險等因素排序
  • Product Backlog 是持續演進的產出物——項目可隨時新增、刪除、修訂

Product Backlog Grooming（梳理）#

整體而言，創建與精煉 PBI、估算、排序的活動統稱為 Grooming：

Figure 2.5: Product backlog grooming

  • 創建與精煉（Creating and refining）
  • 估算（Estimating）
  • 排序（Prioritizing）

Prioritized vs. Ordered： 2011 年 Scrum Guide 將 Product Backlog 的排列從「prioritized」改為「ordered」，引發爭論。理論上排序受多種因素影響，但實務上多數人（包括本書作者）將兩個詞交替使用。

估算大小#

排序前需要知道每個 PBI 的大小（size），因為大小等同於成本，Product Owner 需要知道成本才能正確排序。

Figure 2.6: Product backlog item sizes

  • Scrum 不強制使用哪種度量方式
  • 實務上多數團隊使用相對大小度量（relative size measure），例如 Story Points 或 Ideal Days
  • 相對大小表達的是項目之間的比較關係，而非絕對值（例如：Feature E 是 8 點，Feature C 是 2 點，代表 E 大約是 C 的四倍）

Sprint#

Sprint 是 Scrum 中的工作迭代週期，最長一個月。

Figure 2.7: Sprint characteristics

  • Sprint 是 Timebox（固定時間盒）：有固定的開始與結束日期
  • 所有 Sprint 通常應為相同長度
  • 新 Sprint 在前一個 Sprint 完成後立即開始
  • 原則上 Sprint 期間不允許改變範圍或人員的目標性變更（但商業需求有時使此規則難以完全遵守）
  • 每個 Sprint 完成的工作應為客戶或使用者創造有形價值

Sprint Planning（Sprint 規劃）#

Sprint Planning 是每個 Sprint 的第一個活動，決定 Sprint 要完成的工作子集。

Figure 2.8: Sprint planning

關鍵步驟：

  1. Product Owner 與開發團隊就 Sprint Goal（Sprint 目標）達成共識
  2. 開發團隊檢視 Product Backlog，判斷在可持續步調（sustainable pace）下能實際完成的高優先項目
  3. 將每個目標功能拆分為一組任務（tasks），形成 Sprint Backlog
  4. 為每個任務提供工時估算（通常以小時計）

Figure 2.9: Sprint backlog

時間建議：

  • 2 週至 1 個月的 Sprint：約 4 至 8 小時
  • 1 週的 Sprint：不超過 2 小時

常用方法： 選取一個 PBI（盡可能是最重要的） -> 拆分為任務 -> 判斷是否能放入 Sprint -> 若有容量則重複循環。

Forecast vs. Commitment： 2011 年 Scrum Guide 引發了 Sprint Planning 結果應稱為「forecast」還是「commitment」的爭論。本書作者傾向使用 commitment，原因是承諾支持 Product Owner 與開發團隊之間的互信、支持合理的短期規劃與決策，以及在多團隊開發中支持同步規劃。

Sprint Execution（Sprint 執行）#

Sprint Execution 佔據 Sprint 中大部分的時間，開發團隊在 ScrumMaster 的教練指導下，執行所有任務層級的工作以完成功能。

Figure 2.10: Sprint execution

  • 沒有人告訴開發團隊以什麼順序或如何執行 Sprint Backlog 中的任務
  • 團隊成員自行定義任務層級的工作，並以最佳方式自組織以達成 Sprint Goal

Daily Scrum（每日站會）#

每天在固定時間進行，限時 15 分鐘以內的檢視與調適活動（也稱為 daily stand-up）。

Figure 2.11: Daily scrum

常見做法——每位成員回答三個問題：

  1. 自上次 Daily Scrum 以來我完成了什麼？
  2. 到下次 Daily Scrum 前我計畫做什麼？
  3. 有哪些障礙阻礙了我的進展？

Daily Scrum 的本質：

  • 是檢視、同步、每日調適規劃活動
  • 不是問題解決會議——問題在 Daily Scrum 後由少數相關人員討論
  • 不是傳統的狀態報告會議

Pigs vs. Chickens： Scrum 曾用「豬」和「雞」來區分參與者與旁觀者（來自火腿蛋早餐的笑話：雞只是「involved」，豬才是「committed」）。作者認為 Scrum Team 所有成員都是「豬」，其他人是「雞」。Daily Scrum 只有「豬」發言，「雞」僅旁觀。此用語現已不太流行。

Done（完成的定義）#

Sprint 的成果稱為 Potentially Shippable Product Increment（潛在可交付的產品增量）。

Figure 2.12: Sprint results (potentially shippable product increment)

  • Definition of Done（完成定義）指定了工作品質的信心程度
  • 軟體開發的最低標準：功能的完整切片（slice）已完成設計、建造、整合、測試、文件化
  • 積極的完成定義讓企業能在每個 Sprint 後決定是否交付

「Potentially Shippable」不代表必須出貨。 出貨是商業決策，受到功能是否足夠、客戶是否能承受再次變更等因素影響。「Potentially Shippable」更準確地說是一種信心狀態——Sprint 完成的工作確實「完成」了，沒有重要的未完成工作（如關鍵測試或整合）阻礙出貨。

Sprint Review（Sprint 審查）#

Sprint Review 是 Sprint 結束時的第一個檢視與調適活動，目的是檢視與調適正在建造的產品。

Figure 2.13: Sprint review

  • 參與者包括 Scrum Team、利害關係人、贊助者、客戶、其他團隊成員
  • 核心是圍繞剛完成功能的對話，在整體開發脈絡中審視成果
  • 產生雙向資訊流：
    • 非團隊成員了解開發進展並協助引導方向
    • 團隊成員透過頻繁回饋更深入理解產品的商業與市場面向
  • Sprint Review 是一個有排程的檢視與調適產品的機會

Sprint Retrospective（Sprint 回顧）#

Sprint Retrospective 是 Sprint 的最後一個活動，通常在 Sprint Review 之後、下一個 Sprint Planning 之前。

Figure 2.14: Sprint retrospective

  • Sprint Review 檢視與調適產品，Sprint Retrospective 檢視與調適流程
  • 開發團隊、ScrumMaster、Product Owner 一起討論 Scrum 及相關技術實踐中哪些有效、哪些無效
  • 聚焦於持續流程改善（continuous process improvement），幫助好團隊變得更卓越
  • 結束時團隊應識別並承諾在下一個 Sprint 中執行實際可行的流程改善行動

Sprint 循環： Retrospective 結束後，整個循環再次重複——從下一個 Sprint Planning 開始，選定當前最高價值的工作集，團隊持續聚焦交付。

本章小結#

本章描述了 Scrum 的核心實踐，提供了 Scrum 框架中角色、活動與產出物的端到端描述。除了這些核心實踐外，許多 Scrum 團隊還會使用更高層級的規劃與進度追蹤實踐，後續章節將進一步介紹。下一章將深入描述 Scrum 所依據的核心原則。

Backward Introduction Agile Principles Forward