敏捷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的邮件。