雨前龙井

每日站立会议成为了很多团队的通用仪式，尤其是在敏捷软件开发中。然而，到底是高效的站立会议还是浪费时间，这其中还有一些细节值得探讨。

作者

Jason Yip 是Spotify的敏捷教练，之前是ThoughtWorks的首席咨询师。他一直专注在软件开发、团队和组织中应用敏捷和精益的思想、原则和实践。

原文地址：It's Not Just Standing Up: Patterns for Daily Standup Meetings

我们站立是为了缩短会议时间

每日站立会议描述起来很简单：

整个团队每天聚在一起快速地更新状态，我们站立是为了缩短会议时间。

但是这个简短的描述并没有真正告诉你区别高效站会和浪费时间的细节，那我们怎么办呢？对于有经验的实践者来说，当站会出现问题时，他们本能的知道应该如何调整以解决问题，但是对于新人而言，当出现问题时，他们往往不知道应该怎么办，而且如果没有帮助的话，他们很可能完全放弃实践站会。如果放弃了，那将是非常的可惜，因为良好运作的站会可以给团队带来很大的价值。

为了强调这一点，明确的说明每日站会的好处和重要性非常重要。这些每日站立会议的模式可以帮助没有经验的实践者并且让有经验的实践者搞清楚背后的原因。

好的站立会议长什么样？

Bob Marley的《起来，站起来》响起了，就像巴甫洛夫的铃音一样，团队在没有任何其他提示的情况下都站了起来，走到卡片墙面前站住。这首歌每天早上的这个时间都会播放。一些人在卡片移动到工作流中正确的位置，包括在不同颜色的即时贴上写附加说明。一些项目团队外感兴趣的人也走过来，看看事情进展如何。

注意到大家都移动完毕后，Team Leader启动了团队之前购买的一个计时器，他们想看看每日站会到底花了多少时间。其中一位团队成员上前一步说，白板最右侧的卡片，即将进入部署的点了，但是他在部署脚本上还有一些问题。另一位成员说她可以帮助解决。就这样按照从右至左，从上到下的顺序今夕。人们描述每个工作项的情况，其他人偶尔插话说他们可以帮助解决阻碍。Team Leader站在旁边记录着改进板上提到的阻碍。

偶尔，当Team Leader发现大家开始讨论如何解决一个特定问题时，他会在有人建议将问题下线之前，淡定地打断大家的讨论。

很快，所以的卡片都覆盖到了，Team Leader询问大家是否有其他需要分享的内容。有人提出一个有趣的想法，她想到一个新特性比已经计划的一些特性更先进。她的想法引起了总是想参加站会的产品经理的兴趣，他们同意会后详细讨论。

Team Leader组织大家进行传统的结束仪式：1...2...3... Excelsior（全力以赴、做到最好）。这不是他的原创，不过他得承认，这会让大家在高度共识下结束仪式。

团队分开后各自开始讨论刚刚提到的各种各样的事情，包括阻碍，新想法和特定工作项的问题。

一起工作的那些问题

一群人试图作为一个团队一起工作时时常发生一些问题，每日站立会议是这些问题的常规性解决方案。

站会是一种保持团队持续同步的机制，有了站会之后，团队可以：

分享对目标的理解，即使我们认为我们在开始时理解了对方（其实往往我们没有理解），但是随着事情的进展，我们的理解也会发生变化。一个成员目标不一致的团队是不可能有效率的。 齐心协力，如果工作不需要协作，那你也就不需要团队。但是，如果你有一只团队，我假定工作是需要协作的，团队成员之间低效的协作必然导致团队整体产出低下。

分担问题和分享改进，团队协作比单打独斗更基本的优势之一就是当某个人遇到问题或者发现更好的做事方式时，其他团队成员可以帮助他。一支不会分担问题、不会相互帮助的团队是低效的。

认同团队，当你不经常参与团队活动，很难再心理上认同团队。即使你相信其他人很有能力，大家在追逐相同的目标，你也很难形成强烈的关系情感。

每日站立会议的模式

为了回答如下问题，我整理了每日站立会议的模式：

• 谁参加？
• 我们讨论什么内容？
• 我们按什么顺序讨论？
• 何时何地？
• 如何保持活力？
• 如何鼓励自主性？

1. 谁参加？

全体人员

凡是想知道或需要参与到项目状态和进度的人或者市场、产品支持、高层管理，培训等领域的代表。在各式各样的会议和报告中交流项目状态会造成重复劳动。

因此，使用每日站立会议代替其中一些或者全部会议和报告。任何直接参与项目或者想知道项目每日进展的人都应该参加每日站立会议。但是，团队成员外的人如果不知道站会应该怎么开时，会干扰每日站会的进行。这就需要提前向新的参与者强调站会的要求。

并不是所有的报告都应该使用站会代替，比如：项目的整体进度还是应该采用可视化图表进行沟通，比如燃尽图、累积流图。

工作事项

专注于故事的站会

如果故事对项目很重要，那么故事理应在站会中说话 -- Brian Marick, "Latour 3: Anthrax and standups"

人们总是专注于跑步者，而不是接力棒。也就是说,每个人都很忙,但工作项不一定有进展。因此，将站会视为人的仪式，还不如所是针对工作项的仪式（比如敏捷中的用户故事），人参与只是为了替工作项说话，因为工作项很明显不能说话。昨天、今天、阻碍的问题格式依然有用，但是应该从工作项的角度，而不是人的角度来描述。这就意味着并不是每个人都需要讲话，在站会中不需要讲任何与工作进展无关的事情。因为有了清晰的专注点，人们可以在没有任何提示的情况下提出阻碍、移除阻碍。

但是，没有义务说话可能会掩盖有问题的人，比如害羞的人或不愿意说什么的人。在专注工作项的情况下，很难去发现这些问题。

2. 我们讨论什么内容？

昨天，今天，阻碍

有一些人很健谈，他们往往很容易讲站会变成讲述故事。有一些人在听到问题后总想立即解决问题。长时间的会议总是低效的，与长时间的讨论无直接关系的参与者很容易分心。 因此，建议采用如下格式：

1. 我昨天完成了什么？
2. 我今天打算做什么？
3. 我面临什么样的阻碍？

要满足站立会议目标至少需要回答这三个问题，其他主题应该在站会结束后进行讨论，比如：设计讨论、八卦等等。

Olve Maudal建议将问题的顺序反过来以便强调问题的正确顺序：

1. 有什么阻碍吗？
2. 你今天正在做什么？
3. 你昨天完成了什么？

-- Olve Maudal, "Daily Stand-up Meetings - Perhaps the third question should go first?"

Lasse Koskela建议采用其他的问题格式以便强调团队成员不应该是在给领导汇报：

每个团队成员是在跟团队交流，每个团队成员按顺序为其他成员提供如下三个信息：

1. 昨天的站会之后，我做的事
2. 今天我准备将会完成的事
3. 我需要其他人帮我清除的阻碍

-- Lasse Koskela, "On Scrum and the curse of the three questions

Jonathan Rasmussen提供了不同的词以提高站会的活跃度：

1. 你昨天做什么来改变世界(What you did to change the world yesterday)
2. 你今天将会如何改变世界(How you are going to crush it today)
3. 你将如何消除那些挡你路的阻碍(How you are going to blast through any obstacles unfortunate enough to be standing in your way)

和只是站在那儿更新信息相比，回答这种问题能提升站会的活跃度。

-- Jonathan Rasmusson, The Agile Samura

也有很多的团队已经引入了额外的问题，Buffer 就引入了一些问题以展现他们为自我改进而做的事情

Thomas Cagley建议识别风险

Mark Levison发现增加目标明确的改进问题很有用，他修改了最后两个问题以匹配特定的上下文

1. 你昨天完成了什么？
2. 你承诺今天做什么？
3. 你的阻碍是什么？
4. 你昨天发现了什么代码坏味道、缺失的单元测试了吗？
5. 你昨天做了什么改进代码了吗？

-- Mark Levison, "Daily Stand-Up Variations"

但是，问题的形式远没有问题的答案重要，如果提供的信息并不是那么的结构化，也不用墨守成规。随着团队的成熟，你会发现你想要调整问题的结构，这就已经反映出这种模式是如何进化的了。

更大的问题是，昨天、今天、阻碍是否让大家更加关注个人承若，而不是关注正确的事。这就导致Walk the Board。

改进板

又名：阻塞板、阻碍板、改善公报

站会中提出的阻碍没有被清除或者没有及时的处理。因此，将提出的阻碍放到改进板上。改进板是一个公开可见的用于识别阻碍并跟踪处理过程的白板或者图表。改进板可以在站会之外更新并且作为一个更直接，也许少对抗的方式来面对最初提出的阻碍。一个常见的错误是改进板写的不够大以至于人们不能在远处就能看清阻碍。

将问题写下来这个简单的行为可以明显地减少额外的沟通。即便并不是每个人都同意某个特定项是阻碍，将其写下来并在会后进行讨论也是有价值的。 标注每个阻碍发生的次数，次数高的问题一般需要优先处理。

改进板的设计有多种形式。比如一个张类似如下结构的表：

另一种类似任务板的样式：

但是，如果提出了太多的阻碍，团队却无能为力解决，改进板就会变成抱怨板。

3. 我们按什么样的顺序讨论？

To Be Continue...