1. 一个具体问题
一次项目复盘会上，大家轮流说“沟通不足”“加强责任心”“下次提前准备”，会后文档归档，下一次项目仍然在同一个交接点出错。团队花时间回顾了过去，却没有说明具体哪项工作会改变，也没有人负责检验改变是否有效。
2. 一句话解释
团队复盘是共同重建事实、理解结果形成过程，并选择下一轮改进试验的活动，价值在于改变后续行为而非写出漂亮总结。
3. 出处与原意
事后回顾广泛存在于军事、项目管理和组织学习实践。软件团队熟悉的 Sprint 回顾在《Scrum 指南》中具有明确位置，用于计划提升质量与有效性的办法。不同复盘形式并无唯一通用流程，也不能把所有项目总结都归属于某一框架；共同核心是从实际经历中学习。
4. 原理与机制
先明确讨论范围和基本约定，再建立事件时间线，区分观察、解释与评价。寻找当时的信息、约束和决策依据，避免事后把结果看成显而易见。讨论既包括失误也包括成功，最后只选择少量可控行动，注明负责人、预期影响和检查时间。对人员违规的正式调查应有相应程序，不能让公开复盘变成临时审判。
行动数量需要受执行能力限制。一次会议列出十几项整改，看起来全面，却可能没有任何一项真正落实。每项行动应能回答怎样看出有效，若只是“加强沟通”，就继续细化为谁在什么触发条件下提供哪条信息。
5. 一个完整案例
以下是假设案例。一个活动页面晚两天发布。团队先还原事实：周一需求冻结，周三运营新增优惠规则，周四测试发现旧价格缓存，周五修复完成。大家没有停在“需求总变化”，而是发现变更消息只发在聊天群，测试清单和缓存策略未同步。团队决定下次变更必须在同一个记录中更新验收条件，指定变更发起人与测试共同确认，并在发布前检查价格缓存。两周后的活动按时上线，但确认流程增加了半天等待。复盘因此继续调整为对价格相关变更强制确认，其他改动简化处理；行动需要评估副作用，不能因为来自复盘就永远保留。
6. 适用条件与反例
适合有共同工作经历、还能影响下一轮流程的团队。资料缺失时应承认无法确定的部分，不用最响亮的回忆替代事实。反例是领导先宣布“这次就是某人不认真”，再要求大家开放讨论；结论已被权力固定，成员很难提供相反证据，复盘会变成对既定判断的附和。
7. 今天可以尝试的行动
为最近一次小交付安排三十分钟，提前收集三个时间点和一项实际结果。会议中问“当时为什么这个选择看起来合理”，最后只选一个下周可试的改动。下一次会议先查看旧行动的结果，再决定是否增加新行动。