湛蓝之海 发表于 2022-9-11 13:19:16

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 - 新一代智能研发协作平台,在线申请体验我们的产品。

https://my.oschina.net/u/5057806/blog/5574576
页: [1]
查看完整版本: Sprint Review 到底是迭代评审会,还是功能演示会?