敏捷Scrum指南二：Scrum流程之RetroSpect

RetroSpect的方向

• US：
  • Sprint US是否存在delayed或Cancelled？
  • BurnDownChat走勢是否符合預期？
  • US實際工作量是否與評估Point一致？
    • US拆分是否符合最小MVP、垂直切分原則？
    • US的排期執行過程中是否被調整？
    • US的優先級安排是否遵循"小功能高價值"、輕重緩急。
    • 是否有緊急US的加入？
• 版本：
  • 版本計劃是否合理。
    • 每個版本的計劃必須在plan時被確定。
    • 每個版本上線的US必須完整可用。
  • 發版頻次是否過高或高低。
    • 若是頻次過低，是否需要提升？
    • 若是頻次過高，是否給團隊帶來了壓力？若是有壓力，是哪些方面的壓力？
    • 若是頻次過低，如何提升發版頻次？
  • code版本管理是否合理。
    • 是否可以從容應對緊急上線？
    • 版本功能是否存在遺漏？
    • 不同服務之間是否存在強依賴？
    • 上線版本內容是否與預期一致？
  • 上線流程是否合理。
    • 是否安裝約定時間封板？
    • 上線流程是否存在優化的地方？
    • 版本發佈時間是否存在風險？
    • 版本發佈先後順序是否存在風險？
    • 需要上線的DB、Redis、Server是否存在遺漏？
    • 發版過程是否順利？發版時間是否可以縮短？發版流程是否可以工具化？
    • 封板後迴歸測試是否快速全面？
  • 版本是否被delayed 或 Cancelled。
• 生產環境：
  • 是否有線上故障？線上故障頻次是否過高？
  • 線上經常出現的是什麼問題？
  • 處理線上問題是否佔用了團隊大量時間？是否需要專人處理線上問題？
  • 是否存在大量線上客訴？線上客訴是否給團隊帶來壓力？
  • 線上是否經常出現BUG？經常出現同一類型BUG？是否存在BUG集羣？
  • 緊急上線的頻次是否過高？
• 敏捷：
  • 現有的Sprint流程是否合理？
  • planning是否需要優化？
  • 站會是否高效？
  • 團隊成員是否熟悉敏捷？是否願意瞭解敏捷？是否需要給成員科普敏捷？
  • 會議是否過多？會議時間是否合適？
  • 團隊敏捷成熟度是否有提升？
• 產品：
  • 產品交互是否合理？
  • 產品是否符合產品經理的期望？
  • 產品運營數據是否符合預期？
  • 產品發展是否與目標一致？
  • 產品是否需要重新調整架構？
  • 產品視覺是否需要變更？
• 技術：
  • 研發技術是否需要升級？現有的技術是否足以支撐業務發展？
• 職能：
  • 各個職能是否可以各司其職？
  • 跨職能的能力是否進一步提升？
  • 職能內分工是否合理
  • PO
    • 需求是否完整？是否可以精準描述需求？
    • 是否上線前積極驗收產品？
    • 是否與組內成員積極溝通？
    • 需求是否經常變更？
  • 前端
  • 後端
  • QA
  • UED
• 成員：
  • 人員是否變更？變更是否帶來了好的或不好的影響？
  • 成員是否存在成長困惑？成長計劃是否執行？
  • 成員的情緒是否健康樂觀穩定？
  • 成員工作態度是否健康積極？
  • 成員是否有人存在很大的進步或退步？
• 彙報：
  • 週報郵件是否定時發送？週報內容格式是否需要優化？
  • 月報是否需要優化?
  • show case是否需要優化？
• 溝通:
  • 團隊內部溝通是否順暢？
  • 跨組溝通是否順暢？
  • 與合作方的溝通是否順暢？
• 合作：
  • 團隊內部溝通是否可以良性合作？
  • 跨組溝通是否可以良性合作？
  • 與合作方的溝通是否可以良性合作？

RetroSpect的流程

1. 回顧本Sprint已完成的任務。
2. 查看本Sprint的BurnDownChart。
3. 查看本Sprint的線上運維記錄。
4. 團隊成員思考5分鐘後，提交覆盤內容。
5. 團隊選出一名成員進行Presentation。
6. 覆盤內容由提交人詳細講解。
7. Presentation人員負責對大家的覆盤內容整理歸納成Good、Better。
8. Presentation人員組織大家討論解決方案，根據討論內容整理成Action。
9. SM發送Retrospect的郵件。