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

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

 找回密码
 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 126|回复: 0

货物崇拜--典型的敏捷失败模式

[复制链接]
发表于 2022-1-9 13:59:48 | 显示全部楼层 |阅读模式
一家互联网企业A开展敏捷转型时,曾走过这样一段弯路。首席技术官(CTO)听闻敏捷很流行,可以提升研发效率,意识到这是一个趋势。更为关键的是,友商在做敏捷!迫于竞争的压力,于是CTO下令:“搞敏捷!”

# t7 Y8 ^- ^- U1 Z2 `) D2 I
可为什么搞,怎么搞,谁知道呢?!领导日理万机,怎么可能亲自抓?于是,CTO安排项目管理办公室(PMO)专门负责敏捷工作,目标只有一个:通过敏捷来提升研发效率。
4 `! R/ [/ F4 N% v, C6 Q5 X
PMO得到这个差事之后很有热情,正愁没有抓手驱动组织改进,这是个千载难逢的好机会。不过,总得先对敏捷有所了解。于是,PMO安排专人去参加了Scrum公开课。培训归来,PMO召集各部门主管,花了2个多小时,介绍了敏捷的概念,宣传了领导希望通过敏捷来提升效率的愿景,并要求大家积极响应。部门主管们一头雾水,没人愿意拿自己的团队做实验。但是,这个事情得继续推进,于是,PMO在领导的支持下,指定了一个部门开始试点。
* v) B* L+ h8 q7 K
接下来,在任命了ScrumMaster和产品负责人(ProductOwner,简PO)后,试点部门的几个团队变成了“Scrum团队”。PMO为了固化敏捷,制作了检查表,监督团队每天开站会,以及每个Sprint都召开了计划会议和评审会议。在检查表中,开了这些会的团队打“√”,没开的打“×”,PMO定期将检查表上报给CTO。
/ p* l- S' O* d& Y0 n" b4 l

# S! {. L( D' N# P
就这样,试点部门的团队们开始了他们的“敏捷”之旅。懵懵懂懂地,几个团队坚持了三个月。PMO对团队进行了访谈:效果咋样?团队纷纷反馈,每天对着任务板沟通,感觉协作效率提升了。
+ V% ]3 {4 E  Z5 l0 L" W
CTO听取了PMO的汇报,加之对提高研发效率的渴望,立即决定在公司范围内全面推行敏捷。于是,在试点团队还没有完全理解Scrum,并且在没有定量数据证明效果的情况下,Scrum就被仓促地大范围铺开了。一夜之间,产生了大量的ScrumMaster和产品负责人。PMO则忙得不可开交,因为有太多的团队需要指导、检查和监督。
# i+ Q! _2 I: ]+ p, B
当我应邀去这家企业提供顾问服务的时候,发现该企业做了整整一年敏捷,不仅在数据上没有证明其有效地提升了研发效率,而且从团队的主观感受上也没有什么明显的效果。于是,很多部门主管开始抵制敏捷。CTO向我抱怨道:“说实话,我也开始怀疑敏捷了,这大大低于我们的预期啊!
$ o; }2 j4 q( E  ~; v( b3 h
而当我深入团队后发现,没有一个团队对敏捷的理解是正确而又深入的,大家的敏捷实践还都只停留在简单的召开Scrum会议的层面。这家公司的问题可以归纳为如下几个方面。

( g$ I' p- H$ }) J
首先是团队的组织结构问题。虽然每个团队都被称作Scrum团队,但其仍旧是职能团队,即按照工作职能进行划分的前台团队、后台团队、底层驱动团队等。在没有组建“特性团队”的情况下,很多部门主管不知道敏捷团队的组织架构应该是什么样子,而个别对其有些了解的主管则认为,那样的架构不符合组织的现实情况,所以不应该也不需要调整。

1 J8 [$ `2 z1 w! V( W3 m; w
其次是团队的角色划分问题。虽然每个团队都任命了ScrumMaster和产品负责人,但是团队仍然保持着传统项目经理式的管控方式,完全没有自组织ScrumMaster也不知道自己与项目经理有什么区别。产品负责人不是来自于业务团队,而是由研发部门的业务分析员担任。

3 U; |- k! e4 H% y
产品负责人并没有与业务团队、用户密切合作,而仍旧是关起门来自己创造并分析需求。

/ Q+ ^' V" G  p
最后是Scrum里常见的几个会议问题。在每日站会上,团队成员给ScrumMaster汇报自己的工作状态,ScrumMaster则负责给每个人安排任务——今天该做什么,怎么做。在迭代计划(SprintPlanning)会议上,团队将用户故事拆分为前台开发、后台开发、架构设计、代码评审等任务;在Sprint评审会议上,ScrumMaster使用幻灯片来对团队的迭代工作进行总结,包括完成了哪些用户故事,解决了哪些Bug。在Sprint的回顾会议上,鲜有团队成员发言,多数情况都是在ScrumMaster安排好任务后便草草结束。
' w: H8 O; N/ i% X4 m
除此之外,还有个别团队开展了一些零星的工程实践,例如“有空做,没空不做的”持续集成、自动化测试等。

) b% g0 n) ]9 n/ A4 l+ i
这是一个在业界非常典型而且普遍发生的转型失败案例,我将其总结为“船货膜拜”(CargoCult),即肤浅地应用实践,但没有深入理解敏捷原则和实践的意图,因而也就没有达到敏捷应有的效果。

4 _2 \8 K. N6 M+ K2 y. C9 w( J4 a
令人惊讶的是,很多企业都在做这种船货膜拜式敏捷:
  • 天召开站会,但却没有进行密切协作和自组织;
  • 每个迭代都有计划会议和评审会议,但在迭代结束时没有可交付的产品增量;
  • 每个迭代都有回顾会议,但团队的流程、效率质量、协作等却没有实质的改进;
  • 各种Scrum角色也都存在,但没有行使Scrum赋予他们的职能;
  • 开展的各种工程实践属于应付差事,没有起到实质性作用。
    ) }8 u) K! [% h& g( p% C
8 _6 H; J+ T; Y- a
因此,敏捷转型不是一件说做就做、照猫画虎的事情。相反,它是一场艰巨的变革运动。
/ |! Z8 n+ z! [" x

. o4 N- z# V' D9 X; T- d




上一篇:为什么说敏捷是必然趋势
下一篇:敏捷转型会遇到哪些困难
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

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

QQ|ITIL ( 粤ICP备11099876号 )|appname

GMT+8, 2022-8-17 10:08 , Processed in 0.095276 second(s), 29 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

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