Sprint 回顾会是团队定期审视自身工作方式和规划改进的机会。它在评审之后、下一个 Sprint 计划之前进行。重点是流程 — 人员、关系、工具和完成的定义 — 而不是产品本身。
它是如何运作的
一个简单、流行的结构：
text
1. What went well? (keep doing)
2. What didn't? (problems and friction)
3. What will we change? (1-2 concrete, owned actions)
关键输出是少量可行的改进，最好将其添加到下一个 Sprint 待办事项中，这样它们才能真正发生。
具体例子
团队注意到代码审查停滞了数天。他们同意了一条规则：审查请求应在四小时内处理。一个人负责发送提醒。在下一个回顾会上，他们检查是否有效。
常见陷阱
- 生成 15 个行动项目但什么都不做 — 只选一两个。
- 责备而非好奇心，这会破坏心理安全感。
- 在截止日期压力下跳过它，这会移除改进引擎。
为什么这很重要
持续改进是将每个 Sprint 都变得更好的团队与重复同样错误的团队区分开来的原因。
一个安全、专注的回顾会将挫折转化为具体的改变，这正是实证主义的全部意义。