标准 Sprint 回顾（开始/停止/继续）
使用场景: Scrum 团队，Sprint 结束后进行回顾
开始：团队应该开始做的事
停止：团队应该停止做的事
继续：团队应该保持的做法
静默书写：5 分钟个人贴便利贴
归组和投票：优先讨论前 2–3 个群组
行动项：每项明确负责人和截止日期
这样组织的原因: 开始/停止/继续是最通用的回顾格式，因为它同时产出正向强化和改进行动——只问问题的格式容易形成抱怨文化，而不是改进文化。
回顾复盘示例
下面这些案例展示了敏捷团队和项目经理用来把团队反思转化为可行改进的复盘格式。每个案例对应不同的场景——从标准 Sprint 回顾到事后故障复盘——找最接近你情况的那个格式直接用。
真实案例
四 L 回顾法
使用场景: 想要比"做得好/需改进"更深入的团队
Liked（喜欢的）：这个 Sprint 你享受什么？
Learned（学到的）：你获得了哪些新认知？
Lacked（缺少的）：什么东西缺失或阻碍了你？
Longed for（渴望的）：你希望有什么但没有？
按列归组便利贴并投票
针对 Lacked 和 Longed for 排名靠前的群组制定行动项
这样组织的原因: Liked 和 Learned 两列往往能发现值得刻意保持的好习惯——只聚焦 Lacked 和 Longed for 的团队错过了有意识强化现有优势的机会。
事后复盘（Post-mortem）
使用场景: 研发或产品团队，复盘一次生产故障或发布失败
时间线：还原事件发生的经过和时间节点
根本原因：是什么让这件事发生的？
响应过程中做得好的地方
流程、工具或监控需要改变什么？
行动项：预防性、检测性和纠正性措施
每条行动项明确负责人和截止日期
这样组织的原因: 不问责的 Post-mortem 聚焦于系统和流程问题，而不是个人失误——时间线还原是最重要的步骤，因为它纠正了导致故障的错误认知。
远程团队回顾
使用场景: 跨时区分布式团队，进行异步和同步混合回顾
异步输入：同步前 24 小时团队提前贴便利贴
第 1 列：什么帮助我们远程协作顺畅？
第 2 列：什么让远程工作更困难？
第 3 列：哪项流程改进最有帮助？
同步会议：归组、讨论、投票
行动项：小而具体，立即可执行
这样组织的原因: 同步前异步收集便利贴，确保比较安静的成员平等参与，同步时间用于讨论而不是书写。
季度团队健康检查
使用场景: 团队 Lead 或研发经理，进行季度 Check-in
维度 1：团队协作与沟通
维度 2：流程与工具
维度 3：代码质量和技术债
维度 4：工作生活平衡和可持续节奏
每个维度评红/黄/绿
每个红/黄维度对应一条行动项
这样组织的原因: 用维度而非开放式问题做季度健康检查，产出的反馈更结构化，也更容易追踪某个维度相比上次是否有改善。
项目收尾复盘
使用场景: 项目经理或团队，结束一个历时数月的项目
最初目标是什么？达成了吗？
哪些决策值得再来一次？
哪些决策让你后悔？
如果从第一天重来，你会做什么不同的事？
哪些知识应该传递给下一个团队？
文档化：记录经验教训和负责人背景
这样组织的原因: 项目收尾复盘在团队解散前把机构知识文档化——关于后悔决策的问题最有价值，也最容易被跳过，只有结构化的格式能保证这部分被认真讨论。
使用技巧
- 群体讨论前先静默个人书写，防止第一个发言的人锚定所有人的输入。
- 每次回顾的行动项限制在两到三条——列太多意味着下次回顾前什么都没做完。
- 每条行动项必须有负责人；没有负责人的行动是意向，不是承诺。
- 每次回顾开始时先回顾上一次的行动项——从不跟进的团队没有动力产出真实的反馈。
在线开始编辑
回到模板页，直接替换成你的课程主题、章节和复习重点，就可以继续使用这套结构。
使用这个模板： /editor/new?template=retrospective-board
使用这个模板