我始终记得当年我作为敏捷教练所做的第一次Sprint回顾，这一切都仿佛就发生在昨天。这家公司实行Scrum有好几年了，我自然而然地认为他们这群人是纪律严明并且成熟稳重的敏捷专家。
因此，当他们计划了一系列Sprint回顾会议，用来展示X团队最新Sprint成果时，我感到异常兴奋。我早早地溜进了会议室，并为自己找了个绝佳的位子坐下，翘首以盼。
渐渐地会议室里的人越来越多，并变得嘈杂起来，这反而使我的期望到达顶点，我知道好戏就要开演了。这时，第一个团队登上了“舞台”，准备他们的回顾，他们打开PowerPoint做的幻灯片，“演出”终于开始了！
第一个团队准备的材料实在是精挑细选，他们准备了在这个Sprint中他们所完成的事情的列表，还配了插图，甚至还准备了些在适当时刻调节气氛的小笑话。他们一一讲述团队所做的工作，一页接一页地翻动着幻灯片，在恰当的时机，听众也不失时宜地礼貌地鼓掌以表示对他们的赞许。
然而，当第一场回顾进行到一半的时候，我意识到似乎有非常、非常重要的东西被遗漏掉了，怎么没有代码演示呢？我心中感慨，这样的错误怎么会发生在这样一群成熟且经验丰富的敏捷专家身上呢？整个Sprint回顾的最终目的就在于向各位利益相关者展示这个Sprint所完成的代码，并得到大家的反馈。当时我想，也许这只是一个特例，只是被这个团队疏忽了，接下去肯定会有代码演示。
然而，我期待的事情并没有发生，之后的每一个团队使用着跟第一个团队相同的模式——风趣幽默的幻灯片和文字，对他们的工作量进行说明，并没有代码演示，这让我的热情迅速耗尽， 也让我彻底失望。
对于整个团队而言，还有那些诠释过Sprint回顾意义的人而言，显而易见地是，他们并没有真正理解Sprint回顾的意义。当然，利益相关者也没能理解这么做的目的，他们仍然对那些设计好的笑点礼貌地回应，并鼓掌肯定团队的工作，似乎这个仪式仅仅是为了给Scrum流程列表上的这一项打上个勾而已。
千万杜绝！
在此后的Sprint回顾中，毋庸置疑的是，我再也不会让这类事情发生了。我很敬佩这些团队的自主精神，但我仍然立即列出了今后Sprint回顾应该完成的目标以及如何实现这些目标的纲领。
纲领中的某些项目跟敏捷宣言（Agile Manifesto）非常合拍，例如在每个迭代或Sprint结束时进行代码演示的理念，但有些项目却是我们的组织以及企业文化中特有的。
这才是文章的重点。我打算与大家分享，我们当时是如何转变Sprint回顾的主要纲领、战略以及心态的，正如：
- 从礼节性地鼓掌转变到热烈地欢呼
- 从礼节性地鼓掌转变到获得有建设性的反馈
- 从兜售我们的成果转变到让成果变成真实透明
- 从小众群体参与转变到大众站立方式并运用录影
- 从幻灯片转变到代码演示
- 从娱乐大众的心态转变到展示团队能力及产品价值
- 从“授课”形式的演示转变到有交流、有互动的形式
- 从刻意兜售我们的成果转变到“姜太公钓鱼，愿者上钩”、让事实说话的形式
当然，冰冻三尺非一日之寒，这些不会马上发生，我们仍然在日复一日持续对我们的Sprint回顾进行着调整和优化。幸运的是，我们当真找到了一些门路，使之成为贯穿组织架构中实施敏捷流程的基础。 让我来分享几件我们用心做的事情吧。
“出色”的Sprint回顾
总体来说，我认为Sprint回顾非常重要，之所以这么说是因为：
- 一个敏捷团队为世界上最重要的故事（story）专心工作了一段时间，并准备交付与之相关的功能或故事。单从这点上看，回顾就足够重要，人们的目光都聚集在这里，大家渴望见到成果，所以你必须满足你的“观众”。
- 团队有义务展示他们的工作成果，但这不单单停留在代码演示，团队应该站出来讲述围绕他们的工作所发生的故事。这可以是图文并茂的，伴有情节的，而且这必须与上一次的Sprint回顾有联系，并对下一次的Sprint回顾做出铺垫。
接下去我将为大家分享Sprint回顾的7个最重要的方面以及一个简单的回顾会议日程。我希望这些建议能帮助大家改进你的Sprint回顾，能更有效地拉拢你的利益相关者，并更全面、更充满激情地展示你的团队。
Sprint回顾的7招绝杀
-
职责
在每次Sprint回顾中，我们都会建立起一种产品负责人对此全权负责的理念。诚然，这是每个团队成员的事情，但在每天工作结束时，产品负责人会负责进行外部沟通、展示计划中所交付的代码，以及对收集到的反馈意见进行相应地调整。他们还负责把大家找来做回顾——如果与会者参差不齐，人数稀少（小众参与），他们就必须找到问题所在并做出相应改变，让“合适的”人聚到会议室里进行Sprint回顾（大众站立式）。 我时常把产品负责人比作典礼的主持人——他们负责引导Sprint回顾的各个方面。当然他们不需要事事亲历亲为，但他们需要把握总体的回顾质量，考虑回顾的重点以及对回顾的成果负责。 -
形式
我们对回顾的日程安排以及时间控制出了很多主意（如果你置身于多个Sprint团队，那么也可以是多个Sprint的回顾）。你肯定希望你的回顾具有固定的节奏（时间与间隔），在进行Spring内容回顾时，你也肯定希望每个团队都遵从统一的流程（之后的章节将给出回顾会议日程安排的例子）。 在我们的案例中，由于我们有多个Sprint，并且是同步的，我们在同一天演示多支团队的成果，因此我们的回顾形式有一种跨团队的日常安排，将3个小时的回顾会议合理地分配给每个团队。我们不仅对每个团队的回顾做出安排，更重要的是，我们的首席产品负责人对每个团队的回顾流程进行统一的节奏掌控。 -
Sprint目标
就个人而言，我更倾向于Sprint回顾主动地去契合团队成员都认同的Sprint目标。我经常嘱咐我的团队，当他们在制定Sprint目标的时候，多想一想如何撰写他们需要发送的回顾邀请邮件。这个Sprint的故事就会契合Sprint目标，团队成员也将采取相应的行动来达到Sprint目标。另外，你必须对团队所要承诺的Sprint交付物100%的诚实，你必须告诉大家成功了或是失败了。但千万不要让“失败”这个词把大家都吓坏了，失败乃成功之母，它是团队自我学习的一部分，也是整个组织保持一种“向失败学习，不被其打败”的积极态度的重要组成部分。
-
人人参与
正如我所说，我崇尚把产品负责人当作整个典礼的主持人，那么Scrum Master则是协调者（如果需要的话），而整个团队才是真正的大明星。给予你的团队成员一个表现自己的机会，让他们站出来展示他们的成果。人人参与的方式，将给予你的团队足够的表现空间——让团队成员轮流地去做代码演示，这样一来，每个人都有机会为大家演示自己的劳动成果。但必须记住，不要强迫性格内向的成员去做大范围的演讲，你可以鼓励每个团队成员去表现，但这必须不是强制性的。通常，性格内向的成员可以成为演示的参与者，他们是很好的聆听者，安静地参与回顾。但是，你必须要鼓励团队的每个成员积极参与回顾。
-
准备 如果说什么是成功的Sprint回顾秘诀，那就是之前的准备工作了——别放太多的内容，也别过于简单了，把握好这个度。你必须去思考，什么内容是和这次Sprint回顾相关的；回顾应该以怎样的流程进行下去；你还要去想，这次回顾如何与前一次，后一次的回顾相互呼应。
通常，有着质量保障（Quality Assurance）背景的人会提前写一个回顾的“脚本”，帮助自己更紧凑地揭示工作成果。但最终，产品负责人才是决定回顾哪些内容，以及为什么做这些回顾一锤定音的人，他为利益相关者搭建好回顾的“舞台”。
如果有疑问，在Sprint计划阶段就给回顾的准备留出足够的时间，并认真地去做准备。
-
执行与演示 你需要保证整个回顾演示必须是顺畅的、有思想的、精心商榷的，并且最终的软件是可以无差错地工作。你需要执行试运行（Dry-running）演示，并确保所有代码环境都事先调试通过。你还必须计算好演示的时间，保证不会超过预留给你的时间，同时也不要忘记提问部分。
除了演示，你最好能描述一下你所开发的功能特性或工作流。我曾见过一些团队在他们的第一次Sprint回顾中就给出了他们在未来6次Sprint所规划的工作的架构图。在此后的每一次Sprint回顾，他们只需做做简单的“填空游戏”就能把他们的应用程序架构附上“皮肉”（意指代码实现）。我觉得这是一种非常好的方法，能够帮助回顾会议的听众涉点及面。
在我看来，团队在一个Sprint中涉及的所有工作都可以在Sprint回顾中被展示，这包括：功能特性、功能改进、Bug修复、重构、文档、测试架构等等，任何工作都可以放进来。当然有些东西可能要等到一定的程度才能拿得出，但只要是团队做的，都可以成为回顾的内容之一。
最后，考虑好如何描述清楚你的演示，让你的听众能够理解你所演示的内容，内容的关键部分，以及团队在这些内容背后的辛苦付出。
-
总结 最后，我们总是对两个方面进行回顾总结——软件本身的反馈意见以及回顾会议的反馈意见。例如：这个过度是否平稳？所有人都明白我们做的东西了吗？你清楚如何向我们提供反馈意见了吗？下一次回顾有什么地方需要改进吗？我们通常都会在这个阶段花上几分钟，但这几分钟绝对超值！如果你对举手表决（Fist-of-Five）的理念比较熟悉的话，我们通常使用这个方法来结束反馈过程。
回顾会议日程安排举例
你可以考虑将以下作为你的团队Sprint回顾会议日程安排的模板：
-
介绍
-
组织架构
- 团队成员角色：名字、角色、工作地点等
- 对Sprint提供帮助的外部成员
-
工作认可——感谢
- 这个绝对是团队成员的出彩时间
- 这也是对Sprint提供帮助的外部成员的工作进行认可的好时机
-
Sprint目标
- 阐明Sprint目标，以及有何调整
- 宣布Sprint是否成功，团队成员是否兑现承诺
-
战略目标、成功定义、工作量、新发现、成果
- 分享团队交付的代码所考虑到的整体战略目标
- 围绕Sprint幕后的工作量
- 是否有考虑不周全的地方；关键的成果
- 所有这些都为回顾会议的听众提供了一个了解团队Sprint幕后故事的机会
-
演示、提问时间
- 演示所选择的用户故事集以及功能特征——接受提问
-
未来议项
- 宣布现行目标的进程以及未来Sprint所涉及的工作
-
回顾改进意见的举手表决（Fist-of-Five）
- 鼓励回顾会议的听众对团队的表现进行反馈
- 结束
总结
我无法用语言表达一次高质量的Sprint回顾将带给你何种感受，这需要你亲身去感受。尽管产品负责人及团队很大程度地左右着回顾成果，但作为敏捷项目的项目经理，你同样扮演着至关重要的角色。 通常，团队成员在努力工作时被抓出来，仓促地准备Sprint回顾。事实上，这么做是典型的反例。你必须在Sprint计划时就嘱咐团队留出相应的时间给Sprint回顾，并且在Sprint即将完成的时候，善意地提醒他们，做好Sprint回顾的准备工作。
请记住，这个回顾会议也是团队能力的一个“质量检查点（QA Checkpoint）”。将各项工作放在一起并演示出来，无疑是提高团队Sprint能力的最佳途径了。你往往会发现——环境没有准备好、整合没有做好或者交互没有实现等等诸如此类的麻烦事。
因此，各位敏捷项目的项目经理们，我希望这篇文章能够影响你们，使你们发生转变，把Sprint回顾做成敏捷实现中最有利的一种手段，真正担当起Sprint回顾的重任。虽然团队才是做准备及完成交付的人，但你的任务是去影响他们进行回顾的态度与方式。随着项目的进行而不断的进步，你可以将你能获得的正向反馈无限放大，帮助你的团队更好地完成敏捷项目。