本章描述驅動 Scrum 運作的敏捷原則，並與傳統計畫驅動（plan-driven）的循序開發方式進行對照。作者強調，兩者並無好壞之分，而是適用於不同類型的問題。傳統循序開發適合需求明確且可預測的情境；Scrum 則適合充滿不確定性的產品開發。

原則總覽#

作者將 Scrum 的底層原則歸為六大分類：

mindmap
  root((敏捷原則))
    變異性與不確定性
      擁抱有益的變異性
      採用迭代與增量開發
      透過檢視/調適/透明善用變異性
      同時降低所有形式的不確定性
    預測與調適
      保持選項開放
      接受無法一次到位
      偏好調適性的探索方法
      以經濟合理方式擁抱變更
      平衡預測性與調適性工作
    經過驗證的學習
      快速驗證重要假設
      運用多個並行學習迴圈
      組織工作流以獲取快速回饋
    在製品管理
      使用經濟合理的批次大小
      辨識庫存並管理良好流動
      關注閒置工作而非閒置工人
      考量延遲成本
    進度
      根據即時資訊調適並重新規劃
      透過驗證可運作資產衡量進度
      專注以價值為中心的交付
    績效
      快速但不急躁
      內建品質
      採用最低限度足夠的儀式

變異性與不確定性（Variability and Uncertainty）#

Scrum 善用產品開發中固有的變異性與不確定性來創造創新解法。此類別包含四項原則。

擁抱有益的變異性（Embrace Helpful Variability）#

• 計畫驅動流程將產品開發視同製造業，排斥變異、追求遵循既定流程
• 但產品開發與製造本質不同：製造是重複產出相同成品；開發是創造獨一無二的產品（如同創造食譜，而非照食譜生產）
• 每個功能都不同於其他功能，因此某種程度的變異性是必要的

雖然製造業與產品開發不同，但某些製造概念（如在製品管理）仍適用於產品開發。

採用迭代與增量開發（Employ Iterative and Incremental Development）#

迭代開發（Iterative Development）：

• 承認我們在做對之前可能會先做錯，這是一種有計畫的重工策略（planned rework strategy）
• 透過多次改進來收斂到好的解決方案
• 缺點：在不確定性下，很難事先預估需要多少次改進

增量開發（Incremental Development）：

• 「先做一部分，再做全部」的原則
• 避免在最後才進行大爆炸式（big-bang）的整合與交付
• 將產品拆成較小的部分，逐步建置、學習、調適
• 缺點：逐步建置可能見樹不見林

Scrum 結合兩者：在一系列有時間限制的迭代（Sprint）中同時運用迭代與增量開發，互相彌補對方的不足。

常見誤用： 將每個 Sprint 專注於單一類型的工作（例如 Sprint 1 做分析、Sprint 2 做設計），這是用瀑布式思維套用 Scrum，稱為 WaterScrum 或 Scrummerfall。在 Scrum 中，我們是以功能（feature）為單位工作，而非以階段為單位。

每個 Sprint 結束時會產出一個可運作的產品增量（increment），包含或整合了先前已開發的功能，在完整脈絡下獲取回饋，幫助從全局角度檢視產品。

透過檢視、調適與透明來善用變異性（Leverage Variability through Inspection, Adaptation, and Transparency）#

計畫驅動流程與 Scrum 在三個關鍵維度上有根本差異：

Scrum 的核心是檢視（Inspection）、調適（Adaptation）與透明（Transparency） 三原則，統稱為經驗式流程控制（Empirical Process Control）：

• 不僅檢視與調適「正在建造的東西」，也檢視與調適「建造的方式」
• 透明使檢視成為可能，檢視是調適的前提
• 透明也建立信任（對流程與團隊成員的信任）

同時降低所有形式的不確定性（Reduce All Forms of Uncertainty Simultaneously）#

產品開發的不確定性可分為：

• End uncertainty（目的不確定性）：最終產品功能的不確定性
• Means uncertainty（手段不確定性）：開發流程與技術的不確定性
• Customer uncertainty（客戶不確定性）：誰是真正的客戶（尤其對新創組織而言）

傳統流程先消除所有目的不確定性（完整定義需求），再處理手段不確定性。但在複雜領域中，行動與環境相互制約——展示功能給客戶後，客戶可能改變想法，進而影響設計決策。Scrum 採取更全面的方式，同時處理多種不確定性。

預測與調適（Prediction and Adaptation）#

使用 Scrum 時，我們持續在預測的渴望與調適的需求之間取得平衡。此類別包含五項原則。

保持選項開放（Keep Options Open）#

• 傳統流程要求在各階段做出決策，即使知識有限也必須在進入下一階段前決定
• Scrum 主張不應僅因流程規定就做出過早的決策
• 遵循最後責任時刻（Last Responsible Moment, LRM） 原則：延遲承諾，直到「不做決定的成本」大於「做決定的成本」

開發的第一天是我們知道最少的時候，每一天都會學到更多。為什麼要在最早期、資訊最不完整時做出所有最關鍵且不可逆的決定呢？

接受無法一次到位（Accept That You Can’t Get It Right Up Front）#

• 計畫驅動流程假設我們可以在事前就把需求與計畫全部搞定
• Scrum 承認事前不可能完全正確，嘗試這樣做甚至是危險的
• 在知識最少的時候產出大量需求，會造成大量低品質需求的風險

Scrum 仍會在前期產出部分需求與計畫，但僅到足夠的程度，並假設會隨著學習逐步補充細節。

偏好調適性的探索方法（Favor an Adaptive, Exploratory Approach）#

• 計畫驅動流程專注於利用（exploit） 已知並預測未知
• Scrum 偏好調適性的試錯方法，適當運用探索（exploration）
• 探索：透過建造原型、概念驗證、研究或實驗來獲取知識
• 歷史上軟體探索成本很高（打卡時代），有利於預測方法；但現代工具使探索成本大幅降低

在 Scrum 中，如果有足夠知識就向前推進；面對不確定性時，則用低成本探索來購買相關資訊，再據此做出合理的下一步。

以經濟合理的方式擁抱變更（Embrace Change in an Economically Sensible Way）#

在循序開發中，變更越晚成本越高（分析階段修改成本 $1，測試階段可能要 $1,000），原因是錯誤會在各階段層層複合。

傳統流程試圖透過更精確的預測來避免晚期變更，但這往往適得其反，形成自我應驗的預言：

1. 相信晚期變更非常昂貴
2. 因此在前期投入更多時間避免變更
3. 這導致過早產生大量工作產物（規格書、設計文件）
4. 當變更確實發生時，大量工作產物需要修改或丟棄，確保了高昂的變更成本

Scrum 的目標是盡可能讓變更成本曲線維持平坦。透過即時（just-in-time）方式產出工作產物，避免不必要的產物，使得變更發生時需要修改的東西更少，成本與變更大小保持合理比例。

平衡預測性前期工作與調適性即時工作（Balance Predictive Up-Front Work with Adaptive Just-in-Time Work）#

• Scrum 不是不做前期工作，而是尋找平衡
• 過度預測：在高度不確定下做太多假設
• 過度調適：陷入持續變動的混亂狀態
• 平衡點應以經濟合理的方式設定：最大化基於快速回饋的持續調適，最小化前期預測，同時滿足合規與企業目標
• Scrum 框架運作在秩序與混沌的平衡點上

經過驗證的學習（Validated Learning）#

使用 Scrum 時，我們組織工作以快速產生 validated learning——確認或否定某個假設的知識。此類別包含三項原則。

快速驗證重要假設（Validate Important Assumptions Fast）#

• 假設是被當作事實但尚未經過驗證的猜測或信念
• 計畫驅動開發容忍長期存在的假設；大量前期需求與計畫中嵌入許多重要假設，到很晚的階段才驗證
• 假設代表重大開發風險
• Scrum 盡量減少重要假設的數量，也不讓重要假設長期存在而不加驗證
• 透過迭代增量開發與低成本探索來快速驗證假設

使用 Scrum 時，如果做了根本性的錯誤假設，可能很快就會發現並有機會復原。在計畫驅動開發中，同樣的錯誤假設如果驗證太晚，可能導致開發全面失敗。

運用多個並行學習迴圈（Leverage Multiple Concurrent Learning Loops）#

Scrum 識別並利用回饋迴圈來增加學習。反覆出現的模式是：

Scrum 內建多個學習迴圈（例如 Daily Scrum 是每日迴圈、Sprint Review 是迭代層級迴圈），也能彈性擁抱其他迴圈（如 pair programming 提供秒級回饋、TDD 提供分鐘級回饋）。

組織工作流以獲取快速回饋（Organize Workflow for Fast Feedback）#

• 計畫驅動流程容忍晚學習，快速回饋不是焦點
• Scrum 力求快速回饋，以截斷錯誤路徑、把握時效性機會

以元件整合為例：

• 循序開發中，整合延到下游階段，導致整合變成大規模的測試修復階段（test-and-fix phase）
• 錯誤會複合累積：延遲回饋，基於原始假設的相依決策越來越多，一旦原始假設錯誤，就要面對大量連鎖返工
• Scrum 組織工作流讓回饋生成活動在時間上盡可能接近原始工作，快速關閉學習迴圈

快速回饋的經濟效益非常顯著：它能在錯誤造成嚴重經濟損害前截斷錯誤的開發路徑。

在製品管理（Work in Process, WIP）#

在製品（WIP）是指已開始但尚未完成的工作。此類別包含四項原則。

使用經濟合理的批次大小（Use Economically Sensible Batch Sizes）#

• 傳統開發採用 all-before-any 方法：完成所有某類工作再進入下一階段（批次大小常為 100%）
• 這源自製造業的規模經濟思維，但將其教條式地套用到產品開發會造成嚴重經濟損害

小批次的好處（引用 Reinertsen）：

辨識庫存並管理以維持良好流動（Recognize Inventory and Manage It for Good Flow）#

• 製造業深知庫存的財務影響，積極管理庫存
• 但在產品開發中，庫存是知識資產（磁碟上的程式碼、檔案櫃中的文件），既不像工廠零件那樣實體可見，也不會在財報上被追蹤
• 傳統開發因大批次（通常 100%）而創造大量庫存，顯著影響變更成本曲線
• Scrum 的目標：在「足夠的庫存」與「過多的庫存」之間找到適當平衡
• 需求只是庫存的一種形式，開發過程中有許多地方存在 WIP，都需要主動辨識與管理

關注閒置的工作，而非閒置的工人（Focus on Idle Work, Not Idle Workers）#

• 閒置工作（Idle work）：想做但因阻礙而無法進行的工作
• 閒置工人（Idle workers）：有剩餘產能的人
• 許多組織專注於消除閒置工人的浪費，例如將測試人員指派到多個專案以達 100% 利用率
• 但這在減少一種浪費的同時，增加了更昂貴的閒置工作浪費

接力賽比喻： 你不是靠讓跑者 100% 忙碌來贏得金牌，而是讓接力棒最快到達終點。產品開發中，「看接力棒，不要看跑者」（Watch the baton, not the runners）。

從排隊理論可見：利用率接近 100% 時，等待隊列（delay）呈指數級增長。就像電腦在 100% 利用率時開始 thrashing，每個任務都慢下來；在 80% 左右運行效率更佳。

考量延遲成本（Consider Cost of Delay）#

延遲成本（Cost of delay） 是延遲工作或延遲達成里程碑的財務成本。85% 的組織不會量化延遲成本。

書中舉例說明：

閒置工人成本 $75K 對比閒置工作成本 $500K——如果只專注於優化撰寫者的利用率，會嚴重地次最佳化整體產品經濟。

進度（Progress）#

在 Scrum 中，我們用已交付和驗證的成果來衡量進度，而非根據預定計畫的執行程度。此類別包含三項原則。

根據即時資訊調適並重新規劃（Adapt to Real-Time Information and Replan）#

• 計畫驅動流程中，計畫是權威來源，期望符合計畫
• Scrum 認為盲目相信計畫會使我們忽視計畫可能是錯的
• 目標不是遵從某個前期預測，而是快速重新規劃並調適持續湧入的經濟重要資訊

透過驗證可運作資產來衡量進度（Measure Progress by Validating Working Assets）#

• 循序開發中，完成一個階段並進入下一階段就是進度，但最終產品可能遠低於客戶價值預期
• 如果準時、在預算內完成卻未能滿足客戶期待，算成功嗎？
• Scrum 透過建造可運作的、經過驗證的資產來衡量進度
• 重點不是開始了多少工作，而是完成了多少有客戶價值的工作

專注以價值為中心的交付（Focus on Value-Centric Delivery）#

• 循序開發中功能的整合與交付發生在最後，有「資源耗盡卻尚未交付重要價值」的風險
• 傳統開發認為中間產物（計畫文件、規格書）本身有價值，但這些通常僅對下游流程有價值，非對客戶
• Scrum 是以客戶價值為中心的開發方式：最高價值的功能在下一次迭代中持續建造與交付，客戶更早獲得高價值功能的持續流動

績效（Performance）#

使用 Scrum 時，我們對績效有特定的期待。此類別包含三項原則。

快速但不急躁（Go Fast but Never Hurry）#

• Scrum 的核心目標之一是敏捷、可調適且快速
• 快速交付、快速獲得回饋、更快將價值送到客戶手中
• 但快速不等於匆忙——匆忙會違反 sustainable pace（可持續步調） 原則，也會犧牲品質

泰拳比喻： 表現優異的泰拳需要速度，動作迅捷、敏捷、從容，同時快速適應局勢。但若為求快而匆忙，不僅降低效果，還可能造成傷害。開發也是如此——要快，但絕不急躁。

內建品質（Build In Quality）#

• 計畫驅動開發中，品質要到整合測試階段才能驗證，發現品質不足就進入昂貴的測試修復階段
• 測試團隊常被視為品質的擁有者
• Scrum 中，品質不是最後「測進去」的，而是由跨功能 Scrum 團隊持續內建並在每個 Sprint 驗證
• 每個增量都完成到高信心水準，有潛力可直接上線或出貨

採用最低限度足夠的儀式（Employ Minimally Sufficient Ceremony）#

計畫驅動流程傾向高儀式感（高文件量、高流程量）。Scrum 以價值為中心，將儀式設定在最低限度足夠的水平。

不必要的儀式範例：

• 需要三天重量級流程才能將程式碼從開發環境遷移到 QA 環境
• 所有異常都必須登入追蹤工具，即使拍一下隔壁同事的肩膀就能解決
• 在規定的時間撰寫文件，但沒人能說出為什麼需要該文件

Scrum 不是反文件，而是從經濟角度審視每份文件。值得撰寫文件的情境包括：產品交付物（安裝說明、使用指南）、記錄重要討論或決策、協助新成員快速上手、法規要求。我們要避免的是不帶來任何短期或長期經濟價值的工作。

本章小結#

本章聚焦於驅動 Scrum 運作的核心敏捷原則，並與傳統循序開發的底層信念進行對照。作者的目的不是證明瀑布不好、Scrum 好，而是說明兩者的底層信念使它們各自適用於不同類型的問題。後續章節將詳細描述這些原則如何相互強化，構成一個強大的產品開發方法。