【敏捷FAQ 第6回】每日站会变成了进度汇报会

 感谢您阅读这篇文章。我隶属于敏捷小组的藤井智弘。
 第3回到第5回，作为“敏捷基础解说”可能相当进行了几次变换球，或许有的读者会感到惊讶。不过，作为 FAQ 这些问题确实非常常见，希望能让您回想起这是这样的连载。
 第6回，我想回到最基础的基础。

 我们每天早上都进行15分钟的每日站会，但只成了按照顺序各自报告“昨天做了什么、今天要做什么、遇到什么困难”（培训中学的所谓“三大问题”）然后结束的会议。说实话，没人认真听别人的报告。而且会议一结束，各处就开始真正的讨论。对于所谓的每日站会“仪式”，还有意义吗？

 “会议一结束后就开始真正的讨论”……在提问里，这一句话隐藏了解答的关键。
 团队每天早上都需要讨论以下事项：

• 谁在哪里遇到了瓶颈，
• 需要谁的协助，
• 应该优先完成什么

 这就是为了实现冲刺目标所做的“对今日活动的再规划”。既然这些讨论在会议后自然发生，就说明该团队已经明确了需要讨论的事项，并且彼此之间可以进行讨论（我想告诉提问者，这是一个“好迹象”）。缺少的是将会议后的讨论与“15分钟”连接起来。轮流发言的形式结束后，并没有让“谁和谁今天应该做什么”浮现出来，真正的讨论则是偶然坐在旁边的人，根据所察觉的顺序开始的。并不是说不需要15分钟，而是每日站会并没有作为“引发会后讨论”的装置在发挥作用。

 顺便一提，想必很多人在培训或现场都被指导过“每日站会要控制在15分钟内”“不要做进度报告”等。那时，你有没有产生过这样的疑问？

• 进度共享本身应该很重要，为什么仅此而结束就会被否定？
• 根本上，15分钟能做什么？
• 如果是所有人都需要的信息，即使花30分钟共享，难道不更重要吗？

 我也有同样的想法。先给出答案：并不是共享本身有问题，而是只做了共享这一件事才是问题所在。15分钟对于共享来说确实太短，但足以决定今天的行动。而且，真正需要所有人的信息并没有想象中那么多——光说这些可能还不足以让人信服，所以我们先看看每日站会通常会变成什么样子，再来认真回答。

 变成汇报会形式的每日站会有几种模式。请对照您团队的情况，看最接近哪种。

 模式1：汇报会型——最常见的一种。发言者的目光不是看向队友，而是看向 Scrum Master 或领导；依次发言，轮到之前就等待。与开头提问中的情况一致。

 模式2：客户汇报型——在业务系统现场容易出现。当发包方的负责人或部长级管理者“来看情况”而出现在每日站会时，就会变成这种形式。从那一刻起，每日站会就成了“面向客户的进度汇报”。承包方成员面向发包方发言，领导在一旁应付场面，遇到的问题也被轻描淡写。有时还可能在会前进行“在每日站会上要说什么”的“轻度彩排”。顺便一提，在这种情况下，第3回中看到的发包方和承包方面对面时思考停顿的场景会每天早上重演。

 模式3：其他项目汇报型——在业务系统的维护与更新团队中，同时兼任其他项目或运营的成员并不罕见。兼任者的每日站会如果放任，会变成“今天上午有别的项目故障处理，下午有会议……”如此这般包含其他工作安排的“我的整体工作”报告。虽然本人汇报时很诚实，但对该团队的再规划毫无帮助。

 模式4：日报型——这在远程团队中很常见，通过聊天消息完成每日站会。每个人只写下“昨天、今天、遇到的问题”然后结束。留下记录无可厚非，但没人阅读也没人回复，写作就成了目的。没有收件人的汇报——即日报——是汇报会化的终极形态。

 模式5：延长战型——汇报会化时团队常陷入的模式。讨论在会议中就开始，15分钟延长到30分钟、40分钟。虽然会议中就有了讨论，比单纯汇报会来得前进，但为满足少数人的讨论让所有人都参与的时间每天都会积累。

 这五种模式表面看似不同，但它们的根本误解是相同的：即认定“每日站会是一个共享信息的场所”。基于这个前提出发，就会自然得出“只要完成了信息共享会议就算成功”、“如果花费时间过长就延长会议”、“如果想共享的人增加就让他们一起参加”等一系列判断。五种模式不过是这一前提的直接产物。

 接下来，思考一下开头提到的“被告知要把会议控制在15分钟内时产生的三个疑问”。

 首先，**仅仅共享就结束有什么不好？**进度共享本身很重要，也没错。问题在于手段。人声逐个按顺序共享，是所有共享方式中成本最高的。如果8个人，15分钟，每天要耗费2个小时的工时。且汇报会型的共享偏向于“顺利”，信息质量也往往下降。如果只是信息共享，使用任务看板和燃尽图更便宜、更准确、随时可见。也就是说，在汇报会型的每日站会上，团队把可以通过看板更好完成的事情用时间做了，却没有做任何会议才能完成的——决定事情。并不是共享本身有问题，而是只做了共享这一件事才是问题所在。

 其次，15分钟能做什么？即使花30分钟全员共享，难道不更重要吗？确实，15分钟对信息共享来说太短，但足以决定今天如何行动。确认与目标的距离，确定当前最危险的一个事项，然后决定谁和谁之后要进行讨论。不是做简报，而是分诊时间。如果信息是“所有人都需要的”，即使花30分钟也应共享。但实地统计发现，所有人都需要的信息不过只有与目标的距离，剩余大多数信息只需2～3人知晓。30分钟的每日站会往往是“少数人需要的讨论，却让所有人都听”的时间。把所有人都需要关心的事项留给全员，其他事项只让相关人员参与，这是每日站会的设计，而15分钟的时限正是“所有人都关心的事情也就那么多”的经验法则体现。如果你觉得每天需要30分钟，请把它当作警告，意味着你的目标不明确、事项过于庞大或看板无法承担信息共享这三者中的某一项出了问题。

 那么，真正的每日站会应该用来做什么？Scrum 的基本是经验主义，其支柱为透明性、检验、适应三大原则。每日站会是每天运行这三者的最小循环。
 透明性——对冲刺目标，什么已完成、什么未完成，所有人都能同样地看见。这是看板的工作，而非会议的工作。会议以可见信息为前提开始。
 检验——将可见信息与目标对照，确认“这样下去能赶上进度吗？”、“今天最危险的地方在哪里？”。
 适应——根据检验结果，改变今天的行动。谁先做什么，谁帮助谁，什么事项后置。检验与适应共同构成了每日站会的核心内容。

 这样一来，就能清楚地看到在汇报会型的每日站会上发生了什么。为了在会议上实现透明性而用尽了15分钟，却没有进行检验和适应。我们要将会议从“解释昨天自己做了什么”的场所，转变为“决定今天团队行动”的场所。如果这一点偏离，其他一切都会偏离。

 而适应的内容，就是开头提问中所说的“会议结束后立即开始的讨论”。这并不是要取消讨论，而是要由每日站会有意引发讨论。不过，要在15分钟内完成所有讨论本就不现实。如果让各个讨论分散进行，信息共享功能会失效；如果让所有人都参与所有讨论，又会夺走撰写代码的时间。因此，每日站会在讨论上的作用，就是“明确需要讨论的事项和对象”。“谁和谁、关于什么、随后讨论”即是每日站会的成果物。15分钟不是“不得不在会内完成所有讨论的时间”，而是用来检验，并决定接下来与谁以及就何议题进行适应的时间。

 以下各项解决方案都是手段。关于如何推进每日站会，有资深人士提供了各种提议，选择哪一种都可以。但如果只是照着做，获得“做到了”的感觉就结束，那与照本宣科地念三大问题台本没有区别。试用之后，请根据透明性、检验、适应哪一方面得到了充实，来判断对自身团队有效的做法。

首先，记录一周内每日站会结束后的讨论
 在修正之前，先进行测量。请在一周内记录每日站会结束后立刻开始的讨论，只需记下“谁和谁”、“关于什么”、“持续多少分钟”三项即可。将一周的数据并列，就能得到团队每天早上真正需要讨论的议题清单——当前15分钟未覆盖的实测内容。谁在等谁，讨论集中在哪些事项，同样的两个人是否每天都在谈论。有了这份记录，后续方案的推进就会容易得多。“要改变每日站会”的提案往往会遭遇阻力，但如果你提出“上周每日站会后平均产生40分钟的讨论，能否将这些内容纳入15分钟内？”带着数字的提案会更具说服力。

改变提问方式
 停止询问“昨天做了什么”，尝试改为：

• “为了实现冲刺目标，目前最危险的地方在哪里？”
• “今天将与谁解决什么问题？”
• “能按时完成吗？”

 将话题重心从个人行动确认转向与目标的距离，报告自然就会变为讨论。

不按人，而按任务看板顺序进行
 将发言顺序从“按人顺序”改为“按 PBI（产品待办项）顺序”的方法也很有效。从任务看板的最右侧——最接近完成的事项——开始，逐个询问“要今日完成此项，应如何进行？”。主语从“我”变为“该事项”，对话便从责任人的工作汇报转向团队的交付战略。这也能培养优先完成已着手事项的意识，一举两得。远程团队同理，只需屏幕共享看板后从右侧依次“走”，注意不要回到“依次展示头像报告”的模式。对于日报型团队，可将发布格式改为“今天向谁请求什么”“正在等待谁的什么”，并让被点名者承诺作出回复。有了收件人，即便是文本形式，也能变成讨论。

听众配置调整实验
 对于报告收件人总是对领导的团队来说，让领导（或 Scrum Master）退到团队圈外一步，或干脆不出席，是个有效实验。失去既定收件人的报告会寻找新的倾听对象，转向队友。听上去或许有些激烈，但“没有我就开不了站会”的状态，对领导来说才是危险信号。进行此实验前，请通过任务看板或燃尽图等“想看就能看”的方式保障进度掌握。若要减少汇报场合，务必先搭建好信息存放之所。

为外来人员安排座位
 若已陷入客户汇报型，请在“赶走”发包方或管理者前，先为他们安排座位。若他们想了解进度，就公开看板和燃尽图，让其随时查看；若想参与决策，那就邀请到冲刺评审（我们后续会讲）。如果他们仍坚持要参加每日站会，请让其承诺“不发言，将问题留到评审会上提出”。若对方无法遵守承诺，团队就应意识：只要那个人在场，站会就会退回到汇报会。

兼任成员只报告在本团队可用的时间
 这是针对其他项目汇报型的方案。兼任人员应汇报“对于本团队目标，今天能投入多少时间”。“今天我在本团队可用2小时，并可完成对该事项的确认”就足够。让他们先宣告可用时间，其余成员就能据此安排当日行动。在兼任较多的团队中，如果将这份宣告作为每日站会的开场发言，后续讨论会更加具体。

将“谁和谁、关于什么、随后讨论”作为成果物
 请在每日站会上正式宣告“谁和谁、关于什么、随后讨论”，并将其作为每日站会的成果物，然后仅让相关人员会后留下继续讨论。若出现延长战型，不要让所有人都被束缚在同一讨论中，而要划分出“该讨论随后由谁和谁进行”，然后继续推进。这就是此阶段 Scrum Master 的主要职责。

 晨会本身并非 Scrum 所创。许多组织早已有“早会”或“进度确认”的文化，而每日站会总是在这些既有模式上覆盖安装，且常常失败。由于外观（每天早上、短时间、站着发言）相似，哪怕实质已从“向管理者汇报”变为“团队再规划”，也无人察觉。

 每当有新成员加入，他们都会带来以前职场的“早会”模式。因此，这个问题会在团队换代时反复上演。应对方式也始终相同：不是关注形式，而是确认收件人与目的。团队能否用自己的话回答“这15分钟是为谁服务、用来决定什么的？”换言之，检查今晨15分钟内是否进行了检验与适应，这就是每日站会的健康检查。

下次: 「回顾会议无法发挥作用……相同的改进方案再重放与待办事项列举会」