【敏捷FAQ 第8回】迭代评审中利益相关者不再参加

 感谢您阅读本文。我是隶属于敏捷小组的藤井智弘。
 关于我们接连进行的日常会、回顾会这两个活动，第三个是迭代评审。前两个会议是在团队内部完成的，而评审会的主角是团队外的人。正因为如此，形式化的方式和修正方式都会有些不同。

 在刚开始实施Scrum时，相关部门的人（出于新鲜感）都会来参加迭代评审。然而，4个月过去了，现在几乎只有团队成员自己参加。每次我们都认真准备了演示，却没有人来看。
 前几天，来自发包方的负责人对我说：“演示的话，如果你们把视频或资料发给我们，我们会去看的。具体的确认我们会在验收的时候一并进行。”他看起来并无恶意，我们也能理解他们很忙。
 但是……把评审变成“团队内部的演示会”，继续下去还有意义吗？

 “请把资料发给我们”这句话里面就包含了答案。对方认为评审是“报告”。如果是报告，就没必要专门来参加会议，资料就足够了。从对方的立场来看，这个判断完全合乎情理。问题在于，评审真的变成了报告会议这一事实本身。
 在我接受这个咨询时，咨询者通常会考虑三件事：

• 不再来参加，是因为太忙，还是因为失去了兴趣
• 如果资料就能解决，那就用资料代替会议可行吗
• 仅限团队内部的评审，总比不做要有价值吗

 下面依次回答这三个问题。

• 不再来参加，并非因为太忙或失去兴趣，而是他们已经学会了，来参加也无济于事。仅仅看完完成的内容，然后鼓掌离开，第二次起就没有理由再来参加了。

    图1: 准备万全，座位空无一人——4个月后的迭代评审

• 是否可以用资料代替，取决于会议的内容。如果只是报告，就可以用资料代替。但对于“是否沿用这个替代流程，或是舍弃它”“下一步从哪个业务领域进行验证”这样的决策，不会因为发送资料就会有回复。
• 仅在团队内部进行的评审，遗憾地说，并不是真正的评审。因为没有对成果进行检验的对象。
   解决方案不是催促出席，而是重新定义会议。如果将评审从“完成报告会”转变为“用团队外的人的语言来决定接下来该做什么的会议”，那么一旦让大家知道自己的发言会推动产品发展，就算不邀请也会自发前来。需要关注的地方有两点：要让谁来决定什么；所得到的意见后来如何得到反馈。

 在培训或现场，可能有人对你说过：“迭代评审不是批准或验收的场合”“不是演示会，而是检验会”。但你是否曾这样想过？

• 将完成的内容展示给对方并让其确认，这有什么不对？发包方不是想要验收吗
• 如果每次都听取利益相关者的意见，计划是否会偏离或难以收束
• 不来参加的人该如何召集？除了催促，还有什么方法

 这些疑问很合理。结论是……

• 展示内容本身没有问题，问题在于展示之后什么都不做
• 计划的变动正是预期和目的所在，不过变动的粒度是在冲刺层面
• 人不会因为催促而持续参与，只会在自己能产生影响的场合持续出现

在深入讨论之前，先看看评审往往呈现出的几种场景，然后再逐一说明。

 形式化的评审有几种典型模式（回顾会时介绍的是“脸谱”，此处只是名称，并无深意）。请对照自己的会议，思考哪一种更接近。

模式1：完成报告会型——最常见的模式。团队依次展示“本次冲刺完成了什么”，利益相关者则“谢谢大家”，鼓掌后离开。即使有问题也只回答一下就结束，下次冲刺要做的事在会议开始前就已经确定好了。“请把资料发给我们”就是对这种模式最诚实的评价。

    图2: 鼓掌后离开的会议。“资料我再看一下哦~”

模式2：验收型——在业务型项目中容易出现。发包方的负责人或即使是内制化项目中来自业务部门的负责人也会以“交付确认”的心态来参加。关注点在于“是否按照要求完成”，而“这样可以吗、下一步怎么做”并不会成为议题。在第6回中，我写到发包方或管理层来参加日会属于“客户报告型”，他们若想参与决策，就该参加评审。即便给他们留了席位，如果还是保持验收型，那么不过是将日会的报告会搬到评审里而已。

模式3：全员集合型——以“一切相关者”为对象的一次性邀请。没有告诉任何人“你为什么要来”，结果是每个人都不以为意。第一次因为新鲜而来，几次以后就被归为“可不来参加的例会”。

模式4：盖章型——团队以“可以这样吗”为由，向利益相关者请求批准。利益相关者的角色只是说“好”，并没有提供选项。虽然得到了批准，但方向没有任何改变。如果说验收型是发包方的做法，那么盖章型就是承包方的做法。

模式5：团队内部演示会型——模式1～4走到极致的结果。外部人员不再参加，只剩团队内部演示然后结束。虽然能留下记录，但没有人进行检验。提问的人就在团队内部。

 这五种模式的根源在于，将评审视为“展示成果的场合”。如果真是这样，那么只要展示完成就算成功；如果没人来，就摆好演示就行；得到批准就算结束——这是最直接的理解。这五种模式并没有什么问题，都是水到渠成的结果。
 而如果仅仅是“展示的场合”，那么用资料替代就是理所当然的做法。对方的意见，在这个前提下，完全合理。

 下面回到三个疑问（※本系列的展开也开始模式化了呢）。

• 将完成的内容展示并让对方确认有什么不好的地方？
   没有问题。展示可运行的软件是进行评审的起点。问题在于，展示之后什么都不做。面对可运行的内容，利益相关者能提供的不是“是否符合要求”的确认，而是团队所缺乏的信息——现场的真实感受、市场或其他部门的状况、后续可能遇到的困难——如果听完就结束，对团队来说是报告，对对方来说只是验收，都没有留下决策下一步的依据。验收（与完成定义或验收条件的对照）是必要工作，但不应置于评审会议中进行。应在会前完成对照，将会议时间留给“基于这些信息下一步该怎么做”的讨论。这种分工下，评审才不会被验收工作吞没。

• 如果每次都听取意见，计划会不会动摇？
   会动摇（当然）。而这正是其目的所在。每个冲刺结束展示可运行的内容，就是为了快速修正方向；如果评审完全没有改变方向，就相当于没有进行任何检验。不过，变动的粒度是在冲刺层面。会议中提出的意见，不是立刻插入开发团队的工作，而是作为产品待办列表（Product Backlog）优先级的变更，在下次冲刺规划时再纳入。如果有这样的机制，意见就不再是“破坏计划的东西”，而是“更新计划的依据”。用第4回的说法，切片的替换在日常中就发生在这套机制里，只有用例列表的增减，才作为发包方的显性决策进入流程。

• 不来参加的人该如何召集？
   催促是无效的。人只有在自己能产生影响的场合才会持续出现。读者们也一定希望尽量减少那些既不能发言也没有价值的报告会。
   之所以最初有人人来参加的原因，与他们后来不来参加的原因，其实是同一个——在刚开始时，利益相关者会来看看“用这种新方式会带来什么变化”。几次下来，他们就学会了：演示齐全、有问题会回答、但不论我说什么、或不说，下一次冲刺要做的事似乎都不会改变……当这种学习完成后，评审就被归为“可不来参加的例会”，“请把资料发给我们”也就脱口而出。这并非利益相关者的懈怠，而是理性的行为。
   唯一的召集方法是：让会议成为“来这里就会用自己的话决定什么事的场合”。

 在这里，请回想第3～5回讨论的更改项目。正如那几篇中所示，更改项目中，每个冲刺几乎都会出现只有发包方能决定的事项。是否沿用在验证中发现的“神秘行为”、修复它还是舍弃它；对某个用例的验证深度是以最小集合为止，还是扩展到主要替代流程；下一步从哪个业务领域开始实际操作——这些都是面对可运行内容，由了解业务的人来做出的决策。也就是说，更改项目的评审绝不缺少议题。如果仍然是“报告会”，那么这些决策要么在评审之外（通过邮件或其他例行会）完成，要么就没有人做决定，开发者凭猜测来实现。前者可以把它们拉回评审中进行，后者恰恰就是应在评审中决定的内容。

 那么，**为何“展示场合”这一前提会如此自然地渗透进来？**因为许多组织在引入Scrum之前，就已经有“进度报告会”“成果报告会”“验收”的文化。面对可运行的内容聚集人群的模式相似，评审就会在原有模式上被覆盖，旧有的目的——报告、确认、获取批准——继续保留。在业务型现场，更深层次的原因也会出现：即使是推进内制化的业务公司，在面对原来的外包系统公司时，业务部门与IT部门之间往往依然沿用“委托内外包”的角色分配与上下级关系。在这种关系下，评审就被视为“对发包方交付的确认”，而非“与平等伙伴一起决定下一步的场合”。这并不是谁在偷懒，而是关系的形态决定了会议的形式。

 那么，真正的迭代评审应当是怎样的环节？我们用透明性、检验、适应来描述。
 透明性——冲刺的成果不应是资料，而应是可运行的增量，让团队外的人也能同等地看到。对于冲刺目标，完成了什么、没完成什么都应毫无保留地呈现。演示是实现透明性的手段，而非目的。到此为止，资料就是足够的。
 检验——将可见的增量与产品目标以及利益相关者带来的市场、现场状况进行比照，确认“能否就此继续”“有哪些变化”。只有在这里，团队外的信息才会进入。即使发送资料，也无法获得此环节的反馈。
 适应——基于检验结果，决定下一步要做什么。重新排列产品待办列表，改变方向。评审的产出不是演示，而是反馈意见及基于反馈调整后的待办列表。

 通过这三点，可以看出完成报告会型评审的真相：将全部会议时间都花在透明性（演示）上，却既不进行检验也不进行适应。与报告型的日会和流于形式的回顾会一样，都是同一套图式。要做的是将**“展示成果的场合”转变为“与外部人员一起决定下一步做什么的场合”**。只有这一点改变，其他任何处方才会奏效。

 处方是手段。关于评审的推进方式，专家提供了许多建议，选择哪一种都可以。但如果只是照搬，得到了“已经做到了”的感觉，那与盖章型并无区别。请以评审促动待办列表变动的次数来评估成效，而非出席者人数。

首先，统计评审中待办列表变动的次数
 在采取措施之前，先统计。对于最近3～4次评审，统计在这些评审中，产品待办列表的顺序或内容因会议而发生变化的次数。如果都是零，那就明白评审既未进行检验也未进行适应。将“利益相关者不来”这一感慨，转化为“过去4次评审中，待办列表因评审发生变动的次数为零”的报告，会更有说服力。这与回顾会上统计上次Try的后续情况遵循相同逻辑。

作为决策场合进行再设计
 将议程中心从“演示”移到“决定事项”。每次设定一个、即可由利益相关者决断的问题，并在邀请函中明确写明。“本次评审希望决定的事项：◯◯”只要一句话，就能改变会议性质。如果是更改项目，问题多得不缺：“对于验证发现的此行为，是沿用、修复还是放弃？”“账单开具验证是以最小集合为止，还是扩展到月初批量开具？”“接下来先运行收款对账还是月末结算？”如果是新开发，则“是否按此形式发布此功能？”“下步是沿A方向推进还是B方向？”“这个假设与现场实际感受是否一致？”等等……
 会议开场从冲刺目标完成情况开始，然后提出问题。所决定的事项要记录在会议记录和待办列表中，如果组织内部有正式的变更流程，也请及时对接。不要仅停留在口头共识，这是维持这种运作的关键。
 此外，那些现场无法当场决定的议题（如需要审批的事项），应事先明确：“评审只决定方向性建议，正式决策将按既有流程执行”，以避免会议体的定位及权限产生混乱。

 图3: 面对可运行内容，用外部人员的语言推动待办列表变动

提前分发问题
 在会上临时问“各位意见如何？”，没人能立刻给出高质量回答。请将要演示的内容及需要决断的事项提前简明共享，给对方留出思考时间。反馈质量与准备时间成正比。如果有人说“请把资料发给我们”，就将这份事前共享当作资料发出。发送的不是报告，而是“请在会上决断此事”的问题。

点名邀请，并附理由
 放弃一刀切的全员邀请，仅邀请与本次议题相关的人。“财务部的◯◯先生/女士，此次报表输出与您手头的月度业务直接关联，请您在实际界面上确认。”无法说明邀请理由的人，这次就不必邀请。人数少，但能够产生影响且有意义的反馈的会议，远比沉默的大会议更有价值。在第6回，我提到让想参与决策的发包方及管理层来日会，但如果他们真正想参与决策，那应该是来参加评审。在邀请他们时，同样要附上“希望您做出此决策”的理由。

将验收放在会前完成
 对于倾向验收型的现场，应在评审前与负责人完成与验收条件的对照（如果验收条件已事先明文化，大部分可直接对照完成）。评审当日，不再验证“是否符合要求”，而是用时间讨论“基于此，下一步如何行动”。如果能事先就利益相关者的参与方式达成一致，评审就不会被验收工作吞没。

提供一张可带走的摘要
 发包方负责人还需在内部汇报。请求“请把资料发给我们”的部分原因，是他们需要汇报材料。在第3回中，我提到与负责人共享“已验证清单”“剩余风险”“业务影响顺序”这套词汇。在评审结束时，请将本次验证中已验证清单扩展到哪里、做了哪些决策、剩余风险发生了怎样变化，一并汇总在一张单页上交给对方。负责人可直接带回公司进行汇报。决策在会上，报告在这一页上。如此分工，便能消除“请发资料”这一要求。

展示反馈的“后续情况”
 在下次评审的开场，一定要报告收到的意见如何被处理。“上次◯◯先生/女士的指摘，以此形式纳入了待办列表，并已在本次演示中体现”“△△的需求经考虑，本期暂缓，原因是……”。不论是采纳还是不采纳，只要让对方感觉到自己的发言被追踪，就不再是“多说无益”。这将成为他们下次参加的最大动力。
 这种再设计是团队与利益相关者的共同协作。团队负责提出问题并追踪反馈去向，受邀者带着决策来参与，并在下一次检验自己的意见如何被处理。当这种往返开始运转时，评审就会成为不需要邀请也会有人自发参加的会议。这也是将“委内包”上下级关系转变为平等协作的地道举措。

 “定期展示可运行软件”的形式从引入之初就能效仿。但“基于所展示内容，与外部人员一起决定下一步做什么”的实质，需要深入到团队外的人员关系与组织的决策模式，难度远超形式。因此许多团队先从形式入手，却停留在形式上。几个月后，就在空座排开的会议室里产生同样的疑问。

 评审的出席人数，是团队与组织对接健康程度的晴雨表。如果空位持续出现，那就是团队与外部对话几近中断的信号，应当比演示效果更先被关注并改进。此次评审是否在外部人员的语言中有某项决策并使待办列表发生了变动——这一道问题，将成为衡量迭代评审的仪表盘。

 诶？试过了，但利益相关者就是不肯行动？
嗯嗯嗯，这种环境下的应对之道，迟早会在本系列的某篇中讨论。

下次： “上司要求将故事点转换为人日”