# Reflect Team Retro

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

- Skill: `zeroz-lab/reflect-team-retro` (Agent Skill)
- Install (CLI): `npx skillmds@latest add zeroz-lab/reflect-team-retro`
- Raw SKILL.md: https://api.skillmd.com/api/skills/zeroz-lab/reflect-team-retro/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: zeroz-lab (https://skillmd.com/u/zeroz-lab)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/zeroz-lab/reflect-team-retro

---


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

## 事故复盘专用模板

```markdown
# 事故复盘: [标题]

## 时间线
- [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 |
| 同一问题第二次出现 | 上次行动项未执行是根因。追踪上次行动项执行状态，确认阻塞原因后重新设定期限 |

## 好/坏示例

**坏：模糊复盘**
```markdown
# 复盘: Q2 发布

做得不好：沟通不够，测试不足，上线出了问题。
改进：加强沟通，增加测试。
行动项：团队讨论改进方案。
```
问题：无时间线、无具体改进、无 owner、无截止日期——下次复盘会出现同样的条目。

**好：可追踪复盘**
```markdown
# 复盘: 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/<name>/ 或 docs/retro/ 目录）：

```markdown
### Retro 交付记录

**复盘类型**: [功能上线 / 事故 / 里程碑 / 重构]
**复盘对象**: [功能名 / 事故标题 / 里程碑名]
**复盘日期**: [YYYY-MM-DD]
**参与人**: [列出参与者]

**时间线节点数**: [N]
**好做法数**: [≥ 3]
**改进点数**: [N]
**行动项数**: [N]

**行动项追踪表**:
| # | 行动项 | Owner | 截止日期 | 状态 |
|---|--------|-------|----------|------|
| 1 | [具体行动] | [人名] | [日期] | [待执行 / 进行中 / 完成] |

**归档路径**: [docs/retro/YYYYMMDD-<name>.md]
**关联 learnings**: [是否已提取到 .claude/learnings.jsonl]
```

## 验证清单

- [ ] 时间线完整（不是从记忆中直接跳到结论）
- [ ] 至少 3 件好做法被识别
- [ ] 改进点具体（不是模糊的"沟通更好"）
- [ ] 每个行动项有 owner + 截止日期
- [ ] 复盘文档保存到可被引用的位置
- [ ] 如果包含指标——指标数据有来源而非估算