retrospective

Project Retrospective

Reference sources: Agile Retrospectives, Toyota PDCA Cycle

Applicable scenarios

• End of Cycle (5-minute quick retrospective)
• End of milestone (15-minute phase retrospective)
• Project completion (30-minute full retrospective)
• Quarterly/annual review
• After major events (incidents, failed launches, major changes)

Core principles

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

1. No retrospective = repeating the same pitfalls Projects without retrospectives will make the same mistakes next time

2. A retrospective must have action items Summarizing without acting is the same as not doing a retrospective

3. Action items must be trackable In the next retrospective, look back at whether the previous action items were completed

4. Capture into field-journal Do not just absorb it internally within the project; let other projects benefit too

## 三层复盘模型

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

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

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

Full retrospective template

# 项目复盘：[项目名]

## 基本信息

- 项目名称：
- 时间范围：[开始] ~ [结束]
- 实际工期：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 template

## Cycle [N] 简短复盘

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

- [1~2 条]

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

- [1~2 条]

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

- [1 条]

### 行动项

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

4-dimension retrospective (Phase Retro)

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

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

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

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

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

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

Workflow

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

Quality self-check

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

Common pitfalls

1. Retrospective becomes a formality——filling in the template to tick boxes, with no real problems
2. No action items——only summarizing, not improving
3. Action items are too broad——"strengthen collaboration" "improve quality"
4. No capture——experience is only absorbed internally within the project
5. Turns into a criticism session——attacking individuals instead of improving the process
6. No look-back next time——the previous action items were long forgotten
7. Only retrospect the failed parts——successful experience also needs to be captured
8. Missing data——no objective comparison, all based on feelings

Supporting templates

• templates/retrospective-template.md — Quick Retro + Phase Retro + Full Retro + action item tracking template

Collaboration with other skills

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

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