共计 4253 个字符，预计需要花费 11 分钟才能阅读完成。
共创嘉宾| 潮海我的项目教练
撰文编辑| 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 团队以业余、高效的姿势，向干系人和用户出现研发成绩；通过疏导和察看，洞悉实在场景下的应用反馈，更好地服务后续迭代。
