retro-analysis

回顾分析技能

生成一份以数据为依据的回顾简报，将事实与感受区分开来，让团队把回顾时间用在寻找解决方案上，而不是争论发生了什么。

必要输入

如果用户未提供，请向用户询问：

• Sprint 工单：计划数量与完成数量
• 遗留工单及原因（如果已知）
• 关闭后重新打开的工单（质量信号）
• 任何事故或计划外工作（范围蔓延信号）
• Sprint 速度与历史平均值（趋势背景）

流程

1. 计算：完成率、遗留率、计划外工作占比
2. 找出模式：哪些类型的工单最容易遗留？哪些造成了阻塞？
3. 记录数据中反映出的流程或沟通问题
4. 根据数据准备 3 个“开始／停止／继续”讨论提示——针对本次 Sprint，而非泛泛而谈
5. 根据最大的阻碍，为下个 Sprint 提出 1 项具体实验
6. 验证——确认每个提示都针对本次 Sprint（而非重复使用的通用提示），并且建议的实验具体且可衡量

输出结构

Sprint [Number] 回顾简报

数据一览：

• 计划：[n] 个工单 | 已完成：[n] 个 | 遗留：[n] 个 | 完成率：[%]
• 计划外工作：[n] 个工单（占产能的 [%]）
• 速度：[points]，平均值为 [average]

数据反映的情况： [基于上述数字得出的 2-3 条观察]

讨论提示：

• 开始：[根据本次 Sprint 数据提出的具体提示]
• 停止：[根据本次 Sprint 数据提出的具体提示]
• 继续：[根据本次 Sprint 数据提出的具体提示]

下个 Sprint 的建议实验： [一项具体、可测试的流程变更，并附上明确的成功指标]

深入材料

此技能附带了支持文件——如果可用，请使用：

• references/root-cause-vs-symptom.md — 《改变现状的回顾：根本原因与表面症状》。生成输出时请应用其中的内容；它包含了方法摘要所概括的校准标准和判断依据。
• templates/retro-board.md — 可填写的交付物模板，内含质量检查项。如果用户希望自行填写文档，而不是让你生成，请向其提供此模板。

评分标准（0–40）

交付前为此技能生成的任何输出评分；32 分及以上可视为达到交付标准。

维度	0	5	10
数据依据	缺少数字或数字有误；观察只是意见，无法追溯到数据来源	核心比率计算正确，但观察只是复述数字，没有分析模式（工单类型、历史对比）	每条观察都能追溯到计算结果；按类型／原因细分遗留情况；速度与历史趋势（而不只是平均值）进行比较
不责备个人	简报点名或暗示个人／职能是原因（“QA 漏掉了这些问题”）	措辞中立，但表述仍将问题归因于投入程度或认真程度，而非系统性条件	将失败模式重新表述为数据实际支持的流程、覆盖范围或排期模式——即使读者持防御心态，也不会觉得这是在针对他们
提示的针对性	开始／停止／继续只是重复使用的通用类别（如“加强沟通”）	提示提及了本次 Sprint，但仍停留在类别层面——没有数字，也没有明确的行为	每个提示都紧扣本次 Sprint 的数据，明确指出一种具体行为，并以开放讨论而非规定答案的方式提出
实验质量	没有实验，或将跨季度项目伪装成实验	有一项具体变更，但成功与否无法衡量，或无法在下次回顾时评估	一项可在单个 Sprint 内测试的流程变更，包含明确的成功指标和已说明的出错成本，并可在下次回顾时核查

质量检查

• 每条 Start/Stop/Continue 提示词都指出了具体行为，而非模糊的类别
• 建议的实验可在一个冲刺内进行测试
• 结转分析指出了工单类型或原因，而不只是数量
• 数据观察不归咎于任何人，而是描述模式
• 结合背景提及速度趋势（这是一次性的情况，还是一种模式？）

反模式

• 不要在回顾简报中将责任归咎于个人——观察结果必须描述模式，而非具体的人
• 不要给出类别模糊的 Start/Stop/Continue 提示词——每条都必须指出具体行为
• 不要建议无法在一个冲刺内完成的实验——只建议规模小、可测试的实验
• 在确定根本原因类别之前，不要将结转工单视为速度问题
• 不要每个冲刺都采用相同的回顾形式——应变换形式，避免参与者产生疲劳感