摘要：回顾是指团队随时对过去进行反思，以改进未来的工作表现。无论是技术团队还是非技术团队，都可以对几乎任何内容进行回顾！
Agile retrospectives have been a cornerstone of continuous improvement since 2001, when the Agile Manifesto introduced the principle of regular team reflection: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”
This practice encourages teams to pause, assess what’s working, and identify opportunities for growth—ensuring that progress isn’t just about delivering software, but about evolving how teams work together.
While retrospectives are most often associated with software development teams, their value extends far beyond the software industry. Now, more teams are adopting these principles and seeing the benefits of Agile.
Marketing teams review campaign outcomes, management teams reflect on major projects, and even entire organizations use retrospectives to drive industry-wide change. This widespread adoption underscores the significant impact that regular reflection can have on any team wanting better collaboration, morale, and results.
为什么要进行回顾？
2001 年，我们开始了敏捷回顾。敏捷开发十二项原则中最后一项内容如下：
“团队会定期思考如何提高效率，然后相应地调整其行为。”
敏捷宣言明确指出：为了充分践行敏捷价值观，团队应定期开会回顾并进行调整。最常见的是，开发团队通过定期举办回顾会议来应用这一原则，虽然该会议是本页大部分内容的重点，但这并不是唯一的回顾方式。
最近，回顾的概念已经脱离了开发团队，进入了业务和团队合作的各个方面。
我知道营销团队回顾营销活动，管理团队回顾大型演示文稿，更重要的是，Atlassian 针对所在的整个行业进行回顾。这种对回顾的开放态度以及业务各方面激增的回顾，令人非常兴奋。
回顾最让人感到兴奋的是，它们是开始敏捷旅程的地方。敏捷宣言中的许多核心概念都通过回顾性会议得到了加强。考虑以下价值：
个人和交互优先于流程和工具
响应变化优先于遵循计划
从表面上看，这就是回顾的全部意义：与真实的人合作进行变更和改进。没有什么比这更能强化敏捷原则了。既然我们已经知道回顾为何如此重要，请继续阅读并学习如何自己举办回顾会议。
回顾性会议
通过回顾，您的敏捷团队可以进行自我评估并制定计划以解决未来需要改进的领域。回顾通过走出工作周期来反思过去，拥抱持续改进的理念，并防止自满情绪的陷阱：
回顾会议的目的是：
评估上一个冲刺、迭代或工作项目的进展情况，特别是围绕团队动态、流程和工具。
阐明和堆叠对进展顺利的项目以及那些表现不佳的项目进行排名。
制定并实施改善团队工作方式的计划。
回顾为专注于内省和适应提供了一个安全的场所。为了使回顾取得成功，需要营造一种支持性的氛围，鼓励（但不强迫）所有团队成员做出贡献。
对于您的团队来说，回顾应该是一次积极、充满活力的体验。它可以帮助团队成员分享重要的反馈，不受挫折影响，共同努力提出解决方案。主持人还可以从回顾中获得很多好处，包括更好地了解团队如何协作以及他们在上次冲刺中经历了哪些挑战（和成功）。成功的回顾会产生一系列改进，团队成员将在下一次冲刺中掌握并努力实现这些改进。
The retrospective offers a safe space for introspection and adaptation. In order for retrospectives to be successful, there needs to be a supportive atmosphere that encourages (but doesn’t force) all team members to contribute.
The retrospective should be a positive, energizing experience for your team. It helps team members share important feedback, release frustrations, and collaborate to find solutions.
Facilitators can also get a lot from the retrospective, including a better understanding of how the team works together and what challenges (and successes) they experienced in the last sprint. A successful retrospective results in a list of improvements that team members take ownership of and work toward in the next sprint.
如何进行第一次回顾
虽然改变回顾的形式可能是有益的（下文将详细介绍！），某些方面，例如时间、参与者和一般形式，应尽可能保持一致。
时间：
对于在传统的两周冲刺中工作的敏捷团队，回顾应在每个冲刺结束时举行。对于工作风格更像看板的团队来说，每月或每季度进行一次回顾可能更有意义。重大计划推出后，让更多领导层成员参与进来也很合理；注意不要关注交付的内容，而要关注团队如何共同努力产生这些成果。
计划花费至少三十分钟，最多一个小时，具体取决于冲刺的时间和您必须覆盖的量。
人员：
每位团队成员都应参加回顾，由主持人主持讨论。主持人可以是 Scrum 大师、产品负责人，也可以由团队成员轮流担任。设计人员、营销人员或其他为当前冲刺或迭代做出贡献的人均可自由参加。
内容：
有几种方法可以混合您的回顾（我们将在下面讨论），但以下是回顾性会议的基本模板：
创建一份简短的列表，列出行之有效的内容和可以改进的内容。此列表可以在白板上、Atlassian Confluence 页面上创建，甚至可以在墙上的便利贴上创建！无论您在哪里捕捉到最初的反馈，一定要在会议结束后立即记住，供以后参考。
按团队的重要性来确定此列表的优先级。您可能会发现一些共同的主题，这些主题可以组合在一起。
讨论“改进余地”列表上前两项的改进方法和策略。关注结果，而不是操作、人或过去。
制定行动计划。会议结束时，团队应该提出一些可行的想法，明确负责人和到期时间，以解决需要改进的领域。
严格执行第四条。没有什么比在每一次回顾中重复同样的障碍更令人沮丧的了。确保每个人都有明确知道后续步骤，从而避免停滞（和沮丧！）。回顾中确定的每个操作项目都应有一个明确的负责人，负责跟踪直到项目完成。
因为多样性让生活更美好
实现回顾标准化是一个好主意，可以随着时间的推移在团队之间建立一致性并构建信任。但是，主持人可以尝试一些“调整”，这些调整可能有助于发现更多洞察信息，鼓励新团队成员的参与，或者只是保持其趣味性。
请一位外部主持人。通常，回顾由 Scrum 大师或项目主管主持，但您可以考虑邀请一位嘉宾来主持下一次回顾。如果让没有“项目相关利益”的人来主持讨论，动态可能会发生积极的变化。此外，这种策略使组织内的其他人能够观察其他敏捷团队的工作情况，并可能为自己的团队选择一些最佳实践。
改变列表提示。归根结底，回顾旨在揭示哪些方案有效，哪些无效。请考虑以下不同的提示：
开始/停止/继续：团队应该开始做什么、停止做什么，然后继续做什么。关注停止“停止”列中的项目的方法。
多/少：团队需要多做和少做的事情。围绕如何处理“少做”列表中的热门项目制定计划。
高兴/悲伤生气：什么让团队感到高兴、悲伤和生气。猜对了，重点关注悲伤和生气的列表以及如何改进，这样下次就只有高兴一列有项目了。
让领导层参与进来。重大项目推出后，与您的领导团队成员安排一个小时，重点关注团队的合作方式（而不是计划进展的细节）。
有很多方法可以改进，所以不要犹豫，寻找自己的新技巧。无论您是想让分散的团队参与进来，还是要改进停滞不前的回顾流程，关键是要保持团队的参与度并使结果切实可行。
摘要：回顾是指团队随时对过去进行反思，以改进未来的工作表现。无论是技术团队还是非技术团队，都可以对几乎任何内容进行回顾！
Agile retrospectives have been a cornerstone of continuous improvement since 2001, when the Agile Manifesto introduced the principle of regular team reflection: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”
This practice encourages teams to pause, assess what’s working, and identify opportunities for growth—ensuring that progress isn’t just about delivering software, but about evolving how teams work together.
While retrospectives are most often associated with software development teams, their value extends far beyond the software industry. Now, more teams are adopting these principles and seeing the benefits of Agile.
Marketing teams review campaign outcomes, management teams reflect on major projects, and even entire organizations use retrospectives to drive industry-wide change. This widespread adoption underscores the significant impact that regular reflection can have on any team wanting better collaboration, morale, and results.
为什么要进行回顾？
2001 年，我们开始了敏捷回顾。敏捷开发十二项原则中最后一项内容如下：
“团队会定期思考如何提高效率，然后相应地调整其行为。”
敏捷宣言明确指出：为了充分践行敏捷价值观，团队应定期开会回顾并进行调整。最常见的是，开发团队通过定期举办回顾会议来应用这一原则，虽然该会议是本页大部分内容的重点，但这并不是唯一的回顾方式。
最近，回顾的概念已经脱离了开发团队，进入了业务和团队合作的各个方面。
我知道营销团队回顾营销活动，管理团队回顾大型演示文稿，更重要的是，Atlassian 针对所在的整个行业进行回顾。这种对回顾的开放态度以及业务各方面激增的回顾，令人非常兴奋。
回顾最让人感到兴奋的是，它们是开始敏捷旅程的地方。敏捷宣言中的许多核心概念都通过回顾性会议得到了加强。考虑以下价值：
个人和交互优先于流程和工具
响应变化优先于遵循计划
从表面上看，这就是回顾的全部意义：与真实的人合作进行变更和改进。没有什么比这更能强化敏捷原则了。既然我们已经知道回顾为何如此重要，请继续阅读并学习如何自己举办回顾会议。
回顾性会议
通过回顾，您的敏捷团队可以进行自我评估并制定计划以解决未来需要改进的领域。回顾通过走出工作周期来反思过去，拥抱持续改进的理念，并防止自满情绪的陷阱：
回顾会议的目的是：
评估上一个冲刺、迭代或工作项目的进展情况，特别是围绕团队动态、流程和工具。
阐明和堆叠对进展顺利的项目以及那些表现不佳的项目进行排名。
制定并实施改善团队工作方式的计划。
回顾为专注于内省和适应提供了一个安全的场所。为了使回顾取得成功，需要营造一种支持性的氛围，鼓励（但不强迫）所有团队成员做出贡献。
对于您的团队来说，回顾应该是一次积极、充满活力的体验。它可以帮助团队成员分享重要的反馈，不受挫折影响，共同努力提出解决方案。主持人还可以从回顾中获得很多好处，包括更好地了解团队如何协作以及他们在上次冲刺中经历了哪些挑战（和成功）。成功的回顾会产生一系列改进，团队成员将在下一次冲刺中掌握并努力实现这些改进。
The retrospective offers a safe space for introspection and adaptation. In order for retrospectives to be successful, there needs to be a supportive atmosphere that encourages (but doesn’t force) all team members to contribute.
The retrospective should be a positive, energizing experience for your team. It helps team members share important feedback, release frustrations, and collaborate to find solutions.
Facilitators can also get a lot from the retrospective, including a better understanding of how the team works together and what challenges (and successes) they experienced in the last sprint. A successful retrospective results in a list of improvements that team members take ownership of and work toward in the next sprint.
如何进行第一次回顾
虽然改变回顾的形式可能是有益的（下文将详细介绍！），某些方面，例如时间、参与者和一般形式，应尽可能保持一致。
时间：
对于在传统的两周冲刺中工作的敏捷团队，回顾应在每个冲刺结束时举行。对于工作风格更像看板的团队来说，每月或每季度进行一次回顾可能更有意义。重大计划推出后，让更多领导层成员参与进来也很合理；注意不要关注交付的内容，而要关注团队如何共同努力产生这些成果。
计划花费至少三十分钟，最多一个小时，具体取决于冲刺的时间和您必须覆盖的量。
人员：
每位团队成员都应参加回顾，由主持人主持讨论。主持人可以是 Scrum 大师、产品负责人，也可以由团队成员轮流担任。设计人员、营销人员或其他为当前冲刺或迭代做出贡献的人均可自由参加。
内容：
有几种方法可以混合您的回顾（我们将在下面讨论），但以下是回顾性会议的基本模板：
创建一份简短的列表，列出行之有效的内容和可以改进的内容。此列表可以在白板上、Atlassian Confluence 页面上创建，甚至可以在墙上的便利贴上创建！无论您在哪里捕捉到最初的反馈，一定要在会议结束后立即记住，供以后参考。
按团队的重要性来确定此列表的优先级。您可能会发现一些共同的主题，这些主题可以组合在一起。
讨论“改进余地”列表上前两项的改进方法和策略。关注结果，而不是操作、人或过去。
制定行动计划。会议结束时，团队应该提出一些可行的想法，明确负责人和到期时间，以解决需要改进的领域。
严格执行第四条。没有什么比在每一次回顾中重复同样的障碍更令人沮丧的了。确保每个人都有明确知道后续步骤，从而避免停滞（和沮丧！）。回顾中确定的每个操作项目都应有一个明确的负责人，负责跟踪直到项目完成。
因为多样性让生活更美好
实现回顾标准化是一个好主意，可以随着时间的推移在团队之间建立一致性并构建信任。但是，主持人可以尝试一些“调整”，这些调整可能有助于发现更多洞察信息，鼓励新团队成员的参与，或者只是保持其趣味性。
请一位外部主持人。通常，回顾由 Scrum 大师或项目主管主持，但您可以考虑邀请一位嘉宾来主持下一次回顾。如果让没有“项目相关利益”的人来主持讨论，动态可能会发生积极的变化。此外，这种策略使组织内的其他人能够观察其他敏捷团队的工作情况，并可能为自己的团队选择一些最佳实践。
改变列表提示。归根结底，回顾旨在揭示哪些方案有效，哪些无效。请考虑以下不同的提示：
开始/停止/继续：团队应该开始做什么、停止做什么，然后继续做什么。关注停止“停止”列中的项目的方法。
多/少：团队需要多做和少做的事情。围绕如何处理“少做”列表中的热门项目制定计划。
高兴/悲伤生气：什么让团队感到高兴、悲伤和生气。猜对了，重点关注悲伤和生气的列表以及如何改进，这样下次就只有高兴一列有项目了。
让领导层参与进来。重大项目推出后，与您的领导团队成员安排一个小时，重点关注团队的合作方式（而不是计划进展的细节）。
有很多方法可以改进，所以不要犹豫，寻找自己的新技巧。无论您是想让分散的团队参与进来，还是要改进停滞不前的回顾流程，关键是要保持团队的参与度并使结果切实可行。