retrospective

name	retrospective
description	项目结束后做复盘时使用。适用于 Cycle 结束、里程碑结束、项目完成、季度回顾。优先使用结构化复盘模板 + 行动项追踪 + field-journal 沉淀。

项目复盘（Retrospective）

参考来源：Agile Retrospectives、Toyota PDCA Cycle

适用场景

• Cycle 结束（5 分钟简短复盘）
• 里程碑结束（15 分钟阶段复盘）
• 项目完成（30 分钟完整复盘）
• 季度/年度回顾
• 重大事件后（故障、上线失败、重大变更）

核心原则

1. 复盘不是批斗会
   关注流程和方法，不是个人

2. 不复盘 = 重复踩坑
   没有复盘的项目，下次会犯同样的错

3. 复盘必须有行动项
   只总结不行动等于没复盘

4. 行动项必须可追踪
   下次复盘要回看上次的行动项是否完成

5. 沉淀到 field-journal
   不只是项目内部消化，要让其他项目也能受益

三层复盘模型

Quick Retro（简短）：5 分钟
  - 适用：Cycle 结束
  - 方法：3 个问题（做得好/待改进/学到了什么）
  - 输出：1~2 条 field-journal

Phase Retro（阶段）：15 分钟
  - 适用：里程碑结束
  - 方法：4 个维度（目标/流程/协作/技术）
  - 输出：3~5 条改进项 + field-journal

Full Retro（完整）：30 分钟
  - 适用：项目完成
  - 方法：完整复盘模板（见下方）
  - 输出：复盘报告 + 行动项 + field-journal

完整复盘模板

# 项目复盘：[项目名]

## 基本信息

- 项目名称：
- 时间范围：[开始] ~ [结束]
- 实际工期：X 小时
- 计划工期：Y 小时
- 偏差：Z%
- 参与工作流：[列表]

## 1. 目标达成

### 原始目标
[项目最初要解决的问题]

### 实际交付
[实际交付的成果]

### 差距和原因
- 差距 1：[描述]
  - 原因：[根因分析]
- 差距 2：...

### OKR 完成情况（如有）
- KR1：目标 X，实际 Y，完成度 Y/X
- KR2：...

## 2. 时间线

### 计划 vs 实际

| 里程碑 | 计划时间 | 实际时间 | 偏差 |
|--------|---------|---------|------|
| M1 | +15min | +18min | +3min |
| M2 | +50min | +65min | +15min |
| M3 | +2h | +2.5h | +30min |

### 延期原因分析

- [里程碑] 延期 X：原因 [具体]
  - 是否可避免：是 / 否
  - 下次怎么避免：[行动项]

## 3. 风险回顾

### 预见到的风险

| 风险 | 是否发生 | 缓解效果 |
|------|---------|---------|
| R1 | 是 | 缓解方案有效 |
| R2 | 否 | - |

### 实际发生的风险

| 风险 | 影响 | 处理方式 |
|------|------|---------|
| 实际 R1 | 延期 30min | L2 升级，调整计划 |

### 未预见的风险

| 风险 | 启示 |
|------|------|
| [描述] | 下次项目要识别 |

## 4. 协作问题

### 哪些交接顺畅

- 产品经理 → API 设计：契约清晰，0 返工
- 后端 → QA：测试用例齐全

### 哪些交接出问题

- UI/UX → 前端：状态说明不全，导致前端猜了 3 处
  - 改进：UI/UX 工作流的状态清单作为强制门禁

- API 设计 → 前端：错误码定义晚于前端开始
  - 改进：API 契约必须在前端开发前完成

## 5. 可复用经验

### 估算经验

- 后端开发实际比预估快 20%（用了模板）
- 前端联调比预估慢 50%（API 字段不一致）

### 流程改进

- [改进 1]：具体描述
- [改进 2]：具体描述

### 工具改进

- 新增模板：[名称] 解决了 [问题]
- 新增脚本：[名称] 自动化了 [步骤]

### 模板改进

- [现有模板] 需要补充 [内容]

## 6. 后续行动项

| # | 行动项 | 负责工作流 | 截止时间 | 验证方式 |
|---|-------|----------|---------|---------|
| 1 | 更新 UI/UX 交接模板，强制状态清单 | ui-ux-designer | 下个项目前 | 模板中包含状态检查项 |
| 2 | API 契约时间提前到设计阶段 | api-designer + project-manager | 立即 | 在 milestone-gate 中加入此规则 |
| 3 | 优化前端联调缓冲时间到 30min | project-manager | 立即 | 模板中默认值更新 |

## 7. Field Journal 条目

需要回写到 field-journal 的内容：

1. [经验 1]：[简述] - 适用场景：[何时复用]
2. [经验 2]：[简述] - 适用场景：[何时复用]

## 8. 系统更新

需要更新的系统文档：

- [ ] 更新 routing.md：新增 [关键词]
- [ ] 更新 pitfalls.md：新增 [常见坑]
- [ ] 更新 [skill-name]/SKILL.md：补充 [内容]
- [ ] 更新 templates/：[新模板]

简短复盘模板（Quick Retro）

## Cycle [N] 简短复盘

### ✅ 做得好（What Went Well）

- [1~2 条]

### ⚠️ 待改进（What Could Be Better）

- [1~2 条]

### 💡 学到了什么（Lessons Learned）

- [1 条]

### 行动项

- [ ] [立即可做的小改进]

4 维度复盘（Phase Retro）

## 阶段复盘：[阶段名]

### 1. 目标
- 计划：[原始目标]
- 实际：[完成情况]
- 差距：[原因]

### 2. 流程
- 顺畅的环节：
- 卡顿的环节：
- 改进点：

### 3. 协作
- 交接顺畅的：
- 交接卡顿的：
- 改进点：

### 4. 技术
- 顺利的：
- 困难的：
- 改进点：

### 行动项
- [3~5 条具体可执行的]

工作流程

1. 选择复盘级别（Quick/Phase/Full）
   ↓
2. 收集数据：
   - 任务实际工时
   - 阻塞记录
   - 变更记录
   - DORA 指标
   ↓
3. 按模板填充
   ↓
4. 提取行动项（必须具体可执行）
   ↓
5. 沉淀到 field-journal
   ↓
6. 更新系统文档（routing/pitfalls/templates）
   ↓
7. 下次复盘时回看行动项是否完成

质量自检

□ 是否有具体数据（不是"感觉"）
□ 是否分析了根因（不只是现象）
□ 行动项是否具体可执行（不是"加强沟通"）
□ 行动项是否有负责人和时间
□ 是否沉淀到 field-journal
□ 是否更新了系统文档
□ 行动项是否会被追踪（不是写完就忘）

常见坑

1. 复盘流于形式——填模板凑数，没有真问题
2. 没有行动项——只总结不改进
3. 行动项太宽泛——"加强协作" "提升质量"
4. 不沉淀——经验只在项目内部消化
5. 变成批斗会——攻击个人而不是改进流程
6. 下次不回看——上次的行动项早忘了
7. 只复盘失败的部分——成功经验也要沉淀
8. 数据缺失——没有客观对比，全靠感觉

配套模板

• templates/retrospective-template.md — 简短复盘 + 阶段复盘 + 完整复盘 + 行动项追踪模板

与其他 skill 的协作

上游：
  progress-tracking → 提供执行数据
  dora-metrics → 提供效能数据
  risk-management → 风险发生情况
  milestone-gate → 门禁通过情况

下游：
  field-journal → 沉淀经验
  下次项目的所有 skill → 引用本次经验
  系统文档更新（routing/pitfalls/templates）