---

name: retro-analysis language: zh description: "分析迭代交付数据，产出结构化的回顾简报。当被要求开回顾会、分析迭代数据、准备回顾简报，或把迭代指标转成讨论提示时使用。产出基于数据的回顾简报：完成情况统计、规律分析、开始 / 停止 / 继续的讨论提示，以及下个迭代的一个具体实验。项目或活动的复盘请使用 cn-fupan。"

retro-analysis 的简体中文翻译，英文版本为规范版本。

迭代回顾分析

生成一份基于数据的回顾简报，把事实和感受分开，让团队把回顾时间花在解决方案上，而不是争论发生了什么。

所需输入

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

• 迭代任务：计划的与完成的
• 顺延的任务及原因（如知道）
• 关闭后又重新打开的任务（质量信号）
• 任何故障或计划外的工作（范围蔓延信号）
• 迭代速率与历史平均对比（趋势背景）

流程

1. 计算：完成率、顺延率、计划外工作占比
2. 识别规律：哪类任务最容易顺延？哪些造成了阻碍？
3. 记录数据中可见的流程或沟通断点
4. 基于数据准备 3 条"开始 / 停止 / 继续"提示：不是通用的，而是针对这个迭代
5. 针对最大的摩擦点，为下个迭代建议 1 个具体实验
6. 验证：确认每条提示都针对这个迭代（不是循环使用的通用提示），建议的实验具体、可衡量

输出结构

第 [编号] 个迭代回顾简报

数字一览：

• 计划：[n] 个任务 | 完成：[n] | 顺延：[n] | 完成率：[%]
• 计划外工作：[n] 个任务（占容量的 [%]）
• 速率：[点数]，平均为 [平均值]

数据说明了什么： [基于上面数字的 2 到 3 条观察]

讨论提示：

• 开始：[基于这个迭代数据的具体提示]
• 停止：[基于这个迭代数据的具体提示]
• 继续：[基于这个迭代数据的具体提示]

下个迭代的建议实验： [一个具体、可测试的流程改变，附具体的成功指标]

延伸材料

这个技能附带支持文件，可用时请使用：

• references/root-cause-vs-symptom.md：能带来改变的回顾：根本原因与症状。在产出时应用它；它包含上面方法摘要压缩掉的校准和判断。
• templates/retro-board.md：可填写的成果模板，质量关卡写在里面。当用户想自己完成文档而不是生成时提供。

评分量表（0 到 40）

交付前给这个技能的任何产出打分；32 分以上才算可以交付。

维度	0	5	10
数据依据	数字缺失或错误；观察是没有可追溯来源的意见	核心比率计算正确，但观察只是复述数字，没有规律分析（任务类型、历史对比）	每条观察都追溯到计算出的数字，顺延按类型或原因拆分，速率与历史趋势而不只是平均值对比
不指责个人	简报点名或暗示个人、某个职能是原因（"测试漏掉了"）	措辞中性，但框架仍指向努力程度或是否尽责，而不是系统条件	失败模式被重新表述为数据真正支持的流程、覆盖或排期规律：抱有防御心的读者也找不到针对自己的内容
提示的针对性	开始 / 停止 / 继续是循环使用的通用类别（"加强沟通"）	提示提到了这个迭代，但停留在类别层面：没有数字，没有点出具体行为	每条提示都与这个迭代的数据紧密相连，点出一个具体行为，并以开启讨论而不是规定答案的方式表述
实验质量	没有实验，或把跨季度的计划包装成实验	有一个具体改变，但成功无法衡量，或下次回顾时无法评估	一个在单个迭代内可测试的流程改变，有明确的成功指标和失败的代价，下次回顾时可以检查

质量检查

• 每条开始 / 停止 / 继续提示都点出具体行为，而不是模糊的类别
• 建议的实验在一个迭代内可测试
• 顺延分析找出了任务类型或原因，而不只是数量
• 数据观察不指责个人，只描述规律
• 结合背景提到速率趋势（是一次性的还是规律？）

反模式

• 不要在回顾简报中指责个人：观察必须描述规律，而不是人
• 不要写成模糊类别的开始 / 停止 / 继续提示：每条都必须点出具体行为
• 不要建议一个迭代内完成不了的实验：只做小而可测试的实验
• 不要在找出根本原因类别之前，把顺延任务当作速率问题
• 不要每个迭代都用同样的回顾形式：变换形式，避免参与疲劳

示例触发语

• “组织一次回顾会。”
• “分析这个迭代的数据。”
• “准备回顾会材料。”
• “把迭代指标变成讨论问题。”