请选择 进入手机版 | 继续访问电脑版

ITIL,DevOps,ITSS,ITSM,IT运维管理-ITIL先锋论坛

 找回密码
 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 124|回复: 0

敏捷研发每日站会的常见误区

[复制链接]
发表于 2022-1-9 17:51:29 | 显示全部楼层 |阅读模式
每日站会是Scrum团队每天自我检查和调整的机会。关于站会的流程,一般的团队都知道,本书不再赘述。但是大部分刚开始尝试Scrum的团队,或多或少都会碰到以下一些误区。

( V2 B4 \; {6 k6 {2 ?
1.站会不是每天开

( e% U- l. _' a% [9 j+ K7 J: E
经常有团队质疑:“站会为啥要每天开?太浪费时间了。我们从前一周一次周会,不就够了吗?”
3 p9 u' d+ J& L/ b6 h8 ]' t& S
如果一周一次会议,团队彼此之间的信息同步、状态对齐,以及工作的调整周期就是一周发生一次。这样的频次不可避免地会有一个又一个意料之外的事情发生,而这时才开始采取措施来调整,很难保证在一个Sprint内能够实现目标。

2 t% a" y; H- Y% D+ |& W
也有团队说:“我们每天开站会,好像也没发生什么大问题需要解决,是不是太频繁了?还是一周开两次吧!”

7 X8 M3 n& N+ U& ^
如果每天没有什么大问题发生,应该庆幸才对,因为在发生之前团队已经提前规避了风险。如果等发生了大问题后隔了一天才知道,这时候已经晚了一步。

1 \" D5 h9 w; T8 I  s6 [9 p
2.总是有人迟到

2 P  W  z& G" d: S0 I
如果团队经常有人迟到,应该分析一下大家为什么迟到。是不是因为时间不合适,是不是因为大家的座位不在一起,还是由于任务板的位置离工位太远,等等。总之,要了解背后的原因,才能解决根本问题。
% ~1 [; z0 h: Y1 y! s  F: W5 V
如果没有什么背后的原因,只是因为大家不习惯按时到会,那就可以用团队的工作协议来解决。设定工作协议也要注意符合团队和组织的文化。有的团队喜欢采取惩罚的机制,而有的公司不喜欢这种罚款机制,更喜欢用一些正面的奖励机制来牵引。采用什么工作协议没有对错之分,只要团队达成共识,一同遵守即可。

7 w* A: l/ ~# s9 |
1.只动嘴,不更新任务板

3 @' K9 A% u' H- G2 L& k) `* A; D
站会上轮到每个人说话的时候,大家都面朝着任务板,只动嘴说,而任务卡原封不动,或者只是更新了个别任务卡的状态。

$ @  q" d  T4 Z8 K9 c
为什么要用任务板?因为任务板具有可视化功能,可以让团队每个人对每个用户故事、每个任务的状态一目了然。一个状态不保真的任务板,意味着每个人只知道自己手里的任务和用户故事的状态,而其他人不知道;已经完成的卡片还在进行状态中,而已经启动的卡片还在准备状态中,这样团队就对整体上这个Sprint的状态没有正确的认识。

0 |+ ?/ L  Z9 h5 M/ W8 I2 ?
2.啥都谈,就是不谈障碍和风险
2 x) }% e3 ^3 C/ D+ O
我曾经辅导过一个团队,每天站会上风平浪静,大家一一说完自己昨天做了什么,今天要做什么,移动一下卡片就结束了。可是团队每天的进展都很慢。为什么会这样呢?我仔细观察后发现,站会上没有一个人提及自己碰到了什么问题,有什么障碍和风险需要解决。于是,在团队站会结束的时候,我问大家:“真的什么事情都没有吗?请每位同事把站会的第三个问题说出来——我遇到了什么障碍。”
1 y( F9 y$ @- i- i* |( v
结果一发不可收拾。第一个同事说:“我昨天认领了这个任务,可是我发现原先的代码逻辑我有些看不懂,所以过了一天也没做完。也不知道从前这块是谁做的,为啥要那样设计……”随后,几乎每个同事都说出了自己碰到的困难和问题。为什么之前大家都不愿意说呢?因为这个团队已经养成了“一切靠自己”的习惯。更深层的原因是,当工程师求助的时候,其他人忙于做自己的任务,而没有时间和意愿帮助他。
" c9 N6 d# S+ K
暴露障碍是站会的一个重要议题,ScrumMaster的职责之一就是引导团队暴露障碍,帮助团队解决障碍。

) N( k8 k4 A0 e, w  r' R# Q1 C
3.僵化站会的三个问题

: ?4 I  P' P4 Z, y0 p, N
Scrum站会上,标准的三个问题是:
, L; B0 V5 L5 Z' @
  • 我昨天做了什么?
  • 我今天要做什么?
  • 我遇到了什么障碍?' {& _" X7 N( u6 P6 Q7 R

    , I6 o- F. _2 [  k# Q+ F
5 j* ^- c# F3 Y3 e4 b0 u7 D
这并不意味着每个团队必须永远使用这个模板。每个团队要依据自己的情况,调整会议日程。比如,有个团队在试点了Scrum几个月后,发现了一个问题:他们昨天做的并没有给他们带来什么实际价值,反而他们需要及时暴露项目的潜在风险,而这个问题在日程里没有。于是他们将站会问题改为:

/ y4 d7 g; H2 w# Z
  • 我今天要做什么?
  • 我遇到了什么障碍?
  • 我的任务有什么风险?6 G. y' c$ r" _. Q- L

    2 s1 S1 {6 F+ m

% s! t/ b# J5 L7 h7 k. d. @
1.团队向ScrumMaster汇报工作
) z  {. d: ]; Z5 n1 S
在很多Scrum团队的站会上,这一幕你应该看到过:每个同事面向ScrumMaster,回答站会日程里那三个问题。然后,ScrumMaster给出指示:你该注意什么,明天需要做什么。每个同事都这样依次汇报完毕后,站会结束。

7 e( Z, T3 Y2 ^, |3 o  h
这种情况在由项目经理、项目组长或管理层的人员转型做ScrumMaster的人身上容易出现。因为在做Scrum之前,团队就是向他/她汇报工作。因此在站会上,大家就自然地继续向他/她汇报。
# l8 L5 F9 ^& I) h# t$ n& e8 f
当然,这也与大家对ScrumMaster的认知有关。很多团队没有接受过Scrum的培训,以为ScrumMaster与管理者没有区别,只是换了个名字,所以自然就把ScrumMaster当作领导,在站会上向他/她汇报情况。

4 e+ `! b4 ]& k: v7 F
那么如何扭转这个现状呢?其实不止是在站会上,ScrumMaster需要学会在各种活动中引导团队自组织,因为只有自组织的团队才是最高效的(参阅第10章)。
7 |7 m/ q6 ~- T0 b
2.ScrumMaster给每个同事分配任务
' F" T5 C! u* U! T8 H( g7 ]$ w$ h
这个现象产生的原因与上一条相同,不是ScrumMaster本身就是从管理者转型而来,就是团队对ScrumMaster的理解有误。ScrumMaster应该鼓励团队成员主动认领工作任务,积极发挥团队的主观能动性。
0 t- X* N. o" m5 \2 Z% y
3.团队以外的人到站会上指手画脚

8 ~9 A: m2 Y1 l" O% i! w# G
团队在开站会的时候,产品负责人突然跑来打断团队,给团队的任务板上放了一张紧急的用户故事卡片,然后现场讲解需求,于是,站会就演变成了新需求澄清会。

# D6 F/ k" L" |
除了产品负责人以外,团队所在的部门主管有时候也到站会上来。
$ ~3 V2 c5 L+ b5 a% \  l" L2 i
一些主管很好奇,想看看大家玩敏捷是个什么样子,到底有没有收益。在一次站会上,团队提出了阻碍,说缺少大容量的服务器。主管着急了,接上话说:“怎么会少呢,给你们团队分配的最多了,你们都做什么用了?”团队立马安静了,后面的同事也都不敢提障碍和问题了。而有的主管则会说:“这个待会我找下IT部门,帮大家推动一下。”这种处理方式就不会破坏团队自组织的积极性。

& {8 u) m. t  K: \& t
总之,无论是产品负责人还是部门主管,都尽量别到站会上来。团队如果真的需要他们来帮助推动,会主动找他们的。
0 g2 x5 y: z) @, m1 ~7 M0 O
0 I# }7 O; N; I+ @# D3 C




上一篇:开展敏捷研发Sprint计划会议的步骤
下一篇:什么是敏捷研发SprintDemo
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

参加 ITIL 4 基础和专家认证、长河ITIL实战沙盘、DevOps基础级认证、ITSS服务经理认证报名

QQ|ITIL先锋论坛 ( 粤ICP备11099876号 )|appname

GMT+8, 2022-7-5 15:25 , Processed in 0.095775 second(s), 27 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

快速回复 返回顶部 返回列表