本节书摘来自华章出版社《SAFe 4.0参考指南：精益软件与系统工程的规模化敏捷框架》一书中的第3章，第3.12节 作者［美］迪恩·莱芬（DeanLeffingwell），更多章节内容可以访问云栖社区“华章计算机”公众号查看。
3.12 迭代回顾
团队定期地反思如何能提高成效，并依次调整自身的举止表现。
——敏捷宣言
摘要
在每个迭代结束时，采用Scrum框架的敏捷团队成员会聚集起来举行一次迭代回顾会议（有时看板团队也会进行回顾），在回顾中讨论他们所采取的实践，以及如何改进。每次回顾的时间盒是1小时或更短的时间，团队在回顾时需要总结“哪些工作做得好”“哪些工作做得不好”和“哪些工作下一次可以通过改进做得更好”。
每次回顾都包括定量和定性两个方面。定量评审是收集和审查团队所使用的指标并度量其绩效；定性部分会讨论在最近的1～2个迭代中团队所采用的各种实践方法和所面临的挑战。当问题已经被识别出来，也分析了根本原因，讨论了潜在的纠正措施后，就会把改进故事放入团队待办事项列表中。
详述
敏捷团队通过迭代回顾来省思已完成的迭代，并获取新的想法用以改进迭代的过程。这有助于在个人和团队中贯彻持续改进的概念，持续改进也是SAFe精益–敏捷思维的支柱之一。迭代回顾还有助于确保每一次迭代过程中，对团队的流程都进行一些小的改进。
回顾过程需要整个团队的参与，他们与Scrum Master一起，通过应用工具和流程，进行数据采集和问题解决。团队实施的回顾分为两部分：定量部分和定性部分。
定量评审
团队评估他们是否达成了迭代目标，这是一个二元的评定标准，答案为“是”或“否”。他们也同时收集那些已商定的分析标准，比如团队速度，通常包括两部分内容：一部分用于新功能的开发，另一部分致力于已有功能的维护，二者缺一不可。
敏捷团队收集和应用其他可视化的迭代指标，并帮助其过程改进。同时这些数据也可以作为输入，用于后续的定性研究。
定性评审
首先，团队评审那些在以前的回顾中已经识别出来的改进故事的完成情况，然后分析流程现状，并把焦点放在找到他们下一次迭代可以做得更好的1～2件事情上。由于许多改进的故事所涉及的范围较大，所以团队应该将它们划分为更小的改进故事，从而使团队能够专注于在一个迭代中的具体改进工作。
关于迭代成功的几种流行的主观反馈技术如下（参考资料[1]）：
个人——每个人写下记事贴，分小组找出其中的规律
欣赏——记录下是否有人曾经帮助过你，或者帮助过团队
概念——选择一个词语来描述本次迭代
评分——迭代评分范围为1～5分，给本次迭代打分，然后集体讨论如何使下一次迭代达到5分
简单——列出3列内容，然后开放性讨论
以上最后一种方法比较常用，由Scrum Master在纸上画出3列内容，分别是 “做得好的”（What Went Well）“做得不好的”（What Didn’t）和“下次可以做得更好的”（Do Better Next Time），然后开始进行开放性头脑风暴会议。这种方法执行简单，而且使得所有成就和挑战都清晰可见，如图31.12-1所示。
议程
一个迭代回顾议程的示例如下。
第一步：定量
团队是否达到迭代目标（是/否）？收集和评审团队已商定的迭代指标。
第二步：定性
回顾上一次迭代中的改进故事。它们都完成了吗？如果没有，我们需要针对这些改进故事做些什么？
对于本次迭代，进行分析：
哪些是做得好的？
哪些是做得不好的？
哪些是我们可以在下一次做得更好的？
指导原则
以下是成功进行迭代回顾的一些小提示：
保持会议的时间盒在1小时或更短的时间。请记住，每两周举行一次会议，目标必须足够小，按照持续改进的步骤进行。
只挑选1～2件可以在下次做得更好的事情，并将其作为改进故事，在下一次迭代中进行实施。
确保每一个人都发言。
Scrum Master应该花费时间准备回顾会议，因为它是迭代改进的主要手段。
聚焦在团队可以处理的改进项上，而不是那些无法解决的内容。
确保在迭代回顾开始时，进行定量评审的过程中，对前一个迭代中的改进故事进行评审并查看其进展情况。
迭代回顾是一个团队的内部会议，应该只限于团队成员参与。
参考资料
[1] Derby, Esther and Diana Larson. Agile Retrospectives: Making Good Teams Great. Pragmatic Bookshelf, 2006.
[2] Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007, Chapter 15, “Regular Reflection and Adaptation.”
