讨论主题

1.Scrum框架定义了什么事件?

2.什么是时间盒?时间盒有什么好处?

3.Scrum团队怎样运用Scrum事件检视和调整?

一、Scrum事件

子曰“温故而知新”。第二讲《Scrum简介》介绍过，Scrum是一个过程框架。我们可以把框架想象成一座建筑物的地基和墙体，框架是稳定不变的东西。Scrum框架由Scrum团队以及与团队相关的角色、事件、工件、和规则组成。在第三、四、五、六讲里，我们分别讨论了Scrum团队的3个角色：产品负责人、开发团队和Scrum Maśter。截止到第6讲，团队的角色就学完了。接下来这些角色该活动起来啦！从第七讲开始，我们讨论Scrum事件。

Scrum框架定义的5个事件，是冲刺和冲刺里顺序进行的4个事件：冲刺计划（Sprint planning）、每日站会（Daily Scrum）、冲刺评审(Sprint review) 和冲刺回顾(Sprint retrospective)。每个冲刺都要重复进行这4个 事件。

1、什么是冲刺？在Scrum里，工作在迭代中进行，这个迭代称为冲刺。一个冲刺可以被看做一个为期不超过一个月的项目。

2、什么是冲刺计划？项目开始有项目计划，冲刺开始也有冲刺计划。在每个冲刺的开始，Scrum团队为计划本冲刺要进行的工作而召开计划讨论会，讨论冲刺目标，设计方案，开发计划。

3、什么是每日站会？项目有进度监控，冲刺有进度检视。冲刺里的每一天，开发团队为检视进度，而召开例行碰头会，讨论三个问题：昨天做了什么？今天计划做什么？达成冲刺目标有什么障碍？

4、什么是冲刺评审？项目结束交付最终产品，冲刺结束产出产品增量。在每个冲刺结束的时候，Scrum团队和干系人为获取客户反馈，促进合作，而召开产品演示、体验、讨论会，检视产品增量，调整预期产品功能。

Scrum的冲刺，冲刺计划、每日站会、冲刺评审，这4个事件和PMP的项目管理有相通之处。有项目管理经验或者学习过PMP的小伙伴，可以触类旁通。具体到每个Scrum事件，我们以后再详细讲解。

5、什么是冲刺回顾？在冲刺评审之后，下一个冲刺计划之前，Scrum团队为了团队成员之间配合的更加默契，工作的更加高效，而召开的关于"人、人际关系，流程和工具"的讨论会。冲刺回顾这个内容在PMP里少有涉及。有CMMI、6西格玛等过程改进经验的小伙伴，可以回忆持续过程改进的概念，把冲刺回顾这个事件大致理解为过程改进分析、讨论会。

二、时间盒

我好像听到各位的心声～哇，这么多的会议！用过Scrum的团队告诉我：“我们原来以为Scrum开会多，浪费时间。后来发现，其实省时间。这些会议有规律，其它杂七杂八的会减少了。每个会议时间不长，有效果。” 是的，Scrum使用固定的事件产生规律性。所有事件都有时间盒限定，也就是说每一个事件的时间范围都有上限。

对于冲刺来说，时间盒规则是这样的。一旦冲刺开始，持续时间必须固定下来，不能缩短或延长。例如，我们定下来冲刺持续时间是一周，本周三开始，到下周三结束。现在冲刺开始了，到本周五的时候，开发团队问：“如果到下周三做不完，可不可以把结束时间延迟两天哈？” Scrum Master应该怎么回答？应该回答：“不可以”。

对于冲刺计划、每日站会、冲刺评审和冲刺回顾这4个事件来说，时间盒规则是这样的。每个事件限制在最长的时间范围内，事件可以在目标达成之后立即结束。例如，对于4周的冲刺来说，冲刺计划的时间盒为8个小时。有人说啦：“开8个小时会啊？”。听清楚，是最长开8个小时，不是必须开8个小时。只要计划会议目标达成了。哪怕会只开了1个小时，照样结束。

时间盒规则确保时间被适当地使用，避免浪费。时间盒限定有诸多好处。

第一个好处：促进结束。时间盒能激发团队完成工作的动机。当团队有一个确定的结束时间时，事情更有可能做完。结束日期不容更改，这可以激发团队成员全力以赴按时完成工作。如果没有明确的结束时间，人们就不会有完成工作的紧迫感。结合上面说到的例子，开发团队问“做不完，可不可以延期?” Scrum Master回答开发团队"不可以”，更有可能激发团队按时做完。

第二个好处：强制排列优先级。时间盒强制我们按照优先级排序，执行最重要的小批量工作。在第三讲《产品负责人》里，我们谈到过传话筒式的产品负责人，客户说需要什么特性，就转告开发团队，不排优先级。假设用户需求很多，在没有时间盒限定的情况下，开发团队会怎样反应呢？要么要求更长的开发时间，要么要求增添更多的开发人手，把皮球踢回给管理者。但发布日期不能延后，否则会失去市场，输给竞争对手。开发人力不会轻易增加，有朝一日开发需求不那么饱满的时候，裁员是个极其痛苦的事。最经常出现的，是默默地牺牲质量。Scrum采取不同的办法，质量不可以牺牲，给冲刺限定时间盒，产品待办项必须排优先级，高优先级的，本冲刺做，低优先级的，下个冲刺再说。

第三个好处：展示进度。我们在第一讲《敏捷宣言》里谈到敏捷宣言背后的12条原则，其中的第7条原则，可工作的软件是进度的首要度量标准。比如一个软件要开发10个新功能。第1个冲刺，第1个功能可用了，叫做进度10%。第5个冲刺，共有5个功能可用了，叫进度50%。如果完成一个大特性需要6个月的时间，那6个月内如何展示进度呢？把大特性拆分为小特性，每个冲刺都是一个时间盒，完成若干小特性，进度就可视化了。

我们讲了时间盒的三个好处：促进结束、强制排列优先级、展示进度。时间盒还有其它的好处，比如增强可预测性，避免不必要的完美主义。这里不再逐一举例。Scrum Master需要指导团队遵守时间盒规则，培养团队，提升团队在规定时间内达成目标的能力。

三、检视和调整

Scrum中的每个事件都是用来进行检视和调整的正式机会。为了说明怎样在产品开发中做检视和调整，我借用一篇名叫《玩转MVP不要错过这四个案例》的文章。请各位搜索到这篇文章。

第一行，Not like this！（不要这样做），画了四副小图，每幅图隐喻一个产出版本。第一个冲刺次产出一只轮子；第二个冲刺产出更多轮子；第三个冲刺产出物有了下半部分车身；第四个冲刺产出一部完整的汽车。大家想象一下，如果这样开发，在第一、二、三个冲刺的冲刺评审会上，团队怎么演示？客户怎样体验？客户无法体验半成品！设想一下这样的场景，在冲刺评审会上：

“先生，这是我们首次迭代的产物 一 一只前轮。您觉得怎么样？”

客户会这样回答：“见鬼，我订的是整台车，而你却只给我个轮胎！这东西我能用来干嘛？”

到第四个冲刺产出完整产品之前，时间已经过去很久了，但却没有经过任何实际的用户体验，产品中很可能充斥着人们基于对用户需求的错误假设而产生的设计缺陷。

冲刺检视的对象必须是“可用的”，才能给客户演示、请客户体验。这样的检视才能发现真正的偏差，这样的调整才能最终达到客户满意。缺少实际用户体验，没有形成真正的反馈环，无法进行真正有效的检视和调整，产品开发会变得极具风险。

现在看第二行，like this！（要这样做），画了五副小图。第一个冲刺产出滑板；第二个冲刺在滑板上加装一个扶手；第三个冲刺产出一辆自行车；第四个冲刺产出摩托车；第五个冲刺产出一辆敞篷跑车。

有的小伙伴就说啦：“多浪费啊！前四个冲刺，写了那么多代码，做了那么多组件，白辛苦啦！” 从重用的角度来看，我理解你的感受。然而，注意！Scrum的优势在于在需求不确定的环境中，探索客户潜在需求，用最短时间、最低价格，让客户满意。如果我们强调软件组件的重用，而忽视了客户真正的需求，有可能开发出来的产品，客户根本不感兴趣，没有销路。那才是最大的浪费！

在这个隐喻中，客户潜在需求是“我需要更快地从A到达B。” 滑板、摩托车、跑车，都是满足这个需求的方案。哪个方案最佳？需要通过一次次的客户体验，来检视和调整。

例如，相对于在第一个场景中产出的前轮，滑板是一个实际能体验的东西。开冲刺评审会的时候，客户踩着滑板在办公室里玩了一圈，说：“不错，有点意思，能让我更快地到达咖啡机边上。但是不太稳，我太容易掉下来了。” 因此，第二个冲刺计划里，我们要给滑板加装一个扶手。客户满意了吗？有可能。也有可能他还是有点想要那台车。但在这期间，他实际上正在使用产品，并给予我们反馈。他想走得更远点。因此，第三个冲刺，产出的产品增量变成类似于自行车的东西。在体验这个产品时，我们可能会发现，客户主要在一个园区的大楼之间转悠，路太窄了。结果可能是，自行车是比原先设想的汽车更好的产品。

你可能会想：“我们不是应该通过前期的需求分析来知道那些吗？” 对于创新型产品来说，无论前面做多少分析，当把第一个版本交到真实用户手中时，你都会感到惊讶，很多假设都错得离谱。所以，要提前做一些分析，但不要花太多的时间。一 取而代之的是通过冲刺评审，获得用户实际体验，调整产品待办列表，在下一个冲刺计划中，体现预期产品特性的变化。

回到故事。也许客户有时需要去另一个城市，而骑自行车实在太慢、太累。因此第四个冲刺，我们增加了个引擎。那么现在呢？再次，客户可能会对摩托车感到满意。或者，客户可能会选择继续。我们最后交付的有可能是一台敞篷跑车。客户会感到喜出望外！为什么？因为我们在检视和调整的过程中，了解到他喜欢呼吸新鲜空气。

Scrum最适合开发创新型产品。在上面的隐喻中，我们看到“滑板、自行车、敞篷跑车” 这些迥然不同的解决方案。客户的需求是什么？答案有多种可能。我们通过一个个冲刺，不断检视和调整，力图用最短时间，最低价格，达到客户满意。

四、小结

本讲我们复习Scrum框架，Scrum团队的三个角色，引出Scrum事件。Scrum框架定义了5个事件，它们是冲刺，以及冲刺包含的4个事件：冲刺计划、每日站会、冲刺评审和冲刺回顾。Scrum事件遵守时间盒规则，是用来进行检视和调整的正式机会。