第十一讲 Sprint Review

一个冲刺里有4种事件。第九讲谈到在一个Sprint的开始，进行Sprint Planning。第十讲谈到在Sprint中的每天，进行每日站会Daily Scrum。第十一、十二讲，我们将介绍在Sprint结束的时候进行的两个重要的“检视一调整”活动：Sprint Review和Sprint Retrospective。第十一讲，我们详细介绍Sprint Review。

讨论主题 

1.怎样组织Sprint Review?

2.搞Sprint Review有什么好处?

3.Sprint Review的3个常见问题及对策

一、怎样组织Sprint Review

时间安排：在Sprint临近结束的时候，团队进行Sprint Review。对于为期4周的Sprint，时间盒为4小时，时间短的Sprint，Sprint Review会议时间相应缩短。

会议主题：检视增量，调整Product Backlog

参会者：Scrum团队和Product Owner邀请的干系人

会议流程：

A. Scrum Master作为会议的组织者，需要确保会议如期召开、参会者理解会议目的、在时间盒内达成会议目标。

B. 会前准备(输入)

因为有Scrum团队外部干系人参加，还要演示产品增量，Sprint Review会议前需要做一些准备工作。

C. 议事日程

议事日程包括4个环节。首先，Product Owner总结当前Sprint的成果。然后，开发团队演示已经完成的产品增量，回答参会者提出的问题。接下来，参会者就产品和方向发表言论。最后，Product Owner调整Product Backlog和发布计划。

D.会议成果(输出)：经过梳理的Product Backlog和更新后的版本计划。

怎样为Sprint Review做准备?

1.确定邀请谁参加

Scrum团队的所有成员默认每次都参加。Scrum团队以外，内部干系人，例如管理层，销售人员，其他开发团队的代表，欢迎参加。外部干系人，例如实际客户和用户，要定期参加。如果知道某次Sprint Review主要讨论内部事务，最好只限于内部干系人参加。

2.安排会议日程

确定关键利益干系人什么时间方便参加Sprint Review，Sprint Review就安排在这个时间。围绕Sprint Review的时间，再安排其他Sprint活动。例如，某干系人喜欢每周二下午2:00进行Sprint Review，那么Sprint Review就定在每周二下午2:00，Sprint Review结束，接下来搞Sprint Retrospective，Sprint Planning，新的Sprint就开始了。

3.确认哪些条目已经完成

Sprint Review时，只允许团队展示已经完成的工作。哪些Product Backlog Item算是完成了，哪些算尚未完成呢？在Sprint进行中，Product Owner要尽早进行评审，确认工作是否完成（满足大家一致同意的“完成”的定义），为开发团队提供及时、有效的反馈。

4.为演示做准备

Sprint Review是一次仪式少，价值高的非正式会议。没有必要投入很多时间制作精美的PPT。因为被检视的增量是已经完成的，所以准备工作不会花很长时间。对于一周的Sprint，准备时间不超过30分钟。

怎样进行Sprint Review?

1、总结

一般由Scrum Master来主持会议，Product Owner展示Sprint Goal和相关的Product Backlog Item，概括的说明当前Sprint的成果，哪些Product Backlog Item已经完成，哪些还没有完成。开发团队讨论哪些进展顺利，哪些遇到问题，问题是怎样解决的。

如果结果与目标不符，Scrum团队要给出解释。一定要注意，不要把Sprint Review搞成批斗会。如果没有达到目标，任何一个参会者都不可以去指责别人。参会者必须理解，Sprint Review 会议的主题是“检视增量，调整Product Backlog”，描述完成了什么，什么没完成，结合干系人反馈的信息，决定下个Sprint应该做什么。说白了，Sprint Review 是为了在实现产品愿景的征途中，停下脚，回头看，我们现在走到哪儿了，向前看，下一步该往哪儿走。

2、演示

演示的目的，是为了获取反馈并促进合作。

演示的内容，只允许展示已经完成的工作。

演示的方法，开发团队负责演示，并回答问题。如果开发的产品是游戏，基至可以试着让干系人自己玩一玩，亲自体验一把最近这个Sprint里开发的新装备、新技能，看看好不好玩。

谁来演示昵？开发团队可以自己决定，只要评审活动能够取得最好的效果。建议让开发团队的每一位成员都有机会亲自动手演示。

3、讨论

围绕着演示的这个具体的东西，参会者就产品的开发进度、预算、潜在市场等方面展开讨论。例如，进度方面，按照目前的这个进度，什么时候能够发布？预算方面，现有的预算是否能够支撑到产品发布，投资回报率怎样？产品方面，产品方向是否需要调整？但是，不讨论开发工时，也不要只限于对新功能给出反馈。

4、调整

调整指调整Product Backlog，明确下一个Sprint应该做什么。Product Owner与参会者协作，梳理Product Backlog，把干系人喜欢的东西的优先级提高，把遗漏的特性补充进去，把不必要的特性删除。通过这些调整，达到优化价值的最终目的。这个经过梳理的Product Backlog就是下一个Sprint Planning的输入。

Product Owner还应该根据当前开发的速度，合理评估最有可能的发布日期，更新发布计划。

二、搞Sprint Review有什么好处?

提高透明度

人人都知道，搞好管理要提高透明度。Sprint Review，Review的是增量。完成并可用的增量具有高度透明性，我们可以根据增量的当前状况准确判定，系统完成度是多少，剩余的工作还有多少。这是瀑布流程所望尘莫及的好处。

讲一个瀑布流程的案例作为反例。一个12个月的项目，8个月过去了，通过里程碑审批的依据，只有文档。软件能不能运行，会不会死机，不知道。到最后一个季度，剩一堆bug解不完！需求不清楚、设计不合理、平台不稳定，各种问题到最后才暴露出来。经过这些坑以后，反过来看，Review文档这种方法有一个先天不足：透明度低！

俗话说，是骡子是马拉出来溜溜。最透明的，就是review完成并可用的增量。

促进合作

Sprint Review最重要的好处是，参与者之间的深入交谈和合作，能碰撞出有建设性的、实际可行的调整建议。怎样把Scrum团队和干系人之间的交谈与合作引向深入呢？要组织这样一个活动，把干系人(客户或用户)邀请来，为他们现场演示实际完成的工作成果，让人们能够围绕着一个具体的、能动的东西展开积极的对话。这是促进合作的一种有效途径。

有一位Product Owner曾经在产品总结会上这样说：“我们每个Sprint给客户演示，客户看到新特性，就有了更多新想法，我们就可以根据客户的需求及时调整方向。” 他一边说，还一边用手势做出一个蛇行的动作。

举个乐高公司开发玩具的例子。乐高公司经常和当地的幼儿园、学校、家庭合作，把一群群的孩子邀请到办公室，现场体验新产品的早期原型。2016年1月，乐高发布了未来骑士。在开发这套玩具的早期，设计师制作了纸上原型，并交给孩子们。孩子们的第一反应是：“嘿，谁是坏人？我看不出谁好谁坏！” 设计师们不断迭代，调整他们的设计方案。请看最后的玩具图片，我打赌，你也能看出图中谁好谁坏。

三、关于Sprint Review的3个常见问题及对策

问题1：没有可以演示的东西

有的团队说:"我们这个Sprint没有可以演示的东西，怎么演示啊?"

可是，为什么没有可以演示的东西呢?

开发团队说：“我们一直在修bug，没开发什么新特性，要演示也是和上个Sprint一样的内容，不演示了吧～”

修bug，没开发新特性。这是最常见的原因。这个现象说明一个问题，前面几个Sprint的工作没有真正完成，欠下技术债了，所以需要设立一个专门的“技术债Sprint” 来集中还债。但是，尽量不要这样做！当日事，当日毕。应该哪个Sprint完成的工作，不要拖到以后。能不欠的债，尽量不要欠。允许设立“技术债Sprint”会误导开发团队，以为欠债没关系，反正以后可以找到专门的时间还嘛。所以，不要集中还债。如果技术债已经欠下了，建议分期偿还，一边做有客户价值的工作，一边还。这有点像买房还房贷，一边挣钱，一边还贷。

当然，一边开发新特性，一边修bug，开发团队工作会更忙。最好的办法是搞一些工程实践(自动化测试)，帮助开发团队减少因为粗心大意导致的低级错误，控制技术债的增长，保证本该用于开发新特性的时间，不被技术债挤掉。这样做，从实践上看，每个Sprint都有可以演示的新东西，从理念上讲，遵循了Scrum的核心理念：交付客户价值。

问题2：请不动干系人

有的Product Owner说：“客户请不动啊！有可能太忙，没时间，也有可能是不理解参加Sprint Review的意义吧，反正推三阻四，不愿意来。” 

Scrum落地的过程中，这种现象时有发生。这一讲一开始就讲到，干系人不必每次都参加，但强烈推荐他们定期参加。干系人参与不足，缺少实际用户体验，没有形成真正的反馈环，无法进行真正有效的检视和调整，产品开发会变得极具风险。

讲一个实际案例。有个Product Owner抱怨：“我给客户发邮件，他从来都不回复。邀请他看看我们的中间版本，他也不理睬。” 项目结束的时候，管理部门邀请客户的评语，客户是这样写的：“项目没有达到目标，对需求理解存在很多问题。” 哎呀，团队郁闷啊！然后这个Product Owner就邀请组织内部更高级的管理者和他一起去拜访客户。最后终于弄明白了，客户躲着不见面，是因为他没预算了。整个团队忙活大半年，这样的结果大家都很失望。

所以，干系人请不来，Product Owner要主动去拜访，分析干系人不来的原因，千方百计请他来。如果实在难以获得更多预算，就应该及时结束项目。其实这也是一种成功，因为成功的避免了浪费。

问题3：签字接收

有的组织把Sprint Review作为正式签字接收产品增量的环节，干系人看完演示，表示没有什么问题，Product Owner签字接收。这种做法，Product Owner偏向于承担干系人的代言人角色。我推荐Ken Rubin的观点：Product Owner和开发团队同属于一个Scrum团队，在评审会上应该表现的像一个团队。在Sprint进行中，Product Owner要尽早进行确认。在Sprint Review前，Product Backlog Item就应该已经通过Product Owner的“批准”。在Sprint Review时，只演示经过Product Owner“批准”的已经完成的工作。

这样做的好处在于，避免发生在Sprint Review会议上，Product Owner和开发团队两个互相抱怨。Product Owner说：“你们做的这个不是我想要的。”开发团队说：“你怎么不早说？如果你提前2天告诉我们，我们完全可以把这个改过来。” 凡事都有两面性，这样做有好处，也会有问题。如果在Sprint Review时，有一位高级别的干系人认为，演示的某个Product Backlog Item没有完成，就是说，会议上干系人的意见和会前Product Owner的意见不一致，怎么处理这种情况呢？恰当的做法是为这些特性的变更建立新的Product Backlog Item，插入到Product Backlog中合适的位置，安排在以后的Sprint中开发。

小结 

第十一讲讨论了三个主题：1. 怎样组织Sprint Review；2. 搞Sprint Review有什么好处； 3. Sprint Review的3个常见问题及其对策。

Sprint Review是一个重要的"检视一调整"活动。有项目管理基础的朋友，可以回忆一下戴明环一PDCA(plan计划、do执行、check检查、action调整)里面的check和action。Scrum的每个Sprint都是一个完整的反馈环。如果能够触类旁通，对我们学习Scrum一定大有裨益。