万字详解每日站会的各种模式 | IDCF

来源：小船哥说敏捷

作者：adoudou

每日站会已经成为许多团队的常见仪式，特别是在敏捷软件开发中。然而，有许多微妙的细节可以帮助我们区分是在有效的开会还是在浪费时间。

内容大纲

1. 站起来是为了保持会议的简短
2. “好”可能是什么样的？
3. 当人们试图一起工作时出现的一系列特殊问题
4. 每日站会的模式
5. 谁来参加？
6. 我们谈些什么？
7. 我们按什么顺序发言？
8. 何时何地？
9. 我们如何保持精力充沛？
10. 我们如何培养自主性？
11. 我们如何知道站会进展不佳？
12. 这真的只是每天一起站起来而已。

一、站起来是为了保持会议的简短

每日站会（也称为“每日Scrum”、“每日小会”、“早晨点名”等等）描述起来很简单：

整个团队每天都会开会快速更新状态。站起来是为了保持会议的简短。

就是这样。

但这个简短的定义并没有真正告诉你通过哪些细节来区分团队是在有效的开会还是在浪费时间。

那你怎么能知道呢？

对于有经验的从业者来说，当站会出现问题时，他们会本能地知道该如何调整来解决这个问题。

但是对于新手来说，当进展不顺时，他们不太可能知道该怎么做……而且更有可能的是，在没有外在帮助的情况下，他们会干脆完全放弃这一实践。

如果出现这种情况那将是很不幸的，因为运行良好的站会会给团队带来巨大的价值。

为了解决这个问题，重要的是要明确每日站会常用模式的收益和问题。这些每日站会的模式可以帮助经验不足的从业者，也可以提醒经验丰富的从业者关注他们直觉背后的原因。

二、“好”可能是什么样的？

随着音乐的想起，就像巴甫洛夫的铃声一样，团队会在没有任何额外提示的情况下起身走到贴满卡片的看板前站好。这首特定的歌曲会在每天早上同一时间循环播放。一些人将卡片移动到工作流的正确位置，或者在不同颜色的便利贴上贴上附加说明。一些对项目感兴趣的项目组之外的人也在这里徘徊，查看工作的进展情况。

注意到大家都在看板墙边准备就绪，团队负责人启动了团队之前购买的一个大屏计时器：他们对每日站会实际花费的时间很感兴趣。

一个团队成员站出来谈论看板最右侧最靠近部署点的卡片。他的部署脚本仍然存在一些问题。另一个小组成员说她可以帮助解决这个问题。人们按照从右到左，从上到下的顺序阐述每个工作项的情况，如果其他人能帮助解决障碍他们就会自行发言。另一边，团队负责人正在改进板上记录提出的障碍。

有一次，大家在探讨如何处理一个特定问题时讨论的时间略长。注意到有一个停顿，团队负责人正准备举起手指打断他们……就在这之前，其中一个团队成员建议他们应该线下再讨论。

不久之后，所有的卡片都被覆盖到了，团队负责人问还有没有人要补充。有人提出她有一个关于新功能的有趣想法，该想法可能会使一些计划中的需求变得更好。这激起了总是试图参加站会的产品经理的兴趣，他们都同意在会后继续讨论这个问题。

当团队开始进行传统的结束仪式时，大家齐喊口号：“1…2…3…精益求精！”团队负责人翻了个白眼，这不是他的主意，但他不得不承认，这让站会在愉快中结束。

人们分散开并开始讨论提出的各种事情，包括障碍、新想法以及关于某些工作项的问题。

三、当人们试图一起工作时出现的一系列特殊问题

当一群人试图作为一个团队一起工作时，每日站会是一种针对一系列特定问题的重复性解决方案。

每日站会是一种定期同步的机制，以便团队…

• 分享对目标的理解。即使一开始我们就认为彼此对目标达成了一致理解（也可能理解并不一致），我们的理解也会发生变化，同时我们所处的环境也会发生变化。如果一个“团队”的每个成员都在为不同的目标而努力，那么这个团队往往就会很低效。
• 协调工作。如果工作不需要协调，你就不需要一个团队。反之，如果你有一个团队，我认为工作就需要协调。团队成员之间的协调不力往往会导致糟糕的结果。
• 分享问题和改进。团队相对于独自工作的主要好处之一是，当有人遇到问题或发现更好的方法时，团队成员可以互相帮助。如果一个“团队”的成员不愿意分享问题和/或不愿意互相帮助，那么这个团队往往也会很低效。
• 认同为一个团队。如果你不经常与团队接触，就很难在心理上认同这个团队。即使你相信他们能力很强并有着相同的目标，你也不会产生强烈的归属感。

四、每日站会的模式

每日站会的模式通过回答以下问题来给出：

• 谁来参加？
• 我们谈些什么？
• 我们按什么顺序发言？
• 何时何地开会？
• 我们如何保持精力充沛？
• 我们如何培养自主性？

五、谁来参加？

5.1 全体人员

以下人员和代表都可出席：其他领域（如市场、生产支持、高管、培训师等）的人、希望了解项目状态和进展的人、在必要时可以贡献出自己一份力量的人。在多个会议和报告中传达项目状态需要大量的重复工作。

因此

用每日站会来取代部分或全部会议和报告。任何直接参与或想了解项目日常运作的人都应该参加这唯一报告项目状态的会议。

但是

如果有人之前没有参加过每日站会，他们可能不知道会议的流程，他们可能会做出一些扰乱站会秩序的行为。这可以通过提前告知新参与者和观察员预期的行为规范来解决。

并非所有形式的报告内容都会（也不应该）被站会所涵盖。例如，项目的整体进展可以通过一个大型可视化图表[1]进行沟通，这个图表可以是燃尽图[1]、燃起图、累积流图等等。

5.2 工作项也要出席

也被称为：以故事为中心的站会

如果故事对项目至关重要，它们就应该在站会上发言。

——Brian Marick, Latour 3: Anthrax and standups[2]

人们有时会过度专注于跑者，而忽略了指挥棒。也就是说，每个人都很忙，但工作项却没有取得应有的进展。

因此

与其把每日站会视为是人的仪式，不如把它视为是工作项（例如，敏捷开发中常用的用户故事）的仪式，人们参会只是为了替工作项发言……因为很显然工作项是不会说话的。

昨天-今天-障碍的问题仍然可以使用，但会从工作项而不是人的视角来使用。这也意味着可能并不是每个人都会发言，我们没有义务说任何与工作进展无关的事。

因为有了更清晰的焦点，人们才更有可能在没有提示的情况下提出障碍，并登记和解决障碍。

但是

不要求所有人都发言可能会掩盖那些害羞或不愿意说话的人的问题[3]。这在以工作项为重心的情况下更难发现。

六、我们谈些什么？

6.1 昨天-今天-障碍

也被称为：三个问题

有些人很健谈，并且倾向于在讲故事的时候发散很多东西。还有些人在听到一个问题后就想立即解决这些问题。时间过长的会议往往会导致大家注意力不集中，与长时间讨论没有直接关系的参与者往往就会分心。

因此

可以用以下的格式来组织每日站会：

• 我昨天完成了什么？
• 我今天要做什么？
• 哪些障碍阻碍了我的进展？

这些是满足每日站会目标的最小子集的问题。其他的讨论话题（如讨论设计、闲聊等）应该推迟到会议结束后进行。

Olve Maudal建议，这些问题的顺序应该倒过来，以突出问题的重要性：

• 哪些障碍阻碍了你的进展？
• 你今天在做什么？
• 从昨天开始你完成了什么？

——Olve Maudal，每日站会-也许第三个问题应该先说？[4]

Lasse Koskela以另一种形式提出了这些问题，他强调团队成员不应该向领导汇报：

每个团队成员依次向他的队友提供3条信息：

• 自昨天会议以来我所做的事情
• 我今天要完成的事情
• 我需要别人帮忙解决的障碍

——Lasse Koskela，关于Scrum和三个问题的诅咒[5]

Jonathan Rasmussen提供了不同的措辞，以改变站会的态势：

• 你昨天为改变世界做了些什么？
• 你今天打算如何将其完成？
• 你打算如何清除那些挡在前进道路上的障碍？

回答这类问题会完全改变站会的态势。以前你只是站在那里并介绍一些近况，而现在是向全世界宣布你的意图。

——Jonathan Rasmussen，《敏捷武士》[6]

也有一些团队增加了额外的问题：

• Buffer添加了一个环节，人们可以分享他们正在努力提高的领域。[7]
• Thomas Cagley建议寻找风险。[8]
• Mark Levison发现添加更多有针对性的改进问题很有用。为了适应具体的环境，最后两个问题可能需要被修改。

• 你昨天完成了什么？
• 你今天承诺做什么？
• 你的阻碍/障碍是什么？
• 你昨天发现了什么代码坏味道/缺失单元测试/…？
• 你昨天对代码做了什么改进？

——Mark Levison，每日站会的变量[9]

但是

每日站会问题的结构只是手段，在站会上同步进度、问题、风险、障碍等项目信息才是目的。如果通过这些结构化的问题我们收集不到想要的信息，那么就要考虑换一个问题清单了。随着团队的成熟，你可能会发现你想调整这些问题的结构，这也反映了这种模式是如何演进的。

更严重的问题是，昨天-今天-障碍可能会造成对个人承诺的过多关注，而不是关注正确的事情……这个问题可以参考“走板”。

6.2 改进板

也被称为：阻塞板、障碍板、改善报（Kaizen Newspaper）

在站会中提出的障碍没有被及时解决或以其他方式解决。

因此

将提出的障碍张贴到改进板上。这是一个公开可见的白板或图表，用于记录已提出的障碍，并跟踪其解决进度。改进板可以在站会之外进行更新，并作为一种更直接、也许对抗更少的方式来初步提出障碍。一个常见的错误是描述障碍的字写得不够大，导致人们无法从远处阅读它。

把一个问题写下来并明确地承认它，这个行为是减少冗长讨论的非常简单、可靠的方法。因此，即使不是每个人都同意某个特定事项是一个障碍，也值得把它简单地记录下来，以便在会后讨论。

在每个提出的障碍上可以包括一个发生次数的统计，这样可以突出哪些问题通常更重要，需要首先处理。

改进板的设计可以有几种不同的方式。例如，一个板的结构如下：

问题	计数	抑制	对策	状态
问题名称	持续发生的次数	短期解决方案	基于根因分析的长期解决方案	计划（Plan）-执行（Do）-检查（Check）-行动（Action）

另一种风格更像是一个任务板：

待处理	处理中	已完成
索引卡代表提出的障碍	当我们开始处理障碍时，它们会移到这里	当我们解决了障碍时，它们会移到这

但是

如果在改进板上提出了太多团队无法解决的障碍，那么改进板就有可能演变成一个抱怨板。

七、我们按什么顺序发言？

7.1 最后到达最先发言

在站会开始前，与会者需要知道谁应该先发言。由主持人决定谁应该先发言是一种微妙的、但肯定是反自组织的模式。团队应该知道谁先发言，而无需任何干预。

因此

同意最后到达的人最先发言，这是一个简单的规则，同时它还有一个好处，就是鼓励人们准时出席站会。

但是

最后到达的人也可能是最没有准备好开始会议的人。

7.2 顺序发言

在站会期间，与会者需要知道接下来应该由谁发言。由主持人决定谁下一个发言是一种微妙的、但肯定是反自组织的模式。团队应该知道下一个发言的是谁，而不需要干预。

因此

使用一个预先确定的简单规则（如顺序发言）来确定下一个发言的人，顺序是顺时针还是逆时针并不重要，重要的是由团队主持会议，而不是由主持人或经理主持。

7.3 传递令牌

在简单的、可预测的排序机制下（如顺序发言），与会者很容易忽略其他人的发言，直到接近轮到自己时才会集中注意力。在没有轮到自己时，他们可能会想一些其它事情，而不是注意别人在说什么。

因此

引入一个不可预测的排序机制，比如使用发言令牌（比如，一个球）来决定接下来谁应该发言。有了发言令牌，也就简化了决定谁先发言的过程，因为这将是碰巧拿到令牌的人（或他/她将令牌扔给的第一个人）。

传递令牌为每日站会带来了一些乐趣，同时避免了大家注意力可能不集中的问题。

我第一次了解到这种模式是在我和Simon Stewart合作的一个项目中。我们当时用的是一个小杂耍球，但几乎任何东西都可以用作令牌。其他团队也用过橄榄球，甚至是毛绒玩具。

但是

对于较大的团队，可能很难记住谁已经发言了。在这种情况下，继续使用像顺序发言这样的简单机制可能会更容易。

根据组织甚至团队的文化，拿一个球传来传去看起来可能不太专业，并且可能会让人对每日站会这个基本仪式产生不必要的负面看法。

7.4 拿一张卡片

在站会期间，与会者需要知道谁应该先发言，之后谁应该接着发言。由主持人决定谁应该发言是一种微妙的、但肯定是反自组织的模式。团队可能并不热衷于传递令牌，因为通常他们手中拿着咖啡杯。

因此

可以让每个团队成员拿一张卡片来决定发言的顺序[10]。想象一下，有一叠卡片，每张卡片上都有一个数字，当每个团队成员来到会场时，他们可以选择一张卡片，然后告诉他们以什么顺序发言。

7.5 走板（Walk the Board）

又称作为：走墙

站会让每个人都忙碌起来。走板使每个人都集中在最重要的事情上。

——Bret Pettichord通过推特发送

传统形式的另一个问题是，任务或工作流的讨论并不连贯；相反，每个主题都会随着团队成员发言的顺序而短暂地出现。这可能使人很难分辨出到底发生了什么。

——Dave Nicolette，每日站会的另一种形式[11]

人们更专注于繁忙的工作，而不是真正的工作进展，所以这促使你切换到了让工作项出席而不是人出席的模式。然而，即使采用了这种专注于工作项的站会，在使用了诸如顺序发言或传递令牌等排序机制时，仍然很难理解项目的状态如何。

因此

走板，即通过走过可视化看板/任务版上的每个工作项来组织站会。

大多数敏捷和精益团队都会使用一个可视化管理系统来展示正在处理的工作。对于敏捷软件开发来说，这个可视化管理系统可能被称为“任务板”、“故事墙”或“看板”。这些板将展示工作项将流转的流程。进展通常是通过在板上移动卡片来表示。理想情况下，工作项的上下位置将表示优先级。

有了这个板，参加站会的人会从流程结束到流程开始（例如，从右到左）以及从最高优先级到最低优先级（例如，从上到下）的顺序检查工作项的进度。你甚至可以在板上明确指出应该使用什么顺序。

Pawel Brodzinski提出了一个默认顺序[12]：

• 阻碍事项
• 加急或紧急工作项
• 自上次站会以来没有移动的工作项（可能被卡住了）
• 其他一切按优先级排列

但是

显然，拥有一个看板/任务板是一个先决条件，但这并不是所有的团队都会有的。在这种情况下，逐人发言的模式会更合适。

如果不采用轮流主持或其他自组织的模式，走板更容易走向向领导汇报的泥潭。

八、何时何地？

8.1 在工作现场开会

在工作现场开会，而不是在会议室。

——Marc Graban，Everett诊所的每日聚会视频[13]

工作场所有许多关于正在发生的事情的记忆触发器。

我们也不希望这种每日会议需要大量的精力来查找、预定并走到会议室。

因此

在工作现场开会，而不是在会议室。如果你有一个“故事墙”或“看板”，最好就在它前面开会。

但是

在“故事墙”或“看板”前面开会，会议的噪声可能会打扰到附近的人。这通常表明工作空间的设计是有问题的，但必须承认这个问题的存在。

8.2 同一地点，同一时间

我们希望团队对会议有一种主人翁的感觉。我们也希望感兴趣的利益相关者能够前来观看站会，以避免安排另一个类似的状态同步会议，如果允许某个团队成员随意推迟时间或改变地点，这些好处都将难以实现。

因此

让团队达成一致并在同一地点、同一时间举行每日站会。不要等待迟到者，包括架构师和经理。会议是为整个团队开的，而不是为某个特定人开的。如果你使用站会作为一天工作的开始，这一点尤其重要。

一些更严格的团队可能会对迟到者处以罚款。我倾向于对任何形式的惩罚机制保持谨慎，而是更喜欢把这些事情拿出来公开讨论。

但是

同一地点，同一时间并不是盲目地僵化。这里要重点强调的是，开始时间要基本一致，重新安排时间的情况应该会很少。如果需要经常重新安排会议时间，这可能是一个迹象，表明开始时间应该调整。如果一个特定的地点对每个人来说都很不方便，这可能也是一个迹象，表明这个地点应该调整。

8.3 使用站会作为一天工作的开始

每日站会提供了对未决问题的关注和觉察。如果站会发生在一天的晚些时候，这种关注和觉察就会被浪费掉。

因此

使用站会作为一天工作的开始。由于很多公司采用弹性工作时间，并不是每个团队成员都会在同一时间赶到工作地点，应对“弹性工作时间”的一个常见做法是使用一组核心工作时间，即在某个时间段内团队成员是都在公司的（例如，中午12点到下午4点）。站会开始时间应该是在这组核心工作时间的开始。同样，如果团队成员因个人原因经常需要晚一点到达（例如，需要送孩子上学），那么开始时间应该设定在一个让所有人都能参加的时间。

但是

在站会之前，人们可能会倾向于不处理任何与项目相关的任务。如果站会很晚才开始，工作时间的浪费可能就很严重。一般情况下，人们可能只会用来做一些检查电子邮件、填写时间表等工作。但将站立作为“一天的开始”，并将其安排在一天的晚些时候，这个实践或许值得研究一下。

8.4 不要使用站会作为一天工作的开始

站会往往作为设定一天工作焦点的仪式，特别是如果你使用站会作为一天工作的开始。正因为如此，团队成员往往在站会之前不会去做开发工作。当站会开始较晚时，这种倾向可能会对生产力产生重大影响。

因此

不要使用站会作为一天工作的开始。不要把每日站会安排在早晨举行，这样就不会在心理上把它当成一天的开始。

但是

如果每日站会不是一天的开始，那么它就不能再用作在一天开始时设置团队工作焦点的共同的仪式了。根据团队的不同，这个代价可能抵不上效率的明显提高。

当有很多项目使用站会时，可能会有多个站会同时举行。对多个项目都感兴趣的观察者可能希望改变站会时间，以便他们都能够参加。这是有问题的，因为如果观察者可以强迫站会调整成他/她的时间表，这会危及团队的主人翁意识。尽管如此，在决定什么时候举行每日站会时，这也必须是一个考虑因素。

九、我们如何保持精力充沛？

9.1 抱团（Huddle）

我经常看到的一个问题是，人们倾向于将每日站会当做简单的个人报告。“我做了这个…我会做那个”——然后转向下一个人。更为理想的方法是更接近于橄榄球的抱团。

——Jeff Sutherland，每日站会的起源[14]

说话的音量会影响注意力以及沟通的有效性。物理距离会改变沟通所需的音量大小。有些人不会大声说话，而且觉得这样做不舒服。

因此

站会的时候应该更像是一个抱团，而不是一个会议。如果难以听清，就让每个人都靠近一点。除了允许更轻松的说话音量外，身体的距离往往会使参与者更加专注。能够站得更近也是团队成员彼此信任的一种表现。如果大家还不熟悉站会，通常只需用手势招呼人们，并说一些类似“让我们围成一圈”的话就可以开始站会了。如果圈的大小已经有一段时间没变了，在试图缩小圈子以便让人们靠得更近之前，可以考虑解释一下缩小圈子的原因。

但是

团队必须平衡好亲密关系和个人隐私。即使在一个彼此非常信任的团队中，也存在人们因站得太近而不舒适的情况，症状往往是参与者紧张和/或烦躁不安。

9.2 站起来

有些人很健谈，并且倾向于在讲故事的时候发散很多东西。还有些人在听到一个问题后就想立即解决这些问题。时间过长的会议往往会导致大家注意力不集中，与长时间讨论没有直接关系的参与者往往就会分心。

因此

让所有与会者在会议期间站起来。利用站会将身体与感觉联系起来，当会议时间过长时，身体的不适就会提醒与会者。鼓励这样做的一个简单方法是在没有椅子的地方举行会议。

但是

站起来往往会使会议缩短，但并不能保证会议缩短到最佳长度。人们可能会慢慢适应这种不适，而不是尝试去缩短时间。另外，如果会议不会花费太多时间，也不会偏离主题，那么站起来就是一种不必要的仪式了。

9.3 15分钟或更短

大多数人在开长会时都会精神恍惚。以冗长的会议来开始一天的工作，这将是一种可怕的、耗费精力的方式。一个具体的时间要求有助于提醒我们何时应该考虑减少会议的时间。

因此

将每日站会的时间控制在15分钟或更短。一般来说，15分钟后，普通人的注意力就会飘忽不定，这不利于设定工作的重点。

但是

15分钟对于较小的团队来说可能还是太长了。由于注意力的影响，即使对于较大的团队，15分钟也是一个很好的限制。另外，也要注意有可能因为会议时间太短，在会议结束时，与会者仍然不知道发生了什么事，也不知道该和谁谈以了解情况。

9.4 结束的信号

在最后一个人发言后，团队可能不会立即意识到会议已经结束。当人们逐渐意识到会议结束而各自离开的话，这不能让会议在愉快中结束，反而会导致低能量。

因此

用一句话（例如，好了，大家享用午餐吧。[15]）或其他一些动作来表示站会的结束。

9.5 会议时间

很难定性地判断一个会议是否耗时过长，尤其是当它的长度逐渐增加时。

因此

为会议计时并公布结果。大多数时候，与会者并没有意识到讲故事的影响、没有准备好“线下解决”或者没有准备好会议需要多长时间。我们最好让会议时间可量化。

但是

与所有措施一样，除非由于精力问题而又要完成实际的目标，否则不应该强制约束会议的时间安排。一旦目标完成，就应该放弃度量。没有特别原因的度量会导致怀疑和对度量指标的冷漠。

时间是精力、注意力和节奏的代表。比起时间，更要注意这些东西。

9.6 线下解决

有些人在听到一个问题后就想立即解决掉这个问题。时间过长的会议往往使人精力不足，与长时间讨论没有直接关系的参与者往往会分心。承认需要线下进一步讨论以解决提出的问题是很重要的。不过有些人会觉得通过打断别人的发言来维护站会的时间可能让人不舒服。

因此

使用简单而一致的短语（如“线下解决”）提醒此类讨论应该在每日站会之后进行。如果讨论的内容就是闲聊，就不需要再做什么。如果讨论的是问题的解决方案，主持人（最终只应有团队）应确保提名或登记合适的跟进人，以便稍后处理问题。

另外，有些团队使用更多的间接信号。

例如，Mike Cohn描述了一个使用橡胶老鼠来表示“我们正在进入一个老鼠洞”[16]的例子。

Benjamin Mitchell描述了一个两手法则（Two Hand Rule）：

...如果有人认为当前的谈话已经偏离了主题，或者不再有效，那么他们就可以举手。一旦有第二个人举手，那么这就是停止谈话的信号，这时我们就要停止谈话并继续站会的其余部分。站会结束后，发言者可以继续讨论。

——Benjamin Mitchell，陷入冗长的敏捷站会中？试试两手规则[17]

但是

解决问题和澄清问题之间是有区别的。不被理解的信息是没有用的。允许澄清问题的程度应取决于团队的规模以及是否会影响“15分钟或更短”。

十、我们如何培养自主性？

10.1 轮流担任主持人

团队成员倾向于向领导汇报，也就是说，他们只与会议主持人交谈，而不是相互交谈。只有会议主持人在提出和解决与站会有关的流程问题。我们希望团队能够拥有站会的所有权，这就需要消除对单一主持人的依赖。

因此

轮流担任主持人。轮流担任主持人的角色，负责确保人们参加站会并遵守商定的规则。

但是

没有站会经验的团队可以从有经验的教练中学到很多有用的知识。但是更重要的是，应该让团队对站会有更大的主动权。在某些时候，应该根本不需要明确的主持人。

10.2 断开眼神接触

团队成员倾向于向领导汇报，也就是说，他们只与会议主持人交流，而不是彼此交流。我们希望团队能够掌握站会的主动权，这就需要消除对单一主持人的任何依赖。

因此

作为一种巧妙的提醒发言者的方式，主持人应该断开眼神接触[18],让他/她对着团队而不只是对着主持人讲话。这样做的一个方法是四处走动，使当前发言者看不到主持人[19]。

十一、我们如何知道站会进展不佳？

我忍受了三年的定期站会。最使会议痛苦的是我的老板（我叫他Wally）。他召开站会的主要原因不是为了提高效率或拥抱XP，而是为了缩短与产品直接相关人员的互动时间。……然而，对于Wally来说，站会（就像周一早上7点的会议和周五下午5点的会议）是一个忠诚度测试，旨在加强雇主和雇员之间的关系。

——Phillip A. Laplante，站会和交付：为什么我讨厌站会[20]

有一些“味道”是站会出问题的良好指标。需要注意的是，即使没有“坏味道”，也并不意味着站会会顺利进行。这只是意味着它不“臭”。

下面的大多数“味道”都与之前的模式有关。对于那些不在乎站会模式的团队，潜在的问题往往更微妙，这超出了每日站会的范围，人们必须提出自己的解决方案。

11.1 专注于跑者，而忽略了指挥棒

人们过于关注他们正在做的事情，却忽略了他们的努力是否真的在推进工作。重新组织站会，让大家开始关注工作项。

11.2 向领导汇报

团队成员面向经理或会议主持人说话，而不是与团队交流。这表明每日站会是为了经理/主持人而开的，但实际上站会应该是为了团队而开的。有多种方法可以打破这种依赖性：轮换主持人，断开眼神接触，改变昨天-今天-障碍的形式，使用传递令牌，等等。

11.3 迟到的人

这个问题由同一地点、同一时间直接解决，但如前所述，频繁出现这个问题可能表明站会的时间或地点是错误的。

有其他的模式可以用来应对这种情况，例如罚款。然而，我一般不会推荐这种做法，因为它们暗示问题与外在动机有关，而问题更可能是由其他原因引起的。

11.4 站会很晚才开始

因为站会被认为是一天工作的开始，所以很多人在站会之前不会做什么工作。根据早上站会的时间，这可能会对可用的工作时间产生重大影响。这就引出了不要使用站会作为一天工作的开始。

11.5 社交活动

站会的目的之一是增加团队的社交活动。然而，每日站会并不是为了让团队成员在与项目无关的事情上互相“叙旧”。很难提供一些例子来说明社交活动到底是提高了团队建设的水平还是分散了团队的注意力。但每日站会上社交活动的效果，可以从没有直接参与社交活动的参与者的行为中发现。如果他们的注意力仍然很高，那么可能只是团队建设；如果他们的注意力下降了，那么就线下解决，也许还可以提供另一个讨论会来充当冷水器[21]。

11.6 我不记得了

我昨天做了什么？…我不记得了…我今天在做什么？…我不知道…

缺乏准备会导致站会节奏变慢，从而导致能量降低。这也有可能导致15分钟或更短的失败，从而进一步降低能量水平。

避免这个问题的一个好办法是改变站会的方式，让工作项出席，通过走板更新工作项的状态。

否则，想让每个人都能知道昨天-今天-障碍的答案只能期望每个人都很有责任心了。

11.7 讲故事

参与者没有提供问题的简要描述，而是提供了足够的细节和背景，这会导致其他人的注意力被转移。站会的一般的规则是只在站会期间识别障碍，在站会后讨论细节。这可以归纳为“描述标题，而不是整个故事”或“线下解决”。

11.8 解决问题

现在是提出问题和阐明想法的时候，而不是深入解决问题的时候。

——Marc Graban，Everett诊所的每日聚会视频[13]

将站会保持在15 分钟或更短的关键是限制讲故事，不要在会议期间屈服于解决问题。让他们线下解决。

11.9 低能量

低能量可能意味着由于讲故事、解决问题等原因而导致的节奏减慢。在这种情况下，请引导团队成员线下解决。低能量可能还意味着团队规模太大，亦或是站会开始的时间较晚，建议尝试不使用站会作为一天工作的开始来替代使用站会作为一天工作的开始。

11.10 没有提出障碍

也被称为：游记[22]

没有提出障碍可能有几个原因：不记得了，容忍度很高，对提出问题缺乏信任（因为障碍没有被解决），没有方便的提出问题的方式，等等。主持人应注意鼓励人们提出障碍。

引入改进板可以提供一种低对抗的媒介。回顾会[23]是发现障碍没有被提出的根因的有效途径。

11.11 障碍没有被解决

除了指责的环境影响之外，阻止人们提出障碍的最可靠的方法就是不解决它们。为了使人们难以忘记和/或忽视障碍，可以用改进板公开跟踪它们。

11.12 障碍只在站会时提出

站会可以作为兜底障碍的安全网，在最坏的情况下，障碍也会在一天之内被传达给整个团队。然而，站会并不是为了阻止问题在一天内随时被提出和解决。引入另一种实践（如改进板）来提出障碍可能会有所帮助。如果做了改进依然没有效果，可以通过回顾会来分析根本原因。

十二、这真的只是每天一起站起来而已

希望这篇文章能为你提供一些关于有效站会实践的细节和问题常见指标的更多方法。我们应该清楚，每日站会不仅仅是每天站在一起。

最后，重要的是不要太在意每一种模式，甚至是拥有一些“味道”。记住我们要解决的问题：人们是否精力充沛？人们是否在分享问题和想法？人们是否专注于我们的目标？人们是否作为一个团队一起工作？每个人都知道发生了什么吗？

如果你能对这些问题作出肯定的回答，那么会议可能会进行得很顺利。毕竟，这真的只是每天一起站起来而已。

参考资料：

1. http://xprogramming.com/articles/bigvisiblecharts/
2. http://www.exampler.com/blog/2007/11/06/latour-3-anthrax-and-standups/
3. http://blog.mountaingoatsoftware.com/should-the-daily-standup-%20be-person-by-person-or-story-by-story/comment-page-1#comment-23428
4. http://olvemaudal.wordpress.com/2008/05/15/daily-stand-up-meetings-%20perhaps-the-third-question-should-go-first/
5. http://radio.javaranch.com/lasse/2006/05/07/1147034972559.html
6. https://book.douban.com/subject/10789296/
7. http://joel.is/an-invitation-to-come-and-hack-on-buffer/
8. https://tcagley.wordpress.com/2014/07/18/stand-up-meetings-add-ons/
9. https://agilepainrelief.com/notesfromatooluser/2011/01/daily-stand-up-variations.html#.VsoT4ZMrLeQ
10. http://%20web.archive.org/web/20090526072425/http://www.robbyonrails.com/articles/2006/05/29/the-%20daily-stand-up-part-2
11. http://web.archive.org/web/20090611160352/http://dnicolet1.tripod.com/%20agile/index.blog?entry_id=1900488
12. http://brodzinski.com/2011/12/effective-standups.html
13. http://www.leanblog.org/2010/08/video-of-a-daily-huddle-at-everett-clinic/
14. https://www.linkedin.com/pulse/20140926150354-136414-the-origin-of-the-daily-stand-up
15. http://edgibbs.com/2006/08/07/signaling-the-end-of-a-standup/
16. http://www.marketplace.org/2012/02/20/life/hate-those-endless-meetings-try-standing
17. http://blog.benjaminm.net/2012/02/23/overlong-agile-stand-up-two-hand-rule/
18. http://radio.javaranch.com/lasse/2006/05/07/%201147034972559.html#comment1147110635098
19. http://www.netobjectives.com/podcasts/last20060719_podcasts.mp3
20. http://queue.acm.org/detail.cfm?id=957730
21. http://web.archive.org/web/20070103031934/http://www.easycomp.org/cgi-bin/%20OrgPatterns?TheWaterCooler
22. http://blog.jbrains.ca/permalink/stand-updaily-scrum-focus-on-achievement-and-commitment
23. http://www.retrospectives.com/

6月【冬哥有话说】伴你开心一“夏”。今晚8点，无敌哥分享《敏捷项目管理到底是个啥》，关注公众号回复“开心”可获取直播地址。