Sprint Review 到底是迭代评审会，还是功能演示会？

湛蓝之海

迭代结束前，敏捷团队通过Sprint Review，向关键干系人展示其工作结果和目标完成进度，检查已交付的价值增量，并结合反馈确定或调整未来的产品规划和待办列表。
依据敏捷联盟的描述，Sprint Review的与会人包括Scrum团队（产品负责人、Scrum Master和研发团队），以及产品负责人邀请的关键干系人；会议的一般流程如下：

  

• Scrum团队说明产品待办列表中哪些项目已经/尚未完成。  
  
• 开发人员讨论在迭代期间达成的进展、遇到的问题以及其解决方案。  
  
• 开发人员展示已经完成的工作，并回答关于价值增量的问题。  
  
• 产品负责人讨论现有的产品待办列表，并根据目前的项目进展预测可能的目标和交付日期（如果需要的话）。  
  
• 敏捷团队合作讨论下一步怎么做，Sprint Review要为后续的迭代提供有价值的意见。  
  
• 审查产品或市场环境的变化，分析可能对下一步要做的最有价值的事情产生的影响。  
  
• 讨论即将发布的版本的产品功能，审查时间表、预算、潜在功能以及市场变化。
  

不同语境下，Sprint Review多被译为「迭代评审会」或「功能演示会」。但众多实践经验却强调：

You should never call the Sprint Review the Sprint Demo.

Sprint Review是不是Demo/功能演示会？解答这个问题，要先回答会议的「讨论对象」和「会议目标」分别是什么。
01 不局限于迭代成果，重点展示整个产品增量
若从字面涵义理解Sprint Review，或许有朋友会认为它是关于迭代成果的会议，即讨论当前迭代已交付的价值。但Sprint Review的一般流程指出，与会人应该围绕「价值增量」展开讨论。

开发人员展示其已经完成的工作，并回答关于价值增量的问题。

Scrum Guide中定义「增量 Increment」为「所有先前增量的累加」，且实践经验表明，增量会在Sprint Review会议呈现。

每个增量都是所有先前增量的累加，并经过全面验证以确保所有增量可协同工作……增量的总和会在Sprint Review中呈现，以支持经验主义。

因此，除了同步迭代期间工作和障碍外，更重要的，Sprint Review要展示整个产品增量，以供检视，而不仅是关注最新的迭代所实现的价值。

技术侧成员向业务侧呈现基于整个产品目标的已完成工作，业务侧成员结合产品目标和外部变化，对研发成果进行验收。
Sprint Review能够实现「产研-业务-用户」多终端的进度同步和目标对齐。若只停留在迭代增量的展示或报告上，恐怕就会降级成围绕「完成了什么 > 没完成什么 > 为什么没完成」的工作汇报。
也因此，许多实践经验都证明，完整的产品功能展示/Demo演示是更理想的Sprint Review形式。
相比逐一展示用户故事，或者仅使用含功能截图的PPT汇报，Demo演示能够更加直观、全面且集中地呈现业务目标的完成进度，也更便于产品负责人和关键干系人评估研发成果，更快地完成目标的调整和待办优化。
02 不止于Demo演示，协作与反馈更为关键
虽说功能/Demo演示是更理想的形式，但这并不意味着，顺利完成功能演示就大功告成。Sprint Review的最终目的不是演示，而是对产品待办列表做出调整。
敏捷开发的核心是快速响应和拥抱「变化」——所有外部的、业务的、基于时间/预算/组织的变化。敏捷开发通过短周期的价值交付，和及时地获取源自业务的反馈，持续地明确、修正和调整前进目标，以减小变化带来的影响。
是以，Scrum团队呈现围绕目标和业务交付的研发成果（即产品价值增量），只是完成信息透明和进度同步的第一步；
更重要的下一步是，与关键干系人协作，获得基于迭代和增量的反馈，为后续的迭代工作提供宝贵意见，再次明确目标，并分析下一迭代所需交付的「最有价值的事情」的变化。

所谓「协作」就是要打破技术和业务、Scrum团队和干系人之间的「隐形墙」，将所有人揉成一团，在统一的会议目标基础之上，展开互动和讨论。
比如，与其让开发团队演示产品功能，不如让干系人在开发的指导下完成用户路径，以真正的用户视角检查研发成果，贡献反馈。
换句话说，让Scrum团队与主要干系人组织协作，完成对产品待办列表的检查和调整是会议的关键。脱离反馈和待办调整的单方面的功能演示，只是换了外衣的「工作汇报」罢了。正如《深入核心的敏捷开发》所说的：

如何评价迭代评审会的效果？唯一的评价标准是，会后有没有对Product Backlog做出调整。

03 给予正向反馈，尊重并认可团队的贡献
Scrum团队与主要干系人破冰协作，为当前的产品增量提供反馈意见，并确定后续的迭代目标。但在许多敏捷实践中，贡献反馈的环节很容易变形成「质量检验」和「缺陷问责」。
当与会人将Sprint Review视作「成果汇报」或者「阶段验收」，业务端会天然地形成「查漏补缺」和「拨乱反正」的自觉，而技术端则会因免于指责而陷入「粉饰太平」之中。
长此以往，技术和业务、Scrum团队和干系人之间的关系会越发紧张，阵营堡垒也逐渐坚厚，最后Sprint Review成为人人抗拒的仪式。
因此，Sprint Review不是为了贡献一个集中问责的机会，而是为了及时的反馈和更好的提升——这也是敏捷开发所追求的——持续地学习、反馈、提升和再实践。
换言之，Sprint Review希望输出正向反馈：业务端对技术端为实现目标所作出的贡献和成果表示认可与尊重；技术端对业务端传递的反馈和改进建议持以开放心态；至于那些尚未完成/仍需优化的部分正是下一阶段或后续的努力方向。
Sprint Review不是针锋相对的修罗场，而是结合沟通、协作和反馈的最佳实践。

  

• 产品负责人和干系人通过功能演示掌握最新的产品增量和目标进度，作出最及时的修正和调整，确定正确的业务方向；  
  
• Scrum Master和开发团队在展示和讨论中，同步成果、统一目标、定位和评估目标贡献度，在真实的反馈中赢得工作成就感。
  

正确的Sprint Review能让每一位与会人在结束会议时都认为「我们正朝着正确的方向前进」。
# Liga总结
Sprint Review是「以终为始」的优化过程——围绕完整的产品/模块形态，检视当前的进度，评估需要修正的阶段目标并制定下一步的成长计划。
因此，Sprint Review应该围绕产品的价值增量展开，而不是只关注最新的迭代交付了哪些价值；同时，会议结束要有反馈输出，对产品待办列表做出恰当的调整。
Demo演示是比较理想的会议形式，但不要只停留在演示；反馈不为问责，而是为了提升和优化，成就更好的敏捷协作。

了解更多敏捷开发、项目管理、行业动态等消息，关注我们 LigaAI@oschina 或点击LigaAI - 新一代智能研发协作平台，在线申请体验我们的产品。