Sprint Review 到底是迭代评审会,还是功能演示会?

原创
09/09 10:39
阅读数 1.7K

迭代结束前,敏捷团队通过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 - 新一代智能研发协作平台,在线申请体验我们的产品。

展开阅读全文
加载中

作者的其它热门文章

打赏
0
1 收藏
分享
打赏
0 评论
1 收藏
0
分享
返回顶部
顶部