每日站会和站立会议 — 是什么，每日会议规则及好处

什么是每日站会和站立会议？

每日站会（Daily Standup，每日站立会议）—— Scrum团队的简短会议，每个工作日在同一时间和地点举行。时间盒——15分钟。有不同名称：Daily Scrum（Scrum指南中）、晨间同步、morning circle、每日站会。目标是同步团队、发现阻碍并调整当日计划。每日站会不是给经理的报告，而是团队自我组织的工具。由团队决定如何组织会议，而不是经理。

“站立会议”这一术语的来源——字面意义上在会议期间站立的做法：参与者聚集在展板前不坐下。这营造了临时感——没有人想站立超过15分钟。实体站立会议仍被60%的团队使用（根据Scrum.org 2025的数据），其余团队已转为通过Zoom、Slack Huddle或Teams进行远程形式。在远程形式中，保持纪律很重要：开启摄像头，避免多任务处理，提前思考答案。

Scrum Guide 2025将Daily Scrum定义为面向开发人员（Developers）的活动。产品负责人和Scrum Master可以参加，但非必须。如果PO或SM参加——他们不管理会议。团队自行选择结构：经典三个问题或看板巡视（board walk）。关键：每日站会关于检查向冲刺目标（Sprint Goal）的进展，而非每个任务的状态。如果会议变成列举看板上的任务——团队已失去对冲刺目标的关注。

每日站会的三个问题

问题1：“我昨天为实现冲刺目标做了什么？”——已完成任务的简短列表。不是“我在做APP-123”，而是“完成了登录界面，PR已发送审查”。“为实现冲刺目标”这一表述并非偶然——它将日常工作与冲刺的整体目标联系起来。如果开发人员看不到自己的任务与冲刺目标的关联——这表明该任务在当前冲刺中不需要。在移动开发中，昨天的结果不仅是代码，还有测试、文档、CI/CD配置。

问题2：“我今天计划做什么来实现冲刺目标？”——当天的计划。不超过2-3项。开发人员可以说：“今天我将完成个人资料页面的ViewModel，编写单元测试，在真实设备上运行构建”。如果计划与“昨天”相同——这表明任务太大，需要分解。两天规则：如果任务在2个工作日内未完成——应拆分为子任务，否则将卡在In Progress中数周。

问题3：“哪些阻碍影响我的进展？”——最重要的问题。阻碍是指开发人员无法独自解决的事情：等待审查（如果审查SLA已过期）、模拟器不工作、API未准备好、需要访问代码仓库。重要：阻碍应被提及，但不在每日站会上解决。会议后，开发人员和Scrum Master/经理商定解决方案。根据Scrum.org（2025）的数据，移动团队70%的阻碍与以下相关：等待审查（30%）、测试设备不可用（20%）、对后端的依赖（20%）。

如何正确召开站立会议

时间和地点。每日站会每天在同一时间举行——通常在一天工作开始时（9:00-10:00）。对于分布式团队，选择对所有时区都舒适的时间。时长——严格15分钟。计时器——必需。如果团队无法在规定时间内完成——问题不在于每日站会，而在于过程：要么参与者太多，要么任务被讨论而不是仅仅被提及。乒乓规则：每位参与者发言不超过60秒。回答后，将发言权传递给下一位。

“看板巡视�形式（Board Walk）。三个问题的替代方案：团队依次在Scrum看板上移动任务，评论变更。开发人员从“待办”中取出任务，移至“进行中”并说：“我接手APP-123——订单页面，添加促销代码字段”。看板巡视提供对进展的直观理解，并揭示“被遗忘”的任务——那些超过3天未移动的任务。看板巡视更优适用于使用Jira/Linear的分布式团队——所有人都看到看板，而不是听独白。

对于远程团队：必须开启摄像头——根据Microsoft Research（2025）的数据，开启的摄像头可将参与度提高40%。使用共享屏幕显示任务看板（Jira、Linear、Miro）。在聊天中写下阻碍——这创建书面记录。鼓励使用表情符号反应（除用户指令外——不使用表情符号）——对同事消息点赞。每日站会后——2-3分钟用于“停车场�（parking lot）：需要单独讨论的主题记录在后续会议列表中。Scrum Master的关键技能：在每日站会上停止讨论并将其转移到停车场。

召开时的典型错误

错误1：给经理的状态报告。开发人员依次阅读Jira中写的内容，经理提出澄清问题，会议持续45分钟。解决方案：提醒每日站会是为团队而非经理准备的。经理可以从看板了解状态。如果经理提问——将其转移到一对一会议。将每日站会变成报告的团队每周损失2-3小时（所有参与者合计）。对于8名开发人员，这相当于每月16-24人时——每年损失整个冲刺。

错误2：当场解决问题。开发人员说“我的gRPC出了问题——项目无法构建�，整个团队讨论20分钟解决方案。解决方案：将阻碍记入停车场，继续每日站会。会议后——召集相关方（开发人员+可以提供帮助的人）进行10分钟讨论。根据Basecamp（Shape Up）的数据，每日站会上发现的问题只有20%需要整个团队讨论。其余由几名开发人员在10分钟内解决。

错误3：迟到和缺席。有人在开始后5分钟才到——需要重复。解决方案：制定规则“每日站会准时开始，迟到者不得入内”或“迟到者支付罚款�（为团队买咖啡）。更严格：每日站会在同一时间举行，如果有人系统性迟到——这是他的纪律问题，在一对一会议中解决。每日站会是全天的同步。如果开发人员缺席——他未同步且面临做团队不需要的工作的风险。

错误4：参与者过多。15+人的团队，每人发言一分钟——总共20+分钟。解决方案：将团队按功能/模块分为小组。每个小组召开自己的每日站会（5-7人）。小组的一名代表可以参加公共跨团队站立会议（如果需要团队间的同步）。替代方案：通过Slack/GeekBot进行异步站立会议，每个人写下已完成/计划/阻碍。

异步站立会议：替代方案

异步站立会议——参与者在聊天（Slack、Telegram、Teams）或专业机器人（GeekBot、Standuply、Status Hero）中写下回答，而非口头会议的形式。适用于时差3小时以上的分布式团队。每位参与者在规定时间前（例如11:00前）回答相同的三个问题。机器人收集答案并在公共频道发布摘要。优点：灵活性、书面记录、无迟到问题。

异步形式的缺点：缺乏实时交流——丢失非语言信号，更难发现阻碍（开发人员可能不写问题）。写在聊天中的阻碍可能到当天结束时仍未被注意。根据GitLab（2025）的数据，40%转为异步站立会议的团队在3个月内回到了口头形式。建议：使用混合形式——3天口头站立会议（周一、周三、周五），2天异步（周二、周四）。或者：口头站立会议每周1-2次，其余天数——异步。

异步站立会议的工具：GeekBot（Slack）——提出三个问题，发布摘要；Standuply——与Jira集成，自动跟踪；Status Hero——收集状态并为管理层生成周报。工具的选择取决于团队文化：在初创公司，Slack中的机器人足够；在企业中，可能需要与公司流程集成的Standuply。重要规则：无论形式如何，答案应对整个团队可见，而不仅对经理。透明度是敏捷的核心价值。

移动团队每日站会的特点

移动团队在每日站会上面临特定阻碍。主要：在CI中构建项目（Gradle构建可能花费20+分钟——如果出错，开发人员浪费一小时排查）、等待TestFlight/Firebase App Distribution（向测试人员发布构建需要30-60分钟）、模拟器问题（Android Emulator需要KVM/HAXM，iOS Simulator仅在Mac上）。移动团队的每日站会应包括快速检查构建状态：“构建是否成功？所有测试是否通过？”

对于跨平台项目（Flutter、React Native），每日站会可包括关于共享代码状态的问题。如果两名开发人员同时编辑同一Dart文件，一人合并更改——另一人将面临冲突。建议：在按平台划分的看板上使用看板巡视（Android / iOS / Shared）。这有助于查看谁在哪里工作以及更改是否重叠。对于Flutter项目——使用包含Platform Channel、BLoC/Cubit、UI、Tests列的看板。

发布就绪——移动开发中每日站会的另一个特定要点。在发布前3-5天添加问题：“构建是否准备好发布？所有元数据（图标、截图、描述）是否已更新？”这可以防止开发人员在发布当天完成代码，而构建和发布还需要3-4小时的情况。发布跟踪器——带有检查清单的单独看板：更新versionCode/versionName、检查ProGuard、签署AAB、上传至开发者控制台、发布说明。