众所周知，敏捷团队每天要召开每日站会。《Scrum指南》中，将每日站会称为“Daily Scrum”，并给出了建议的会议组织方式——在会议上向团队成员提三个问题，分别是：
- “昨天，我为帮助开发团队达成 Sprint 目标做了什么？”
- “今天，我为帮助开发团队达成 Sprint 目标准备做什么？”
- “是否有任何障碍在阻碍我或开发团队达成 Sprint 目标？”
然而许多团队把这个实践方式实施成了：让团队成员逐个回答三个问题。其实，这是一种对《Scrum指南》的误解。这种做法并不是一种好的实践方法，甚至可以认为，这是一种每日站会的反模式。
今天，我将与大家一起探讨和分析为什么不应该在每日站会上让开发团队成员逐个回答这三个问题，以及我们该如何正确的组织召开每日站会。每日站会的关注焦点应该是“尽快完成故事”
首先，我探讨一下每日站会的目标和关注焦点。
每日站会，是团队自组织检视Sprint进展的协作机制，其主要目的是：
- 检视Sprint目标的完成进度。
- 暴露问题和障碍，促使问题和障碍得到及时应对和解决。
- 规划当天的团队目标和工作任务安排。
需要注意的是：按照敏捷原则，Sprint进度的衡量基准，应当是“已完成的故事”。团队应定义故事的“完成”标准。通常，故事的完成标准，至少会是通过测试。
图1 燃尽图
通常我们会使用燃尽图（如图1所示）来分析Sprint进度的正常情况。燃尽图上包括以下要素：
- 横轴，是时间轴。
- 纵轴，是剩余工作量，其单位为故事点。
- 进度曲线（蓝色），体现了截止当前时间，本Sprint还剩多少故事点数没有完成。
- 参考线（红色），是分析Sprint进度是否正常的参考基准。如果进度曲线位于参考线上方，则表示进度已经延期。
为了控制Sprint的进度风险，我们期望能够尽快地完成一个个故事的开发和测试，以便使燃尽图上的进度曲线处于正常状态。
所以，每日站会关注的核心焦点是“故事完成情况”以及如何“尽快完成故事”，而不是其他。
为什么不应当在每日站会上向团队成员提三个问题
Scrum的开发团队是一个全功能团队，但非所有人都是全栈工程师。这就意味着，完成一个故事的开发和测试，往往需要多个人员来协作完成。例如：一个典型的web开发故事，往往需要1个前端开发工程师、1名后端开发工程师和1名测试工程师来协同完成。而对于规模较大的故事，则往往需要更多人员协作。
当一个故事需要多人协作完成时，如果每日站会的组织形式是向每个开发人员提出三个问题，就会导致两个严重问题：
问题1：使每日站会，失去了对“故事完成情况”的关注。当在询问一个个团队成员这三个问题的时候，我们关注的不再是“故事完成情况”和如何“尽快完成故事”，而是“任务进展”和“人员工作饱和度”；这就使得每日站会不再以如何“尽快完成故事”为管理目标，从而使得团队成员的任务安排也不再以“尽快完成故事”为目标。
问题2：当每日站会关注“单个团队成员”时，极容易使每日站会变成一个个团队成员向ScrumMaster的“工作汇报会”，这会严重破坏了自组织文化的建设。
所以说，每日站会上向团队成员提三个问题，其实是一种反模式。
应该如何正确组织召开每日站会
每日站会的目标是“尽快完成故事”，其组织形式应该是：
- 围绕故事来回顾和规划工作。
- 基于燃尽图来检视进度情况。
以下提供一套行之有效的操作方法：
1）我们应当按照故事的优先级，对于一个个故事进行回顾和规划：
- “昨天，我们完成了这个故事的哪些任务？”、“昨天，我们完成了哪些故事？”
- “今天，我们计划完成这个故事的哪些任务？”、“今天，我们计划完成哪些故事”
- “是否有任何障碍在阻碍我们尽快完成这个故事？”、“是否有任何障碍在阻碍我们完成Sprint目标？”
直到所有团队成员的工作均以排满，直到所有的问题和障碍都已经有了应对措施。
2）打开燃尽图，我们来检视Sprint进度的正常情况。如果迭代进度曲线严重落后于参考线，则意味着Sprint目标的达成风险较大。这种情况下，我们可能要组织召开一次Sprint的重计划会议，确认剩下的工作如何进行调整或重新计划。
您有何经验
您是如何组织召开每日站会的？您会在每日站会上问挨个问团队那三个问题，还是会围绕故事来作回顾和规划，以及使用燃尽图来分析进度正常情况？
欢迎在评论区留下你的观点。
本文作者：
李洁（Jerry Li），CSP，CSM，Scrum中文网资深敏捷顾问和培训师，敏捷教练
