zeroz-lab Retro — 事后回顾
入口/出口
- 入口: 功能/里程碑完成、事故处理完毕、项目阶段结束
- 出口: 事后总结文档 + 行动项（可追踪）
- 指向: 行动项纳入下一次 plan/backlog
- 前置加载: CANON.md
- 输出路径: ship-workflow-ship（行动项纳入 backlog）/ maintain-workflow-learn（经验提取归档）
何时不使用
- 功能尚未完成，仍在 build/review/ship 阶段
- 只是日常小改、文档微调或配置修正
- 没有可复盘的事件、决策或结果证据
何时做复盘
必须做: 每个功能上线后、事故/严重 bug 修复后、Sprint/里程碑结束、大重构完成后
不必做: 日常小改动、文档更新、配置调整
复盘结构
1. 时间线
Checkpoint: 时间线完成后 — 确认时间线基于可验证事实（日志、部署记录、告警），而非纯记忆。至少覆盖起始、关键决策、问题发现、修复部署四个节点。
建立客观事实——按时间顺序列出发生了什么:
- 什么时候开始的
- 关键决策点在什么时间
- 问题什么时候发现的
- 修复什么时候部署的
先时间线，再分析。 跳过时间线直接分析 = 基于记忆的评价而非基于事实。
2. 做得好（保持）
Checkpoint: 好做法列表完成后 — 确认至少 3 条，每条说明为什么好而非泛泛表扬。
至少列出 3 件做对的事。这不是谦虚——识别好的做法才能重复它。
3. 更好（改进）
Checkpoint: 改进点列表完成后 — 确认每条改进点有具体场景和具体改法，而非"X 应更好"。
具体。不是"沟通更好"，而是"数据库 schema 变更没有通知前端团队，导致 3 小时的 breakage。下次 DB 变更 → 在 #frontend 频道提前公告"。
4. 行动项
Checkpoint: 行动项列表完成后 — 确认每条有单人 owner、截止日期、可验证完成标准。模糊行动项必须重写。
每个行动项必须:
- 有 owner（一个人，不是"团队"）
- 有截止日期或下一个里程碑关联
- 可验证完成（"改进测试覆盖率"不行动项；"为 payment 模块增加 3 个集成测试"是行动项）
指标收集
复盘时收集数据支持讨论：
指标类别:
├── 功能/故事点完成数
├── 提交数 + PR 大小
├── 测试覆盖率变化
├── Bug 数量（引入的 vs. 修复的）
├── 上线到稳定时间
├── 回滚次数
└── 会议/同步消耗 vs 编码时间
事故复盘专用模板
# 事故复盘: [标题]
## 时间线
- [HH:MM] 问题开始
- [HH:MM] 告警触发
- [HH:MM] 第一个响应者介入
- [HH:MM] 定位到原因
- [HH:MM] 修复部署
- [HH:MM] 服务恢复正常
## 影响
- 影响时长: XX 分钟
- 影响用户: XX / XX%
- 数据损失: 有/无
## 根因
[1-2 句]
## 5 Why
1. 为什么用户无法下单？→ 支付服务返回 500
2. 为什么支付服务返回 500？→ 数据库连接池满了
3. 为什么连接池满了？→ 新部署的代码有 N+1 查询
4. 为什么 N+1 没在审查中捕获？→ 代码审查没有检查查询性能
5. 为什么没有性能检查？→ 审查清单没有性能项
## 行动项
1. [owner] 修复 N+1 查询 — [date]
2. [owner] 给代码审查清单加性能专项 — [date]
3. [owner] 给支付服务加连接池监控告警 — [date]
常见说辞
| 说辞 | 现实 | 后果 |
|---|---|---|
| "太忙了没时间复盘" | 不花 30 分钟复盘，下次同样的问题花 8 小时。复盘是投资。 | 同类问题反复出现，每次修复 ≥ 8h，累计浪费 ≥ N x 8h |
| "问题很明显不需要分析" | 明显的是症状，不是根因。5 Why 后往往发现真正的原因和最初想的不同。 | 只治症状不治根因，同类问题 3 个月内复发概率 ≥ 80% |
| "行动项以后再说" | 没有 owner 和截止日期的行动项不会发生。任何人在复盘结束前 assign。 | 无 owner 的行动项永远不会被执行，下次复盘出现相同问题 |
红旗 — STOP
- 复盘变成 blame game（谁的责任）而非系统改进
- 只列出坏的不列好的（只看到问题 = 士气低落）
- 行动项模糊或没有 owner / 截止日期
- 同一个问题第二次出现在复盘（上次的行动项显然没执行）
- 没有人负责跟踪行动项完成
验证失败处理
| 失败场景 | 处理方式 |
|---|---|
| 时间线基于记忆而非事实 | 要求提供日志、部署记录、告警截图等客观证据。无证据的节点标注为"待确认" |
| 复盘变成 blame game | 立即转向系统改进视角。问"系统为什么允许这个错误发生"而非"谁犯了错" |
| 好做法少于 3 条 | 扩大观察范围——代码质量、协作效率、自动化程度、工具改进等维度都有好做法 |
| 行动项无 owner 或截止日期 | 复盘结束前必须 assign。无 owner 的行动项视为无效，不纳入 backlog |
| 同一问题第二次出现 | 上次行动项未执行是根因。追踪上次行动项执行状态，确认阻塞原因后重新设定期限 |
好/坏示例
坏：模糊复盘
# 复盘: Q2 发布
做得不好：沟通不够，测试不足，上线出了问题。
改进：加强沟通，增加测试。
行动项：团队讨论改进方案。
问题：无时间线、无具体改进、无 owner、无截止日期——下次复盘会出现同样的条目。
好：可追踪复盘
# 复盘: Q2 发布
## 时间线
- 05/01 开始开发
- 05/10 DB schema 变更未通知前端
- 05/15 前端 3 小时 breakage
- 05/20 上线后 P99 延迟升至 500ms
- 05/22 修复部署
## 做得好
1. 自动化部署流水线节省 2 小时/次
2. 代码审查捕获了 3 个安全漏洞
3. 监控告警在 30 秒内通知团队
## 更好
1. DB 变更未通知前端 → 下次 DB 变更在 #frontend 频道提前公告
2. N+1 查询未在审查中捕获 → 审查清单加性能专项
## 行动项
1. [张三] 给审查清单加性能专项 — 05/30
2. [李四] DB 变更公告流程写入 README — 05/28
3. [王五] 给支付服务加连接池监控 — 06/01
优点：时间线基于事实、好做法可重复、改进点具体、行动项有 owner 和截止日期。
输出模板
复盘完成后应产出以下结构（保存到 docs/features// 或 docs/retro/ 目录）：
### Retro 交付记录
**复盘类型**: [功能上线 / 事故 / 里程碑 / 重构]
**复盘对象**: [功能名 / 事故标题 / 里程碑名]
**复盘日期**: [YYYY-MM-DD]
**参与人**: [列出参与者]
**时间线节点数**: [N]
**好做法数**: [≥ 3]
**改进点数**: [N]
**行动项数**: [N]
**行动项追踪表**:
| # | 行动项 | Owner | 截止日期 | 状态 |
|---|--------|-------|----------|------|
| 1 | [具体行动] | [人名] | [日期] | [待执行 / 进行中 / 完成] |
**归档路径**: [docs/retro/YYYYMMDD-<name>.md]
**关联 learnings**: [是否已提取到 .claude/learnings.jsonl]
验证清单
- 时间线完整（不是从记忆中直接跳到结论）
- 至少 3 件好做法被识别
- 改进点具体（不是模糊的"沟通更好"）
- 每个行动项有 owner + 截止日期
- 复盘文档保存到可被引用的位置
- 如果包含指标——指标数据有来源而非估算