發布規劃的目的#
發布規劃（Release Planning）決定了在特定時間內或特定範圍內，團隊要交付哪些功能。它是一個高層級的計畫，用來和利害關係人溝通預期。
規劃步驟#
步驟一：選擇迭代長度#
常見的迭代長度為 1-4 週。選擇時考慮：
- 較短的迭代（1-2 週）：更快的回饋循環，但規劃開銷相對較高
- 較長的迭代（3-4 週）：較少的規劃開銷，但回饋循環較慢
- 如果在兩個長度間猶豫不決，選擇較短的
步驟二：估算速度#
速度（Velocity）是團隊在一個迭代中能完成的 Story Point 總數。初始速度可以透過以下方式估算：
- 歷史數據：如果團隊有過去的經驗，直接採用
- 有根據的猜測：根據團隊人數和可用時間粗估
- 試跑一個迭代：做一次迭代後用實際數據作為基準
步驟三：排定優先順序#
客戶將 Story 依照商業價值和成本排序。常用的分類法：
- Must Have：沒有就不能上線
- Should Have：非常重要，但可以稍後補上
- Could Have：錦上添花
- Won’t Have（this time）：這次不做
步驟四：分配到迭代#
根據速度和優先順序，將 Story 分配到各個迭代中：
- 從最高優先的 Story 開始
- 累加 Story Point，直到達到速度上限
- 重複此過程，直到所有迭代排滿或 Story 用完
發布計畫是一個假設，不是承諾。它會隨著實際速度和需求變化而調整。在每個迭代結束後，都應根據實際進度更新計畫。
不確定性與緩衝#
估算永遠有誤差。處理不確定性的方式：
- 使用速度範圍（如 7-10 點/迭代）而非單一數字
- 為高風險的 Story 預留緩衝
- 定期根據實際速度重新校準計畫
與其試圖讓計畫更精確，不如讓計畫更容易調整。敏捷規劃的核心理念是「計畫永遠在改變」。