引子
迈克.科恩（Mike Cohn，《用户故事与敏捷方法》的作者）对企业的敏捷转型做了这样的比喻：敏捷转型就像发射一枚火箭，让火箭飞上天的力量源自引擎，而地球的引力会把火箭往回拉。如果火箭能够飞得足够远，就可以进入轨道而脱离地球的重力作用。如果火箭飞得不够远，那么不可避免会发射失败，摔倒地球上。在敏捷转型过程中，如果组织重力（包括现有的文化、制度、流程）与敏捷相左，不要说等到敏捷转型这枚火箭进入轨道，哪怕在起飞的路上都可能随时被组织重力牵引回来。
敏捷转型的三个阶段
实践敏捷（Doing Agile）
敏捷管理实践——目前，被业界广泛应用的管理实践是Scrum框架和精益看板方法。对于大型组织来说，有SAFe（Scaled Agile Framework，）这样的规模化敏捷框架。
SAFe是目前国际上最流行的规模化敏捷方法，将敏捷实践从团队级（Team Level）有效扩展到项目群级（Program Level）乃至企业级（Portfolio Level）；SAFe也是一套开放的精益-敏捷知识体系，基于客户的实践与反馈来快速迭代完善并吸收新的最佳实践。
敏捷工程实践——在工程领域相关的实践有很多，例如测试驱动开发（TDD）、结对编程、行为驱动开发（BDD)、持续集成（CI)，持续交付（CD）、敏捷测试等。
敏捷产品实践——在产品管理领域，常见的敏捷实践包括：精益创业（Lean Startup)、原型（Prototype）和用户画像（Persona）等工具，以及设计思维（Design Thinking）和用户故事地图（User Story Mapping）等系统化的方法论。
敏捷实践通常是上手容易，精通困难。对于各种敏捷实践的引入和应用，很多企业只是引入了敏捷的实践。然而，实践敏捷和敏捷转型是完全不同的两个层次：实践敏捷只是在行为上采纳了敏捷的相关实践，但是人们的思维模式和组织的文化可能还保持原样，
随着敏捷转型的深入，必然会伴随着传统的思维模式、组织固有文化与敏捷之间的碰撞。如果思维模式不调整、组织文化不改变，敏捷转型的每一步都会异常艰难。
思想敏捷（Thinking Agile)
敏捷宣言是大家共同认同的软件开发方法的价值观：
以“人”为中心——敏捷尊重团队每一个个体的作用，这与传统软件开发模式不同。但是，这不代表敏捷要抛弃流程，摒弃工具。由于软件开发是典型的创新型工作，所以只有发动每一个个体的主观能动性，才能创造最大的价值。
以“价值”为驱动——敏捷与IPD、CMMI等崇尚过程和文档的管理模型是不同的理念。但是，这并不代表敏捷不需要文档，而是更强调敏捷为客户解决了什么问题，给他们提供了什么价值。
敏捷鼓励与客户密切合作——只有和客户保持持续的沟通和协作，我们才能有效地了解客户的真实想法和意图。
敏捷积极地拥抱变化——在互联网时代，我们所处的世界越来越不可预测。从前，业务和市场的变化以年为单位，而现在以周、天甚至小时为单位。我们曾经完美地执行了计划，但是那个计划已经过时了，市场已经不再需要过去计划中的产品。
敏捷思想不是参加几个敏捷培训就可以掌握的、也不是在墙上打着标语就能进入大家的脑袋里的，而是在实践的过程中被逐步理解、接受，置换固有的传统思维模式，并不断加强的。
文化敏捷（Being Agile)
敏捷有很强的文化特征。在协作型、培养型文化为主导的组织里，敏捷开展会容易得多，这是因为这样的组织天生就有敏捷的基因。反之，在控制型为主导的组织里，敏捷文化和企业自身文化的摩擦就会比较多。
如果一种文化极强，强大到每日的工作中你感觉不到其他文化的存在，这时需要引入其他的文化元素来补充。比如，在控制型组织的转型过程中，敏捷的文化与现有的控制型文化会不断地产生摩擦和冲突。这不是一件坏事，在摩擦过程中，组织自然地引入协作并培养出新鲜的文化元素，从而让组织的文化保持一定的活力和平衡。
如果团队不只是实践敏捷，而且掌握了敏捷思想，学会了用敏捷的价值观和原则思考，逐步达到知行合一，养成了敏捷的思维和行为习惯，我们称之为文化敏捷。达到文化敏捷的团队会得到很大的收益，比如客户满意、工作开心、团队凝聚力增强、创新和创造力提高、拥有持续学习的机会。
敏捷团队的发展阶段
我们可以从练功中总结出一套可以掌握所有事情的规范模式。练功的学徒需要经历三个阶段：守、破、离（守即服从规则，破即打破规则，离即创造规则）。
敏捷开发处处都能看到规则的踪影。比如15分钟左右的站会，不管发生了什么，都按照预定时间开始和结束，而且每个成员只回答三个问题。这样将规则安插到团队工作的每个环节的过程为“守”。
当团队开始学会隐藏在这些实践背后的原则，理解更深层面的意义的时候，他们开始打破规则，然后用敏捷开发的“检查并调整”机制来告诉他们这些规则是否是正面和有用的。这个过程为“破”。
对于“离”阶段的敏捷团队，他们也许会决定用其他形式彻彻底底地替换掉站会，这种新形式势必要符合站会的原则，甚至有更深层的意义和作用。
后记
企业所经历的敏捷大致遵循这样的路线：
团队级敏捷——以小团队为单位开展敏捷转型，当试点结束后，组织往往会继续拓展敏捷转型的范围，鼓励更多的团队加入敏捷的阵营。
团队敏捷实践一般包括：Scrum或看板方法，持续集成，涌现式架构设计，领域驱动开发，行为驱动开发，自动化测试，结对编程，测试驱动开发等。
如果单个团队可以独立发布产品，他们可能会进一步尝试一些工程技术实践，比如微服务、持续交付流水线和自动化运维。
对于那些由多个团队协作交付的大型项目来说，即使每个团队都在开展敏捷实践，也未必能够看到整个项目明显的收益和效果。因为大型项目关乎是整个版本、产品的交付效率和质量，团队与团队之间需要互相配合才能交付整个产品。
产品级敏捷——以整个产品的价值流为单位开展敏捷转型。产品级敏捷旨在拉通产品价值流的上下游，将相互依赖的团队纳入同一个敏捷框架里。
产品级敏捷和团队级敏捷关注的视角有很大不同。团队级敏捷关注单个团队的效率、质量和士气等。而产品级敏捷旨在拉通产品价值流的上下游，将相互依赖的团队纳入同一个敏捷框架里，在需要的情况下调整结构，让价值流上的每个团队协同交付，最大限度地减少交接、等待，去除价值流动中的浪费，通过缩短产品的质量反馈时间来快速提高产品质量，最终提升客户满意度。
规模化敏捷和精益实践包括：价值流映射，精益看板方法，投资组合管理，敏捷发布火车的组织架构和流程，Scrum of Scrums。工程实践包括：主干开发，微服务，持续交付流水线，DevOps。
企业级敏捷——经历了团队级敏捷到产品级敏捷，产品从无到有，直到产品发布的整个过程都已纳入了敏捷范围，但是这还不够。那些支持部门，比如人力资源、行政、财务、市场和销售等部门也应该被纳入敏捷转型的范畴。
本文作者万学凡，ThoughtWorks首席咨询师，武汉。作者保留本文一切权利，未经许可请勿转载。
