共计 2849 个字符，预计需要花费 8 分钟才能阅读完成。
在 Scrum 中，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/ 性能演示会？ 解答这个问题，要先答复会议的「探讨对象」和「会议指标」别离是什么。
不局限于迭代 重点展现整个产品增量
若从字面涵义了解 Sprint Review，或者有敌人会认为它是对于迭代成绩的会议，即探讨以后迭代已交付的价值。但 Sprint Review 的个别流程指出，与会人应该围绕「价值增量」展开讨论。
开发人员展现其曾经实现的工作，并答复对于 价值增量 的问题。
Scrum Guide 中定义「增量 Increment」为「所有先前增量的累加」，且实践经验表明，增量会在 Sprint Review 会议出现。
每个增量都是所有先前增量的累加，并通过全面验证以确保所有增量可协同工作……增量的总和会在 Sprint Review 中出现，以反对经验主义。
因而，除了同步迭代期间工作和阻碍外，更重要的，Sprint Review 要展现整个产品增量，以供检视 ，而不仅是关注最新的迭代所实现的价值。
技术侧成员向业务侧出现基于整个产品指标的已实现工作，业务侧成员联合产品指标和内部变动，对研发成绩进行验收。
Sprint Review 可能实现「产研 - 业务 - 用户」多终端的进度同步和指标对齐。若只停留在迭代增量的展现或报告上，恐怕就会降级成围绕「实现了什么 > 没实现什么 > 为什么没实现」的工作汇报。
也因而，许多实践经验都证实，残缺的产品性能展现 /Demo 演示是更现实的 Sprint Review 模式。
相比逐个展现用户故事，或者仅应用含性能截图的 PPT 汇报，Demo 演示可能更加直观、全面且集中地出现业务指标的实现进度，也更便于产品负责人和要害干系人评估研发成绩，更快地实现指标的调整和待办优化。
不止于 Demo 演示 合作与反馈更为要害
虽说性能 /Demo 演示是更现实的模式，但这并不意味着，顺利完成性能演示就功败垂成。Sprint Review 的最终目标不是演示，而是对产品待办列表做出调整 。
麻利开发的外围是疾速响应和拥抱「变动」——所有内部的、业务的、基于工夫 / 估算 / 组织的变动。麻利开发通过短周期的价值交付，和及时地获取源自业务的反馈，继续地明确、修改和调整后退指标，以减小变动带来的影响。
是以，Scrum 团队出现围绕指标和业务交付的研发成绩（即产品价值增量），只是实现信息通明和进度同步的第一步；
更重要的下一步是，与要害干系人合作，取得基于迭代和增量的反馈，为后续的迭代工作提供宝贵意见，再次明确指标，并剖析下一迭代所需交付的「最有价值的事件」的变动。
所谓「合作」就是要突破技术和业务、Scrum 团队和干系人之间的「隐形墙」，将所有人揉成一团，在对立的会议指标根底之上，开展互动和探讨。
比方，与其让开发团队演示产品性能，不如让干系人在开发的领导下实现用户门路，以真正的用户视角查看研发成绩，奉献反馈。
换句话说，让 Scrum 团队与次要干系人组织合作，实现对产品待办列表的检查和调整是会议的要害。脱离反馈和待办调整的单方面的性能演示，只是换了外衣的「工作汇报」罢了。正如《深刻外围的麻利开发》所说的：
如何评估迭代评审会的成果？惟一的评估规范是，会后有没有对 Product Backlog 做出调整。
给予正向反馈 尊重并认可团队的奉献
Scrum 团队与次要干系人破冰合作，为以后的产品增量提供反馈意见，并确定后续的迭代指标。但在许多麻利实际中，奉献反馈的环节很容易变造成「质量检验」和「缺点问责」。
当 与会人将 Sprint Review 视作「成绩汇报」或者「阶段验收」，业务端会人造地造成「查漏补缺」和「拨乱反正」的盲目，而技术端则会因免于指摘而陷入「粉饰太平」之中。
长此以往，技术和业务、Scrum 团队和干系人之间的关系会越发缓和，营垒堡垒也逐步坚厚，最初 Sprint Review 成为人人抗拒的典礼。
因而，Sprint Review 不是为了奉献一个集中问责的机会，而是为了及时的反馈和更好的晋升——这也是麻利开发所谋求的——继续地学习、反馈、晋升和再实际。
换言之，Sprint Review 心愿输入 正向反馈 ： 业务端对技术端为实现目标所作出的奉献和成绩示意认可与尊重 ； 技术端对业务端传递的反馈和改良倡议持以凋谢心态；至于那些尚未实现 / 仍需优化的局部正是下一阶段或后续的致力方向。
Sprint Review 不是唇枪舌剑的修罗场，而是联合沟通、合作和反馈的最佳实际。
- 产品负责人和干系人 通过性能演示把握最新的产品增量和指标进度，作出最及时的修改和调整，确定正确的业务方向；
- Scrum Master 和开发团队 在展现和探讨中，同步成绩、对立指标、定位和评估指标贡献度，在实在的反馈中博得工作成就感。
正确的 Sprint Review 能让每一位与会人在完结会议时都认为「咱们正朝着正确的方向后退」。
# Liga 总结
Sprint Review 是「以终为始」的优化过程——围绕残缺的产品 / 模块状态，检视以后的进度，评估须要修改的阶段指标并制订下一步的成长打算。
因而，Sprint Review 应该围绕产品的价值增量开展 ，而不是只关注最新的迭代交付了哪些价值；同时， 会议完结要有反馈输入，对产品待办列表做出失当的调整。
Demo 演示是比拟现实的会议模式，但不要只停留在演示；反馈不为问责，而是为了晋升和优化，成就更好的麻利合作。
· END ·
# 举荐浏览
1. 麻利四会之如何晋升近程团队的站会效率？请点击《分布式团队的高效站立会说明书》
2. 更清晰地实现程序员成长定位，制订可操作的晋升计划，欢送珍藏《优良的程序员要学会「软硬兼施」》
理解更多麻利开发、项目管理、行业动态等音讯，关注咱们的 sf 账号 -LigaAI~ 或者点击 LigaAI- 新一代智能研发合作平台，在线申请体验咱们的产品。
