每日站会并不是只是站在开会就行了:每日站会范例
日常站会已经成为很多团队的惯例,尤其是在敏捷软件开发(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)等。
工作事项核心
也叫:故事核心的站会
如果故事对项目来说非常重要,站会中就该是它们发言
人们太注意接力者了,而没有给予接力棒足够的重视。也就是,人人都在忙着做事,但并不一定是处理工作事项。
因此
把日常站会看作是以工作事项(例如在敏捷软件开发背景下的用户故事)为核心的惯例,而不是人的惯例,与会者只是代表工作事项发言……因为工作事项显然不会说话。
昨日今日困难的问题可能仍然适用,但是是从工作事项角度出发的,而不是从人的角度出发的。这也意味着不是每个人都会发言。人们没有责任要说跟改进工作无关的事情。
由于这样更清晰的关注点,人们更可能在不需要督促的情况下提出困难和申请解决困难。
但是
没有发言的责任可能会隐藏一些人的问题,他们害羞或者往往在这种情况下不发言。这在以工作事项为核心的情况下更难察觉。
我们谈论什么?
昨日今日困难
也叫:三个问题
有些人健谈,可能漫谈到讲故事中去。有些人想在听到问题后立即开始解决问题。过于长的会议往往是低迷的,与长时间的讨论没有直接关系的参与者往往会分心。
因此
用以下格式组织谈话内容:
- 我昨天完成了什么?
- 我今天要做什么?
- 什么障碍拖延了我的进度?
满足日常站会的目标至少需要这 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 提供了不同的说法来改变站会的动态:
▪你昨天做了什么来改变世界
▪你今天准备怎么做
▪你准备怎么突破任何不幸挡了你路的困难
回答这些类型的问题完全改变了站会的动态。你正在使尽浑身解数,宣布你对宇宙的意图,而不是仅仅站在那陈述更新信息。
还有很多团队加入了额外的问题。
Buffer 增加了一个部分,人们可以分享手头上用来提升自己的事请。
Thomas Cagley 建议寻找风险。
Mark Levison 发现,增加更有针对性的改进问题是有用的。改动后两个问题来与具体背景接轨。
1、你昨天完成了什么?
2、你今天要做什么?
3、 障碍/困难有哪些?
4、你昨天注意到什么代码味道/缺少单元测试……了吗?
5、昨天你对代码做了哪些改进?
但是
结构不像由问题的答案所提供给我们的信息那么重要。如果提供信息的准则不那么结构化,遵循清单就不重要了。随着团队成长,你可能会发现你想要调整结构,反映了这个范例是如何演变的。
更大的问题是,昨天今天困难是否太过于关注个人成就,而不是注意正确的事情……这就引向了。
改进板(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. 根据优先级的其他事件
但是
显然,一块板是需要预先准备的,不是所有团队都有。在这种情况下,一人一人发言的结构更合适。
过一遍板更可能会屈从于向队长汇报,如果没有应用轮流当协调人或者其他自我组织范例。
时间和地点
在工作地点开会
在工作场地开会,而不是在会议室。
工作地点有很多触发记忆的东西,能让你想起来发生的事情。
我们也不希望日常会议需要大量提前协调、寻找再走到开会的房间。
因此
在工作地点开会,而不是在会议室。如果你们有故事墙或者看板,就在它前面开会。
但是
附近的其他人可能会觉得会议的噪音令人分心。这一般暗示了潜在的糟糕工作空间设计,但仍然必须被承认。
同样的时间,同样的地点
我们希望团队对站会有主人翁意识。我们也希望利益相关方能路过旁听一场站会,避免再安排另一场状态会议。如果任意队员都能强制推迟或者改变站会的地点,这就很难实现。
因此
团队要同意在同一时间同一地点开站会。不要等掉队的人,包括发起人和经理。会议是为整个团队开的,而不是为了某个人。如果你用站会来开始一天的话,这就尤其重要了。
一些更严格的团队可能会惩罚迟到者。我倾向于讨论,并谨慎使用任何惩罚。
但是
同一时间同一地点并不是盲目地不知变通。重要的是开始时间基本一致,很少要重新安排。如果经常需要重新安排,可能意味着应该调整开始时间。如果每个人都不方便去某个地方,很可能意味着应该调整地点。
用站会来开始一天
日常站会让我们意识到并注意突出问题。如果在晚些时候开站会,那么这种注意和意识就浪费了。
因此
用站会来开始一天。由于弹性工作时间,不是每个队员都在同一时间开始上班。针对弹性工作时间的一个常见方法是利用核心工作时间。站会应该在核心工作时间开始时开始。
类似地,如果队员由于个人原因要迟到一会(比如得送孩子上学),站会开始时间应该设在每个人都能参加的时刻。
但是
在站会前大家往往不会做任何与项目相关的任务。如果开始一天的站会开晚了,懒散时间会很显著。到某种程度下,这些时间可能会被简单地用来查看邮件、填时间表等。但是把站会安排在晚一点的时间,而不是“一天的开始”值得研究。
别用站会来开始一天
站会往往被作为为一天设置关注点的惯例,尤其是如果你用站会来开始一天。因此,在站会开始前,队员往往不处理特性。当会议实际上不是第一件事时,这个倾向可能会对生产效率有显著影响。
因此
别用站会来开始一天。把日常站会安排到一个足够晚的时间,晚到人们不会从心理上把会议和一天的开始联系在一起。
但是
如果不用日常会议开始一天,那它就不能再作为一个在一天的开始设定团队关注点的惯例了。效率的明显提高可能不值得这样的代价,取决于不同团队。
当有很多项目用到站会时,可能同时有很多站会。对多个项目感兴趣的观察者可能想要更改站会时间,这样他们能都参加。问题在于,如果一个观察者能要求与会者调整他/她的安排,会威胁到团队的主人翁意识。然而,在决定什么时候开站会时也必须考虑这一点。
我们怎样保持精神抖擞?
聚集在一起
我经常发现的问题是,人们往往把日常站会看作简单的个人报告。“我做了这个……我要做那个”——接着下一个人也这么说。更理想的方法是站得更近,像足球队围在一起那样。
讲话的音量影响参与度,也影响交流的效率。物理距离会改变好的交流所要求的音量。有些人不大声讲话,大声讲话会感到不舒服。
因此
站会更应该是 Huddle 而不是会议。如果很难听清,让大家站近一点。除了可以用更轻松的说话音量,身体上更接近往往也会增加与会者的参与度。能够站得更近也表现了队里更多的信任感。如果站会是一个新事物,用手势招呼别人参加和说些有“来吧。”效果的话通常来说就足够了。如果圈子的大小已经建立了一段时间,在尝试缩小它之前考虑解释一下缩小圈子的原因。
但是
团队必须平衡近距离和个人舒适区域。即使在非常有信任感的团队中,也有一个点,站得太近以至于超过了这个点,人们会觉得不舒服。症状往往是与会者紧张并/或者坐立不安。
站起来
有些人健谈,可能漫谈到讲故事中去。有些人想在听到问题后立即开始解决问题。过于长的会议往往是低迷的,与长时间的讨论没有直接关系的参与者往往会分心。
因此
在会议期间要求所有与会者站起来。用站立来链接身体和心理的意愿。身体上的不适也会提醒与会者会议拖得过长了。鼓励这种做法的一个简单方法是:直接在没有椅子的地方开会。
但是
站起来往往会导致会议缩短,但并不保证会缩短到一个理想的时长。人们可能会学着适应不适感而不是采用一个更合适的对策。而且如果会议没有拖得过长,也没有跑题,站起来就是一个不必要的仪式了。
十五分钟或者更短
大多数人会在长时间的会议中走神。又长又无聊的会议是一个糟糕的、消耗精力的开始一天的方法。一个具体的时长帮助我们想起来什么时候该考虑调整,以缩短会议时长。
因此
保持日常站会在十五分钟或者更短。一般来说,十五分钟过后,普通人开始走神,这对设定关注点来说一点帮助都没有。
但是
十五分钟对小一点的团队来说可能太长了。由于走神的影响,甚至对大一点的团队来说,十五分钟是一个好的限制。另外,会议也可能太短,以至于结束时,与会者仍然不清楚发生了什么或者该问谁来弄清楚。
结束信号
在最后一个人发言结束后,团队可能不会马上意识到会议结束了。如果人们是逐渐意识到该散了的,会议不能高调结束,可能会导致低迷。
因此
用一句顺嘴的话(例如,“好了,大家去吃午饭吧。”)或者其他动作作为站会结束的信号。
给会议计时
很难从量上判断站会是否超时,尤其在长度是逐渐增加的情况下。
因此
给会议计时并发布结果。大多时候,与会者仅仅是没有意识到讲故事的影响,没有准备要线下讨论,也没有准备会议要开多久。把它量化。
但是
和所有措施一样,除非真的有一个要完成的目标是由于能量级导致的问题,不应该引入给会议计时的方法。一旦完成目标,应该抛弃这个方法。没有特定的原因就计时会导致怀疑和对度量的冷漠。
时间是精力、注意力和节奏的代表。要更注意这些东西而不是时间。
线下讨论
有些人想要在听到问题后立即开始解决问题。过于长的会议往往是低迷的,与长时间的讨论没有直接关系的参与者往往会分心。承认要解决提及的问题需要进一步讨论仍然是重要的。有些人可能会觉得打断站会的结构不舒服。
因此
用像“线下讨论”这么一句简单一致的话作为提示,提醒大家这样的讨论应该在日常站会外进行。如果讨论的是社交,没有更多要求。如果讨论的是解决问题,协调人(最终就是团队)应该确保提名或者指定了正确的人来之后解决问题。
或者,有些团队使用更间接的信号。
例如,Mike Cohn 描述了一个信号,使用橡胶老鼠来暗示“我们要钻进老鼠洞了”。
Benjamin Mitchell 描述了一个双手法则:
如果任何人觉得现在的对话跑题了,或者已经不再有效率了,他们就举起一只手。一旦另一个人也举起了手,就标志着这段对话该结束了,并继续站会的剩余部分。正在发言的人可以在站会结束后继续。
— Benjamin Mitchell, “Stuck in an overlong Agile stand up? Try the two hands rule”
但是
解决问题和澄清问题有不同之处。没有被理解的信息是没用的。允许澄清问题到哪种程度取决于团队的大小以及是否会影响十五分钟或更短这一规则。
我们怎么鼓励自主?
轮流当协调人
队员向队长汇报,也就是他们只跟会议协调人说话,而不互相说话。会议协调人只提出并解决与站会相关的过程问题。我们希望团队作站会的主人,这就要求去除对单个协调人的依赖。
因此
轮流当协调人。轮流安排队员负责确保大家参加站会,并坚持商定的准则。
但是
没有丰富站会经验的团队从一个经验丰富的教练那收获颇多。更重要的是,团队应该戒除依赖,对站会掌握更多的控制。到了一定时刻,就不该要协调人了。
打破眼神交流
队员向队长汇报,也就是他们只跟会议协调人说话,而不互相说话。会议协调人只提出并解决与站会相关的过程问题。我们希望团队作站会的主人,这就要求去除对单个协调人的依赖。
因此
协调人必须打破眼神交流,来委婉提醒发言者,他/她应该强调整个团队而不是一个人。一种方法是四处走走,这样当前的发言者就看不见协调人了。
我们怎么知道什么时候站会进行得不顺利?
我忍受了三年日常站会。站会中最让我痛苦的是我的老板(我叫他 Wally)。他开站会的主要原因不是提高效率,也不是尽可能多地用 XP 来减少人与人在与产品直接相关事情之外的互动。然而,对 Wally 来说,站会(例如周一早上 7 点的会议和周五下午 5 点的会议)是用来加强雇主和雇员关系的忠诚度测试。
— Phillip A. Laplante, “Stand and Deliver: Why I Hate Stand-Up Meetings”
站会的“味道”是极好的暗示事情进展不顺利的指示剂。重要的是注意即使你没有闻到什么,也不意味着站会进行得顺利。这只意味着它不臭。
下面的这些味道,大多数都与前面的范例有关。与前面的范例无关的那些,潜在的问题往往更轻微,或者是在日常站会的关注点之外;人们得想出自己的解决方法。
注意接力者,而不是接力棒
人们太注意自己正在做什么了,而忽略了去考虑他们的行动是不是真的在改进工作。重新组织站会,这样就是以工作事项为核心了。
向队长汇报
队员面对着经理或者会议协调人,还要跟他们说话,而不是跟团队说话。这表明日常站会是为经理/协调人准备的,但它实际上是为团队准备的。有很多方法来打破这种依赖性:轮流当协调人,打破眼神交流,改变昨日今日困难问题的模式,传递信物等。
人们会迟到
这直接用同一时间同一地点解决,但是像之前提到的,这可能意味着站会举办的时间或者地点不对。
有其他范例来处理这个问题,比如罚款。但是,我一般不推荐这些方法,因为它们暗示这些问题是外在推动的,但是更可能有其他原因。
开始一天的站会开晚了
由于站会被视为工作日的开始,站会之前没有工作能完成。这可能会对可用工作时间产生显著影响,取决于早晨的站会多晚开始。这引向了别用站会来开始一天。
社交
站会的目标之一是提高团队的社会化程度。但是,日常站会不是为了队员能在与项目无关的事上互相“跟上”。很难举出例子,因为社交从团建到偏离的程度取决于不同的团队。这个界可以从未直接参与到社会化中的参与者的行为中检测到。如果他们保持积极的精力水平,那么可能就是团建;如果他们的精力水平降低,那么就线下讨论,可能的话用另一场讨论来充当饮水机。
我不记得了
我昨天做了什么?…__…我不记得了……我今天在做什么?…__…我不知道…__…
缺乏准备导致更慢的进节奏,从而导致低迷。这也冒着满足不了十五分钟或更少这一规则的风险,这会进一步降低精力水平。
绕过这个问题的一个好方法是转向以工作事项为核心的站会,并过一遍板。
否则,这是一个期望的问题,期望人们有责任知道昨日困难今日问题的答案。
讲故事
参与者不是只简单描述一个问题,而是提供了足够的细节和背景导致别人走神。一般规则是在站会期间识别困难,在站会后讨论细节。这可以总结为“讲讲标题,而不是整个故事”或者线下讨论。
解决问题
站会是提出问题和表面想法的时间,而不是深度解决问题的时间。
保持站会在十五分钟或者更短的关键是在会议期间限制讲故事,别屈服于解决问题。线下讨论。
低迷
低迷可能暗示着由讲故事、解决问题等导致的节奏变缓。在这种情况下,线下讨论。低迷可能仅仅是团队规模的问题。低迷也可能暗示该试试备选的用站会来开始一天和别用站会来开始一天。
没提及的困难
也叫:游记
困难没被提及有很多原因。不记得了、高疼痛阙值、对提出问题的不信任感(因为困难没有被解决)、没有提出问题的方便渠道等。协调人应该鼓励人们提困难。
引进一个改进板也能提供一个不那么有压迫感的中介。Retrospectives 是发现困难没有被提及的潜在原因的有效方法。
困难没有被解决
除了埋怨环境之外,让人们停止提困难的最确定的方法是别解决困难。为了让人们很难忘记或者忽略困难,用改进板公开跟踪它们。
只有在站会上提出的困难
站会充当一个安全网。在最糟糕的情况下,一天内会将一个困难与更大的团队交流。但是,开站会并不是为了避免问题被提出并在一天内解决。引进一个像改进板这样的替代媒介来提出困难可能有用。如果没用,潜在原因可能会在使用 Retrospectives 时发现。
真的只是每天一起站起来
希望这篇文章为你提供了一些关于有效站会的细节和常见问题指示的见解。要清楚日常站会不仅仅是每天一起站起来。
在一天结束时,重要的是不要太在意每一个范例,或者有某些“味道”。记住我们正试着解决的问题。大家精力充沛吗?大家在分享问题和想法吗?大家是否专注于我们的目标?大家是否像一个团队一样工作?每个人都知道发生了什么吗?
如果你能肯定地回答这些问题,站会很可能还比较顺利。毕竟,真的只是每天一起站起来。
本文文字及图片出自 伯乐在线
你也许感兴趣的:
- 【外评】研究发现敏捷软件项目失败的可能性高出 268%。
- 【外评】《敏捷宣言》合著者抨击失败率报告,大谈 “重新构想 “项目
- 【程序员搞笑图片】敏捷开发
- 敏捷宣言并未改变任何事情
- 敏捷时代必须终结
- 被捧上天的 Scrum 敏捷管理为何不受大厂欢迎了?
- 事实证明,假敏捷都比瀑布优秀
- 为什么总有人喜欢说“敏捷已死”?
- 为什么谷歌的开发人员认为敏捷开发是无稽之谈?
- 译 | 为什么使用 Scrum 开发软件是错误的?
你对本文的反应是: