Overview#

在 Scrum 專案中，我們在多個層次的細節和多個時間點進行規劃。本章提供各種 Scrum 規劃活動的高層次、由上而下的描述，以及它們之間的關聯。

使用 Scrum 開發產品時，規劃在以下層次上進行：

• 策略（Strategy）——最高層級，雖然對組織的成功至關重要，但超出本書範圍
• 組合（Portfolio）——管理產品組合
• 產品（Product）——願景和產品演進
• 發布（Release）——增量交付的範圍、日期和預算權衡
• 衝刺（Sprint）——下一個 Sprint 的功能
• 每日（Daily）——透過每日站會進行的最細節規劃

Scrum 正式定義的只有 Sprint 規劃和每日規劃（透過每日站會 daily scrum）。然而，大多數組織也會從組合、產品和發布規劃中受益。

各層次規劃摘要#

為說明各層次的規劃，本章使用 Scrum Alliance 網站的重新設計作為範例。2006 年，Scrum Alliance 擁有一個糟糕的網站——不好看、難以導航、內容貧乏。作者擔任此工作的產品負責人（Product Owner），負責描述所執行的層級式規劃。

Portfolio Planning#

組合規劃（或組合管理）是一種活動，用於決定要處理哪些產品、以什麼順序、以及持續多長時間。雖然組合規劃在概念上高於產品規劃（因為它處理的是產品集合），但產品規劃的輸出——新構思的產品想法——是組合規劃的主要輸入之一。

「高層次」並不意味著組合規劃一定先於產品規劃。事實上，新產品的構思（envisioning）輸出是組合規劃的重要輸入。組合規劃決定是否資助該產品以及如何將其排入組合待辦清單。

在 Scrum Alliance 的範例中：2006 年 Scrum Alliance 的組合只包含現有網站的持續開發。一旦新網站的初始構思完成，董事會（組合待辦清單的利害關係人）批准了新網站第一個版本的開發。

Product Planning (Envisioning)#

產品層級規劃（也稱為構思 envisioning）的目標是捕捉潛在產品的本質，並為該產品建立一個粗略的計畫。構思包含三個主要階段：

Vision（產品願景）#

產品願景提供對利害關係人（如使用者和客戶）獲得價值之領域的清楚描述。

Scrum Alliance 網站的願景：

For people worldwide who are interested in Scrum, the new Scrum Alliance website will be their trusted source of Scrum knowledge. It will be feature and content rich and will be their first stop on the Internet for learning more about Scrum or to collaborate on Scrum topics of interest.

High-Level Product Backlog（高層級產品待辦清單）#

建立產品願景後，下一步是產生產品待辦清單的初始高層級版本。在 Scrum Alliance 的案例中，到 2006 年底已經有了一份不斷增長的利害關係人和使用者想要的功能待辦清單。

產品待辦項目包括以下 epic 層級的 User Story：

• 「身為認證 Scrum 培訓師，我希望能在 Scrum Alliance 網站上發布我的公開 Scrum 課程，以便社群知道我開課的地點和時間。」
• 「身為潛在學生，我希望能查看所有公開可用的 Scrum 課程的詳細資訊，以便找到符合我出席標準的課程。」

如果產品是全新的，需要做一些最小量的前期需求產生來填充產品待辦清單，並至少估算最高優先級的項目。

Product Roadmap（產品路線圖）#

建立產品願景和高層級產品待辦清單後，建構產品路線圖（有時稱為發布路線圖）是很有幫助的。產品路線圖傳達產品將如何隨時間增量地建構和交付，以及驅動每次發布的重要因素。

如果組織專注於持續部署（continuous deployment）——功能一完成就部署到生產環境——可能不需要產品路線圖。但即使打算持續部署，路線圖仍可作為思考較大功能集合、約束條件以及功能可用時間的有用工具。

Scrum Alliance 路線圖中的兩個發布：

• Release 0.5（Q1 2007）——新網站的第一個版本，功能少於舊網站的一半，但包含更好的新功能。核心功能：全球公開 Scrum 課程列表和基本的 CST 支持。這是一個固定範圍的發布（fixed-scope release）——我們知道需要哪些特定功能，但不知道需要多久。
• Release 1.0（Q2 2007）——固定日期的發布（fixed-date release），需要在 2007 年 5 月 7 日 Scrum Gathering 會議首日前準備好一組令人興奮的功能。我們不知道能在該版本中加入多少功能。

到產品層級規劃結束時，你應該有：

• 產品願景
• 高層級產品待辦清單（含已估算的 User Story）
• （可選）產品路線圖
• 其他為決策者提供足夠信心的產出物

產品層級規劃的輸出成為組合規劃的輸入。在 Scrum Alliance 的範例中，重新設計的網站初始 0.5 版本由董事會批准開發。

flowchart LR
    A[產品願景] --> B[高層級\nProduct Backlog]
    B --> C[產品路線圖]
    C --> D[Release Planning]
    D --> E[Sprint Planning]

    C -.->|回饋| A

Release Planning#

發布規劃是關於在範圍（scope）、日期（date） 和預算（budget） 之間做出增量交付的權衡取捨。

在大多數開發工作中，於構思（產品規劃）之後、開始第一個 Sprint 之前進行初始發布規劃是合理且必要的。此時可以建立一份初始的發布計畫，平衡能開發多少與何時可用。

視覺化發布#

一個簡單的方式來視覺化發布，是在產品待辦清單中畫一條線：線上方的所有項目是為該發布規劃的，線下方的則不是。隨著對產品的了解加深，這條線可以在待辦清單中上下移動。

路線圖與待辦清單的連結#

產品路線圖上的發布可以輕鬆地對應到產品待辦清單中的一組功能，將路線圖與待辦清單連結起來。路線圖上的一個發布對應到待辦清單中的一組功能。

發布的時間維度#

發布計畫也必須有時間維度，可以用完成發布所需的 Sprint 數來表示。大多數發布規模較大，包含的功能超過一個 Sprint 能建構的量。

在發布規劃期間，你可能會嘗試猜測前幾個 Sprint 會交付哪些功能。當多個團隊需要協調工作，或團隊需要提前申請額外的硬體、工具或協助時，這會很有幫助。但猜測超過兩三個 Sprint 幾乎總是不必要的，且違反了即時且適量規劃的原則。

Sprint Planning#

Scrum 團隊在下一個 Sprint 中將處理的特定產品待辦項目，是在 Sprint 規劃時達成共識的，這發生在每個 Sprint 的開始。在此活動中，團隊產生 Sprint 待辦清單（sprint backlog）：完成產品待辦項目所需的任務層級工作描述。

Sprint 規劃是團隊進行下一層次的即時詳細規劃。詳細的 Sprint 規劃將在第十九章討論。

Daily Planning#

最詳細的規劃層級發生在團隊的每日站會（daily scrum） 期間。這是團隊成員聚在一起，每個人輪流說明以下內容的活動：

• 自上次每日站會以來完成了什麼
• 今天計畫做什麼
• 是否有任何阻礙（impediments）

在每日站會中，團隊成員集體以高度可見的方式描述當天的全局計畫。這也讓團隊能運用資源提醒（resource alerts）。例如：

「今天我要處理預儲程序的任務，午餐前應該能完成。接下來要處理商業邏輯任務的人，請記住那個任務在我們這個 Sprint 完成工作的關鍵路徑上，午餐後就應該準備好開始處理它。」

這樣的溝通能快速識別潛在的工作阻礙，並促進 Sprint 執行期間更好的工作流程。

Closing#

本章說明了在使用 Scrum 的開發工作中，規劃如何在多個層次的細節上進行。下圖以圖形方式總結了這些層次（除了組合和每日規劃層次）產生的產出物及其相互關聯的性質。

整體規劃層次的產出物串聯關係：

1. 產品願景 引導建立 產品待辦清單 和 產品路線圖
2. 路線圖上的發布對應到待辦清單中的功能集合
3. 每個發布包含一個或多個 Sprint
4. 每個 Sprint 有自己的 Sprint 待辦清單，將產品待辦項目分解為任務

接下來的幾章將更深入地探討組合規劃、產品規劃、發布規劃和 Sprint 規劃的主題。