90天炼就斯巴达方阵（六）

3.4 Sprint Review（冲刺评审会）

评审会是对产品进行检验并适应的过程。在会上，团队（包括Developers，不仅仅是PO）通过对增量的演示，从干系人那里收集到反馈，并据此更新产品的PBI。如果Sprint的长度是2周的话，评审会一般不超过2小时。

在实践过程中，对于评审会，发现有两点经常会被误解，所以这里澄清如下：

1. 评审会的演示对象不是PO。根据敏捷原则——“业务人员必须和开发人员每天都在一起工作”，PO不应该到Sprint结束的时候才看到这些潜在的交付物（Increment）。评审会的演示对象应该是各种利益干系人，包括潜在的客户、市场人员等等。

2. 评审会不是成果展示。根据敏捷价值观——“可工作的软件胜于面面俱到的文档”，不需要花大量的时间和精力去做演示稿，30分钟之内的准备就足够了。

   ‍

由于各种原因，终端客户或者市场人员往往无法参加会议，那么评审会还要不要继续开下去呢？建议是继续，可以包括以下两个议题：

1. PO和团队一起就某个增量进行深入的讨论，共同考虑如何改进；

2. 如果时间允许， Developers之间可以选取某些有价值的增量做知识分享。这个分享不仅仅是技术的，也可以包括业务层面。因为刚刚完成，此时记忆最深刻，讲的人有成就感，听的人受益匪浅；从实际效果来看，也确实不错。

   ‍‍

因为不是所有的增量都需要被演示，建议在评审会当天的站会后进行议题的收集。我常用的议题收集模板如下：

图16 议题收集表格模板

图16显示，在这次评审会议上，PO有两个完成的增量会和大家一起深入讨论，分别由Peter和Alex来演示；初此之外，如果2小时的时间还没有用完，Developers希望Ivan和Janik能就另外两个完成的增量进行一次知识分享。对于Developers之间的知识分享，只要有人想听，或者只要有人想讲，哪怕只有一个人，建议就将其标记为“Y”。这样不仅仅是为了珍惜每一次学习的机会，还通过行动来鼓励每位成员大胆提出自己的真实想法，融入团队之中，同时增强对产品的“经营者”意识。“尊重”是Scrum的五个价值观之一，也是精益（Lean）的两大支柱之一。何况到目前为止，我也没有遇到因此而导致分享泛滥成灾，失去重点的情况。

3.5 Sprint Retrospective（冲刺回顾会）

回顾会是对过程进行检验并适应的过程，需要引导技术来帮助自我成长和集体决策。它和评审会之间的留白时间最好不要太长，建议将这两个会议安排在同一个下午，中间留20分钟左右的休息时间就足够了。为期2周的Sprint，一般会议时长不超过90分钟。

关于如何开好回顾会，如果只看一本书的话，推荐Esther Derby和Diana Larsen合著的《Agile Retrospectives Making Good Teams Great 》，书中将回顾会分为了5个阶段：做好准备，收集数据，生成见解，决定行动，和结束回顾。

如果想看两本书的话，就再推荐Marc Loeffler的《Improving Agile Retrospectives: Helping Teams Become More Efficient》。此书在“做好准备”和“收集数据”之间增加了一个阶段“检查假设”，即针对上次Sprint的行动，检验其是否达到了预期的目标：没有的话，可以据此进行回顾，寻找原因并改进。

如果想进一步提高主持技巧，需要学习专业的引导技术，这已经脱离本文的范围了。

图17 敏捷回顾相关书籍推荐

总而言之，回顾会是Event中主持难度系数最大的会议，但也是最有趣和放松的一个。即使有很多活动可以安排在会议当中，但在Sprint 1，建议：

1. “收集数据”阶段采用“静默头脑风暴“。对于新成立的团队，成员之间生疏，信任度不高，用“写”的方式比“说”会更加安全，收集到的数据也会更全面真实。

2. “生成见解”阶段采用“鱼骨图”和“5个Why”相结合的活动。Sprint1中亟需改进的地方多，团队对于集体决策的方式也生疏，用以上两个强大工具会帮助大家很快定位根本原因，并协助找到解决方案。

   ‍‍

回顾会上生成的行动有效，大家后续才会对回顾会更有信心。否则，就会进入“问题都找到了，但从来没被解决”的循环。在这种情况下，即使每个Sprint都召开回顾会，大家也只是在疲于应付而已。长此以往，团队就会患上官僚组织中常见的“习得性无助”。如果你实在没有信心，就邀请公司有经验的专家来主持引导回顾会，自己也从旁观察学习。

回顾会上生成的行动还应该在下个Sprint就能完成。如果行动的实施比较花费精力，请事先和PO商量好最多可占用多少工作量，并当作PBI记录下来。一般不应超过Sprint容量的10%。另外，会议生成的团队协议（team agreement或者working agreement）也应当记录在固定地方，供大家随时查阅。

图18 团队协议示例

回顾会本身的纪要也要保存下来，帮助大家跟踪、回忆。如果有图片或者视频等多媒体记录最好了。

图19 回顾会纪要示例

3.6 小结

团队从形成期走向震荡期的过程，充满了冲突和不稳定，SM本人也会面临各种被质疑的挑战。这些在上面的内容中不可能完全体现出来。但随着Scrum框架的逐渐落地，SM终于取得团队的认可和信任；并在你教练式的领导下，团队开始向规范期大步迈进。

此时此刻，端一杯咖啡坐下来，看看Wiki页面上日渐丰满的Scrum专栏：这些努力都是值得的——“雄关漫道真如铁，而今迈步从头越”！

图20 Scrum  Wiki目录示例