Sprint 评审会议

    Sprint 评审会议在Sprint 结束时召开，由开发团队展示这个Sprint 中完成的功能，长度为两个小时左右，不需要PPT，一般是已经完成功能的Demo，而且客户、管理层、Product Owner 以及其他开发人员等都可以参加。在每个Sprint 结束时，应该组织一次Sprint 评审会议。Scrum 开发团队将在会上展示他们在这个Sprint 中所做的工作，一般采用向大家演示产品新功能的方式来展示。相对来说，Sprint 评审会议不必很正式。通常不需要用到PPT，而且长度最好控制在两个小时之内。也就是说，不要让Sprint 评审会议成为Scrum 团队的负担，不必让他们花太多时间来准备这个会议。
    Sprint 评审会议的参与者包括所有对该产品感兴趣的人，可以是产品责任人、Scrum团队、利益相关者、管理层人员、客户，甚至是来自其他项目的开发人员等。在Sprint 评审会议上，Scrum 团队用Demo 的形式展示产品的新功能之后，与会人员依据在Sprint 计划会议上确定的这个Sprint 的目标来评审具备了这些新功能的产品。为什么一定要用Demo 的形式来展示产品的新功能呢？因为这种方式有很多好处。
    首先，参与会议的人都能直观地看到Scrum 团队的工作成果；其次，利益相关者们可以据此提出更切合实际的反馈意见；第三，为了完成Demo，团队会努力完成并发布那些功能，即使只是发布在测试环境下，也比没完成的好。如果不做Demo，也许不少功能会停留在“已完成99%”的阶段。相比较起来，在有Demo 的情况下，也许“已完成”的功能数量会相对少一些，但它们是确确实实完成了的。否则，那些“99%”的貌似完成的功能势必还要拖到下个Sprint 来解决。
    假如有一个刚从传统的开发模式转而采用Scrum 的团队，由于不习惯这种自我约束、自组织的方式，在Sprint 中并没做多少工作，那么在会上演示的时候，他们会觉得很尴尬。没准老板会因为看到他们花了这么多时间只做了这么少的工作而感到很生气。发生这种情况当然是大家都不想看到的。但良药苦口，在下一个Sprint 中，这个团队肯定会吸取教训。他们会明白，无论什么情况下都必须做Demo，那么他们必然会很好地完成这个Sprint 并演示给大家看。