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

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

 找回密码
 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 241|回复: 0

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

[复制链接]
发表于 2022-1-9 13:59:48 | 显示全部楼层 |阅读模式
一家互联网企业A开展敏捷转型时,曾走过这样一段弯路。首席技术官(CTO)听闻敏捷很流行,可以提升研发效率,意识到这是一个趋势。更为关键的是,友商在做敏捷!迫于竞争的压力,于是CTO下令:“搞敏捷!”
  j# d" @' t, ~; ~7 ?
可为什么搞,怎么搞,谁知道呢?!领导日理万机,怎么可能亲自抓?于是,CTO安排项目管理办公室(PMO)专门负责敏捷工作,目标只有一个:通过敏捷来提升研发效率。
' p" {% ~; W8 B: Z' V' [
PMO得到这个差事之后很有热情,正愁没有抓手驱动组织改进,这是个千载难逢的好机会。不过,总得先对敏捷有所了解。于是,PMO安排专人去参加了Scrum公开课。培训归来,PMO召集各部门主管,花了2个多小时,介绍了敏捷的概念,宣传了领导希望通过敏捷来提升效率的愿景,并要求大家积极响应。部门主管们一头雾水,没人愿意拿自己的团队做实验。但是,这个事情得继续推进,于是,PMO在领导的支持下,指定了一个部门开始试点。

2 G% o; S! U* ^  y
接下来,在任命了ScrumMaster和产品负责人(ProductOwner,简PO)后,试点部门的几个团队变成了“Scrum团队”。PMO为了固化敏捷,制作了检查表,监督团队每天开站会,以及每个Sprint都召开了计划会议和评审会议。在检查表中,开了这些会的团队打“√”,没开的打“×”,PMO定期将检查表上报给CTO。
4 `/ x, U" Z5 K  i" N- Q

0 B. T8 p, c# P6 T6 o# N0 z& B
就这样,试点部门的团队们开始了他们的“敏捷”之旅。懵懵懂懂地,几个团队坚持了三个月。PMO对团队进行了访谈:效果咋样?团队纷纷反馈,每天对着任务板沟通,感觉协作效率提升了。

) o' r1 F0 E- C1 Z: q" J
CTO听取了PMO的汇报,加之对提高研发效率的渴望,立即决定在公司范围内全面推行敏捷。于是,在试点团队还没有完全理解Scrum,并且在没有定量数据证明效果的情况下,Scrum就被仓促地大范围铺开了。一夜之间,产生了大量的ScrumMaster和产品负责人。PMO则忙得不可开交,因为有太多的团队需要指导、检查和监督。
: k4 e: M4 x$ v8 ~: l7 B) U
当我应邀去这家企业提供顾问服务的时候,发现该企业做了整整一年敏捷,不仅在数据上没有证明其有效地提升了研发效率,而且从团队的主观感受上也没有什么明显的效果。于是,很多部门主管开始抵制敏捷。CTO向我抱怨道:“说实话,我也开始怀疑敏捷了,这大大低于我们的预期啊!
: ~" X+ [  }, h" c' q* D
而当我深入团队后发现,没有一个团队对敏捷的理解是正确而又深入的,大家的敏捷实践还都只停留在简单的召开Scrum会议的层面。这家公司的问题可以归纳为如下几个方面。

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

! b  j% d$ c$ @' d  S
其次是团队的角色划分问题。虽然每个团队都任命了ScrumMaster和产品负责人,但是团队仍然保持着传统项目经理式的管控方式,完全没有自组织ScrumMaster也不知道自己与项目经理有什么区别。产品负责人不是来自于业务团队,而是由研发部门的业务分析员担任。
" `: Q7 L" I! J# I
产品负责人并没有与业务团队、用户密切合作,而仍旧是关起门来自己创造并分析需求。
* u) ~) ]7 h) _' ~0 H) s3 `# {; C
最后是Scrum里常见的几个会议问题。在每日站会上,团队成员给ScrumMaster汇报自己的工作状态,ScrumMaster则负责给每个人安排任务——今天该做什么,怎么做。在迭代计划(SprintPlanning)会议上,团队将用户故事拆分为前台开发、后台开发、架构设计、代码评审等任务;在Sprint评审会议上,ScrumMaster使用幻灯片来对团队的迭代工作进行总结,包括完成了哪些用户故事,解决了哪些Bug。在Sprint的回顾会议上,鲜有团队成员发言,多数情况都是在ScrumMaster安排好任务后便草草结束。
' [  @" y3 t- q6 a* {
除此之外,还有个别团队开展了一些零星的工程实践,例如“有空做,没空不做的”持续集成、自动化测试等。
7 j/ i! H8 T% v4 S9 T( \
这是一个在业界非常典型而且普遍发生的转型失败案例,我将其总结为“船货膜拜”(CargoCult),即肤浅地应用实践,但没有深入理解敏捷原则和实践的意图,因而也就没有达到敏捷应有的效果。

( c* D# K. D* F4 `& F
令人惊讶的是,很多企业都在做这种船货膜拜式敏捷:
  • 天召开站会,但却没有进行密切协作和自组织;
  • 每个迭代都有计划会议和评审会议,但在迭代结束时没有可交付的产品增量;
  • 每个迭代都有回顾会议,但团队的流程、效率质量、协作等却没有实质的改进;
  • 各种Scrum角色也都存在,但没有行使Scrum赋予他们的职能;
  • 开展的各种工程实践属于应付差事,没有起到实质性作用。
    6 T+ G) u6 W" k3 P+ r( A4 W8 T: A3 e

! y$ E3 R+ P7 S  Z
因此,敏捷转型不是一件说做就做、照猫画虎的事情。相反,它是一场艰巨的变革运动。

. N# m) U, e7 A/ q

& T$ h4 `3 e3 d6 w' T4 X+ Q




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

本版积分规则

参加 ITIL 4 基础和专家认证、长河ITIL实战沙盘、DevOps基础级认证、ITSS服务经理认证报名
ITIL(R) is a registered trademark of AXELOS Limited, used under permission of AXELOS Limited. The Swirl logo is a trademark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.

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

GMT+8, 2023-1-28 02:30 , Processed in 0.094727 second(s), 29 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

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