持续交付时代，还有必要进行 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为中大型团队提供优秀的敏捷研发实践，打造研发过程当中多角色间的高效协做环境，帮助中大型企业快速可靠地迭代版本，持续交付价值。