Overview#

一個常見的迷思是：使用 Scrum 開發不需要規劃，我們只要開始第一個 Sprint 然後邊飛邊修就好。這並非事實。在 Scrum 中，我們確實進行真正的規劃，而且是在多個細節層次和多個時間點上進行。只是大部分的規劃以即時（just in time） 方式發生，而非大量的前期規劃。事實上，團隊在 Scrum 中花在規劃上的時間往往比傳統開發更多，只是感覺不太一樣。

本章擴展了第三章描述的幾個 Scrum 原則，專注於它們如何應用於規劃。這為第十五章討論 Scrum 規劃的多層次架構奠定了基礎。

Scrum 規劃原則包括：

Don’t Assume We Can Get the Plans Right Up Front#

傳統的預測式（predictive）規劃方法是在開發工作開始前建立詳細計畫。目標是把計畫做對，讓後續工作能按部就班進行。有人認為沒有這份計畫，我們就不知道方向，也無法協調人員和活動，尤其是在多團隊的大型開發工作中。這個論點有一定道理。

然而，Scrum 的規劃方式忠於其經驗主義（empirical） 的根基——檢視與調適（inspection and adaptation）。使用 Scrum 開發時：

• 我們不相信能在前期就做對，因此不會試圖預先產出所有規劃產出物
• 我們確實會在早期產出一些規劃產出物
• 目標是在前期規劃與即時規劃之間取得良好平衡

Up-Front Planning Should Be Helpful without Being Excessive#

前期規劃應該有幫助但不應過度。作者以一個極限滑雪者 John 的故事來說明這個原則。

當 John 站在山頂準備開始滑降時，他不會規劃整條路線。他的做法是：

1. 選擇山下某個距離的點作為第一個目標
2. 只規劃前兩到三個轉彎
3. 到達該點後再根據實際情況繼續規劃

為什麼不做更多規劃？因為：

• 地形不是它看起來的樣子——光線和其他因素會產生錯覺
• 看不見的障礙物——從山頂看不到下方的樹木
• 不可預測的事件——例如突然出現的滑雪板少年

這個類比完美地描述了產品開發的現實：你永遠無法準確預測何時需要改變方向，或為什麼需要改變。試圖做過多的前期規劃是浪費的；相信這樣的計畫是正確的，到了忽視即時資料的程度，更是危險的。

我們不應該完全不做前期規劃——那是疏忽且愚蠢的。John 確實做了一些前期規劃：他研究地形的主要特徵以建立信心。同樣愚蠢的是，規劃到難以或成本高昂地回應現實的程度。我們必須像 John 一樣，在前期預測與即時調適之間找到適當的平衡。

Keep Planning Options Open Until the Last Responsible Moment#

為了在前期規劃和即時規劃之間取得良好平衡，我們遵循一個原則：將重要選項保持開放，直到最後負責時刻（last responsible moment）。

這意味著：

• 將最適合即時執行的規劃保留到更好的時機——那時我們會有更充足的資訊
• 不要基於不充分的資訊做出過早的規劃決策——這不僅代價高昂，而且可能很危險
• 延遲決策不是拖延——而是等待資訊更充分時再做出更好的決策

Focus More on Adapting and Replanning Than on Conforming to a Plan#

許多產品開發工作的問題在於過分強調前期計畫，而忽略了持續規劃。如果我們花大量時間建立高度預測性的計畫並相信做對了，就會產生巨大的慣性去遵循計畫而非更新它以回應變化。

在 1980 年代，作者曾參與開發大型計畫或諮詢擁有這類計畫的公司。那種計畫會產生巨大的甘特圖（Gantt chart），需要跨多頁列印、拼接在一起、掛在牆上。在某些開發工作中，花了多達六週來開發高度預測性的前期計畫。一旦產生這些計畫，它們就成為專案的地圖，被「假設正確直到被證明錯誤」。

一句常被歸因於瑞士軍隊的智慧：「在森林中迷路時，如果地圖與地形不一致，在所有情況下都要相信地形。」（When lost in the woods, if the map doesn’t agree with the terrain, in all cases believe the terrain.）

當我們對地圖的信念超過了對地形的信任：

• 進度被衡量為對計畫的遵循程度或偏離程度
• 當計畫偏差發生時，我們對計畫遵循的渴望使我們忽視了地圖本身可能是錯的
• 如果地圖變得比地形更重要，我們就與必須導航的現實脫節了

在 Scrum 中，我們的做法不同：

• 將前期計畫視為有幫助的，但相信閱讀地形並據此調適才是必要的
• 認識到任何前期計畫都是在我們對產品了解最少的時候拼湊出來的，因此它們準確地編碼了我們早期的無知
• 偏好頻繁地重新規劃，在驗證假設的過程中持續產生更好、更有用的計畫
• 不擔心計畫是錯的，因為我們知道很快就會用更準確的計畫取代它們
• 因為我們在幾週到不超過一個月的短 Sprint 中工作，即使錯了，也不會在錯誤的方向上走太久

大多數 Scrum 團隊不使用甘特圖，但他們確實做規劃，也確實重視某種形式的長期規劃。關鍵是不要過度執著於計畫，以至於不願在情況變化或學到重要資訊時重新規劃。

Correctly Manage the Planning Inventory#

在確定前期規劃與即時規劃之間的適當平衡時，一個關鍵洞察是：建立大量預測性的、尚未經驗證的規劃產出物庫存（planning inventory），可能是非常浪費的。正確管理我們的規劃產出物庫存是經濟上合理的做法。

以前面的大型前期甘特圖為例。隨著開發工作展開，我們透過獲取知識來驗證假設，會發現原始計畫哪裡錯了。不幸的是，到那時我們已經背負了必須解開和重做那些被新知識推翻的未來計畫的浪費。

這產生了至少三種形式的浪費：

1. 白費的精力——產生那些現在必須丟棄的計畫部分所花的力氣
2. 更新計畫的浪費——更新計畫可能需要大量的額外工作
3. 錯失的機會成本——沒有將時間投入在更有價值的活動上（如交付高價值的可運行軟體）

以甘特圖中的例子來說，可能有一個 George 的名字被放在 18 個月後才開始的任務旁邊。George 在 18 個月後真的會執行那個特定任務的機率有多大？幾乎是零！ 既然這麼遠的未來計畫有這麼高的出錯機率，為什麼要規劃那麼遠？

通常我們做長遠規劃是為了回答「我們何時能完成？」或「這個開發工作需要多少人？」這類問題。這些是需要解決的合理問題，但我們不能欺騙自己，以為我們有正確的答案——僅僅因為我們做了長期、低確定性的猜測。

Favor Smaller and More Frequent Releases#

Scrum 偏好較小、較頻繁的發布，因為它們能提供更快的回饋並改善產品的投資報酬率（ROI）。透過利用增量式開發和較小可行銷子集（marketable subsets）的多次發布，我們幾乎總能改善產品的生命週期利潤。

單次發布的經濟學#

單次發布產品的經濟模型：

• 開發開始時，我們在花錢（進入投資期）但沒有任何回報
• 產品發布發生在投資期曲線的下降段
• 最終達到自籌資金（self-funding）——產品收入等於開發成本
• 收入超過成本後，進入回收期（payback period）
• 當總收入等於總成本時，達到損益平衡（breakeven）
• 此後才開始真正獲利

多次發布的經濟學#

如果我們發布兩次而非一次，我們能更早達到自籌資金、損益平衡和獲利的時間點，從而改善產品的整體 ROI。

ROI 模型的具體數據#

假設以下條件：

不同發布週期的 ROI 比較：

限制條件#

• 任何產品都有最小可發布或可行銷的功能集（minimum releasable/marketable set），初始發布不能無限縮小
• 在某些市場中，較小且較頻繁的發布可能不可行
• 但如果你的市場願意提前接收部分價值，較小且較頻繁的可行銷發布就是一個非常重要的原則

Plan to Learn Fast and Pivot When Necessary#

沒有任何前期預測或猜測能取代實際去做、快速學習、然後在必要時轉向（pivot）。

轉向（Pivot） 的定義是：在保持紮根於已學到的知識的基礎上改變方向。Ries 將轉向定義為「一種結構化的路線修正，旨在測試關於產品、策略和成長引擎的新基本假設」。

就像滑雪者 John 一樣，我們需要準備好在學到當前計畫不再有效時快速轉向。

核心做法：

• 我們的目標是快速且經濟地通過學習迴圈（learning loop）
• 應該以學習為關鍵目標來建構計畫
• 透過快速回饋來確定計畫是否朝著可行的方向前進
• 如果不是，就轉向或重新定位自己

規劃的最終目標不是產生一份完美的計畫，而是創造一個能夠快速學習和調適的框架。計畫本身是會改變的——真正重要的是從規劃過程中獲得的理解和對話。

flowchart TD
    A[快速執行計畫] --> B[收集回饋與學習]
    B --> C{計畫仍然可行?}
    C -->|是| D[堅持方向\n繼續執行]
    C -->|否| E{有替代方向?}
    E -->|是| F["轉向（Pivot）\n重新定位"]
    E -->|否| G[終止專案]
    D --> A
    F --> A

Closing#

這些 Scrum 規劃原則讓我們能以經濟上合理的方式進行規劃：做適量的前期規劃，並以更詳細的即時規劃作為平衡，隨著我們對正在建造的東西和如何建造它了解更多而持續調整。接下來的五章將在 Scrum 多層次規劃的脈絡中，以更深的層次和實際範例來運用這些原則。