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 编码时间