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

第一章  敏捷转型不易，但它是必走之路

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

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

    即肤浅地应用实践，但没有深入理解敏捷原则和实践的意图，因而也就没有达到敏捷应有的效果。

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

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

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

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

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

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

2、敏捷转型会遇到哪些困难

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

    由此可见，敏捷转型是个系统性的变革工程。

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

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

1）敏捷是没有终点的

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

2）敏捷属于侵入式变革

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

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

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

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

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

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

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

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

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

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