本章詳細描述源自 Extreme Programming 的規劃遊戲（Planning Game），這套規劃方式在 SCRUM、Crystal、FDD 等敏捷方法中也有類似的做法，但 XP 將其闡述得最為詳盡與嚴謹。

初始探索（Initial Exploration）#

專案開始時，開發者與客戶透過對話來發掘系統的重要功能：

• 不需要一次辨識出所有功能——隨著專案推進，客戶會持續發現新需求
• 每個功能被拆分為一或多個 User Stories，寫在索引卡上
• 卡片上只需記錄故事名稱（如 Login、Add User），不需要捕捉細節
• 開發者共同估算每個故事的相對成本，以「點數」（story points）表示

技巧： 估算使用的是相對值而非絕對值。我們不確定一個 story point 代表多少時間，但知道 8 點的故事大約是 4 點故事的兩倍工作量。

Spiking、拆分與速度#

故事的拆分與合併#

• 太大或太小的故事都難以準確估算——開發者傾向低估大故事、高估小故事
• 過大的故事應拆分成較小的故事，過小的故事應合併
• 拆分或合併後必須重新估算，不能簡單加減原有的點數

速度（Velocity）#

• 每週完成的 Story Points 總和稱為 velocity
• 經過 3-4 週後，團隊的平均速度會趨於穩定，成為預測未來進度的可靠指標
• 專案初期的速度估計可以用「科學猜測」（SWAG, Scientific Wild-Assed Guess）

發布規劃（Release Planning）#

有了速度之後，客戶可以根據每個故事的成本、商業價值和優先順序做出選擇：

• 開發者與客戶協議首次發布的日期，通常是未來 2-4 個月
• 客戶選擇想在該發布中實作的故事與大致順序
• 客戶不能選擇超過當前速度所能承載的故事數量
• 發布計畫可以隨著速度更加精確而逐步調整

重點： 選擇故事不僅是優先順序的問題——一個重要但昂貴的故事可能被延後，以便先實作一個不那麼重要但便宜得多的故事。這些是商業決策。

迭代規劃（Iteration Planning）#

• 開發者與客戶選擇迭代長度，通常是 1-2 週
• 客戶選擇要在該迭代實作的故事，不得超過速度預算
• 故事的實作順序是技術決策，由開發者決定
• 迭代開始後，客戶不可變更該迭代的故事
• 迭代結束時計算實際完成的 Story Points，作為下一次迭代的速度

定義「完成」（Defining “Done”）#

一個故事只有在所有驗收測試都通過時才算完成：

• 驗收測試由客戶、業務分析師、QA 和測試人員在迭代初期撰寫
• 這些測試定義了故事的細節，是判斷功能是否完成的最終權威

任務規劃（Task Planning）#

每個迭代開始時，開發者將故事拆解為開發任務：

• 一個任務是一位開發者可以在 4-16 小時內完成的工作
• 開發者逐一認領任務，以任意的 task points 估算每個任務
• 每位開發者的任務預算基於上一次迭代的個人實際完成量
• 開發者可以認領任何類型的任務，不受專長限制——促進知識擴散

迭代中點檢查#

• 迭代過半時召開會議，檢查是否已完成一半的故事（非任務）
• 目標是完成故事，而非完成任務——避免「90% 的任務完成但 0 個故事完成」的噩夢
• 若進度落後，團隊重新分配任務；仍無法追上則通知客戶調整

迭代執行（Iterating）#

• 每兩週，當前迭代結束、下一個迭代開始
• 每次迭代結束時向客戶展示目前的可執行系統
• 客戶評估系統的外觀、感受和效能，以新的 User Stories 形式提供回饋

追蹤（Tracking）#

管理 XP 專案的核心是記錄每次迭代的結果，並以此預測未來。兩個關鍵圖表：

速度圖表（Velocity Chart）#

• 顯示每週完成的 Story Points 數量
• 雖然每週有些波動，但能清楚看出團隊的穩定產出速度

燃盡圖（Burn-down Chart）#

• 顯示距離下一個重要里程碑或發布還剩多少 Story Points
• 圖表的斜率可以合理預測完成日期

補充： 燃盡圖中的柱狀差異可能不等於速度圖中的柱狀高度，因為專案中可能新增了故事，或開發者重新估算了既有故事。

規劃遊戲全貌#

flowchart LR
    A[初始探索<br/>撰寫 User Stories] --> B[發布規劃<br/>選擇故事與日期]
    B --> C[迭代規劃<br/>選擇本輪故事]
    C --> D[任務規劃<br/>拆解與認領任務]
    D --> E[迭代執行<br/>開發與測試]
    E --> F[追蹤<br/>計算速度與燃盡]
    F -->|下一個迭代| C
    F -->|下一個發布| B

本章小結#

透過迭代到迭代、發布到發布的節奏，專案會進入一個可預測且舒適的韻律。所有人都知道該期待什麼。利害關係人看到的是實際可觸摸的軟體而非充滿圖表的文件。開發者基於自己的實際速度制定合理計畫。管理者每次迭代都收到可靠的管理數據，不需要靠威脅或訴諸忠誠來達成不切實際的日期。