迭代复盘经验总结

01 复盘内容

今天组织了一场迭代复盘会，我们的迭代复盘会两个迭代组织一次，所以类似于月度复盘会。从以下3个方面展开：

1.迭代整体情况

• 目的：从整体上了解团队的研发效能情况，及时发现研发过程问题

• 效能指标数据：分别为任务延期率、任务创建规范率

  
  image.png
  image.png

2.持续改进案例分析

• 目的：复盘的核心目标是实现团队的持续改进，关键案例是我们持续改进的基础
• 案例：通用能力调用问题
  • 案例背景：项目初始阶段白名单业务相关代码实现在应用层，随着业务的发展，白名单能力演化为一个多业务调用的通用能力，需要将此部分代码抽象为领域层能力，但是在实际研发过程中，团队并没有意识到需要抽象通用能力，会引起维护成本、及质量保障成本增加。
  • 改进意见：随着业务发展，涉及到通用模块的接口需要在技术方案阶段体现；通用模块的抽取可以体现在开发、测试实际任务安排中

3.缺陷分析

• 目的：对上线前上线后缺陷数据的分析，可以及时观察团队测试过程质量保障能力及交付质量情况

• 缺陷分析内容：测试总结，缺陷统计，缺陷分析，缺陷总结

• 测试总结：
  本月两个迭代测试用例总计XXX个，其中未执行用例X个。并总结此次测试过程问题。

• 缺陷统计：
  本月两个迭代总计发现bugXXX个，其中线上问题XXX个，预发问题XXX个，日常问题XXX个，未修复问题XXX个。
  线上问题XXX个，其中线上回归发现X个，XX个后续发现（6个为历史遗留问题）
  从测试总结和缺陷统计可以看出，总共1个用例未执行通过，6个线上问题，覆盖率1/6，覆盖率偏低。

• 缺陷分析：
  线上问题依次分析，这里省略......

• 缺陷总结：
  发布平滑性问题
  日常、预发无法测试考虑模拟测试
  测试覆盖率偏低，漏测多，导致线上问题偏多

02 可优化方面

复盘过程本身也有提升空间

• 迭代整体情况部分的总结
  团队的总体评价，对于团队有改进的方面，需要及时表达肯定。
  “从开始统计团队任务创建规范及任务延期率开始，整体情况有较为明显的改善，10月24日发布上线后，团队有所松懈，部分同学有反弹趋势，及时提醒后恢复执行意识，在这一点上团队的执行力有所提高，也是值得肯定的。”
  "任务管理体现了团队的计划能力，也是团队良好工作习惯的一部分，习惯形成是需要一个过程的，现在习惯培养起来了，希望大家能够持续保持下去，利用好上班的8个小时，利用8个小时以外的时间做好总结和提升"
• 持续改进部分的启示
  启示一：复盘的主体要交给团队，启发团队思考才是复盘目的

复盘会之前，和团队leader过复盘方案，在复盘之前我做了一个基于“研发过程综合评分”的一个问卷，问卷中有团队提出的问题。原计划把这部分提问拿出来进行复盘，但是复盘究竟是会议主持作为回答者，还是团队作为回答者？答案是团队，主持人是启发者，团队才是复盘的主体，团队通过思考得出的结论才能让团队更加认可，但是这些问题是团队提出的，那就需要主持人或者团队主管来解答这些问题，违背了复盘的目的。
问卷本身是有价值的，便于我们真是了解团队，提高迭代过程满意度，但是不应该也无需放到团队复盘会上，这些问题是需要管理者来重视和改进的问题，而不是拿团队提出的问题来问团队。
团队可以提出问题进行复盘的，是由团队成员提出，团队其他成员共同来解决，并且由ScrumMaster引导提出改进方案。

启示二：复盘要以案例为基础
只有详细的案例描述，才能分析出问题的本质。同下面讲的缺陷一样，没有案例的实际现象的还原，很可能提出的问题是并不是这个问题，或者可能就不是问题。

• 线上问题复盘如何做？
  第一步：还原现象，找到问题根本原因
  只有从代码层面还原了问题的实际现象，才能找到问题的根本原因。我们只能是透过现象才能看到本质，找到本质问题，才能为后一步的提升提供正确的方向。

  第二步：提出改进措施
  改进措施一定是实际可落实的。例如“开发应该更加严谨，测试应该更加严谨"，这样的改进措施还没有办法落地的。
  怎么样的才是实际可落实的？
  可以是“沉淀一份图片上传的边界值测试用例文档”，“实现mock，以解决支付日常预发无法测试问题”

• 线上问题的记录和解决
  线上问题体现了我们的质量问题，同时也是团队的镜子，可以照出团队的质量问题到底在哪里。如果没有利用好这面镜子照出的问题，可能会引起团队后续更多的问题的爆发。因此，记录和解决好线上问题也是团队持续改进的一个重要方面。

  如何记录问题

  • 描述缺陷现象
  • 还原重现路径
  • 描述影响范围

  如何解决问题

  • 还原问题想象。问题引入时间，问题引入代码等
  • 给出实际影响范围

03 如何将复盘做得更好

除了上面复盘的一些经验，要想把复盘做得更好，还是需要更深入理解业务，深入观察和发现团队问题。

• 深入了解业务，用一遍团队的开发的核心功能
• 和测试负责人制定线上问题记录规范
• 定期查看线上问题记录和解决规范性
• 和开发同学在一起，经常和他们一起吃饭，融入到他们中间，给与帮助
• 增加加班统计。项目管理铁三角，范围、成本、进度，范围从需求角度管控的目前没有太大问题，计划制定和跟进情况目前状况良好，可以关注成本方面是否有存在问题，团队加班情况如何，是由于需求角度，还是技术方案问题导致的返工问题。

结语，复盘可以翻盘，对于团队如此，对于PM更是如此。