1.2　敏捷转型是一项艰巨的工作

1.2.1　典型的失败模式：船货膜拜

　一家互联网企业A开展敏捷转型时，曾走过这样一段弯路。首席技术官（CTO）听闻敏捷很流行，可以提升研发效率，意识到这是一个趋势。更为关键的是，友商在做敏捷！迫于竞争的压力，于是CTO下令：“搞敏捷！”

可为什么搞，怎么搞，谁知道呢？！领导日理万机，怎么可能亲自抓？于是，CTO安排项目管理办公室（PMO）专门负责敏捷工作，目标只有一个：通过敏捷来提升研发效率。

PMO得到这个差事之后很有热情，正愁没有抓手驱动组织改进，这是个千载难逢的好机会。不过，总得先对敏捷有所了解。于是，PMO安排专人去参加了Scrum公开课。培训归来，PMO召集各部门主管，花了2个多小时，介绍了敏捷的概念，宣传了领导希望通过敏捷来提升效率的愿景，并要求大家积极响应。部门主管们一头雾水，没人愿意拿自己的团队做实验。但是，这个事情得继续推进，于是，PMO在领导的支持下，指定了一个部门开始试点。

接下来，在任命了Scrum Master和产品负责人（Product Owner，简称PO）后，试点部门的几个团队变成了“Scrum团队”。PMO为了固化敏捷，制作了检查表，监督团队每天开站会，以及每个Sprint都召开了计划会议和评审会议。在检查表中，开了这些会的团队打“√”，没开的打“×”，PMO定期将检查表上报给CTO。

就这样，试点部门的团队们开始了他们的“敏捷”之旅。懵懵懂懂地，几个团队坚持了三个月。PMO对团队进行了访谈：效果咋样？团队纷纷反馈，每天对着任务板沟通，感觉协作效率提升了。

CTO听取了PMO的汇报，加之对提高研发效率的渴望，立即决定在公司范围内全面推行敏捷。于是，在试点团队还没有完全理解Scrum，并且在没有定量数据证明效果的情况下，Scrum就被仓促地大范围铺开了。一夜之间，产生了大量的Scrum Master和产品负责人。PMO则忙得不可开交，因为有太多的团队需要指导、检查和监督。

当我应邀去这家企业提供顾问服务的时候，发现该企业做了整整一年敏捷，不仅在数据上没有证明其有效地提升了研发效率，而且从团队的主观感受上也没有什么明显的效果。于是，很多部门主管开始抵制敏捷。CTO向我抱怨道：“说实话，我也开始怀疑敏捷了，这大大低于我们的预期啊！”

而当我深入团队后发现，没有一个团队对敏捷的理解是正确而又深入的，大家的敏捷实践还都只停留在简单的召开Scrum会议的层面。这家公司的问题可以归纳为如下几个方面。

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

其次是团队的角色划分问题。虽然每个团队都任命了Scrum Master和产品负责人，但是团队仍然保持着传统项目经理式的管控方式，完全没有自组织，Scrum Master也不知道自己与项目经理有什么区别。产品负责人不是来自于业务团队，而是由研发部门的业务分析员担任。产品负责人并没有与业务团队、用户密切合作，而仍旧是关起门来自己创造并分析需求。

最后是Scrum里常见的几个会议问题。在每日站会上，团队成员给Scrum Master汇报自己的工作状态，Scrum Master则负责给每个人安排任务——今天该做什么，怎么做。在迭代计划（Sprint Planning）会议上，团队将用户故事拆分为前台开发、后台开发、架构设计、代码评审等任务；在Sprint评审会议上，Scrum Master使用幻灯片来对团队的迭代工作进行总结，包括完成了哪些用户故事，解决了哪些Bug。在Sprint的回顾会议上，鲜有团队成员发言，多数情况都是在Scrum Master安排好任务后便草草结束。

除此之外，还有个别团队开展了一些零星的工程实践，例如“有空做，没空不做的”持续集成、自动化测试等。

这是一个在业界非常典型而且普遍发生的转型失败案例，我将其总结为“船货膜拜”（Cargo Cult）^[3]，即肤浅地应用实践，但没有深入理解敏捷原则和实践的意图，因而也就没有达到敏捷应有的效果。

令人惊讶的是，很多企业都在做这种船货膜拜式敏捷：

·每天召开站会，但却没有进行密切协作和自组织；

·每个迭代都有计划会议和评审会议，但在迭代结束时没有可交付的产品增量；

·每个迭代都有回顾会议，但团队的流程、效率质量、协作等却没有实质的改进；

·各种Scrum角色也都存在，但没有行使Scrum赋予他们的职能；

·开展的各种工程实践属于应付差事，没有起到实质性作用。

因此，敏捷转型不是一件说做就做、照猫画虎的事情。相反，它是一场艰巨的变革运动。

1.2.2　敏捷转型会遇到哪些困难

在《VersionOne敏捷开发状态调查报告》中，有83%的受访者表示他们曾经经历过敏捷转型的困难，只有17%的受访者表示没有遇到过障碍。如图1-2所示，在组织应用敏捷所遇到的障碍中，排在前三位的是：改变组织文化的能力；人们对组织变革的抵制；组织现有的瀑布式流程。

迈克·科恩（Mike Cohn）对企业进行敏捷转型做了这样的比喻：敏捷转型就像发射一枚火箭，让火箭飞上天的力量源自引擎，而地球的引力会把火箭往回拉。如果火箭能够飞得足够远，就可以进入轨道而脱离地球的重力作用。如果火箭飞得不够远，那么不可避免会发射失败，摔到地球上。在敏捷转型过程中，如果组织重力（包括现有的文化、制度、流程）与敏捷相左，不要说等到敏捷转型这枚火箭进入轨道，哪怕在起飞的路上都可能随时被组织重力牵引回来。

资料来源：《VersionOne敏捷开发状态调查报告》，2016年4月

由此可见，敏捷转型是个系统性的变革工程。很多人以为应用Scrum、看板一类的方法，或者自动化测试、持续集成之类的技术实践，就是敏捷转型了。其实，这只是冰山的一角，在企业里引入任何一项新事物都不是一件容易的事情，更不用说像敏捷这样对思想和行为、管理方式和理念、流程、制度以及文化都会产生重大冲击的变革了。

1.2.3　敏捷转型不是一场普通的变革

任何变革都是艰巨的。任何没有把敏捷转型当作一场变革来小心管理的企业，最终都难逃失败或停滞不前、悄无声息地结束的结局。此外，敏捷转型不是一场普通的变革，它有其特殊性，需要组织用敏捷的方式来领导敏捷转型，任何采用传统的计划驱动方式的敏捷转型，最终都不会成功，原因有以下几点。

1.敏捷是没有终点的

　很多公司的管理层都表示：“我们公司已经做敏捷好几年了，各方面做得还挺好的，敏捷的各种实践我们多少都有去做，现在没有什么可以做的了，敏捷转型对我们来说算是过去时了。”

敏捷与传统的CMMI^[4]导入和评级方法完全不同，敏捷没有统一的成熟度模型或评价体系。每个开展敏捷转型的组织永远行走在更加敏捷的道路上，如果需要存在一个终点的话，那这个终点的名字就是“持续改善”（Kaizen）^[5]。

2.敏捷属于侵入式变革

敏捷对组织里每个角色的工作方式都有很大的改变，因此属于侵入式变革。

　很多开展敏捷转型的企业让团队有了这样的认识：敏捷只是大家围着白板开会，就是比从前多开了Scrum的那几个会。

通常，组织的变化可能有很多种，有的只是改变了流程中的某个环节，例如，服务器环境的审批权限从高层管理者下放到部门主管。这样的变化只是改变了准备服务器环境的等待时间，间接减少了客户的等待时间，但这种改变还不能称之为变革。只有那些使组织的流程、制度、文化发生本质变化的改变，才能称之为变革。

从瀑布开发方式转型为敏捷开发方式，每个工程师需要学会将需求拆分成小粒度的用户故事，即从最后一次性提交代码到每天都提交代码的转变。而且每次提交都要编写自动化测试脚本，如果提交的代码没有通过测试，则需要马上修改代码。对于引入测试驱动开发（Test Driven Development，简称TDD）的团队来说，他们还需要学会测试先行，并且持续重构已有的设计和代码。这些都与他们之前的工作方式完全不同。

3.敏捷转型具有不可预测性

由于敏捷转型最终是对人以及人与人之间交互方式的改变，这决定了转型过程具有不可预测性。

　很多企业做了敏捷转型的长期路线图，规划了未来3~5年内组织的转型路线图。然后，这些企业每年都会设定转型的目标，以及每个月的执行计划，并严格按照这个目标和计划执行。

首先，从来没有一家企业完全按照当初规划的3~5年路线图实施下去。当今世界变化太快，等不到3年的时间，组织的战略方向就已经调整，组织架构也会跟着调整，比如，上次做长期路线图的决策者已经换作他人。

其次，从来没有一家企业完全按照每年设定的敏捷转型目标和计划实施下去。在转型的过程中，总是有与计划不一致的新发现，原来做的计划已不符合实际需求。

尤尔根·阿佩洛（Jurgen Appelo）在其著作《管理3.0：培养和提升敏捷领导力》（Management 3.0：Leading Agile Developers，Developing Agile Leaders）中介绍过，所有的组织实质上都是网络，这个网络由人以及人与人之间的互动与关系构成。尽管人们用组织的层级关系绘制组织结构图，但是这改变不了组织是网络这一事实。这个网络不会完全按照你的计划方式执行，因为它是一个复杂的自适应系统。在你触碰它后，它会有所反应，而通过它的反应，你才知道下一步该怎么做。这决定了敏捷转型不能用传统的计划驱动方式来控制执行。

4.敏捷没有标准的模板，也没有最佳实践。

　很多组织喜欢了解其他公司的案例或业界最佳实践，拿回来照着做。

也许你学过一些Scrum或TDD的课程，然后回到公司信心饱满地开干。但很快你就会发现，将课堂上很完美的实践拿到自己团队里应用却会碰到各种问题和困难。这是因为以你团队里现有的组织结构、流程、团队能力和实践习惯，生搬硬套一定不可行。

同行的敏捷实践只具有参考价值，不具有复制价值，因为每个公司都有其自身的特殊性。即便在同一个公司里，不同的部门和不同的团队，它们的情况也会有所不同。团队需要探索适合自己的敏捷，其他团队的敏捷虽具备学习和参考价值，但是不能直接复用。