我始终记得当年我作为敏捷教练所做的第一次Sprint评审，这一切都仿佛就发生在昨天。这家公司实行Scrum有好几年了，我自然而然地认为他们这群人是纪律严明并且成熟稳重的敏捷专家。
因此，当他们计划了一系列Sprint评审会议，用来展示X团队最新Sprint成果时，我感到异常兴奋。我早早地溜进了会议室，并为自己找了个绝佳的位子坐下，翘首以盼。
渐渐地会议室里的人越来越多，并变得嘈杂起来，这反而使我的期望到达顶点，我知道好戏就要开演了。这时，第一个团队登上了“舞台”，准备他们的评审，他们打开PowerPoint做的幻灯片，“演出”终于开始了！
第一个团队准备的材料实在是精挑细选，他们准备了在这个Sprint中他们所完成的事情的列表，还配了插图，甚至还准备了些在适当时刻调节气氛的小笑话。他们一一讲述团队所做的工作，一页接一页地翻动着幻灯片，在恰当的时机，听众也不失时宜地礼貌地鼓掌以表示对他们的赞许。
然而，当第一场评审进行到一半的时候，我意识到似乎有非常、非常重要的东西被遗漏掉了，怎么没有代码演示呢？我心中感慨，这样的错误怎么会发生在这样一群成熟且经验丰富的敏捷专家身上呢？整个Sprint评审的最终目的就在于向各位利益相关者展示这个Sprint所完成的代码，并得到大家的反馈。当时我想，也许这只是一个特例，只是被这个团队疏忽了，接下去肯定会有代码演示。
然而，我期待的事情并没有发生，之后的每一个团队使用着跟第一个团队相同的模式——风趣幽默的幻灯片和文字，对他们的工作量进行说明，并没有代码演示，这让我的热情迅速耗尽， 也让我彻底失望。
对于整个团队而言，还有那些诠释过Sprint评审意义的人而言，显而易见地是，他们并没有真正理解Sprint评审的意义。当然，利益相关者也没能理解这么做的目的，他们仍然对那些设计好的笑点礼貌地回应，并鼓掌肯定团队的工作，似乎这个仪式仅仅是为了给Scrum流程列表上的这一项打上个勾而已。
千万杜绝！
在此后的Sprint评审中，毋庸置疑的是，我再也不会让这类事情发生了。我很敬佩这些团队的自主精神，但我仍然立即列出了今后Sprint评审应该完成的目标以及如何实现这些目标的纲领。
纲领中的某些项目跟敏捷宣言（Agile Manifesto）非常合拍，例如在每个迭代或Sprint结束时进行代码演示的理念，但有些项目却是我们的组织以及企业文化中特有的。
这才是文章的重点。我打算与大家分享，我们当时是如何转变Sprint评审的主要纲领、战略以及心态的，正如：
- 从礼节性地鼓掌转变到热烈地欢呼
- 从礼节性地鼓掌转变到获得有建设性的反馈
- 从兜售我们的成果转变到让成果变成真实透明
- 从小众群体参与转变到大众站立方式并运用录影
- 从幻灯片转变到代码演示
- 从娱乐大众的心态转变到展示团队能力及产品价值
- 从“授课”形式的演示转变到有交流、有互动的形式
- 从刻意兜售我们的成果转变到“姜太公钓鱼，愿者上钩”、让事实说话的形式
当然，冰冻三尺非一日之寒，这些不会马上发生，我们仍然在日复一日持续对我们的Sprint评审进行着调整和优化。幸运的是，我们当真找到了一些门路，使之成为贯穿组织架构中实施敏捷流程的基础。 让我来分享几件我们用心做的事情吧。
“出色”的Sprint评审
总体来说，我认为Sprint评审非常重要，之所以这么说是因为：
1. 一个敏捷团队为世界上最重要的故事（story）专心工作了一段时间，并准备交付与之相关的功能或故事。单从这点上看，评审就足够重要，人们的目光都聚集在这里，大家渴望见到成果，所以你必须满足你的“观众”。
2. 团队有义务展示他们的工作成果，但这不单单停留在代码演示，团队应该站出来讲述围绕他们的工作所发生的故事。这可以是图文并茂的，伴有情节的，而且这必须与上一次的Sprint评审有联系，并对下一次的Sprint评审做出铺垫。
接下去我将为大家分享Sprint评审的7个最重要的方面以及一个简单的评审会议日程。我希望这些建议能帮助大家改进你的Sprint评审，能更有效地拉拢你的利益相关者，并更全面、更充满激情地展示你的团队。
Sprint评审的7招绝杀
1. 职责
在每次Sprint评审中，我们都会建立起一种产品负责人对此全权负责的理念。诚然，这是每个团队成员的事情，但在每天工作结束时，产品负责人会负责进行外部沟通、展示计划中所交付的代码，以及对收集到的反馈意见进行相应地调整。他们还负责把大家找来做评审——如果与会者参差不齐，人数稀少（小众参与），他们就必须找到问题所在并做出相应改变，让“合适的”人聚到会议室里进行Sprint评审（大众站立式）。 我时常把产品负责人比作典礼的主持人——他们负责引导Sprint评审的各个方面。当然他们不需要事事亲历亲为，但他们需要把握总体的评审质量，考虑评审的重点以及对评审的成果负责。
2. 形式
我们对评审的日程安排以及时间控制出了很多主意（如果你置身于多个Sprint团队，那么也可以是多个Sprint的评审）。你肯定希望你的评审具有固定的节奏（时间与间隔），在进行Spring内容评审时，你也肯定希望每个团队都遵从统一的流程（之后的章节将给出评审会议日程安排的例子）。 在我们的案例中，由于我们有多个Sprint，并且是同步的，我们在同一天演示多支团队的成果，因此我们的评审形式有一种跨团队的日常安排，将3个小时的评审会议合理地分配给每个团队。我们不仅对每个团队的评审做出安排，更重要的是，我们的首席产品负责人对每个团队的评审流程进行统一的节奏掌控。
3. Sprint目标
就个人而言，我更倾向于Sprint评审主动地去契合团队成员都认同的Sprint目标。我经常嘱咐我的团队，当他们在制定Sprint目标的时候，多想一想如何撰写他们需要发送的评审邀请邮件。这个Sprint的故事就会契合Sprint目标，团队成员也将采取相应的行动来达到Sprint目标。
另外，你必须对团队所要承诺的Sprint交付物100%的诚实，你必须告诉大家成功了或是失败了。但千万不要让“失败”这个词把大家都吓坏了，失败乃成功之母，它是团队自我学习的一部分，也是整个组织保持一种“向失败学习，不被其打败”的积极态度的重要组成部分。
4. 人人参与
正如我所说，我崇尚把产品负责人当作整个典礼的主持人，那么Scrum Master则是协调者（如果需要的话），而整个团队才是真正的大明星。给予你的团队成员一个表现自己的机会，让他们站出来展示他们的成果。人人参与的方式，将给予你的团队足够的表现空间——让团队成员轮流地去做代码演示，这样一来，每个人都有机会为大家演示自己的劳动成果。
但必须记住，不要强迫性格内向的成员去做大范围的演讲，你可以鼓励每个团队成员去表现，但这必须不是强制性的。通常，性格内向的成员可以成为演示的参与者，他们是很好的聆听者，安静地参与评审。但是，你必须要鼓励团队的每个成员积极参与评审。
作者:佚名 来源:酷勤网
