retrospective

当此技能被调用时：

1. 读取参数确定这是 Sprint 回顾 （sprint-N）还是里程碑回顾（里程碑名称）。

1. 读取 Sprint 或里程碑计划从相应位置：
2. Sprint 计划：production/sprints/
3. 里程碑定义：production/milestones/

提取：计划任务、预估工作量、负责人和目标。

1. 读取 git log 以了解该 Sprint 或里程碑覆盖的时间段内 实际提交了什么以及何时提交。

1. 扫描已完成和未完成的任务，通过对比计划与实际交付物。检查：
2. 按计划完成的任务
3. 已完成但与计划有修改的任务
4. 延期任务（未完成）
5. Sprint 中途添加的任务（计划外工作）
6. 被移除或缩减范围的任务

1. 扫描代码库中的 TODO/FIXME 趋势：
2. 统计当前的 TODO/FIXME/HACK 注释数
3. 与上一 Sprint 的计数对比（如可用，检查之前的回顾）
4. 注意技术债务是在增长还是减少

1. 读取之前的回顾（如有），来自 production/sprints/ 或 production/milestones/，以检查：
2. 之前的行动项是否已处理？
3. 相同的问题是否在重复出现？
4. 速率趋势如何？

1. 生成回顾：

## 回顾：[Sprint N / 里程碑名称]
周期：[开始日期] -- [结束日期]
生成日期：[日期]

### 指标

| 指标 | 计划 | 实际 | 差异 |
|------|------|------|------|
| 任务数 | [X] | [Y] | [+/- Z] |
| 完成率 | -- | [Z%] | -- |
| 故事点 / 工作量天数 | [X] | [Y] | [+/- Z] |
| 发现的 Bug | -- | [N] | -- |
| 修复的 Bug | -- | [N] | -- |
| 新增的计划外任务 | -- | [N] | -- |
| 提交数 | -- | [N] | -- |

### 速率趋势

| Sprint | 计划 | 完成 | 完成率 |
|--------|------|------|--------|
| [N-2] | [X] | [Y] | [Z%] |
| [N-1] | [X] | [Y] | [Z%] |
| [N]（当前） | [X] | [Y] | [Z%] |

**趋势**：[上升 / 稳定 / 下降]
[一句话解释趋势]

### 做得好的方面
- [由具体数据或示例支持的观察]
- [另一个正面观察]
- [认可特定贡献或取得了回报的决策]

### 做得不好的方面
- [具有可衡量影响的具体问题 — 例如 "功能 X 花了 5 天而非预估的 2 天，阻塞了任务 Y 和 Z"]
- [另一个有影响的问题]
- [不要归咎个人 — 关注系统性原因]

### 遇到的阻碍

| 阻碍项 | 持续时间 | 解决方式 | 预防措施 |
|--------|---------|---------|---------|
| [什么阻碍了进展] | [持续多久] | [如何解决] | [如何预防再次发生] |

### 估算准确性

| 任务 | 预估 | 实际 | 偏差 | 可能原因 |
|------|------|------|------|---------|
| [最严重高估的任务] | [X] | [Y] | [+Z] | [为什么] |
| [最严重低估的任务] | [X] | [Y] | [-Z] | [为什么] |

**整体估算准确性**：[X%] 的任务在预估的 +/- 20% 以内

[分析：我们是否持续高估或低估？对于哪些类型的任务？应该做何调整？]

### 延期分析

| 任务 | 原始 Sprint | 延期次数 | 原因 | 处理方式 |
|------|-----------|---------|------|---------|
| [未完成的任务] | [Sprint N-X] | [N] | [为什么] | [完成 / 缩减范围 / 重新设计] |

### 技术债务状态
- 当前 TODO 数量：[N]（上次：[N]）
- 当前 FIXME 数量：[N]（上次：[N]）
- 当前 HACK 数量：[N]（上次：[N]）
- 趋势：[增长 / 稳定 / 减少]
- [注意任何令人关注的领域]

### 上次行动项跟进

| 行动项（来自 Sprint N-1） | 状态 | 备注 |
|--------------------------|------|------|
| [上次的行动] | [已完成 / 进行中 / 未开始] | [上下文] |

### 下次迭代的行动项

| # | 行动 | 负责人 | 优先级 | 截止日期 |
|---|------|--------|--------|---------|
| 1 | [具体、可衡量的行动] | [谁] | [高/中/低] | [何时] |
| 2 | [另一个行动] | [谁] | [优先级] | [何时] |

### 流程改进
- [工作方式的具体改变，附预期收益]
- [另一项改进 — 保持在 2-3 个可执行的改进项，而非愿望清单]

### 总结
[2-3 句话整体评估：这是一个好的 Sprint/里程碑吗？下一步最重要的改变是什么？]

1. 保存回顾到相应位置：
2. Sprint：production/sprints/sprint-[N]-retrospective.md
3. 里程碑：production/milestones/[里程碑名称]-retrospective.md

如目录不存在则创建。

1. 向用户输出摘要：完成率、速率趋势方向、首要阻碍项，以及最重要的行动项。

指南

• 要诚实和具体。模糊的回顾（"沟通可以更好"）只能产生模糊的改进。使用数据和示例。
• 关注系统性问题，而非个人责任。
• 行动项限制在 3-5 个。更多会分散注意力。
• 每个行动项必须有负责人和截止日期。
• 检查之前的行动项是否已完成。反复出现的未处理项是流程问题的信号。
• 如果这是里程碑回顾，还需评估里程碑目标是否达成，以及这对整体项目时间线意味着什么。