reflect-team-retro

name	reflect-team-retro
description	事后回顾——提取经验和改进行动。当功能完成、里程碑达成、事故处理后需要系统性复盘，或提到"回顾""复盘""retro""postmortem"

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 + 截止日期
• 复盘文档保存到可被引用的位置
• 如果包含指标——指标数据有来源而非估算