在这瞬息万变的环境里，企业的生存与发展状况取决于其快速响应变化的能力，而敏捷运作是构建该能力的核心。
敏捷和其他创新思想一样，需要时间传播。全世界不少企业都已迈向敏捷的运作模式，也有很多传统企业，还没有尝试敏捷，处于观望评估的阶段。从2001年公布敏捷宣言至今，经过十来年的时间，敏捷在中国可以算是已经跨越了鸿沟，逐渐成为主流。这些企业在实施敏捷的过程中获得了明显的改进，也遇到不少困难。
与其独自探索，不如向行业的先行者学习。在敏捷逐渐成为主流的这十几年间，行业也一定为后来者积累了可参考的经验，这对于还在观望评估的企业来说，无疑会是宝贵的财富。ThoughtWorks在2017年6月至7月期间进行了一项针对中国企业的敏捷实施调查，了解这些早期采纳敏捷的企业：
- 为什么要实施敏捷?
- 面临哪些挑战，经历了哪些困难?
- 采用了哪些敏捷实践?
- 采取了哪些实施措施应对那些挑战和困难?
希望通过这个调查的结果，能为后来者提供有价值的参考。
当前实施敏捷企业的特征
本次调查的范围主要是敏捷在中国的早期实施者。调查参与者总共229名。调查参与者来自全国各地，40%北京、9%上海、17%深圳广州、19%成都杭州武汉西安。调查不可避免有局限性，但我们仍相信结果具有一定代表性。
受访者来自不同行业，其中来自互联网企业的26%、信息科技21%、通信16%、金融17%。这些行业面临激烈的市场竞争和技术变革，必须走向更敏捷的运作方式，很自然地就会实施敏捷。
调查的参与者主要是敏捷教练(25%)和项目经理(17.6%)。这些角色都有提升开发团队交付能力的职责。调查参与者也包括开发(15%)、测试(14%)、产品经理(7%)、需求分析师(4%)。也有不少中层与高管参与调查，其中部门经理占10%，高管占4%。非研发人士也逐渐认识到敏捷的意义，参与了我们的调查。
敏捷实施规模大部分在100人以内
企业敏捷实施的团队规模大部分(79%)在100人以内。其实，这是一个趋势，随着技术和工具的发达，一个人能做的事越来越多，所以团队规模也自然变小。更重要的是，自主小团队和网络式组织结构，更灵活、更能够产出成绩。这也符合敏捷理念。只有特别复杂的系统，才需要大规模100人以上的团队。我们仔细分析了500人以上的敏捷实施团队，他们大部分实际上是多个独立产品线并行交付。单产品的交付，大部分还是100人以内。
敏捷实施的主要目的： 缩短周期、提高质量和满意度
企业实施敏捷不是为了敏捷，而是要达到效果。
有69%的受访者表示他们企业实施敏捷最主要的目的是缩短开发周期。这是通过更快的迭代节奏来达成的。贯彻和运作精益思想、减少浪费、解除瓶颈也是重要手段。所以，很多企业会同时实施敏捷和精益。有些人误以为敏捷会导致质量下降。其实，敏捷是有保障质量的理念和实践，有60%的受访者认为“提升质量”也是实施敏捷的目的，49%的受访者把“客户满意度”也设为重要改进目标。
其他实施敏捷的目的如下：
- 缩短开发周期(69%)
- 提高质量(60%)
- 提升用户满意度(49%)
- 提高人员的能力(30%)
- 增强协作(43%)
- 减少工作量，提高产能(32%)
- 产品创新(17%)
- 改变管理方式，让成员更有参与感(34%)
- 其他(4%)
敏捷实施周期与效果：坚持6个月，必有效果
大部分(56%)受访者回复他们企业实施敏捷不到一年。这可能是受访者范围的局限性——敏捷在中国的推广已经有10年了，那些前几年实施敏捷的企业应该是早期领先者，敏捷已经逐渐受到认可，这是再次崛起的一波新浪潮。实施敏捷的企业，不管是刚起步还是实施多年，43%表示有所改进，18%表示获得了显著的改进。敏捷实施就是持续改进、系统性地解决问题，如果能够坚持半年以上，效果必然大增。
敏捷实施要解决的问题
实施敏捷是一个富有挑战的变革。敏捷本身要解决的也是个复杂问题。我们向受访者询问了这些挑战的影响程度：
- 不涉及
- 没有遇到这个问题
- 偶尔遇到这个问题，没有影响
- 偶尔遇到这个问题，影响不大
- 遇到这个问题，对我们有影响
- 经常遇到，影响很大
- 就是它搞得我们特别累
我们按照挑战的影响程度分为三大组。每个企业的成长旅途都不同，所以它们面临的挑战也不同。然而这其中存在着规律，它们所面临的挑战的影响程度或许能够被粗略的归纳为“需求与架构、流程治理、以及企业文化”三大组。
***组挑战：需求与架构不良
***组挑战对企业影响***。这些基本都是和需求、产品相关的问题，也包括架构和团队能力的问题。具体包括：
- 需求变化多、工作量过载、需求工作拆分不够细
- 需求不合理、定位不稳定、架构不良、团队能力不足
敏捷体系当中有不少实践都是为了解决这些问题。需求流程前端的实践，如设计思维、产品画布、用户故事等都是为了让开发团队更聚焦在有价值的需求上，以最少的投入快速产生价值。然而，敏捷虽然可以提供快速验证产品的机制，但是并不能指定产品方向。这还是依赖于有智慧、有眼光的产品负责人。有能力的产品经理，加上一个有效的敏捷运作机制是一个***的组合。
关于架构问题，组织需要有策略地进行优化或改造遗留系统，清除过去的技术债务。这不是一夜之间能够解决的事，不是喊着敏捷的口号就能解决的，解决是需要规划和投入的。敏捷设计方法，例如领域设计、持续重构、结对编程、自动化测试，能够防止后续的腐化。不管是需求还是架构，这都是软件工程师本身该有的专业能力。系统快速增量的演进，暴露了这些能力的缺失。企业必须有系统性的能力培养和人才的引入。
第二组挑战：笨重的流程治理
第二组挑战对企业有不少影响。这些大部分是流程治理的问题。具体包括：
- 治理不敏捷、团队之间协作、流程笨重
- 涉众意见不合、绩效考核不敏捷、第三方合作
这些问题不是纯软件工程的问题。任何行业的企业在敏捷实施的过程中都可能遇到。实施敏捷的企业应该投入时间来分析已有的流程并进行简化。在这方面，精益思想非常重要。通过对精益价值流的分析，重新梳理团队职责、其贡献的价值和绩效导向的关系，就能够很快识别问题的根因。但是如果要彻底解决问题，还是需要上下的合作，制定新的流程。
第三组挑战：企业文化
第三组挑战的影响程度在不同企业中的表现并不集中，因为我们的问题是通过印象程度组合的，而不是它们所属的领域。然而，我们发现这大部分都是与人相关的问题。敏捷实施的持续性，最终必须要考虑人性。
- 团队不愿意学习新东西、公司文化不敏捷
- 开发测试和开发运维协作不好、需求实现复杂、团队分散
就像第二组问题一样，大部分问题不是跟软件工程有关，而在于文化和协作。有效协作的动力来自两方面：首先是成员本身的态度，有些成员本来就热爱学习，愿意为企业的长期利益着想。有些成员更多的考虑个体的利益，很难跳出舒适区。要改变企业文化是不简单的。所以，实施敏捷的时候，首先要先从一批意愿比较强的成员入手，同时也要考虑当前的绩效管理体系是否会促进或阻碍协作。领导的积极参与、以身作则，也是非常重要的。如前所述，敏捷实施是一项长期的变革，是需要坚持的。
敏捷实践落地步伐：团队、端到端、企业
企业要实施敏捷时，需要考虑实施的范围和要引入的敏捷实践。以及如何把这些改变有效的落地和生根。在我们的经验中，企业通常会先从小范围做起，有了一些成果之后再逐渐铺开到整个交付流程，从需求到交付上线，然后再考虑如何将敏捷精神扩散到整个组织。此次调查结果确认了我们的观点。我们向受调查者询问他们敏捷实践的落地情况：
- 已决定不会尝试
- 不知道这是什么
- 还没开始尝试
- 刚开始尝试(3个月以内)
- 已实施一段时间，有挑战但是会坚持
- 实施成功了，已经是习惯性的做法
我们按照他们有意愿尝试的实践进行了排序，并将其划分为三个组合。所谓“有意愿”就是包括他们认为自己还没开始尝试、刚开始尝试、已实施一段时间、以及实施成功的实践。
我们发现，这些实践组合正好和我们之前建议的开发测试敏捷、端到端需求交付敏捷、以及企业级敏捷，这三个实践组合一致。
***组实践组合：开发测试敏捷
***组实践组合包含最普遍的基础敏捷实践，包括Scrum和看板，也包含一系列的自动化实践，如自动化测试、持续集成、持续发布、以及敏捷管理工具(例如JIRA)。 团队如果不实施这些实践，就不能说他们是敏捷的。如果一个团队说他们很敏捷，但是没有站会，没有工作跟踪，没有自动化测试，更没有持续集成，你觉得他们能够敏捷起来吗?这些都是必备因素。然而，即使有了这些实践也可能只是流于形式。更重要的是团队有敏捷的学习心态。
第二组实践组合：端到端敏捷
第二组实践组合包含的都是开发团队以外和周边的协作，包括开发运维、业务人员、团队各角色的协作。它们存在于需求从概念形成到完成交付的各个环节，包括：设计思维、前期需求管理、微服务、特性团队、测试驱动开发、验收测试驱动开发、DevOps。有效协作的前提是开发测试的实践已经有效落地。如果稍微一动代码就崩溃，开发测试不能够迭代交付，那么就谈不上什么端到端的敏捷。
第二组实践组合本身不是特别难，但是一旦牵扯到不同职能，就难免有利益冲突。教练可以采用逻辑一个个地说服各职能的成员。一个行之有效的办法就是在各职责成员中共享产品愿景和目标。产品一旦能够有明确的发展发向，并且能有效的传达到每个成员，每个成员理解他对产品成功的贡献，那么各职能成员的参与度就更有可能提高。敏捷是一个很好的工具，但它的有效落地还是需要方向的。
第三组实践组合：企业敏捷
第三组实践组合包括：项目组合管理、预算与绩效管理、其他职能的敏捷、大规模敏捷、精益创业。
这些实践大部份都是软件交付以外的实践，是一系列很不同的专业。这里有财务人员、有人力资源、有企业战略、有业务负责人等。要有效的开展敏捷协作，首先必须理解他们的观点以及他们面临的挑战和矛盾。他们大部分都不是IT出身，不理解IT的术语。传统敏捷实践和术语不能够解决他们的问题。
企业治理需要另一套崭新的实践。其中，超越预算是一个开始受人关注的体系。它提供了一套财务办公室、人力资源办公室、以及战略办公室的协作理念和机制。有不少企业开始在这方面进行尝试。企业治理的敏捷事关重大。领导层，以及这层职能的敏捷，完全决定了企业上下的敏捷。企业级的敏捷实践还是在演化中。我们期待这方面的发展。
不要忘记代码质量
我们也发现，受调查的企业对代码设计方面的关注比较缺失，这包括领域设计、UML、结对编程。其中最有争议的实践就是测试驱动开发(TDD)以及结对编程。有不少企业决定不尝试这些实践，对它们的效果有所怀疑。这或许是由于受访者对这些实践的理解不足，或者是他们的落地比较困难。我们的观点是这些实践都是非常重要的。代码质量决定系统的质量。即使实施有所困难，企业应该在这方面更加专注。
敏捷实施措施：流程、自动化、领导力、组织文化
企业敏捷实施基本上是一个组织的变革，所以必须按照变革项目来对待。变革项目必须要有全面的考虑。如果不够全面的话，实施会受到一些阻碍。我们将敏捷实施措施按照它们的必要性和投入排序。
***组措施：流程变更，自动化投入
这些措施都是企业觉得有必要并进行了合适的投入、是大家默认最基本的事实策略。首先，必须要建立一个敏捷实施工作组、调整运作流程。另外，自动化这方面是需要有额外的人力投入的，否则会对研发团队的交付速度有所冲击。
- 调整运作流程、敏捷实施工作组
- 建立内部自动化测试、持续集成、持续交付能力
第二组措施：领导参与，建立改进目标
敏捷变革基本上是一个组织发展工作。必须有领导以及外部顾问的积极参与。顾问会带来他们的经验，避免团队走冤枉路。另外，企业必须例行跟进和分享，确保实施敏捷的团队受到关注。敏捷的实施也必须敏捷。
- 领导积极参与、雇佣外部教练
- 把敏捷改进作为团队目标
- 例行敏捷实施会议、组织敏捷相关的分享
第三组措施：组织文化、绩效管理
这些措施是受访者觉得必要、但是没足够投入的。如果要有效可持续的敏捷落地，不仅仅要考虑团队的辅导，也要考虑其他方面。这或许会涉及到系统架构、组织结构的演进。一般来说，遗留系统是妨碍企业敏捷的原因。除此之外，也要建立内部教练机制、实践社区，要让员工持续的学习。最重要的，也要考虑企业的绩效管理。已有的绩效考核是否正在阻碍敏捷文化的推进，还是能够促进敏捷文化的建立。
- 系统架构改造
- 实践社区、内部教练
- 改造绩效管理制度
敏捷实施有套路
敏捷已经拥有将近20年的历史。对于软件开发这样一个迅速发展的领域来说，这是一个很长的时期，在这个时期中，敏捷有了很大的进步。事实上，企业可能面临的任何问题似乎都与敏捷相关。问题不在于解决方案不存在，而在于企业采用这样的解决方案的态度过于谨慎和保守。企业害怕实施敏捷时所带来的变化对组织的冲击太大。企业需要系统地将敏捷整合到他们的工作方式中，并转向敏捷的思维方式。
企业在这敏捷实施旅程中并不孤单。有很多企业的经验可以参考，而我们这次的调查就系统地收集了许多企业的经验，总结了一些通用可借鉴的实施措施。首先，企业必须克服以下几个方面的挑战：需求和架构、笨重的流程、以及企业文化。我们发现企业采用的步伐通常都是先实施团队级的敏捷，然后端到端交付敏捷，最终实现企业级敏捷 。
***，敏捷企业应考虑采取以下措施：
- 简化流程
- 投入自动化
- 确保领导参与
- 建立改进目标
- 让组织文化和绩效管理更符合敏捷理念
在当今的商业环境中，不敏捷的工作方式已经不再是企业的选择。实施敏捷不是为了时尚，不是为了跟上“***和最伟大”的潮流。“企业不实施敏捷是等死，错误实施敏捷是找死。” 实施敏捷是一个生存的根本动作。没有敏捷，就难以执行任何其他战略举措，例如数字化转型。
希望我们的这些总结和反思，能给正在实施敏捷或将要实施敏捷的企业，提供有价值的参考和指导，让大家少走一些弯路，早日实现企业级敏捷。也期待大家留言分享各自的观察和思考。
【本文是51CTO专栏作者“ThoughtWorks”的原创稿件，微信公众号：思特沃克，转载请联系原作者】
