PO 角色
- 負責需求的管理、產品路徑規劃、組織版本驗收。維護好產品代辦列表、梳理需求優先級排序，對需求ROI負責。
“Product Owner（PO）——用戶/客戶/業務的代言人，就是可以做出業務決策的人，所謂業務決策包括需求與優先級。”
- 需求產品端生命週期分爲：原始需求、已確認需求、待評審需求。
- 版本路線規劃
- 採用用戶故事地圖框架，定義
版本、Epic、story - 採用JIRA 進行上述三要素的規劃
- 需求管理：
- 產品經理與業務方的需求採集以及內部規劃的需求。（需要篩選的需求）
- 產品經理內部溝通與確認，並歸入用戶故事地圖的需求。（確定是想做的需求，
product backlog） - PO計劃組織需求評審會與DevTeam進行溝通討論的需求列表；
- MVP 原則：起牀出門的案例
- 採用用戶故事地圖框架，定義
- 版本路線規劃
SM 角色
“Scrum Master——熟悉Scrum流程的人，指導和確保團隊以Scrum的方式進行交付。”
- 指導整個項目組以敏捷和Scrum的方式交付項目，主持各種敏捷會議，比如每日例會、Sprint計劃和評審會議、回顧會議等，幫助各交付團隊掃除障礙
DevTeam 角色
- 負責迭代開發，爲過程負責（需求拆分、工作量評估、需求流轉、系統設計、規範開發、質量內建）。
- 研發人員
- 測試人員
- 版本管理員(負責版本、分支管理）
Sprint 週期節奏
Sprint Planning Meeting
- 時間
- 每個Sprint開始的前一至兩天，不超過兩個小時
- 輸入
- 已排好優先級的PBL
- 目的
- 團隊明確接下來需要工作的內容；梳理需求不清楚的問題；
- 內容
- 用戶故事講解
- 識別僞需求（什麼場景、誰用、使用頻次等）
- 驗收條件：包括快樂路徑與意外場景（DOD，如何定義這個故事開發完成了）
- 拆分用戶故事（如果故事太大）
- 估算用戶故事
- 距離是常量，時間是變量
- 每個故事需要評估出故事點數
- 設計分析（偏技術，PO可退出討論）
- 流程、架構
- 用戶故事講解
- 輸出
- 經過估算排序的Sprint BackLog
看板設計
- 待辦列表：經過sprint planning 會議輸出的用戶故事清單
- 任務流轉：用戶故事需要拆分爲研發Task進行流轉，Task到了提測階段，已用戶故事爲單位進行提測；
- 快速通道：第一行是緊急需求快速通道，給緊急臨時需求留用，每次只允許一個需求通過。
- 看板形式：採用線上和線下看板結合的形式
- 電子看板：電子看板採用JIRA自有的流程，泳道比較粗（待開發、處理中、已完成）
- 物理看板：每天站會進行更新，泳道細分
- 開發：開發中、自測中
- 測試：待提測、測試中
- 發佈：待發布、已發佈
- 團隊內電子看板，整個團隊物理看板
每日站會
- 時間：每天早上九點十分準時開始，以團隊爲單位在會議室中進行；
- 內容：每人輪流發言（昨天做了什麼，今天計劃做什麼，遇到什麼問題），同時移動看板的任務；
- 標準十五分鐘，不超過二十分鐘
sprint 評審會議
- 什麼時候開？
- 測試完成後，由PO發起邀請業務需求方一起參與需求演示；
- 內容
- 本次迭代中，哪些完成了，哪些沒完成，沒完成的原因是什麼？計劃什麼時候完成。
- 需求業務方下一個迭代比較關注的需求，方便PO及時調整下個迭代的product backlog
- 時長不超過1個小時
sprint 回顧會議
- 什麼時候開？
- 部署上線完成後
- 時長不超過1個小時
- 內容
- 充分溝通本次sprint迭代過程中有哪些做得好的，哪些做得不好的，後續如何改進。（PDCA）
- 利用工具：頭腦風暴、5WHY法、魚骨圖分析問題
- 識別最有問題，最需要改進的問題，創建改進計劃;
- 比如：
- 團隊任務太多以至於迭代期間無法完成；
- 團隊深陷現存的技術債； 功能開發未能確保持續性，以避免在代碼庫中引入新的bug；
- 團隊的開發習慣沒有適時調整；
- Product Owner在迭代過程中更改了優先級，而開發團隊則因範圍的變更陷入困境；
注意：團隊在迭代中遇到困難是常有的事。迭代回顧會議時，團隊可以花費點時間探討一下爲什麼迭代過程中會發生變更，並制定計劃在下一個Sprint中解決問題。
跟蹤推進
- 每日站會跟進
- sprint計劃會議-產出看板待辦事項
- sprint評審會議-業務、產品和研發共同參與
- sprint回顧會議-每次迭代完成後PO、SM、DevTeam共同參與
- 指標
- 燃盡圖
- 累計流量圖