基本上每周我都会到一两家企业进行Scrum内部培训，或是做Scrum教练辅导的工作。最近，参加敏捷课程的学员多多少少都有些相关经验，或者阅读过或看过相关视频。大部分情况下，这是个好事情。但是，我还是发现一个情况，我注意到有些学员把Scrum的“Sprint评审”实践当成“Sprint演示”或仅仅是“演示”。
这看起来有点咬文嚼字，但是把评审称为“一个演示”使人们偏离了该实践的真正目的。
虽说演示是Sprint评审的一个有效部分，但是这不是Sprint评审的最终目的。 Sprint评审最重要的部分是参会者之间的深度沟通和合作，以确保开发出的产品是客户真正需要的产品。演示实际上是激起对具体事情进行沟通的一个有效方式。没什么能比看到可工作的软件更能吸引人的注意力的了。
下图阐明了我对Sprint评审的看法。
图片的中间是Sprint评审的图示。该实践的精髓就是检查和调整这个Sprint中的产品增量。
该图示下方是Sprint评审的一个行为导图。
步骤1：回顾这个Sprint的目标和承诺要完成的特性，并比较一下哪些是真正已完成的。
步骤2：演示一个完整的特性，对其进行讨论，并根据讨论结果对产品backlog或发布计划做必要的调整。
重复该步骤，直到讨论完所有已完成的特性。
在这个方法中，演示仅仅是Sprint评审包含的一项活动，而不是srpint评审的目的。这就是为什么我认为把整个实践看做Sprint评审而不是一个Sprint演示非常重要了。
再重申一下，Sprint评审的目的是对已完成产品的检查和调整。一个成功的评审能带来双向的信息流。Scrum团队外的人能了解开发进度，帮助其把握方向。 同时，Scrum团队成员通过获得频繁的反馈能从业务和市场方面更加了解整个产品。
Sprint评审因此象征着每个Sprint中都有一个机会来检查和修改产品。
作者：Ken Rubin
译者：Scrum中文网
http://www.innolution.com/blog/its-a-Sprint-review-not-a-Sprint-demo
