持续交付时代，还有必要进行 Sprint Review 么？

持续交付时代，企业通过自动化构建部署，快速频繁地发布软件。很多团队为了尽早获取用户和干系人的反馈来适应变化，采用一次性的特性评审来取代迭代评审会（Sprint Review）。那么持续交付时代，是否还要坚持 Sprint Review？Sprint Review 的价值在哪里？本期「项目管理100问」来聊一聊 Sprint Review。

Sprint Review 是什么？

在「ONES 小课堂：让我聊一聊 Scrum」中说到，Scrum 将整个开发过程分为多次 Sprint，通过多次 Sprint 来改善正在构建的特性，逐步完善产品。

Sprint 需要经过 Planning - Implementation - Review - Retrospective 4个阶段流转，在 Sprint 结束时进行 Review，来检视所交付的产品增量并按需调整产品待办事项列表。

Scrum 迭代流程图

Sprint Review 的价值

Sprint Review 的目的是为本次迭代交付的产品获得反馈，响应业务需求，确保达到应用效果，避免开发对用户没有价值的功能。Sprint Review 将参与该过程的所有人员联系在一起，集中展示多个特性功能，帮助利益相关者全方位思考，从整体上优化和改进产品。

对于团队来说，整体优化和改进是很难的，通过仪式感的会议机制持续地学习和讨论，让团队成员清楚地知道每次交付的是一个可用的软件版本，而不是单纯的产品功能。Sprint Review 让持续交付文化融入团队，保证研发的节奏和质量。

Scrum 过程中每个要素都是以一种微妙的方式相互作用，随意裁剪模块会破坏敏捷的节奏。Sprint Review 作为敏捷中重要的一环，必不可少。那么，如何高效地完成 Sprint Review 并充分获得反馈？

Sprint Review 成功要点

1. 在会议准备阶段，PO 需要根据迭代规划周期和类型确定演示计划和演示日期，在 ONES Wiki 中与团队成员同步演示环境及数据，提高会议效率；

ONES Wiki 共享文档，沉淀团队知识

2. 确定会议主持人，把控会议流程及会议走向，避免将会议变成简单的演示会议。

Sprint Review 不是 Sprint Demo，Sprint Demo 是单向沟通，而 Spirnt Review 是双向沟通。它不仅是展示本次迭代的成果，还要求项目组内部成员（包括PO、SM、开发测试等）和项目组外部利益相关者（包括客户、最终用户等）相互提问反馈，检查新功能是否满足客户需求；

3. 建议由 PO 进行操作，讲解当前完成功能及遗留问题或风险，所有参会人员根据体验及演示提出反馈或建议，按照优先级录入 Sprint 或 Product backlog;

ONES Project 建立需求池

4. Sprint Review 结束后，如未达上线标准，PO 需要引导团队成员根据演示反馈形成问题的「行动计划」并执行，直至下一次演示通过方可上线；

5. Sprint Review 不是唯一获得反馈的方式，团队应该尽早获取用户和干系人的反馈。ONES Desk 支持快速收集、跟踪、管理和解决客户的建议反馈，帮助团队改善产品功能、解决用户需求，不断从事件中学习和沉淀。

ONES Desk 帮助企业快速响应客户反馈

持续交付时代，ONES为中大型团队提供优秀的敏捷研发实践，打造研发过程中多角色间的高效协作环境，帮助中大型企业快速可靠地迭代版本，持续交付价值。