不仅仅是站着开会:每日站会模式
照片:Karthik Chandrasekarial
每日站会已成为许多团队的常见仪式,尤其是在敏捷软件开发中。 然而,许多微妙的细节区分了有效的站会和浪费时间的站会。
2016 年 2 月 21 日
我们站着开会是为了保持会议简短。
每日站会(也称为“每日 Scrum”、“每日晨会”、“早点名”等)很容易描述。
整个团队每天开会进行快速状态更新。 我们站着开会是为了保持会议简短。
就是这样。
但这个简短的定义并没有真正告诉你区分有效站会和浪费时间的微妙细节。
那么你怎么知道呢?
对于经验丰富的从业者来说,当站会出错时,他们会本能地知道如何调整以解决问题。
对于新手来说,当事情出错时,他们不太可能知道该怎么做......而且更有可能的是,在没有帮助的情况下,他们会完全放弃这种做法。
这将是不幸的,因为运作良好的站会为团队增加了巨大的价值。
为了解决这个问题,重要的是要明确说明每日站会的常见做法的利弊。 这些每日站会模式可以帮助经验不足的从业者,并提醒经验丰富的从业者了解他们直觉背后的原因。
“好”的站会是什么样的?
鲍勃·马利的“Get Up Stand Up”响了起来......就像巴甫洛夫的铃声一样,团队成员们起身走到卡片墙前站着,无需任何额外的提示。 那首特别的歌是每天早上同一时间播放的轮换曲目的一部分。 有些人正在将卡片移动到工作流程中的正确位置,包括贴上不同颜色的便利贴和额外的注释。 一些对直接项目团队以外感兴趣的人也走过来看看事情的进展情况。
注意到墙上的活动已经停止,团队负责人启动了一个团队之前购买的大计时器;他们想知道每日站会实际花了多长时间。
其中一名团队成员走上前去谈论看板上最右边、最靠近部署点的卡片。 他在部署脚本方面仍然遇到一些问题。 另一位团队成员表示她可以帮助解决这个问题。 顺序从右到左、从上到下继续,人们描述每个工作项的情况,其他人如果可以帮助解决障碍,也会插话。 在一旁,团队负责人正在改进看板上记录提出的障碍。
有一次,他们进行了一次稍长的讨论,探讨如何处理一个特定的问题。 注意到停顿,团队负责人巧妙地举起一根手指打断......就在其中一人建议他们应该线下讨论之前。
不久之后,所有卡片都被覆盖了,团队负责人询问是否还有其他人要分享。 有人提出了一个有趣的想法,即关于一个新功能,该功能将使一些计划中的内容过时。 这引起了产品经理的兴趣,他总是试图参加站会,他们都同意之后再谈论这件事。
然后,当团队开始传统的结束仪式时,团队负责人翻了个白眼......1...2...3... Excelsior!这不是他的风格,但他不得不承认,它以一种高调的方式结束了会议。
人们分开并开始讨论提出的各种事情,包括障碍、新想法以及关于某些工作项的问题。
当人们试图一起工作时,会出现一系列特定的问题。
每日站会是当一群人试图作为一个团队一起工作时出现的一系列特定问题的反复出现的解决方案。
站会是一种定期同步的机制,以便团队......
- 分享对目标的理解。即使我们认为我们在开始时就理解了彼此(我们可能没有),但我们的理解会随着我们运作环境的变化而改变。 一个“团队”,如果每个团队成员都在朝着不同的目标努力,往往是无效的。
- 协调工作。如果工作不需要协调,你就不需要团队。 相反,如果你有一个团队,我认为这项工作需要协调。 团队成员之间协调不力往往会导致糟糕的结果。
- 分享问题和改进。团队相对于单独工作的主要好处之一是,当有人遇到问题或发现更好的做事方式时,团队成员可以互相帮助。 一个“团队”,如果团队成员不习惯分享问题和/或不互相帮助,往往是无效的。
- 认同团队。如果你不定期地与一个群体接触,你就很难在心理上认同这个群体。 即使你相信他们有能力并追求相同的目标,你也不会发展出强烈的关联感。
每日站会模式
我已经组织了这些模式来回答以下问题
- 谁参加?
- 我们讨论什么?
- 我们按什么顺序发言?
- 地点和时间?
- 我们如何保持精力充沛?
- 我们如何鼓励自主性?
谁参加?
全体人员
来自各个领域(例如,市场营销、生产支持、高层管理人员、培训等)的人员和代表希望了解和/或为项目的现状和进展做出贡献。 在多个会议和报告中传达状态需要大量的重复工作。
因此
用每日站会代替部分或全部会议和报告。 任何直接参与或希望了解项目日常运作的人都应该参加每天一次的站会。
但是
如果不直接参与的人员不清楚预期的行为,他们可能会扰乱站会。 这可以通过事先简单地告知新的参与者和观察者预期的规范来解决。
并非所有形式的报告都将或应该由站会形式涵盖。 例如,整体项目进度最好通过大型可见图表来传达,例如燃尽图、燃起图、累积流程图等。
工作项参加
也称为:以故事为中心的站会
如果故事对项目如此重要,那么它们就应该是站在台上发言的人
人们过于关注跑步者,而不是接力棒。 也就是说,每个人都很忙,但不一定在推进工作项。
因此
不要把每日站会看作是人们的一种仪式,而应该把它看作是工作项参加的仪式(例如,敏捷环境中的用户故事),而人们只是为了代表工作项发言......因为很明显,工作项实际上不能说话。
仍然可以使用昨天、今天、障碍问题,但将从工作项的角度出发,而不是从人的角度出发。 这也意味着不是每个人都需要发言。 没有义务说出任何与推进工作无关的内容。
由于重点更加明确,人们更有可能在没有提示的情况下提出障碍并报名消除障碍。
但是
没有发言的义务可能会掩盖那些害羞或不愿意发言的人的问题。 这在以工作项为中心的情况下更难察觉。
我们讨论什么?
昨天、今天、障碍
也称为:三个问题
有些人很健谈,往往会漫无目的地讲故事。 有些人想在听到问题后立即参与解决问题。 会议时间过长往往会导致精力不足,与长时间讨论没有直接关系的参与者往往会分心。
因此
使用以下格式构建发言内容
- 我昨天完成了什么?
- 我今天要做什么?
- 是什么障碍阻碍了我的进展?
这些是满足每日站会目标的最少问题数量。 其他讨论主题(例如,设计讨论、闲聊等)应推迟到会议结束后进行。
Olve Maudal 建议应该颠倒问题的顺序,以强调正确的优先级顺序
- 你有什么障碍吗?
- 你今天要做什么?
- 你从昨天到现在完成了什么?
Lasse Koskela 提出了另一种形式的这些问题,以强调团队成员不应该向领导汇报
每个团队成员都向他的同伴更新
反过来,每个团队成员都向他的同伴提供 3 条信息
- 自昨天会议以来我所做的事情
- 我今天要完成的事情
- 我需要别人帮我移除的障碍
Jonathan Rasmussen 提供了不同的措辞,以改变站会的动态
- 你昨天为改变世界做了什么
- 你今天打算如何粉碎它
- 你打算如何突破任何不幸挡在你路上的障碍
回答这些类型的问题完全改变了站会的动态。 你不再只是站在那里做更新,而是把一切都摆在台面上,向宇宙宣告你的意图。
还有许多团队增加了一些额外的问题。
Buffer 添加了一个版块,供人们分享他们正在努力改进自己的事情。
Thomas Cagley 建议 搜寻风险。
Mark Levison 发现添加更有针对性的改进问题很有用。最后两个问题将根据具体情况进行更改。
- 你昨天完成了什么?
- 你今天承诺做什么?
- 你有什么障碍/阻碍?
- 你昨天发现了什么代码异味/缺少单元测试/…?
- 你昨天对代码做了哪些改进?
但是
结构并不像问题答案提供的信息那样重要。如果信息是在结构化程度较低的协议中提供的,则不必坚持清单。随着团队的成熟,你可能会发现你想调整结构,这反映了这种模式是如何演变的。
更大的问题是,**昨天今天障碍**是否过于关注个人承诺,而没有关注正确的事情……这导致了**走看板**。
改进看板
**_又称:_** 障碍板、阻碍板、改善报纸
在站会中提出的障碍没有得到及时清除或以其他方式解决。
因此
将提出的障碍发布到**改进板**上。这是一个公开可见的白板或图表,用于识别提出的障碍并跟踪其解决进度。**改进板**可以在站会之外更新,并且可以作为一种更直接、可能更不那么具有对抗性的方式来最初提出障碍。一个常见的错误是没有写得足够大,以至于人们无法从远处看到障碍。
简单地写下一个问题并因此明确承认它,是减少冗长对话的一种非常可靠的方法。因此,即使不是每个人都同意任何特定事项都是障碍,也值得简单地将其写下来,以便在会议结束后进行讨论。
在每个提出的障碍中包含一个发生次数计数,可以突出显示哪些问题通常更重要,需要首先处理。
板的设计可以有多种变化。例如,像下面这样的表格结构
问题 | 计数 | 遏制 | 对策 | 状态 |
---|---|---|---|---|
问题名称 | 正在进行的发生次数计数 | 短期解决方案 | 基于根本原因分析的长期解决方案 | 计划 - 执行 - 检查 - 行动 |
另一种风格更像是任务板
待办事项 | 进行中 | 已完成 |
---|---|---|
代表提出的障碍的索引卡 | 当我们积极处理障碍卡时,它们会移动到这里 | 当我们解决障碍卡时,它们会移动到这里 |
但是
如果在**改进板**上提出了太多团队无法解决的障碍,则**改进板**有可能沦为抱怨板。
我们按什么顺序发言?
最后到的人先发言
在站会期间,与会者需要知道谁应该先发言。让主持人决定谁应该先发言,是对自组织的一种微妙但明确的力量。团队应该在没有干预的情况下知道谁先发言。
因此
同意**最后到达者先发言**。这是一个简单的规则,它还有一个额外的好处,就是鼓励人们准时参加站会。
但是
最后到达者也可能是最没有准备好开始会议的人。
轮流发言
在站会期间,与会者需要知道谁应该接下来发言。让主持人决定谁接下来发言,是对自组织的一种微妙但明确的力量。团队应该在没有干预的情况下知道谁接下来发言。
因此
使用一个简单的预定规则,比如**循环赛**,来决定谁应该接下来发言。顺时针还是逆时针并不重要。重要的是团队管理会议,而不是主持人或经理。
传递令牌
使用简单、可预测的排序机制(例如,**循环赛**),参与者很容易忽略其他发言者,直到轮到他们发言。人们可能倾向于想其他的事情,而不是关注别人在说什么。
因此
引入一种不可预测的排序机制,比如抛出一个发言令牌(例如,一个球)来决定谁应该接下来发言。拥有一个发言令牌还可以简化决定谁先发言,因为这将是碰巧拿到令牌的人(或者他/她第一次抛给的人)。
抛东西为每日站会仪式增添了一点乐趣,因此可以作为其他观察团队的良好感染机制。
我第一次了解到这种模式是在我与 Simon Stewart 合作的一个项目中。我们使用了一个小的杂耍球,但几乎任何东西都可以用作令牌。其他团队则使用了橄榄球,甚至毛绒玩具。
但是
对于较大的团队,可能很难记住谁已经发言过。在这种情况下,坚持使用更简单的机制(如**循环赛**)可能会更容易。
根据组织甚至团队的文化,抛球也可能被视为不专业,并且会对潜在的仪式造成不必要的负面看法。
抽卡片
在站会期间,与会者需要知道谁应该先发言,以及之后谁应该接下来发言。让主持人决定谁应该发言,是对自组织的一种微妙但明确的力量。团队不喜欢**传递令牌**,因为他们通常手里拿着咖啡杯。
因此
让每个团队成员**抽取一张卡片**来决定发言顺序。想象一堆卡片,每张卡片上都有一个数字。当每个团队成员来到会议室时,他们可以选择一张卡片,然后卡片会告诉他们发言的顺序。
走看板
**_又称:_** 走墙
[站]会让每个人都忙碌起来。[走]看板让每个人都专注于最重要的事情。-- Bret Pettichord 通过 Twitter
传统格式的另一个问题是,任务或工作流没有得到连贯的讨论;相反,每个主题都会根据团队成员发言的顺序简要地出现。这使得很难判断实际情况。
人们更专注于忙碌而不是实际推进工作,因此你切换到**工作项参加**而不是人员参加的模式,但是,即使使用这种以工作项为中心的站会,在使用典型的排序机制(如**循环赛**或**传递令牌**)时,仍然很难理解正在发生的事情。
因此
**走看板**,也就是说,通过遍历显示在你的可视化管理板上的每个工作项来构建站会。
大多数敏捷和精益团队将使用可视化管理系统来公开正在进行的工作。对于敏捷软件开发,这可能称为“任务板”、“故事墙”或“看板”。这些板将呈现工作项将经历的过程。进度通常通过在板上物理移动卡片来表示。理想情况下,垂直定位将指示优先级。
有了这个板,站会就会从流程的末尾到开始(例如,从右到左)以及从最高优先级到最低优先级(例如,从上到下)遍历每个工作项。你甚至可以在板上明确指示应该使用什么顺序。
Pawel Brodzinski 提出了一个默认顺序
- 障碍
- 加急或紧急事项
- 自上次站会以来没有移动的项目(很可能被卡住了)
- 其他所有按优先级排序的项目
但是
显然,拥有一个板是一个先决条件,并非所有团队都有。在这种情况下,逐人结构更合适。
如果**轮换主持人**或其他一些自组织模式没有得到应用,**走看板**更容易屈服于**向领导汇报**。
地点和时间?
在工作发生的地方开会
在现场开会,而不是在会议室。
工作场所中有许多关于正在发生的事情的记忆触发器。
我们也不希望每日会议需要大量的协调、寻找和步行到会议室的开销。
因此
**在工作发生的地方开会**,而不是在会议室。如果你有一个“故事墙”或“看板”,就在它前面开会。
但是
附近的其他人可能会觉得会议的噪音很烦人。这通常表明底层的工作空间设计很差,但仍然必须承认。
同一地点,同一时间
我们希望团队对站会有主人翁意识。我们还希望感兴趣的各方能够顺便来观察站会,以避免安排另一次状态会议。如果允许任何特定的团队成员强制推迟或更改站会的地点,这将是困难的。
因此
让团队在**同一地点、同一时间**商定并运行每日站会。不要等待迟到者,包括架构师和经理。会议是为整个团队服务的,而不是为任何特定个人服务的。如果你**使用站会来开始新的一天**,这一点尤其重要。
一些更严格的团队可能会对迟到者处以“罚款”。我倾向于对任何形式的惩罚机制保持警惕,更喜欢讨论。
但是
**同一地点、同一时间**并非要盲目地不灵活。重要的是开始时间要基本一致,并且很少重新安排时间。如果需要经常重新安排时间,这可能表明应该更改开始时间。如果某个特定地点对每个人来说都不方便到达,这可能表明应该更改地点。
用站会开始新的一天
每日站会可以让人们关注和了解未解决的问题。如果它发生在一天的晚些时候,这种关注和意识就会被浪费掉。
因此
**使用站会来开始新的一天**。由于工作时间灵活,并非每个团队成员都会在同一时间上班。“弹性工作制”的一个常见做法是使用一组核心工作时间。开始时间应该是这些核心工作时间的开始。同样,如果团队成员由于个人原因需要晚到(例如,需要送孩子上学),则应将开始时间设置为每个人都可以参加的时间。
但是
在站会之前,可能有一种倾向是不处理任何与项目相关的任务。如果**站会开始得很晚**,这段闲散时间可能会很长。在某种程度上,这可能只是被用作查看电子邮件、填写时间表等的机会,但可能值得调查一下,通过将站会安排在当天晚些时候来消除它作为“开始新的一天”的仪式。
不要用站会开始新的一天
站会往往是设定一天工作重点的仪式,尤其是如果你**使用站会来开始新的一天**。正因为如此,团队成员往往在站会之前不会开始处理功能。当会议实际上不是在第一时间举行时,这种倾向可能会对生产力产生重大影响。
因此
**不要使用站会来开始新的一天**。将每日站会安排在一天中足够晚的时间,这样它就不会在心理上与开始新的一天联系在一起。
但是
如果每日会议不是从一天的开始,那么它就不能再被用作在一天的开始设定团队目标的共同仪式。根据团队的不同,这个代价可能不值得明显的效率提高。
当有许多项目使用站会时,可能会同时发生多个站会。对多个项目感兴趣的观察者可能希望更改站会时间,以便他们能够参加。这是有问题的,因为如果观察者可以强迫站会调整到他/她的时间表,就会危及团队的主人翁意识。然而,在决定何时举行每日站会时,这也必须是一个考虑因素。
我们如何保持精力充沛?
围成一圈
我经常看到的一个问题是,人们倾向于将每日站会仅仅视为个人报告。“我做了这个...我将做那个”——然后换下一个人。更理想的方法更接近于橄榄球的“huddle”(球员围拢)。
说话的音量会影响注意力和沟通效率。物理距离会改变良好沟通所需的音量水平。有些人说话声音不大,也不习惯大声说话。
说话的音量会影响注意力和沟通效率。物理距离会改变良好沟通所需的音量水平。有些人说话声音不大,也不习惯大声说话。
因此
站会应该更像是一个 围拢 (Huddle),而不是一个会议。如果难以听清,就让每个人都靠近一点。除了可以降低说话的音量外,身体上的靠近也会让参与者更加专注。能够在物理上站得更近也是团队内部更加信任的一种表现。如果站会是一个新事物,通常用手势示意人们靠近并说“让我们靠拢一点”就足够了。如果圆圈的大小已经建立了一段时间,在尝试缩小圆圈之前,请考虑解释一下这样做的原因。
但是
团队必须在亲密和个人舒适区之间取得平衡。即使在一个非常信任的团队中,当人们站得太近时,也会让人感到不舒服。症状往往是参与者感到紧张和/或坐立不安。
站着开会
有些人很健谈,往往会漫无边际地 讲故事 (Story Telling)。有些人一听到问题就想立即进行 问题解决 (Problem Solving)。时间过长的会议往往会让人精力不足,与冗长讨论没有直接关系的参与者也会容易分心。
因此
让所有与会者在会议期间都 站起来 (Stand Up)。利用站立将身体与精神上的准备联系起来。身体上的不适也会提醒与会者会议时间过长。一个简单的鼓励方式就是在没有椅子的地方开会。
但是
站立往往会缩短会议时间,但并不能保证会议时间会缩短到最佳长度。人们可能会学会忍受这种不适,而不是采取更合适的应对措施。此外,如果会议 没有 时间过长或跑题,站立就是一个不必要的仪式。
十五分钟或更短
大多数人在长时间的会议中都会走神。冗长乏味的会议是开始一天工作的一种可怕的、消耗精力方式。一个具体的数字有助于提醒我们何时应该考虑调整以减少会议时间。
因此
将每日站会控制在 十五分钟或更短 (Fifteen Minutes or Less)。一般来说,十五分钟后,普通人的注意力就会开始涣散,这不利于集中精力。
但是
对于规模较小的团队来说,十五分钟甚至可能太长。由于走神的效应,即使对于规模较大的团队来说,十五分钟也是一个很好的限制。此外,会议时间过短也是有可能的,与会者在会议结束后仍然不知道发生了什么,也不知道该找谁了解情况。
发出结束信号
在最后一个人发言后,团队可能不会立即意识到会议已经结束。逐渐意识到该走开的现实并不能给会议画上一个圆满的句号,反而可能会导致 精力不足 (Low Energy)。
因此
用一句结束语(例如,“好了,大家好好享用午餐吧。”)或其他一些动作来 示意结束 (Signal the End) 站会。
计时
很难定性地判断站会是否时间过长,尤其是当它只是逐渐变长的时候。
因此
记录会议时间 (Time the Meetings) 并公布结果。大多数情况下,与会者只是没有意识到 讲故事 (Story Telling)、没有准备好 线下讨论 (Take It Offline) 或没有做好准备对会议时长产生的影响。使其量化。
但是
与所有措施一样,除非由于精力水平问题而有实际目标要实现,否则不应引入会议计时。一旦目标达成,就应该放弃测量。毫无理由地测量会导致怀疑和对指标的冷漠。
时间是精力、注意力和节奏的代表。与其关注时间,不如更多地关注这些方面。
线下讨论
有些人一听到问题就想立即进行 问题解决 (Problem Solving)。时间过长的会议往往会让人精力不足,与冗长讨论没有直接关系的参与者也会容易分心。承认需要进一步讨论来解决提出的问题仍然很重要。有些人可能会觉得通过打断来强制执行站会的结构会让他们感到不舒服。
因此
使用简单一致的短语,如“线下讨论 (Take It Offline)”,来提醒大家此类讨论应该在每日站会之外进行。如果讨论是 社交 (Socialising),则无需再做其他事情。如果讨论是 问题解决 (Problem Solving),主持人(最终只是团队)应确保指定合适的人员或报名稍后处理该问题。
或者,一些团队使用更间接的信号。
例如,Mike Cohn 描述了一个使用 橡胶老鼠来表示“我们正在钻牛角尖” 的例子。
Benjamin Mitchell 描述了一个“两只手规则”
...如果有人认为当前的对话已经跑题,或者不再有效,那么他们就举手。一旦第二个人举手,这就是停止对话并继续进行剩余站会的信号。发言者可以在站会结束后继续对话。
但是
问题解决 (Problem Solving) 和澄清问题之间是有区别的。不理解的信息是没有用的。允许澄清问题的程度应根据团队的规模以及是否会影响 十五分钟或更短 (Fifteen Minutes or Less) 的目标而有所不同。
我们如何鼓励自主性?
轮流担任主持人
团队成员正在 向领导汇报 (Reporting to the Leader),也就是说,他们只与会议主持人交谈,而不是彼此交谈。只有会议主持人会提出和解决与站会相关的流程问题。我们希望团队能够掌控站会,这就需要消除对单个主持人的任何依赖。
因此
轮换主持人 (Rotate the Facilitator)。轮流指派一个负责人,负责确保人们参加站会并遵守约定的规则。
但是
没有站会经验的团队会从一位经验丰富的教练那里获益匪浅。更重要的是,应该让团队逐渐学会更好地控制站会。在某种程度上,根本不需要明确的主持人。
避免眼神接触
团队成员正在 向领导汇报 (Reporting to the Leader),也就是说,他们只与会议主持人交谈,而不是彼此交谈。我们希望团队能够掌控站会,这就需要消除对单个主持人的任何依赖。
因此
主持人应该 避免眼神接触 (Break Eye Contact),以此作为一种微妙的提醒方式,提醒发言者他/她应该面向整个团队,而不仅仅是一个人。一种方法是 四处走动,这样当前的发言者就看不到主持人。
我们如何知道站会进行得不顺利?
我忍受了三年的定期站会。最让我痛苦的是我的老板(我叫他沃利)。他举行站会的主要原因不是为了提高效率或拥抱极限编程,而是为了将人际互动缩短到与工作产品直接相关的范围之外。...然而,对于沃利来说,站会(就像周一早上 7 点的会议和周五下午 5 点的会议一样)是一种忠诚度测试,旨在加强雇主与雇员之间的关系。
有一些站会“异味”可以很好地表明事情正在朝着错误的方向发展。需要注意的是,即使你没有闻到异味,也不意味着站会进展顺利。这仅仅意味着它没有臭味。
以下大多数异味都与之前的模式有关。对于那些没有关联的异味,其根本原因往往更加微妙,或者超出了每日站会的范围,人们必须自己想办法解决。
关注跑步者,而不是接力棒
人们过于关注自己正在做的事情,而忽略了考虑他们的活动是否真的在推动工作进展。重新定义站会,让 工作项参与 (Work Items Attend)。
向领导汇报
团队成员面向经理或会议主持人并与之交谈,而不是与团队交谈。这表明每日站会是为经理/主持人准备的,而实际上它应该是为团队准备的。有多种方法可以打破这种依赖:轮换主持人 (Rotate the Facilitator)、避免眼神接触 (Break Eye Contact)、改变 昨天-今天-障碍 (Yesterday Today Obstacles) 的形式、使用 传递令牌 (Pass the Token) 等。
有人迟到
相同地点,相同时间 (Same Place, Same Time) 直接解决了这个问题,但正如前面提到的,这可能表明站会的时间或地点不对。
还有其他模式可以应对这种情况,例如罚款。然而,我通常不建议这样做,因为它们暗示问题在于外部动机,而实际上更有可能是其他原因。
站会开始时间... 迟了
因为站会被视为工作日的开始,所以在站会之前不做任何工作。根据站会开始的时间,这可能会对可用的工作时间产生重大影响。这导致了 不要用站会来开始一天的工作 (Don't Use the Stand-up to Start the Day)。
社交
站会的目标之一是加强团队的社交。然而,每日站会并不是为了让团队成员“互相了解”与项目无关的事情。很难为此提供例子,因为从团队建设到分散注意力的社交程度因团队而异。可以从没有直接参与社交的参与者的行为中发现这个阈值。如果他们的精力水平仍然很高,那么这可能只是团队建设;如果他们的精力水平下降,那么就 线下讨论 (Take It Offline),也许可以提供另一个论坛来充当 饮水机 (Water Cooler)。
我不记得了
我昨天做了什么?...我不记得了...我今天要做什么?...我不知道...
缺乏准备会导致节奏变慢,从而导致精力不足。它还有可能无法实现 十五分钟或更短 (Fifteen Minutes or Less) 的目标,这会进一步降低精力水平。
一个很好的解决这个问题的方法是,切换到 工作项参与 (Work Items Attend) 并且我们 巡视看板 (Walk the Board) 的站会模式。
否则,这就是对 昨天-障碍-今天 (Yesterday Obstacles Today) 的答案负责任的期望问题。
讲故事
参与者没有简要描述问题,而是提供了足够的细节和背景信息,导致其他人无法集中注意力。一般的规则是在站会期间识别障碍,并在站会结束后讨论细节。这可以概括为“只说标题,不说整个故事”或 线下讨论 (Take it Offline)。
解决问题
这是一个提出问题和想法的时间,而不是深入解决问题的时间。
将站会控制在 十五分钟或更短 (Fifteen Minutes or Less) 的关键是限制 讲故事 (Story Telling),并且不要在会议期间屈服于 问题解决 (Problem Solving)。线下讨论 (Take it Offline)。
精力不足
可能表明由于 讲故事 (Story Telling)、问题解决 (Problem Solving) 等原因导致节奏放缓。在这种情况下,线下讨论 (Take it Offline)。也可能仅仅是团队规模的问题。也可能是时间问题,这表明可以尝试 用站会来开始一天的工作 (Use the Stand-up to Start the Day) 和 不要用站会来开始一天的工作 (Don't Use the Stand-up to Start the Day) 这两种方法。
没有提出障碍
障碍没有被提出可能有几个原因。不记得了、忍痛能力强、对提出问题缺乏信任(因为 障碍没有被移除 (Obstacles are not Removed))、没有方便的方式提出问题等等。主持人应注意鼓励人们提出障碍。
引入 改进看板 (Improvement Board) 也可能提供一种不那么具有对抗性的媒介。回顾 (Retrospectives) 是发现 障碍没有被提出 (Obstacles are not Raised) 的根本原因的有效方法。
障碍没有被移除
除了指责性的环境外,阻止人们提出障碍的最可靠方法是不予理会。为了使人们难以忘记和/或忽视障碍,请使用**改进板**公开跟踪它们。
只在站会上提出障碍
站会就像一张安全网。在最坏的情况下,障碍会在一天内传达给更大的团队。然而,进行站会的目的并不是阻止在一天中提出和解决问题。引入另一种提出障碍的媒介,例如**改进板**,可能会有所帮助。如果没有,可以使用回顾来发现根本原因。
这真的只是每天聚在一起站着
希望本文能让您对有效站立实践的微妙细节以及常见问题指标有更深入的了解。应该清楚的是,每日站会不仅仅是每天站在一起。
归根结底,重要的是不要太在意每个模式,甚至是一些“坏味道”。记住我们试图解决的问题。人们有活力吗?人们在分享问题和想法吗?人们是否专注于我们的目标?人们是否在作为一个团队一起工作?每个人都知道发生了什么吗?
如果您可以肯定地回答这些问题,那么会议可能进展顺利。毕竟,这真的只是每天站在一起。
致谢
我要感谢最新版本的审阅者:Joe Ely、Steven List、Michelle Pace、Jonathan Rasmusson 和 Nigel Waddington
我还要感谢以前版本的审阅者:Ivan Moore、Alan Francis、Owen Rogers、Susan Newton、James Ross、Rebecca Parsons、Brian Marick、Dick Gabriel、Linda Rising、James Coplien、Lise Hvatum、Cecilia 和 Terje Haskins、Danny Dig、David Hecksel、Ali Arsanjani、Bill Wake、Ralph Johnson、Pau Arumi、David Garcia、Leon Welicki、Djamal Bellebia、Dirk Riehle、Hesham Saadawi 和 Paddy Fagan。
最后,我要感谢所有曾经和我一起参加过每日站会的人。
重大修订
2016 年 2 月 21 日:简化目标。根据 2011 年以来的其他文章进行一般更新。
2011 年 8 月 29 日:全面检修。强调“遍历看板”风格。
2007 年 1 月 15 日:完整修订
2006 年 7 月 17 日:首次发表于 martinfowler.com