摘要：回顾是指团队随时对过去进行反思，以改进未来的工作表现。无论是技术团队还是非技术团队，都可以对几乎任何内容进行回顾！
什么是敏捷回顾？它们为何重要？
敏捷回顾是团队定期召开的会议，旨在反思近期工作，包括做得好的方面、可改进的领域，以及如何推动积极变革。
这类会议至关重要，因为回顾能促进开放沟通、鼓励持续改进，并帮助团队调整工作方式以获得更好的协作效果和成果。通过留出时间学习和调整，团队能更有效地开展工作，交付更高质量的成果。
从表面上看，这正是敏捷回顾的核心—与真实的团队成员共同推动变革与改进。没有什么比这更能强化敏捷原则了。
回顾性会议
回顾是敏捷团队进行自我评估并制定计划以解决未来需要改进领域的绝佳机会。回顾秉持持续改进的理念，通过跳出工作周期反思过往，避免团队陷入自满的陷阱。
回顾会议的目的是：
评估上一个冲刺、迭代或工作项目的进展情况，特别是围绕团队动态、流程和工具。
阐明和堆叠对进展顺利的项目以及那些表现不佳的项目进行排名。
制定并实施改善团队工作方式的计划。
回顾为团队提供了一个用于内省和调整的安全空间。为了使回顾取得成功，需要营造一种支持性的氛围，鼓励（但不强迫）所有团队成员做出贡献。
对于您的团队来说，回顾应该是一次积极、振奋的体验。它能帮助团队成员分享重要反馈、释放挫败情绪，并协作寻找解决方案。
主持人还可以从回顾中获得很多好处，包括更好地了解团队如何协作以及他们在上次冲刺中经历了哪些挑战（和成功）。成功的回顾会产生一系列改进，团队成员将在下一次冲刺中掌握并努力实现这些改进。
如何进行第一次回顾
虽然改变回顾的形式可能是有益的（下文将详细介绍！），某些方面，例如时间、参与者和一般形式，应尽可能保持一致。
时间：
对于在传统的两周冲刺中工作的敏捷团队，回顾应在每个冲刺结束时举行。对于工作风格更像看板的团队来说，每月或每季度进行一次回顾可能更有意义。重大计划推出后，让更多领导层成员参与进来也很合理；注意不要关注交付的内容，而要关注团队如何共同努力产生这些成果。
计划花费至少三十分钟，最多一个小时，具体取决于冲刺的时间和您必须覆盖的量。
人员：
每位团队成员都应参加回顾，由主持人主持讨论。主持人可以是 Scrum 大师、产品负责人，也可以由团队成员轮流担任。设计人员、营销人员或其他为当前冲刺或迭代做出贡献的人均可自由参加。
内容：
有几种方法可以混合您的回顾（我们将在下面讨论），但以下是回顾性会议的基本模板：
创建一份简短的列表，列出行之有效的内容和可以改进的内容。此列表可以在白板上、Atlassian Confluence 页面上创建，甚至可以在墙上的便利贴上创建！无论您在哪里捕捉到最初的反馈，一定要在会议结束后立即记住，供以后参考。
按团队的重要性来确定此列表的优先级。您可能会发现一些共同的主题，这些主题可以组合在一起。
讨论“改进余地”列表上前两项的改进方法和策略。关注结果，而不是操作、人或过去。
制定行动计划。会议结束时，团队应该提出一些可行的想法，明确负责人和到期时间，以解决需要改进的领域。
严格执行第四条。没有什么比在每一次回顾中重复同样的障碍更令人沮丧的了。确保每个人都有明确知道后续步骤，从而避免停滞（和沮丧！）。回顾中确定的每个操作项目都应有一个明确的负责人，负责跟踪直到项目完成。
因为多样性让生活更美好
实现回顾标准化是一个好主意，可以随着时间的推移在团队之间建立一致性并构建信任。但是，主持人可以尝试一些“调整”，这些调整可能有助于发现更多洞察信息，鼓励新团队成员的参与，或者只是保持其趣味性。
请一位外部主持人。通常，回顾由 Scrum 大师或项目主管主持，但您可以考虑邀请一位嘉宾来主持下一次回顾。如果让没有“项目相关利益”的人来主持讨论，动态可能会发生积极的变化。此外，这种策略使组织内的其他人能够观察其他敏捷团队的工作情况，并可能为自己的团队选择一些最佳实践。
改变列表提示。归根结底，回顾旨在揭示哪些方案有效，哪些无效。请考虑以下不同的提示：
开始/停止/继续：团队应该开始做什么、停止做什么，然后继续做什么。关注停止“停止”列中的项目的方法。
多/少：团队需要多做和少做的事情。围绕如何处理“少做”列表中的热门项目制定计划。
高兴/悲伤生气：什么让团队感到高兴、悲伤和生气。猜对了，重点关注悲伤和生气的列表以及如何改进，这样下次就只有高兴一列有项目了。
让领导层参与进来。重大项目推出后，与您的领导团队成员安排一个小时，重点关注团队的合作方式（而不是计划进展的细节）。
有很多方法可以改进，所以不要犹豫，寻找自己的新技巧。无论您是想让分散的团队参与进来，还是要改进停滞不前的回顾流程，关键是要保持团队的参与度并使结果切实可行。