Sprint Planning 衝刺計劃會議簡介
Sprint Planning （衝刺計劃會議），又叫規劃會議。此會議透過 Scrum 團隊的集體溝通討論，確定接下來的 Sprint 中要完成的待開發項，把它們組成一個 Sprint Backlog。這些待開發項都是從 Product Backlog 中挑選的。
- Product Backlog：產品功能特性列表
- Sprint Backlog：迭代任務列表，可以細化為更小的開發任務 Task
可以規劃一個 Sprint Backlog，也可以規劃多個，根據產品規劃路線圖、產品開發進度、團隊任務量等等多種因素來確定。
Sprint計劃會議目的
- 設定目標：設定 Sprint 迭代的計劃、目標和期望的成果。
- 理解需求：對於待開發的需求，需要團隊成員的理解是一致的。
- 估算工作量：對 Sprint Backlog 中待開發項進行估算，有的待開發項需進一步細化然後估算。最後估算整個 Sprint 的工作量。
- 承諾：團隊對完成 Sprint（衝刺）目標做出承諾，並達成一致。
Sprint計劃會議內容
1、Sprint 目標，確定 Sprint Goal
產品負責人提議如何在這次的 Sprint 中增加產品的價值。然後，與 Scrum 團隊共同討論並制定本次衝刺的目標 - Sprint Goal，最後確定下目標。
2、待辦項選擇，這次 Sprint 迭代要完成哪些待開發項
Scrum 開發團隊和產品負責人一起討論，按優先順序順序從 Product Backlog 中選取待開發項，放入到當前 Sprint 中，組成 Sprint Backlog。
在此過程中，可以對 Sprint Backlog 中的待開發項進一步細化、拆解，分解為更小的開發 Task，這樣容易估算工作量，也容易完成開發任務。
3、任務拆分，估算工作量，制定開發計劃，分配開發任務，領取任務
可以將一些待開發項拆分為更小的開發項。比如把大的 Epic 拆分為 Feature（特性），在把 Feature 拆分為更具體更小的 User Story（使用者故事）。比如把使用者故事拆分為程式設計師的開發任務 Task，便於開發人員開發和估算。
待開發項或 更小的開發 Task，對它們的工作量進行估算，通常以天或小時為單位。
確定每個待開發任務的執行順序、所需資源和依賴關係。
澄清待開發項，確保團隊成員對它的理解是一致的。
團隊成員根據自己的技能和興趣領取工作 Task。
制定開發計劃，可以用甘特圖、燃起圖來跟蹤專案完成情況。
一般一個 Sprint 的迭代開發週期是 1 - 4 周。
4、定義驗收標準
定義驗收標準，確保團隊成員對 “完成” 有共同的理解。
- DoD - Definition of Done ，完成的定義
- Acceptance Criteria，驗收標準
Sprint計劃會議注意事項
- 明確會議議程：在開始會議前，明確會議的議程和目標，並通知所有參與者分享。
- 時間控制：對一個為期 2 周的 Sprint，會議時間通常持續 2 - 4 個小時，以此類推。
- 利益相關者參與：產品負責人、Scrum Master、開發團隊，以及邀請必要的與此次會議有關的人員，也要注意限制參與人數。因為人數越多，一是浪費無關人員時間，二是討論事情複雜增大。
- 透明溝通：要確保所有的溝通都是開發和透明的。
- 避免過度承諾：團隊應該避免選擇過多的開發任務，而無法完成衝刺目標。
- 衝刺計劃靈活性：衝刺計劃靈活性，以適應 Sprint 中需求的變更。
開發項與使用者故事的拆分
大開發項的拆分
對 Sprint 中需求開發項的拆分和細化。
比如從 Product Backlog 中挑選的大的 Epic（史詩），拆分為多個具體的 Feature（特性），特性進一步拆分為更小、更具體的 User Story（使用者故事）。每個使用者故事都是站在使用者角度的最小可交付的工作項。
在把使用者故拆分為開發任務（Task）。
- Epic：史詩，更大更高層次的使用者故事。可以是多個功能集合，對業務產生顯著價值。
- Feature：特性，可以看著是關聯使用者故事的集合，組合提供某種業務價值。
- User Story：使用者故事，站在使用者角度對功能的描述，給使用者帶來什麼價值。
使用者故事拆分
使用者故事拆分方法有哪些呢，下面來看有哪些方法。
1、基於流程步驟拆分
按照使用者完成一個業務流程步驟來拆分使用者故事。梳理出清晰的使用者操作路徑。
比如：常見的 "使用者下單購買商品" 的使用者故事，可以拆分為
- 使用者瀏覽商品列表
- 使用者檢視商品詳情
- 將商品加入購物車
- 購物車商品結算
- 選擇支付方式完成支付
等更小的使用者故事。這裡每一個子故事代表了“下單購買商品”流程中的一個一個關鍵步驟，開發人員就可以根據這些子故事來進行系統功能的開發。
2、基於使用者角色拆分
當一個系統涉及多個角色和系統互動時，可以根據不同的角色來拆分使用者故事。這樣可以明確角色在系統中的功能需求和角色許可權。
比如：比如 ERP 系統的開發，在這個系統中有管理員、銷售人員和倉庫管理人員等不同的角色。對於“庫存管理”這個使用者故事，可以拆分為
- 管理員設定庫存預警闕值
- 銷售人員查詢庫存數量以確定銷售策略
- 倉庫管理人員，根據收貨單更新庫存數量
等這些子使用者故事，開發人員可以根據每個角色的需求進行功能開發。
3、基於功能特性拆分
按照開發的系統提供的功能特性來進行拆分。這種方法有助於聚焦系統具體功能模組。
比如：在社交媒體軟體上“使用者釋出內容”的使用者故事，可以拆分為
- 使用者釋出文字內容
- 使用者釋出圖片內容
- 使用者釋出影片內容
- 編輯已釋出的內容
等子使用者故事，開發人員可以根據每個功能特性來進行開發。
比如“釋出圖片內容”的子故事，支援哪些圖片格式？這就是業務規則。
4、其它一些拆分方法
其它一些方法有哪些：
- 基於規則和約束拆分
- 基於資料邊界
- 基於功能依賴順序
開發任務的拆分
細化研發工程師開發的任務（Task），比如一個需求開發，把它所有的開發任務都列出來：
- 使用者文件、頁面設計、前端、功能的編碼、測試、Bug修復、測試驗收、部署等。
比如需求功能的編碼，有哪些步驟？
有多少個功能需要開發？對應程式中的功能模組有哪些？程式編碼設計？功能模組裡的類有哪些？需要提前設計嗎？等等，程式開發人員都可以進一步細化開發任務（Task）。
如果你使用 CICD Pipeline 整合開發測試交付流水線，那麼需要寫的測試指令碼就有很多。
總之，統統列出來，便於估算開發時長。
說明：不僅有對使用者故事的拆分，拆分為更小功能，還有對開發任務的拆分。