iterate-retrospective

回顾

回顾是一种结构化反思，帮助团队从经验中学习并持续改进。通过定期审视哪些方面进展顺利、哪些不尽如人意，以及需要做出哪些改变，团队能够建立学习和适应的文化。其价值不仅在于讨论，还在于记录下来的行动及后续落实。

适用场景

• 每个冲刺结束时（适用于敏捷团队）
• 完成重要项目或里程碑后
• 发生重大事故或服务中断后
• 团队协作氛围不佳、需要解决问题时
• 定期开展（每月、每季度），即使没有特定触发事件
• 新团队成员入职时，以建立持续改进的文化

不适用场景

• 你想为组织留下一项持久的经验记录 -> 使用 iterate-lessons-log；回顾是仪式，而日志记录会长期留存
• 你要在 OKR 周期结束时进行评分 -> 使用 measure-okr-grader
• 反思必须以“转向或坚持”的决策告终 -> 使用 iterate-pivot-decision
• 你需要总结一般（非回顾）会议 -> 使用 foundation-meeting-recap

说明

收到主持或记录回顾的请求时，请遵循以下步骤：

1. 设定背景 明确本次回顾涵盖的时间段或项目、参会人员以及发生过的重大事件。这能为讨论提供背景，帮助未来的读者理解具体情况。

2. 选择形式 选择适合团队需求的回顾形式。常见选项包括：

   • 开始／停止／继续： 简单直接
   • 4L： 喜欢、学到、缺少、期望
   • 愤怒／悲伤／高兴： 聚焦情绪
   • 帆船： 视觉隐喻（风 = 助力，锚 = 阻碍）

3. 收集意见 收集团队所有成员的观察和意见。确保每个人都参与。沉默寡言的成员往往也有重要见解。将相似内容归类，以识别主题。

4. 讨论并确定优先级 不要试图解决所有问题。将讨论重点放在影响最大的事项上。通过投票或讨论，确定最优先处理的 2-3 个问题。

5. 明确行动事项 将见解转化为具体、可分派的行动。每项行动都需要指定负责人和截止日期。避免使用“加强沟通”之类含糊的改进措施。

6. 检查以往行动 检查上次回顾中行动事项的进展。庆祝已完成的事项，并讨论未完成事项的阻碍。这有助于建立责任意识。

7. 记录以供日后参考 记录要点，方便未来的团队成员查阅，并追踪一段时间内出现的模式。

项目记忆约定

仅当 .claude/pm-skills.local.md 存在时生效。若该文件不存在，则完全忽略本节， 并严格按照上述说明执行。

• 读取： 最近的 artifacts[] 条目，让回顾能够查看本周期实际产出的内容，而非依赖回忆。
• 写入： 将经验教训作为 interpretation artifact 写入。
• 处理方式： 提出条目并等待确认后再写入，除非设置了 memory_auto_append: true；若已设置，则追加并回显写入的内容。
• 写入纪律： 写入前立即重新读取文件，切勿使用生成提案时所依据的副本。如果文件期间发生了变化，应将条目合并到当前状态并重新提出，而不是覆盖文件；只添加自己的条目，并保持其他所有字段和章节逐字节不变。运行时没有任何机制强制执行此要求，而且该文件已被 git 忽略，因此草率地重写整个文件会丢失其他会话的工作，且无法恢复。

回顾会同时呈现原始观察、模式和承诺。请将其中持久有效的部分——经验教训——记录在单一标签下；下游读者需要知道应当在多大程度上重视该条目，而混合标签无法提供任何这类信息。

输出格式

使用 references/TEMPLATE.md 中的模板来组织输出。完整的回顾应填写模板中的每个部分：概述；上次回顾复盘；进展顺利之处；待改进之处；讨论记录；行动项；暂存事项；指标与趋势；主持人备注；以及下次回顾。

质量检查清单

定稿前，请确认：

• 所有参会者都有机会参与
• 已记录做得好的方面和待改进之处
• 行动项均注明负责人和截止日期
• 已复盘上次回顾中的行动项
• 即使读者未参加回顾，也能仅凭本文档了解已作出的决定以及每项行动的负责人

示例

已完成的示例请参阅 references/EXAMPLE.md。