（点击
上方公众号
，可快速关注）
编译：伯乐在线/精算狗
日常站会已经成为很多团队的惯例，尤其是在敏捷软件开发（Agile software development）中。然而，将有效站会和浪费时间区分开来的是很多小细节。
（photo: Karthik Chandrasekarial）
我们站着以保持会议简短
日常站会（daily stand-up meeting）（也叫 daily scrum，daily huddle，morning roll-call 等）可以简单地描述为：
整个团队每天见面，快速汇报状态最新进展。我们站着以保持会议简短。
就是这样。
但是这么简短的定义没有真正告诉你那些把有效站会和浪费时间区分开来的细节。
所以你怎么区分呢？
对有经验的人来说，当站会出问题的时候，他们凭直觉就知道该调整什么来处理问题。
对新手来说，出问题时他们不太可能弄清该做什么……如果没有协助的话，他们更可能直接完全放弃这项实践。
这令人感到遗憾，因为进展顺利的站会给团队带来显著的价值。
为了解决这个问题，重要的是详述日常站会一般做法的好处和结果。日常站会的这些范例能够帮助缺乏经验的人，也能提醒更有经验的人其直觉背后的原因。
“好”可能是什么样？
Bob Marley 的“Get Up Stand Up”响起……像巴甫洛夫的铃铛一样，队员们不需要额外的督促就站起来漫步到卡片墙前。这首歌是每天早晨同时播放的循环歌单的一部分。
有些人把卡片移动到工作流中的正确位置，包括贴上不同颜色的便利贴，写上备注。直接项目团队以外的一些人如果对此感兴趣的话，会闲逛过来看看事情进展如何。
注意墙边的活动已经停下了，队长启动团队之前购买的巨大计时器；他们对日常站会实际要花多长时间感兴趣。
一个队员上前一步，谈论黑板上最右边的卡片，离部署点最近。他对部署脚本还有一些疑问。另一个队员表示她能帮忙解决。人们从右到左从上到下继续描述每个工作项都发生了什么，其他人如果能帮忙解决困难就插话进去。队长在一边将提及的困难记录在进展板上。
一度有一场稍长的讨论来探索怎么解决一个特定的问题。队长意识到这次拖延时，会轻轻举起一根手指打断他们…….恰恰在一个人提议他们应该线下讨论之前。
一小段时间之后，大家讨论过了所有的卡片，队长询问还有没有人想分享其他事情。某人提了一个有趣的想法，是关于一个会使计划中的一些东西被淘汰的新特征。这引起了一个总试图参加站会的产品经理的兴趣，他们都同意之后再讨论。
队长在团队开始传统结束仪式时转了转眼睛……1……2……3……精益求精！不是他的菜，但是他得承认，这使得事情高调结束了。
人们散开并开始讨论提及的不同事情，包括那些困难，新想法和特定工作项的问题。
当人们试图一起工作时发生的特定问题
当一队人试图作为团队工作时会发生特定的问题，日常站会是这些问题的常见解决方法。
站会是定期同步的机制，这样团队……
对目标有同样的理解。
即使我们觉得一开始是互相理解的（很可能并不是），我们的理解也会发生变化，就像我们工作的背景会发生变化。如果一个“团队”中的每个成员是朝不同的目标工作的，那么这个“团队”是无效的。
协调工作
。如果不需要协调工作，你也就不需要团队。反过来，如果你有一个团队，我假定工作就需要协调。队员之间蹩脚的协调往往会导致糟糕的结果。
分享问题和改进。
团队合作与单独工作相比，主要好处之一就是在某人遇到问题或者发现一个更好的做事方法时，队员能够互相帮助。如果一个“团队”的队员对分享问题感到不适，而且/或者不互相帮助，那么这个团队往往是无效的。
识别为一个团队。
如果你不经常与团队接触，在心理上认同一个团队是很困难的。即使你认为他们有能力，而且追求同一个目标，你也无法产生强烈的关联感。
日常站会的范例
我整理了一些范例来回答下列问题：
▪谁参加？
▪我们谈论什么？
▪我们发言的顺序是什么？
▪时间和地点？
▪我们怎么保持精神抖擞？
▪我们怎么鼓励自主？
谁参加？
所有人
来自不同领域（比如市场，产品支持，上层管理，培训等）的人和代表希望了解项目的状态和进程，并且/或者贡献一份力量。在多次会议和报告中交流项目状态需要大量重复的工作。
因此
将部分或者全部会议和报告替换成日常站会。任何直接相关的人员，或者想要了解项目的日常工作的人员应该只参加日常站会。
但是
如果不直接相关的人不清楚什么是期望行为，可能会打断站会。这可以通过简单地向新的参与者和观察者提前声明预期规范来解决。
不是所有形式的报告都是，或者应该是站会形式的。举例来说，项目概述使用大型可视化图表（Big Visible Chart）会更好，比如燃尽图（burn-down）、燃烧图（burn-up）、累计流量表（cumulative flow diagram）等。
工作事项核心
也叫：
故事核心的站会
如果故事对项目来说非常重要，站会中就该是
它们
发言
— Brian Marick, “Latour 3: Anthrax and standups”
人们太
注意接力者了，而没有给予接力棒足够的重视
。也就是，人人都在忙着做事，但并不一定是处理工作事项。
因此
把日常站会看作是以工作事项（例如在敏捷软件开发背景下的用户故事）为核心的惯例，而不是人的惯例，与会者只是代表工作事项发言……因为工作事项显然不会说话。
昨日今日困难
的问题可能仍然适用，但是是从工作事项角度出发的，而不是从人的角度出发的。这也意味着不是每个人都会发言。人们没有责任要说跟改进工作无关的事情。
由于这样更清晰的关注点，人们更可能在不需要督促的情况下提出困难和申请解决困难。
但是
没有发言的责任可能会隐藏一些人的问题，他们害羞或者往往在这种情况下不发言。这在以工作事项为核心的情况下更难察觉。
我们谈论什么？
昨日今日困难
也叫：
三个问题
有些人健谈，可能漫谈到
讲故事
中去。有些人想在听到问题后立即开始
解决问题
。过于长的会议往往是低迷的，与长时间的讨论没有直接关系的参与者往往会分心。
因此
用以下格式组织谈话内容：
-
我昨天完成了什么？
-
我今天要做什么？
-
什么障碍拖延了我的进度？
满足日常站会的目标至少需要这 3 个问题。讨论的其他主题（例如设计讨论，八卦等）应该推迟到会议结束后。
Olve Maudal 建议应该掉转问题的顺序来强调重要性的正确顺序：
1、有什么障碍？
2、今天要做什么？
3、从昨天起完成了什么？
— Olve Maudal, “Daily Stand-up Meetings – Perhaps the third question should go first?”
Lasse Koskela 提出了另一种形式的问题，为了强调队员不应该向队长汇报：
每个队员向他的同伴更新信息：
每个队员依次向他的同伴提供 3 条信息：
1、昨天开会以来我做的事情
2、我今天要做的事情
3、我需要某人来解决的困难
— Lasse Koskela, “On Scrum and the curse of the three questions”
Jonathan Rasmussen 提供了不同的说法来改变站会的动态：
▪
你昨天做了什么来改变世界
▪
你今天准备怎么做
▪
你准备怎么突破任何不幸挡了你路的困难
回答这些类型的问题完全改变了站会的动态。你正在使尽浑身解数，宣布你对宇宙的意图，而不是仅仅站在那陈述更新信息。
— Jonathan Rasmusson, The Agile Samurai
还有很多团队加入了额外的问题。
Buffer 增加了一个部分，人们可以分享手头上用来提升自己的事请。
Thomas Cagley 建议寻找风险。
Mark Levison 发现，增加更有针对性的改进问题是有用的。改动后两个问题来与具体背景接轨。
1、你昨天完成了什么？
2、你今天要做什么？
3、
障碍/困难有哪些？
4、你昨天注意到什么代码味道/缺少单元测试……了吗？
5、昨天你对代码做了哪些改进？
— Mark Levison, “Daily Stand-Up Variations”
但是
结构不像由问题的答案所提供给我们的信息那么重要。如果提供信息的准则不那么结构化，遵循清单就不重要了。随着团队成长，你可能会发现你想要调整结构，反映了这个范例是如何演变的。
更大的问题是，
昨天今天困难
是否太过于关注个人成就，而不是注意正确的事情……这就引向了。
改进板（Improvement Board）
也叫
__
：
阻碍板（Blockage Board）、障碍板（Impediment Board）、改善新闻表（Kaizen Newspaper）
站会中提出的困难没有被解决或者及时处理。
因此
把提及的困难贴到
改进板
上。这是一个公开可见的白板或者表格，记录提及的困难，并跟踪解决方法的进度。一个
改进板
可以在站会以外的时间更新，并作为一个更即时的、不那么具有压迫性的提出困难的方法。一个常见的错误是没能写得足够大，使人们能在很远的地方看到。
把问题写下来并坦率地承认它的简单行为是减少在对话中走神的可靠方法。所以即使不是每个人都同意某个特定事物是障碍，写下来以便会议结束后讨论也是值得的。
加上每个提及的困难发生的次数，这强调了哪些问题一般来说更重要，得先处理。
板面的设计有几种方法。比如像下面一样的表格结构：
|
问题
|
计数
|
控制
|
对策
|
状态
|
|
问题的名字
|
问题发生的计数
|
短期解决方法
|
基于根本原因分析的 长期解决方法
|
计划-执行- 检查-行动
|
另一种更像任务板的风格：
|
要做
|
正在进行
|
已完成
|
|
代表困难的卡片
|
当我们主动解决困难时， 把对应的卡片移动到这里
|
当我们解决了困难时， 把对应的卡片移动到这里
|
但是
如果提出了太多困难，团队没有能力解决的话，要冒着
改进板
变成抱怨板的风险。
我们发言的顺序是什么？
最后到达的最先发言
在站会期间，与会者得知道谁应该先发言。由协调人决定谁先发言是与自我组织对抗的、虽然微妙、但是确切的力量。在不需要干预的情况下，团队也应该知道谁先发言。
因此
同意
最后到达的人先发言
。这是个简单的规则，也带来了额外的好处——鼓励人们准时参加站会。
但是
最后到达的人可能也是准备最不充分的，不能给站会开一个好头。
接龙
在站会期间，与会者得知道谁应该先发言。由协调人决定谁先发言是与自我组织对抗的、虽然微妙、但是确切的力量。在不需要干预的情况下，团队也应该知道谁先发言。
因此
使用一个简单的、预先制定的规则来决定谁下一个发言，例如
接龙
。顺时针转还是逆时针转不重要，重要的是团队主导会议，而不是协调人或者经理主导会议。
传递信物
有了简单的、可预测的排序机制（例如
接龙
），直到快轮到自己发言之前，参与者很容易忽略其他发言人。人们往往会想其他事情，而不是注意听其他人说了什么。
因此
引进一个不可预测的排序机制，比如投掷一个发言信物（例如一个球）来决定谁下一个发言。用发言信物也简化了谁第一个发言的问题，可以是恰好取回信物的人（或者是他/她把信物投向的第一个人）。
投掷东西也给日常站会增添了一点乐趣，也可以作为一个良好的、感染其他观察团队的机制。
我在参加与 Simon Stewart 合作的一个项目时第一次学到这个方法。我们用了一个小杂耍球，但是几乎所有东西都可以用作信物。其他团队用过橄榄球，甚至毛绒玩具。
但是
对大一点的团队来说，可能很难记住谁已经发过言了。在这些情况下，坚持像
接龙
这样简单一点的机制更容易。
取决于组织甚至团队的文化氛围，扔球可能会显得不专业，对这个惯例产生不必要的负面看法。
抽一张卡片
在站会期间，与会者得知道谁应该先发言，之后谁应该发言。由协调人决定谁先发言是与自我组织对抗的、虽然微妙、但是确切的力量。团队不喜欢传信物是因为他们手里一般都拿着杯咖啡。
因此
让每个队员抽一张卡片来决定发言顺序。想象一摞卡片，每张卡片上有一个数字。每个队员到达时可以选一张卡片，根据卡片上的数字来决定发言顺序。
过一遍板
也叫：
过一遍墙
站会保证每个人都不闲着。过一遍板上的内容保证每个人都只关注最重要的事。
— Bret Pettichord via Twitter
会议形式的另一个问题是，没有清楚地讨论任务或者工作流。每个话题被简单提及，取决于队员发言的顺序。这使得正在发生的事情很难讲清楚。
— Dave Nicolette, “An alternative format for the daily stand-up”
人们更关注让自己忙起来，而不是真正改进工作，所以你转向一个以工作事项为核心的模型，而不是以人为核心的模式。但是，即使是工作事项核心的站会，如果使用了像
接龙
或者
传递信物
这样的传统排序机制，也很难理解发生了什么。
因此
过一遍板
，就是在站会中过一遍可视管理板上的每个工作事项。
大多数敏捷和精益团队使用可视管理系统来展示正在处理的工作事项。对敏捷软件开发来说，这可能叫做任务板（task board）、故事墙（story wall）或者看板（Kanban board）。这些板展示工作事项的进程。通常用在板上移动卡片的方法来展示进程。理论上，垂直位置表示优先程度。
站会中，从尾到头（例如从右到左）并从高优先级到低优先级（例如从上到下）过一遍每个工作事项。你可能在板上明确地标明应该使用怎样的顺序。
Pawel Brodzinski 提出了一个默认顺序：
1. 困难
2. 加速或者紧急事件
3. 上次站会后没再有新进展的事项（可能卡住了）
4. 根据优先级的其他事件
但是
显然，一块板是需要预先准备的，不是所有团队都有。在这种情况下，一人一人发言的结构更合适。
