共计 12311 个字符，预计需要花费 31 分钟才能阅读完成。
每日站会曾经成为许多团队的常见典礼，特地是在麻利软件开发中。然而，有许多奥妙的细节能够帮忙咱们辨别是在无效的散会还是在浪费时间。
具体内容
- 站起来是为了放弃会议的简短
- “好”可能是什么样的？
- 当人们试图一起工作时呈现的一系列非凡问题
- 每日站会的模式
- 谁来加入？
- 咱们谈些什么？
- 咱们按什么程序发言？
- 何时何地？
- 咱们如何放弃精力充沛？
- 咱们如何造就自主性？
- 咱们如何晓得站会停顿不佳？
- 这真的只是每天一起站起来而已。
一、站起来是为了放弃会议的简短
每日站会（也称为“每日 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 阻碍只在站会时提出
站会能够作为兜底阻碍的安全网，在最坏的状况下，阻碍也会在一天之内被传播给整个团队。然而，站会并不是为了阻止问题在一天内随时被提出和解决。引入另一种实际（如改良板）来提出阻碍可能会有所帮忙。如果做了改良仍然没有成果，能够通过回顾会来剖析根本原因。
十二、这真的只是每天一起站起来而已
心愿这篇文章能为你提供一些对于无效站会实际的细节和问题常见指标的更多办法。咱们应该分明，每日站会不仅仅是每天站在一起。
最初，重要的是不要太在意每一种模式，甚至是领有一些“滋味”。记住咱们要解决的问题：人们是否精力充沛？人们是否在分享问题和想法？人们是否专一于咱们的指标？人们是否作为一个团队一起工作？每个人都晓得产生了什么吗？
如果你能对这些问题作出必定的答复，那么会议可能会进行得很顺利。毕竟，这真的只是每天一起站起来而已。
参考资料：
- http://xprogramming.com/artic…
- http://www.exampler.com/blog/…
- http://blog.mountaingoatsoftw…
- http://olvemaudal.wordpress.c…
- http://radio.javaranch.com/la…
- https://book.douban.com/subje…
- http://joel.is/an-invitation-…
- https://tcagley.wordpress.com…
- https://agilepainrelief.com/n…
- http://%20web.archive.org/web…
- http://web.archive.org/web/20…
- http://brodzinski.com/2011/12…
- http://www.leanblog.org/2010/…
- https://www.linkedin.com/puls…
- http://edgibbs.com/2006/08/07…
- http://www.marketplace.org/20…
- http://blog.benjaminm.net/201…
- http://radio.javaranch.com/la…
- http://www.netobjectives.com/…
- http://queue.acm.org/detail.c…
- http://web.archive.org/web/20…
- http://blog.jbrains.ca/permal…
- http://www.retrospectives.com/
起源：小船哥说麻利
作者：adoudou
申明：文章取得作者受权在 IDCF 社区公众号（devopshub）转发。优质内容共享给思否平台的技术伙伴，如原作者有其余思考请分割小编删除，致谢。
6 月每周四晚 8 点，【冬哥有话说】开心一“夏”。公众号留言“开心”可获取地址
- 0603 无敌哥《IDCF 人才成长地图与 5P》（《端到端 DevOps 继续交付 (5P) 精品课》第 1 课）
- 0610 冬哥《带你玩转翻新设计思维》
- 0617 无敌哥《麻利项目管理到底是个啥》
- 0624 冬哥《VUCA 时代的麻利领导力》
