【万字长文】详解每日站会的各类模式 | IDCF

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

详细内容

  • 站起来是为了保持会议的简短
  • “好”多是什么样的?
  • 当人们试图一块儿工做时出现的一系列特殊问题
  • 每日站会的模式
  • 谁来参加?
  • 咱们谈些什么?
  • 咱们按什么顺序发言?
  • 什么时候何地?
  • 咱们如何保持精力充沛?
  • 咱们如何培养自主性?
  • 咱们如何知道站会进展不佳?
  • 这真的只是天天一块儿站起来而已。

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

每日站会(也称为“每日Scrum”、“每日小会”、“早晨点名”等等)描述起来很简单:java

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

就是这样。web

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

那你怎么能知道呢?安全

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

可是对于新手来讲,当进展不顺时,他们不太可能知道该怎么作……并且更有可能的是,在没有外在帮助的状况下,他们会干脆彻底放弃这一实践。echarts

若是出现这种状况那将是很不幸的,由于运行良好的站会会给团队带来巨大的价值。less

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

2、“好”多是什么样的?

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

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

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

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

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

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

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

3、当人们试图一块儿工做时出现的一系列特殊问题

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

image.png

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

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

4、每日站会的模式

每日站会的模式经过回答如下问题来给出:

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

5、谁来参加?

5.1 全体人员

如下人员和表明均可出席:其余领域(如市场、生产支持、高管、培训师等)的人、但愿了解项目状态和进展的人、在必要时能够贡献出本身一份力量的人。在多个会议和报告中传达项目状态须要大量的重复工做。

所以

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

可是

若是有人以前没有参加过每日站会,他们可能不知道会议的流程,他们可能会作出一些扰乱站会秩序的行为。这能够经过提早告知新参与者和观察员预期的行为规范来解决。

并不是全部形式的报告内容都会(也不该该)被站会所涵盖。例如,项目的总体进展能够经过一个大型可视化图表[1]进行沟通,这个图表能够是燃尽图[1]、燃起图、累积流图等等。

5.2 工做项也要出席

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

若是故事对项目相当重要,它们就应该在站会上发言。

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

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

所以

与其把每日站会视为是人的仪式,不如把它视为是工做项(例如,敏捷开发中经常使用的用户故事)的仪式,人们参会只是为了替工做项发言……由于很显然工做项是不会说话的。

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

由于有了更清晰的焦点,人们才更有可能在没有提示的状况下提出障碍,并登记和解决障碍。

可是

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

6、咱们谈些什么?

6.1 昨天-今天-障碍

也被称为:三个问题

image.png

有些人很健谈,而且倾向于在讲故事的时候发散不少东西。还有些人在听到一个问题后就想当即解决这些问题。时间过长的会议每每会致使你们注意力不集中,与长时间讨论没有直接关系的参与者每每就会分心。

所以

能够用如下的格式来组织每日站会:

  • 我昨天完成了什么?
  • 我今天要作什么?
  • 哪些障碍阻碍了个人进展?

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

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

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

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

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

image.png

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

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

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

Jonathan Rasmussen提供了不一样的措辞,以改变站会的态势:

image.png

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

回答这类问题会彻底改变站会的态势。之前你只是站在那里并介绍一些近况,而如今是向全世界宣布你的意图。

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

也有一些团队增长了额外的问题:

  • Buffer添加了一个环节,人们能够分享他们正在努力提升的领域。[7]
  • Thomas Cagley建议寻找风险。[8]
  • Mark Levison发现添加更多有针对性的改进问题颇有用。为了适应具体的环境,最后两个问题可能须要被修改。
  • 你昨天完成了什么?
  • 你今天承诺作什么?
  • 你的阻碍/障碍是什么?
  • 你昨天发现了什么代码坏味道/缺失单元测试/…?
  • 你昨天对代码作了什么改进?

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

可是

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

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

6.2 改进板

也被称为:阻塞板、障碍板、改善报(Kaizen Newspaper)

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

所以

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

把一个问题写下来并明确地认可它,这个行为是减小冗长讨论的很是简单、可靠的方法。所以,即便不是每一个人都赞成某个特定事项是一个障碍,也值得把它简单地记录下来,以便在会后讨论。

在每一个提出的障碍上能够包括一个发生次数的统计,这样能够突出哪些问题一般更重要,须要首先处理。

改进板的设计能够有几种不一样的方式。例如,一个板的结构以下:

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

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

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

可是

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

7、咱们按什么顺序发言?

7.1 最后到达最早发言

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

所以

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

可是

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

7.2 顺序发言

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

所以

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

7.3 传递令牌

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

所以

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

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

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

可是

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

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

7.4 拿一张卡片

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

所以

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

7.5 走板(Walk the Board)

又称做为:走墙

image.png

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

——Bret Pettichord经过推特发送

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

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

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

所以

走板,即经过走过可视化看板/任务版上的每一个工做项来组织站会。

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

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

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

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

可是

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

若是不采用轮流主持或其余自组织的模式,走板更容易走向向领导汇报的泥潭。

8、什么时候何地?

8.1 在工做现场开会

在工做现场开会,而不是在会议室。

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

image.png

工做场全部许多关于正在发生的事情的记忆触发器。

咱们也不但愿这种每日会议须要大量的精力来查找、预约并走到会议室。

所以

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

可是

在“故事墙”或“看板”前面开会,会议的噪声可能会打扰到附近的人。这一般代表工做空间的设计是有问题的,但必须认可这个问题的存在。

8.2 同一地点,同一时间

image.png

咱们但愿团队对会议有一种主人翁的感受。咱们也但愿感兴趣的利益相关者可以前来观看站会,以免安排另外一个相似的状态同步会议,若是容许某个团队成员随意推迟时间或改变地点,这些好处都将难以实现。

所以

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

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

可是

同一地点,同一时间并非盲目地僵化。这里要重点强调的是,开始时间要基本一致,从新安排时间的状况应该会不多。若是须要常常从新安排会议时间,这多是一个迹象,代表开始时间应该调整。若是一个特定的地点对每一个人来讲都很不方便,这可能也是一个迹象,代表这个地点应该调整。

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

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

所以

使用站会做为一天工做的开始。因为不少公司采用弹性工做时间,并非每一个团队成员都会在同一时间赶到工做地点,应对“弹性工做时间”的一个常见作法是使用一组核心工做时间,即在某个时间段内团队成员是都在公司的(例如,中午12点到下午4点)。站会开始时间应该是在这组核心工做时间的开始。一样,若是团队成员因我的缘由常常须要晚一点到达(例如,须要送孩子上学),那么开始时间应该设定在一个让全部人都能参加的时间。

可是

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

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

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

所以

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

可是

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

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

9、咱们如何保持精力充沛?

9.1 抱团(Huddle)

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

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

image.png

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

所以

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

可是

团队必须平衡好亲密关系和我的隐私。即便在一个彼此很是信任的团队中,也存在人们因站得太近而不温馨的状况,症状每每是参与者紧张和/或烦躁不安。

9.2 站起来

image.png

有些人很健谈,而且倾向于在讲故事的时候发散不少东西。还有些人在听到一个问题后就想当即解决这些问题。时间过长的会议每每会致使你们注意力不集中,与长时间讨论没有直接关系的参与者每每就会分心。

所以

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

可是

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

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、咱们如何培养自主性?

10.1 轮流担任主持人

团队成员倾向于向领导汇报,也就是说,他们只与会议主持人交谈,而不是相互交谈。只有会议主持人在提出和解决与站会有关的流程问题。咱们但愿团队可以拥有站会的全部权,这就须要消除对单一主持人的依赖。

所以

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

可是

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

10.2 断开眼神接触

团队成员倾向于向领导汇报,也就是说,他们只与会议主持人交流,而不是彼此交流。咱们但愿团队可以掌握站会的主动权,这就须要消除对单一主持人的任何依赖。

所以

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

11、咱们如何知道站会进展不佳?

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

——Phillip A. Laplante,站会和交付:为何我讨厌站会[20]

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

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

11.1 专一于跑者,而忽略了指挥棒

人们过于关注他们正在作的事情,却忽略了他们的努力是否真的在推动工做。从新组织站会,让你们开始关注工做项。

11.2 向领导汇报

image.png

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

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 障碍只在站会时提出

站会能够做为兜底障碍的安全网,在最坏的状况下,障碍也会在一天以内被传达给整个团队。然而,站会并非为了阻止问题在一天内随时被提出和解决。引入另外一种实践(如改进板)来提出障碍可能会有所帮助。若是作了改进依然没有效果,能够经过回顾会来分析根本缘由。

12、这真的只是天天一块儿站起来而已

但愿这篇文章能为你提供一些关于有效站会实践的细节和问题常见指标的更多方法。咱们应该清楚,每日站会不只仅是天天站在一块儿。

最后,重要的是不要太在乎每一种模式,甚至是拥有一些“味道”。记住咱们要解决的问题:人们是否精力充沛?人们是否在分享问题和想法?人们是否专一于咱们的目标?人们是否做为一个团队一块儿工做?每一个人都知道发生了什么吗?

若是你能对这些问题做出确定的回答,那么会议可能会进行得很顺利。毕竟,这真的只是天天一块儿站起来而已。

参考资料:

  1. http://xprogramming.com/artic...
  2. http://www.exampler.com/blog/...
  3. http://blog.mountaingoatsoftw...
  4. http://olvemaudal.wordpress.c...
  5. http://radio.javaranch.com/la...
  6. https://book.douban.com/subje...
  7. http://joel.is/an-invitation-...
  8. https://tcagley.wordpress.com...
  9. https://agilepainrelief.com/n...
  10. http://%20web.archive.org/web...
  11. http://web.archive.org/web/20...
  12. http://brodzinski.com/2011/12...
  13. http://www.leanblog.org/2010/...
  14. https://www.linkedin.com/puls...
  15. http://edgibbs.com/2006/08/07...
  16. http://www.marketplace.org/20...
  17. http://blog.benjaminm.net/201...
  18. http://radio.javaranch.com/la...
  19. http://www.netobjectives.com/...
  20. http://queue.acm.org/detail.c...
  21. http://web.archive.org/web/20...
  22. http://blog.jbrains.ca/permal...
  23. http://www.retrospectives.com/

来源:小船哥说敏捷

做者:adoudou

声明:文章得到做者受权在IDCF社区公众号(devopshub)转发。优质内容共享给思否平台的技术同伴,如原做者有其余考虑请联系小编删除,致谢。

6月每周四晚8点,【冬哥有话说】开心一“夏”。公众号留言“开心”可获取地址

  • 0603 无敌哥 《IDCF人才成长地图与5P》(《端到端DevOps持续交付(5P)精品课》第1课)
  • 0610 冬哥 《带你玩转创新设计思惟》
  • 0617 无敌哥 《敏捷项目管理究竟是个啥》
  • 0624 冬哥 《VUCA时代的敏捷领导力》