本章以作者 Kenneth Rubin 在 Genomica 公司的親身經歷開場，說明為何選擇 Scrum，並概述 Scrum 的定義、起源、適用情境與效益。
什麼是 Scrum？#
Scrum 是一種用於開發創新產品與服務的敏捷方法（Agile approach）。其運作方式如下：
- 建立 Product Backlog：一份按優先順序排列的需求清單，包含打造成功產品所需的功能與能力
- 永遠先做最重要的事：團隊始終從最高優先級的項目開始工作；當資源（如時間）用盡時，未完成的都是較低優先級的工作
- 以迭代（Iteration）交付：工作在短期、固定時間箱（Timebox）內進行，通常為一週至一個月
- 自組織、跨功能團隊：團隊在每個迭代中完成設計、開發、測試等所有工作，產出可運作的功能
- 迭代審查與回饋：每個迭代結束時向利害關係人展示成果，根據回饋調整後續計畫
Figure 1.1: Agile development overview
關鍵概念： 每個迭代結束時，團隊應產出一個潛在可交付的產品增量（Potentially Shippable Product Increment）。可以選擇在每個迭代後發布，也可以累積多個迭代的功能後一次發布。
Scrum 的起源#
- 1986 年：Takeuchi 與 Nonaka 在《Harvard Business Review》發表〈The New New Product Development Game〉，描述 Honda、Canon、Fuji-Xerox 等公司使用可擴展的團隊式方法進行產品開發，強調賦權的自組織團隊
- Scrum 一詞：源自橄欖球（Rugby）術語，比喻團隊像橄欖球隊一樣「整體前進、互相傳球」，而非像接力賽般逐段交接
- 1993 年：Jeff Sutherland 在 Easel Corporation 結合上述文章的概念與物件導向開發、經驗式流程控制、迭代增量開發等思想，創建了 Scrum 流程
- 1995 年：Ken Schwaber 在 OOPSLA 會議上發表第一篇 Scrum 論文
timeline
title Scrum 發展歷程
1986 : Takeuchi 與 Nonaka 發表論文
: 提出產品開發的整體性方法
1993 : Sutherland 創建 Scrum 流程
: 應用於 Easel Corporation
1995 : Schwaber 發表正式論文
: Scrum 方法論公開推廣雖然 Scrum 最常用於軟體產品開發，但其核心價值與原則也已成功應用於硬體開發、行銷計畫及銷售專案等不同領域。
為什麼選擇 Scrum？——Genomica 案例#
作者以 Genomica 的經驗說明 Scrum 適用的典型情境：
- 複雜領域（Complex Domain）：未知遠多於已知，產品前所未見，需要快速探索與學習
- 快速回饋需求：需要每隔數週向戰略夥伴展示可運作的成果，傳統的詳細前期規劃無法滿足
- 避免大型前期架構設計：過去花了近一年做純架構工作，最終驗證時發現畫面切換一個欄位需要 42 秒——徹底失敗
- 跨功能團隊協作：打破開發完成後才交給測試的傳統模式，目標是每日同步
Genomica 的成果#
| 指標 | Waterfall | Scrum |
|---|---|---|
| 投入人力 | 10x | 1x |
| 速度（Velocity） | 1x | 7x |
| 客戶滿意度 | 差 | 優秀 |
採用 Scrum 後，Genomica 以十分之一的人力投入達成相當的功能產出，開發速度提升至 7 倍，並在合作夥伴的硬體平台發布時程內準時交付。
Scrum 的效益#
Figure 1.2: Scrum benefits
成功導入 Scrum 的組織所體驗到的好處：
| 效益 | 說明 |
|---|---|
| 客戶滿意（Delighted Customers） | 交付客戶真正需要的東西，而非第一天（所知最少時）規格化的功能 |
| 改善投資報酬率（Improved ROI） | 透過更小、更頻繁的發布來提升價值回報 |
| 降低成本（Reduced Costs） | 持續揭露組織失能與浪費，進而消除之 |
| 快速交付成果（Fast Results） | 每個迭代交付可運作、已整合、已測試的業務功能 |
| 應對複雜世界的信心（Confidence in a Complex World） | 快速適應競爭者、客戶、法規等多方行動 |
| 更多工作樂趣（More Joy） | 頻繁而有意義的協作，提升人際關係與互信 |
Scrum 的適用情境——Cynefin 框架#
Cynefin 框架是一種情境感知框架（Sense-making Framework），幫助我們判斷所處環境並選擇合適的方法。它定義了五個領域：
Figure 1.3: Cynefin framework
Complex（複雜）領域#
- 特徵：不可預測多於可預測，正確答案只有事後才知道；屬於湧現（Emergence）領域
- 策略：探索（Probe） → 感知（Sense） → 回應（Respond）
- 需要：創造安全失敗（Safe-fail）的實驗環境、高度互動與溝通
- Scrum 適用性：最佳契合。創新產品開發與創新功能開發屬於此類
Complicated（繁雜）領域#
- 特徵：可能有多個正確答案，但需要專家診斷才能找出
- 策略：感知（Sense） → 分析（Analyze） → 回應（Respond）
- Scrum 適用性：可以使用，但不一定是最佳方案。例如效能調校更適合讓專家評估。日常軟體維護多屬此類
Simple（簡單）領域#
- 特徵：因果關係明確，正確答案顯而易見且無爭議；屬於最佳實踐（Best Practices）領域
- 策略：感知（Sense） → 分類（Categorize） → 回應（Respond）
- Scrum 適用性：可以用但效率不高。重複性工作（如第 100 次部署相同 COTS 產品）更適合定義好的標準流程
Chaotic（混沌）領域#
- 特徵：危機狀態，需要立即行動以防止進一步損害
- 策略：行動（Act） → 感知（Sense） → 回應（Respond）
- Scrum 適用性：不適用。此時不需要整理 Backlog 或規劃迭代，需要有人立即掌控局面、果斷行動
Disorder（失序）領域#
- 特徵：不知道自己處於哪個領域，是最危險的狀態
- 脫離方法：將情境分解為組成部分，分別歸類到其他四個領域中
軟體開發是一項豐富的活動，其各個面向會橫跨多個 Cynefin 領域。雖然大部分軟體開發工作落在 Complicated 或 Complex 領域，但不應一刀切地宣稱「軟體開發就是複雜領域」。
Scrum 與高度中斷驅動的工作#
Scrum 不適合高度中斷驅動（Interrupt-driven）的工作環境，例如客戶支援組織：
- Backlog 內容持續變動（可能每小時甚至每幾分鐘就改變）
- 無法可靠地規劃一週以上的迭代
- 高優先級請求隨時可能打斷既有計畫
替代方案：Kanban——更適合維護與支援工作的敏捷方法。其核心做法：
- 視覺化工作流程（Visualize the workflow）
- 限制在製品數量（Limit WIP）以確保不超過產能
- 度量與優化流程（Measure and optimize flow）以持續改善
在某些組織中，Scrum 與 Kanban 可以並存：Scrum 用於新產品開發，Kanban 用於中斷驅動的支援與維護。
結語#
- Scrum 不是萬靈丹，但它能讓你擁抱複雜產品開發中不可避免的變化
- Scrum 框架簡單但不容易：它不會給你標準答案，而是賦權團隊提出並回答自己的問題
- Scrum 會揭露組織的失能與浪費，這個過程可能令人痛苦，但若能克服最初的不適並解決問題，組織將在流程、產品、員工與客戶滿意度方面獲得顯著進步
Scrum 不會直接給你「食譜式」的解決方案。它讓組織的問題無所遁形——這對許多組織來說是痛苦的第一步，但也是改善的起點。