怎样破解迭代评审会七宗罪,开一场高效会议

09/16 10:09
阅读数 861

共创嘉宾| 潮海项目教练

撰文编辑| LigaAI

全文约 4,300 字,阅读约需 12 分钟


迭代评审会(Sprint Review)基于真实的用户使用场景,展示当前整个产品增量,通过获取贴合用户使用习惯的反馈和建议,最终输出产品待办列表的优化调整。迭代评审会应重点关注用户需求的解决情况,而不是查找缺陷(当然,影响核心流程的重大缺陷一定要记录在册)。

  • 展示结果:开发团队检视当前迭代的最初计划,展示每个需求/故事的工作结果及变化;
  • 评审反馈:产品负责人进行确认,收集反馈,并记录进一步的改进设想为新需求/故事;
  • 调整方案:产品负责人及关键干系人介绍有关后续迭代的新信息/设想,为接下来的迭代计划会议提供有价值的输入信息。

基于清晰的会议目的和讨论重点,如何更好地完成迭代评审会?高效的迭代评审会又有哪些不为人知的事半功倍小技巧?

本期敏捷实践,LigaAI联合潮海项目教练团队的资深敏捷教练,一一为你解答。

一、 每个迭代结束都要进行评审吗?

作为Scrum五大事件之一,迭代评审会通常在产品增量完成后、正式发布前举行,但在实践经验中,并非每个迭代完成都必须要进行评审。依据时间频率的不同,迭代评审会分为高频评审和低频评审。

  • 高频评审适用于产品增量复杂的情况。通过将产品增量拆分成若干个关键需求,并在每个关键需求完成后,邀请重要干系人参与检验,以分散一次性评审的会议压力。
  • 低频评审适合产品增量对干系人的感知价值不大(比如长流程的端到端需求)或干系人时间紧张等情况。通过多个增量的合并评审,减少频繁会议对工作的占用和干扰。

此外,以迭代周期/固定周期作为举行迭代评审会的标志并非最优解。迭代周期是团队内部的开发管理单位,在可感知价值增量层面或有不稳定性。

更好的做法是基于里程碑/史诗的完成情况,以增量结果为指标,按需开展迭代评审会。 研发里程碑一般分为「内部里程碑」和「外部里程碑」两种。

  • 内部里程碑常指项目关键决策点,如需求阶段完成、设计阶段完成,主要用于评估项目内部风险,一般不涉及用户反馈,无需迭代评审;
  • 外部里程碑是涉及对外发布的重大功能/模块的完成,需要在产品发布前邀请关键干系人参加迭代评审会,并贡献真实的使用反馈。

二、 干系人一定要参与会议吗?

在《每日站会能不能取消?》一文中,我们曾提到「非必要情况下,Scrum Master可以不参加每日站会」。那么,迭代评审会是否也可以不需要关键干系人的参与呢?

答案是——不可以。

迭代评审会的核心目标是收集用户反馈,所以关键干系人的参与极其重要。 但在实际中,不可避免地,干系人可能因各种原因无法参加会议,可以采用以下几种方式解决:

第一,由干系人授权的决策代表代替干系人参加会议。决策代表需要具备对产品增量贡献反馈的能力,并且要能够提出「通过与否」的关键性意见。

第二,如果干系人无法分出大块时间参与评审,那Scrum团队可以采用高频小模块的方式完成反馈,遵循「价值原则」——先展示最急需反馈的功能。

第三,将干系人的会议预约列入待办。避免临期预约的冲突和缺席隐患,产品负责人可以在迭代规划期,就提前锁定关键干系人的会议时间,或将迭代评审会以定期形式常态化(比如安排在每双周的固定时段),确保干系人可成功出席。

贡献反馈的干系人必须参加,而执行反馈的技术人员也同样不能缺席。 开发团队应在现场直面用户,聆听最真实的用户声音,才能更好地理解业务、理解需求。

理想情况下,开发团队应全员参与迭代评审会,同干系人一起协作讨论,在认同中建立工作价值感;

如果团队规模较大,也可以轮流派代表或者安排技术骨干参与会议,负责本次产品增量的开发人员必须出席会议,以减少一手反馈的传递偏差。

三、迭代评审会的多种打开方式

01 合而为一

践行Scrum的过程中,敏捷四会(即计划会、每日站会、评审会和回顾会)不必是完全独立的。

例如,对于每周一迭代的短周期敏捷团队,可以考虑将评审会和计划会合为一次会议,以减轻会议负担。会议中,应先评审、后计划:关键干系人在评审结束后先行离场,Scrum团队继续进行新一期迭代的计划会议。

迭代回顾会则不建议与其它会议合并,因为这是敏捷团队复盘和经验总结的宝贵机会;但可以考虑将多个迭代的回顾会合并一次举行。

02 一分为二

对于产品增量价值低、客户感知影响不大、或有高质量要求,需先进行内部评审的迭代而言,可以采用「一分为二」的低频评审形式,将迭代评审会分为「Scrum团队的内部会议」和「与干系人协作的外部会议」两次进行。

  • Scrum团队的内部评审侧重于完整的功能展示,重点审查关键功能能否跑通、是否存有Bug尚未修复/发现等;
  • 有关键干系人参与的外部评审以收集用户真实反馈为主,重点验证产品增量是否满足客户需求、是否达成真正的产品价值。

03 直面客户是最好的形式

远程办公和异地协作盛行的今天,共享式的文档/表格/问卷协作免去许多会议,但是迭代评审会以获取用户真实反馈为核心,面对面沟通却是不可省去的重要仪式——直面客户、观察用户的使用和体验是获取有效反馈的主要途径。

对于重要且急需用户反馈的功能,Scrum团队应主动安排产品负责人和功能相关的技术骨干前往干系人公司,进行一对一展示和沟通

面对无法克服的时差或时空问题,也可以采用线上视频会议的形式,但是建议要开启摄像头和麦克风,并使用共享屏幕,让Scrum团队「看到」干系人的使用反馈。

四、迭代评审会的四个黄金搭档

高效的迭代评审会一般包含功能演示、体验试用、讨论反馈和待办优化四个环节。

01 功能展示

述清会议内容与目的后,开发成员结合迭代计划与产品增量,向产品负责人和关键干系人展示已经完成的产品价值。

看似简单的功能展示,也存在一些共性的改进空间——《深入核心的敏捷开发》提出「展示会七宗罪」以描述功能展示过程中的七大问题,并针对性地提出了高效展示会的七个技巧。

七宗罪之一:准备工作没做好,空耗会议时间

正确做法:主讲人在正式展示前,应该做好充分的准备工作——预演演示步骤,准备测试数据,提前部署演示环境等等,避免手忙脚乱和空转浪费,提高会议效率。


七宗罪之二:没有说明铺垫,云里雾里不知所以

正确做法:在开始演示之前,主讲人应当简要地介绍会议目标和所要展示的功能,并说明功能给用户带来的价值。清晰的上下文能让产品负责人和干系人更快地进入状态。


七宗罪之三:逐条过验收标准,缺失业务完整性

正确做法:不要逐个演示用户故事/验收标准。主讲人应以功能为单位,将完整的产品/功能/模块串起来展示;最好定义出单独的业务场景,使用业务语言让业务成员更有代入感。


七宗罪之四:相同/类似的功能,演示所有路径

正确做法:只演示最关键的路径。遇到多个路径实现相同或相似功能时,选择其中一条最复杂/重要的路径详细演示,其他路径指出不同的地方,点到为止,无需覆盖全部路径。


七宗罪之五:过多提及跟演示功能无关的内容

正确做法:专注于最有价值/重要的功能演示,不要让小反馈/未完成的模块耽误会议时间;尽量不提及技术难题或技术方案等业务人员不感兴趣的内容。


七宗罪之六:认为展示仅仅是BA或QA的事情

正确做法:不让某个角色独占功能展示,人人都应该参与进来;可以采用人员轮换的方式进行展示,这样可以提升成员的业务意识,更熟悉整个系统功能。


七宗罪之末:不熟悉的新人负责展示,重点模糊

正确做法:新人展示前应充分了解业务和系统,确保能够应对和解答业务的挑战和疑问;也可以让新人在结对编程、Story Kickoff等多做主导,具备一定的系统和业务意识后再向干系人展示。

02 体验试用

开发成员完成功能演示后,更重要的是要让关键干系人亲自体验和试用系统功能/Demo。用户亲自下场试用和检验,是获取反馈中必不可少的一环。

产品负责人也可以邀请真实的用户参加评审会,让其在开发的指导下体验演示的功能和系统。需要注意,此时开发团队应该为干系人和用户留出足够的自主探索空间,引导他们重现最真实的使用习惯和场景,避免成为「产品推销员」。

03 讨论反馈

产品负责人要收集关键干系人(和用户)的反馈,及时记录最新的改进与设想为新的需求。在体验试用环节,Scrum团队可以通过以下几种方式,观察用户体验,洞悉真实反馈。

  • 注重整体的展示,避免成为验收测试

让干系人和用户体验功能并非授权全自主探索——开发成员需要提供必要的场景描述,还原功能使用场景,让用户更有代入感;但,切忌进行步骤指导,过多的干预反而不利于观察真实反馈。

另外,不要逐一演示用户故事。开发成员应尽可能引导用户对整个产品/功能模块进行试用,并关注基于产品整体的功能完整性和衔接流畅性,观察和分析可能存在的优化空间。

  • 细心观察用户表现,敏感捕捉使用障碍

在用户体验功能时,Scrum团队应该留心观察他们自然表达和流露的语言、表情、操作和使用习惯等,要具备捕捉异常的敏感度

比如用户是否在使用期间出现困惑表情、在无反应的地方反复点击等等。通过深入挖掘用户行为背后的原因,了解最真实的行为反馈。

  • 使用开放性问题,引导用户自主表达

与干系人和用户协作、沟通和讨论时,避免使用「是不是」、「有没有」等封闭性问题;多用开放性问题,一步步引导用户表达出最真实的想法

发现用户频繁点击某个按钮,或浏览选项的时间过长时,可以通过抛出「你希望这个按钮提供什么功能/选项(但没有满足)吗?」等问题,鼓励用户主动说出对系统功能的期待,为后续的迭代贡献有价值的意见和改进空间。

04 待办优化

在评审会的最后,产品负责人及关键干系人介绍有关后续迭代的新信息或新设想,结合当前产品或市场环境的变化,讨论即将发布的版本的产品功能,为接下来的迭代计划会议提供有价值的输入信息。

通常在会后,产品负责人会结合迭代评审会的结果,对产品待办列表和需求优先级进行重新评审和整理——这也是衡量会议成功的关键。

为了更准确地完成待办列表调整,开发团队应对未完成的工作保持开放和透明,以便产品负责人能制定更全面的决策;

产品负责人可以结合不同决策依据,应用优先级排序的三个模型和四张画布,更高效地完成调整。

更多阅读请点击:

不同决策应参考什么指标进行优先级优化?

做优先级排序时使用最多的三个模型

译文 | 四张画布教你判断「产品开发优先级」

# Liga总结

迭代评审会的核心目标是为了获取真实的用户反馈,为后续的迭代和研发工作贡献有价值的意见。

高效的迭代评审会要抓住功能展示、体验试用、讨论反馈和待办优化四个关键环节。Scrum团队以专业、高效的姿态,向干系人和用户呈现研发成果;通过引导和观察,洞悉真实场景下的使用反馈,更好地服务后续迭代。

了解更多敏捷开发、项目管理、行业动态等消息,关注我们 LigaAI@oschina 或点击LigaAI - 新一代智能研发协作平台,在线申请体验我们的产品。

展开阅读全文
加载中

作者的其它热门文章

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