回顾 (Retropective) 是在产品发布后举行的会议，讨论产品开发和发布过程中发生的事情，目的是根据这些学习和对话在未来改进事情。
什么是敏捷回顾 (Agile Retropective)？
那些不从过去吸取教训的人注定在未来重蹈覆辙。这个概念已经被各个学科的许多人所宣扬，产品开发也不例外。
在敏捷环境中，重点主要是快速发布产品并担心接下来会发生什么，因此通常不会对后视镜中已有的内容进行大量讨论。敏捷回顾迫使整个团队停下来反思在特定项目中发生的事情，讨论哪些有效，哪些无效。
会议形式是有效回顾的关键，因为价值来自对话和对话，而不仅仅是一堆个人陈述。每个小组的代表应出席（如果没有，则每个人都参加），每个人都有时间分享他们对经验的看法。这也可以包括营销、销售、客户服务和运营代表。
虽然指出所遇到的缺陷和问题很重要，但同样鼓励参与者提出积极的方面。会议应被视为提出有争议的问题和相反观点的安全场所，以使其尽可能富有成效和洞察力。
这些会议通常由产品管理人员领导，因为他们是组织中最具跨职能的角色，并且对项目期间发生的事情有更广泛的了解。但是，也可以使用公正的第三方主持人来确保每个人都得到平等对待并获得公平的发言时间。
回顾会议 (Retropective Meeting) 的理想结果是什么？
每次回顾可发间这类问题, 例如, “进展顺利的事情”, "是什么导致了问题，无法正常工作或进展不顺利?", “可以改进的事情” 和 "下次我们能做些什么改变呢" 等。这些列表可能不会特别详尽，但每个项目的每一列中可能都有一些突出的项目。
除了提出这些项目之外，讨论还应该揭示这些事情发生的原因。目标是了解如何通过创建新的最佳实践（或加强现有实践）在未来的项目中复制积极的一面，同时确定消极的根本原因，以便在未来预防或减轻它们。
虽然回顾有时可能会遇到必须解决的重大问题，但它们更有可能将重点放在现有流程和习惯的渐进式改进上。我们的目标不是指责和挑剔个人，而是讨论每个人下次可以做得更好、更多或不同。
为了确保没有人感到过于孤立或处于防御状态，回顾应该探索项目的各个方面，从锁定需求到执行营销计划。调度、资源分配、文档、通信、测试……它们都是讨论的可行主题。
虽然这些话题可能会在另一个场合出现，但在回顾中贯穿整个项目的过程让每个人都有机会在一个小组环境中讨论它们，致力于回顾发生的事情，明确的目标是持续改进。
你应该多久举办一次回顾展？
任何重大发布或项目都值得回顾，并且应该在发布后一周内举行，以免人们忘记发生的事情并继续进行下一件事。回顾可以更频繁地举行，包括次要版本、每个 sprint 甚至每天或每周的站立会议。
这些微观回顾可能仅限于一两个主题，但在协作环境中及时处理任何进展顺利（或不顺利）的事件是从错误或成功中吸取教训并在错误或成功的基础上再接再厉的好方法。未来。回顾越频繁，参与者就越有可能提供诚实的反馈并接受他人的想法；如果它们只在发生了非常糟糕的事情之后才发生，它们就会与消极情绪相关联，这不是本意。
结论
回顾是改善团队动态、流程和生产力的宝贵工具。他们可以成为一个很好的平台，用于表达赞美和赞美，以及在事情不那么积极时抱怨和指责。
他们的关键是专注于将这种反馈转化为未来的行动，而不仅仅是“表达不满”——当发现改进时，应该记录并落实，然后在未来的回顾中重新审视，看看它们是否有所作为。最成功的回顾通常包括动摇气氛，要么把东西带到一个新的地方，要么带一些食物或饮料来增加欢乐。
如果参与者对坦诚的反馈感到不自在，他们一开始可能会感到尴尬，但定期重复该过程将培养熟悉度和惯例，从而使该论坛得到更广泛的接受和赞赏。经理和高管应鼓励诚实和透明，加强回顾的“安全空间”方面，并在他人面前进行自我批评。
扫一扫
2811
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
