| 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
□ 是否更新了系统文档
□ 行动项是否会被追踪（不是写完就忘）
常见坑
- 复盘流于形式——填模板凑数，没有真问题
- 没有行动项——只总结不改进
- 行动项太宽泛——"加强协作" "提升质量"
- 不沉淀——经验只在项目内部消化
- 变成批斗会——攻击个人而不是改进流程
- 下次不回看——上次的行动项早忘了
- 只复盘失败的部分——成功经验也要沉淀
- 数据缺失——没有客观对比，全靠感觉
配套模板
templates/retrospective-template.md — 简短复盘 + 阶段复盘 + 完整复盘 + 行动项追踪模板
与其他 skill 的协作
上游：
progress-tracking → 提供执行数据
dora-metrics → 提供效能数据
risk-management → 风险发生情况
milestone-gate → 门禁通过情况
下游：
field-journal → 沉淀经验
下次项目的所有 skill → 引用本次经验
系统文档更新（routing/pitfalls/templates）
