Files

4.2 KiB
Raw Permalink Blame History

Retrospective 检查清单

迭代复盘自检。Retrospective Lead 在 Phase 7 报告前检查。


1. 数据收集(DATA — Data Quality)

# 检查项 通过 不通过 备注
1.1 分析范围已明确(tag range / time range) ☐ ☐
1.2 Commit 按类型统计已运行(BREAKING/feat/fix/...) ☐ ☐
1.3 Revert 数和无前缀 commit 数已统计 ☐ ☐
1.4 文件改动 Top 10 已列出(按 +/− 排序) ☐ ☐
1.5 测试结果已获取(通过/失败/跳过数) ☐ ☐
1.6 测试文件改动情况已检查(无测试改动的源码改动) ☐ ☐
1.7 Typecheck + Lint 当前状态已检查 ☐ ☐
1.8 依赖审计已运行,变更已记录 ☐ ☐
1.9 流程基础设施已检查(pre-commit/CI/PR/review/doc/artifact) ☐ ☐
1.10 已检查是否存在被删除的未合并 workflow/* 分支(废弃工作/资源浪费) ☐ ☐
1.11 已检查 merged workflow/* 分支与关联 worktree 在合并后已清理(本地分支删除 + worktree 移除) ☐ ☐
1.12 周期时长和团队规模已记录(压缩周期 = 质量风险,单点故障) ☐ ☐
1.13 范围估算验证:triage/scope 声明前已统计各标签下的 issue 数量(如 Status/Blocked、Kind/*、Priority/*),并与之前声明对比,偏差 >20% 标注为估算偏差 ☐ ☐
1.14 门缺陷逃逸分析已运行(§2.8 escape-rate 单指标,[TT-3061]):各 gate 的 clean runs / escapes / escape_rate 已统计,UNDER-POWERED(≥0.3)门已标注并回馈 §2.9 pre-flight(gate-trim 元进程已退役,[TT-3072] phase 3) ☐ ☐

2. 分析质量(ANAL — Analysis Quality)

# 检查项 通过 不通过 备注
2.1 "What went wrong" 每一项都有数据证据支撑 ☐ ☐
2.2 根因追溯到具体环节(测试缺失/模块过于庞大/提交不规范) ☐ ☐
2.3 "What went well" 有可复用的模式描述 ☐ ☐

3. 行动项(ACT — Action Items)

# 检查项 通过 不通过 备注
3.1 行动项数 ≤ 5 ☐ ☐
3.2 每个行动项有具体文件路径(修改哪个 template/checklist/SKILL/config) ☐ ☐
3.3 每个行动项有 Owner 角色 ☐ ☐
3.4 行动项可度量(如何判断已执行) ☐ ☐
3.5 行动项不是"更努力"、"更仔细"等空泛措辞 ☐ ☐

4. 闭环(LOOP — Feedback Loop)

# 检查项 通过 不通过 备注
4.1 所有素材文件已更新(行动项中引用的文件) ☐ ☐
4.2 更新的素材变更已在 report 中记录 ☐ ☐

5. 无指责原则(SAFE — Blameless)

# 检查项 通过 不通过 备注
5.1 报告不含任何个人指责 ☐ ☐
5.2 所有问题归因于流程/工具/信息不足,非个人能力 ☐ ☐