上篇我帶你從理解產品 Backlog 最好的形式 Story 開始，經過建模、蒐集、編寫、估算這四個步驟，編寫出有效並且粒度合適的 Story 來幫助團隊成員在理解需求上達成一致，讓“一張卡片”發揮出它的洪荒之力，快速挖掘需求，理解需求。
本篇我會帶着你用編寫好的 Story 來制定發佈計劃、迭代計劃，並且在過程中進行有效測試和監控。
發佈計劃
當 Scrum 團隊按照 Sprint 的方式進行迭代交付的時候，他們更加關注的是發佈，而不是項目。那麼什麼是一個發佈呢？ 簡單的說，它就是一個開發團隊交付一個可以工作的軟件給團隊外部的人使用，以滿足他們的某個目的。當你交付一些內容給下游的QA驗證團隊來做測試時不是一個發佈，當你把你的軟件功能和其他團隊開發的功能進行集成的時候不是一個發佈。當你告訴其他人：“來吧，你現在可以使用它了”，這叫做一個發佈。 一個發佈是多個Sprint 集中交付工作的一個成果，這常常是對市場、業務和客戶產生影響的標誌性的時刻。
確定優先級
大部分軟件項目以每 2 到 6 個月作爲一個發佈週期，一般以產品開發線路圖開始規劃發佈。它可以是未來幾個發佈要關注的重點，可以是之前我在產品 Backlog 裏講到的“主題”，也可以是必須包含的功能，那如何排列出優先級呢？
這裏推薦莫斯科規則（ MoSCoW ) 排列優先級的方法：
必須有（Must ) ：指系統的基本功能
應該有 ( Should ) ：很重要但短期內有替代解決方法的功能
可以有 ( Could ) ：如果沒有時間可以不予考慮
這次不會有 ( Won’t have this time ) ：客戶期望擁有但同時承認需要在後續發佈中實現
這裏需要考慮面對高風險故事和有價值的故事如何權衡。我之前講過風險驅動開發可以讓我們儘早的消除風險帶來的不確定性，但是敏捷宣揚先做最有價值的部分，這樣可以使項目儘早發佈，提供最有價值的功能，所以在高風險和有價值之間，優先選擇價值最高的需求並且充分考慮到它的風險因素。選擇迭代長度
團隊所有成員一起選擇一個適合的 Sprint 長度，一般建議1～4周，避免期間確定的 Sprint 時間隨意更改。
- 從 Story 到工期
這裏要說一個概念 — 團隊速率，指團隊一個 Sprint 能完成的工作量。前1～2次 Sprint 先進行觀察，粗略計算出不受干擾的環境下團隊平均能完成的 Story 數量。如 PO 已經計算排好所有 Story 的優先級，並且累計卡片數量 100個。如果經過幾次 Sprint 觀察，團隊速率是25，那計劃經過4輪 Sprint 可以發佈。
這裏需要注意三點：
- 速率不是人天，是經過估算的 Story 規模（上篇估算 Story 有具體講解），比如一個 Story 估算了1個故事點，實際花了2天完成，本次 Sprint 預估完成3個這樣的故事點，那團隊速率是3，而不是6。
- 速率是團隊內部衡量工作量的標準，不與其他團隊做比較，因爲每個團隊對於估點的單位、規模是不一致的。
- 速率是實際完成的 Story ，不是列在迭代計劃裏未完成或者完成一半的點數。比如本次 Sprint 預計完成3個故事點，實際前兩個故事點全部完成，最後一個故事點只完成了一半，那團隊實際速率是2.5，而不是3。
- 創立發佈計劃
最後一步將 Story 按照優先級分別分配到每個 Sprint 中，這裏建議將發佈計劃釘在牆上這樣可視化的方式讓團隊成員每天能看見。
注意，不要迷信發佈計劃！如果在迭代的過程中獲得任何新的信息，應該不斷調整期望和計劃。
迭代計劃
迭代計劃是發佈計劃的進一步計劃，但只在 Sprint 開始是纔開始做迭代計劃。 Sprint 是以功能爲緯度，而發佈計劃是以時間爲緯度。這裏要引入一個敏捷裏的重要實踐 - Spint 會議，整個團隊通過舉行 Spint 會議來爲下一輪 Sprint 做計劃，會議的內容包括：
討論故事
會議的輸入是已經排好優先級的 Story 集合，團隊成員可以根據自己的想法對優先級進行討論。流程是 PO 根據優先級順序將 Story 依次將給開發人員，開發人員可以進行提問，直到全員統一理解，並且可以從中分解出任務爲止。從 Story 分解任務
很多人會問我，爲什麼要做任務分解，把 Story 繼續細分成更小的故事不就好了麼？在我看來，分解任務其實是敏捷即時設計（just in time design)中的一次短脈衝,它取代了 Waterfall 模式前期的設計階段。它不是用戶價值的功能描述，是作爲開發人員的待辦事項。這裏需要注意一點，任務卡片的模式可以不參照 Story 卡片的格式，只要能表示出完成 Story 的最快途徑就好。開發人員承擔每個任務的職責
開發人員可以在分解任務之後對任務進行認領，理想的任務卡片標準是一個任務卡片對應一個責任人一個人天，責任人最好是寫在卡片旁邊，即使是結對編程，每個卡片也需要有一個責任人。討論過所有故事，開發人員單獨估計承諾他們的任務
每個開發人員對認領的任務進行估算，如果 Sprint 時間內估算超過了開發人員所能承擔的工作量，有以下幾種選擇：請求團隊成員接受一些任務；與 PO 討論，放棄其中一個 Story （或者是分解後的一部分）
小結
本篇我們將項目分成一系列 Sprint 來做發佈計劃，每輪 Sprint 中安排一定的 Story 和任務。一輪迭代完成的故事點就是團隊的速率。下篇我帶着大家詳細瞭解怎麼根據不同速率的可視化管理工具，測量並監控速率。
