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

万事ONES

+ 关注

2021-10-25 15:57

562次阅读

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

Sprint Review 是什么？

Scrum 将整个开发过程分为多次 Sprint，通过多次 Sprint 来改善正在构建的特性，逐步完善产品。

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

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

Scrum 迭代流程图

Sprint Review 的价值

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

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

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

Sprint Review 成功要点

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

共享文档，沉淀团队知识

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

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

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

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