在这个瞬息万变的环境中，企业的生存和发展取决于快速应对变化的能力，而敏捷运营正是构建这种能力的核心。敏捷与其他创新思想一样，需要时间来传播。全球有不少企业已经走向敏捷运作模式，也有不少传统企业还没有尝试敏捷，处于观望评估阶段。自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%的受访者将“客户满意度”作为重要的改进目标。实施Agile的其他目的如下：缩短开发周期(69%)提高质量(60%)提高用户满意度(49%)提高人的能力(30%)加强协作(43%)减少工作量并提高生产率(32%))%)产品创新（17%）改变管理方式，让会员更有参与感（34%）其他（4%）敏捷实施周期及效果：坚持6个月，就会有结果大多数（56%）受访者回复他们说企业实施敏捷还不到一年。这可能是受访者范围的局限——敏捷在中国已经推广了10年，前几年实施敏捷的公司应该是早期的领导者，敏捷逐渐被认可，这是一波再次掀起新浪潮。在实施敏捷的组织中，无论是刚刚起步还是已经实施多年，43%的组织有所改善，18%的组织取得了显着改善。敏捷实施是持续改进和系统性的问题解决。如果能坚持半年以上，效果肯定会大增。敏捷实施要解决的问题实施敏捷是一项具有挑战性的变革。敏捷本身也是一个需要解决的复杂问题。我们询问了受访者这些挑战的影响程度：没有涉及没遇到过这个问题偶尔遇到过这个问题，没有影响偶尔遇到过这个问题，影响不大遇到过这个问题，影响我们经常，影响大的是它让我们很累。我们根据挑战的影响分为三组。每个企业的成长历程不同，面临的挑战也不同。但是，这其中有规律可循，它们所面临的挑战的影响大致可以概括为三组：“需求与架构、流程治理、企业文化”。***群体挑战：需求和架构不佳***群体挑战影响企业***。这些基本上都是需求和产品相关的问题，还有架构和团队能力的问题。具体包括：需求变更、工作量超负荷、需求工作分工不够细化需求不合理、定位不稳定、结构不佳、团队能力不足敏捷系统中的很多实践都是为了解决这些问题而设计的。设计思维、产品画布、用户故事等需求流程的前端实践，都是为了让开发团队更专注于有价值的需求，以最少的投入快速产生价值。但是，敏捷虽然可以提供一种快速验证产品的机制，却不能指明产品的方向。这还是要靠有智慧和远见的产品负责人。一个得力的产品经理，加上行之有效的敏捷运营机制，是一个完美的组合。关于架构问题，组织需要战略性地优化或改造遗留系统并清除过去的技术债务。这不是一蹴而就的事情，更不是喊着敏捷的口号就能解决的。该解决方案需要规划和投资。领域设计、持续重构、结对编程和自动化测试等敏捷设计方法可防止后续损坏。不管是需求还是架构，这些都是软件工程师本身应该具备的专业能力。系统的快速增量演化暴露了这些能力的不足。企业必须有系统的能力培养和人才引进。第二组挑战：笨拙的流程治理第二组挑战对企业有几个影响。这些主要是流程治理问题。具体包括：治理不敏捷、团队间协作、流程繁琐、涉众分歧、绩效考核不敏捷、第三方合作等问题，这些问题都不是纯粹的软件工程问题。任何行业的企业在敏捷实施过程中都可能遇到。敏捷公司应该投入时间分析现有流程并简化它们。精益思想在这方面非常重要。通过分析精益价值流，重新梳理团队职责、他们的贡献价值和绩效导向之间的关系，可以快速找出问题的根源。但是，要想彻底解决问题，还是需要上下通力合作，制定新的流程。第3组挑战：组织文化第3组挑战的影响程度并不集中在公司之间，因为我们的问题是按印象程度而不是它们所属的领域分组的。但是，我们发现其中大部分是与人有关的问题。敏捷实施的可持续性最终必须考虑人性。团队不愿意学习新事物，公司文化不敏捷，开发测试和开发运维协同不好，需求复杂，团队分散。就像第二组问题一样，大部分问题都与软件工程无关，而是文化和协作。有效协作的动力来自两个方面：第一，成员自身的态度。部分成员热爱学习，愿意为企业的长远利益着想。一些成员更多考虑的是个人利益，难以走出自己的舒适区。改变企业文化并不容易。因此，在实施敏捷时，首先要从一群意志坚强的成员开始，同时还要考虑当前的绩效管理体系是否会促进或阻碍协作。领导者积极参与，以身作则也很重要。前面说过，敏捷实施是一个长期的变化，需要坚持。敏捷实践的实施节奏：当团队、端到端和企业想要实施敏捷时，他们需要考虑实施的范围和要引入的敏捷实践。以及如何有效地实施和生根这些变化。在我们的经验中，企业通常是从一个小区域开始，在取得一些成果后，逐渐扩展到整个交付过程，从需求到交付，再到上线，再考虑如何将敏捷精神传播到整个组织。本次调查的结果证实了我们的观点。我们向受访者询问了他们实施敏捷实践的情况：决定不尝试我不知道是什么我还没有尝试我刚开始尝试（3个月内）我已经实施了一段时间，有challengesbutIwillstilltoit成功实施，已经习惯的做法我们将他们愿意尝试的做法进行了分类，并将他们分为三组。所谓“愿意”，包括他们认为还没有开始尝试、刚开始尝试、已经实施了一段时间、实施成功的做法。我们发现这些实践组合与我们之前建议的开发测试敏捷、端到端需求交付敏捷和企业敏捷组合相吻合。***实践组合：DevTestAgile***实践组合包含最常见的基础敏捷实践，包括Scrum和看板，以及一系列自动化实践，例如自动化测试、持续集成、持续发布和敏捷管理工具（例如JIRA）。如果一个团队不实施这些实践，就不能说他们是敏捷的。如果一个团队说他们是敏捷的，但是没有站会，没有工作跟踪，没有自动化测试，没有持续集成，你觉得他们能变得敏捷吗？这些都是必要的因素。然而，即使这些做法也可能仅仅是形式。更重要的是，团队拥有敏捷的学习心态。第二组实践组合：端到端敏捷第二组实践组合包括开发团队外部和围绕开发团队的协作，包括开发与维护、业务人员、团队角色之间的协作。它们存在于需求从构思到完成交付的各个方面，包括：设计思维、前期需求管理、微服务、特性团队、测试驱动开发、验收测试驱动开发、DevOps。有效协作的前提是开发和测试的实践得到了有效的落实。如果代码一碰就崩溃，开发和测试无法迭代交付，那么就没有端到端的敏捷性。第二组实践组合本身并不是特别困难，但一旦涉及到不同的功能，难免会产生利益冲突。教练可以用逻辑将每个功能的成员一一说服。做到这一点的一个好方法是在各个负责的成员之间分享产品愿景和目标。一旦产品能有明确的发展方向，并能有效地传达给每个成员，每个成员都明白自己对产品成功的贡献，那么每个职能成员的参与度就更有可能增加。敏捷是一个很好的工具，但它的有效实施仍然需要指导。第三组实践组合：企业敏捷第三组实践组合包括：项目组合管理、预算和绩效管理、其他职能敏捷、规模敏捷、精益创业。大多数这些实践都在软件交付之外，并且是一组非常不同的职业。有财务人员、人力资源、企业战略、业务负责人。要有效地敏捷协作，首先必须了解他们的观点以及他们面临的挑战和矛盾。他们中的大多数人不是IT背景的，也不懂IT术语。传统的敏捷实践和术语无法解决他们的问题。公司治理需要一套全新的实践。其中，超出预算是一个开始引起人们关注的制度。它为财务办公室、人力资源办公室和战略办公室提供了一套协作概念和机制。很多企业已经开始在这方面进行尝试。公司治理的敏捷性非常重要。领导力，以及这个职能的敏捷性，完全决定了整个企业的敏捷性。企业级敏捷实践仍在不断发展。我们期待这方面的进展。不要忘记代码质量我们还发现，接受调查的公司很少关注代码设计，包括域设计、UML和结对编程。最具争议的做法之一是测试驱动开发(TDD)和结对编程。许多企业决定不尝试这些做法，怀疑它们的有效性。这可能是由于受访者对这些做法缺乏了解，或者他们难以实施。我们认为这些做法非常重要。代码质量决定了系统的质量。即使实施起来有难度，企业也应该更加重视这方面。敏捷实施措施：流程、自动化、领导力、组织文化企业中的敏捷实施基本上是一种组织变革，因此必须将其视为变革项目。必须全面考虑变革项目。如果不是全面的话，实施也会受到一定程度的阻碍。我们按照必要性和成本对敏捷实施措施进行排名。第一套措施：流程变革、自动化投资，这些措施都是企业觉得有必要并进行了适当的投资，也是大家默认的最基本的事实策略。首先，要成立敏捷实施工作组，调整运作流程。另外，自动化需要额外的人力投入，否则会影响研发团队的交付速度。调整运营流程，敏捷实施工作组建立内部自动化测试、持续集成、持续交付能力第二套措施：领导参与，建立改进目标敏捷变革基本上是一种组织开发工作。必须有领导以及外部顾问的积极参与。顾问带来他们的经验，并防止团队走错路。此外，组织必须定期跟进和分享，以确保实施敏捷的团队得到关注。敏捷实施也必须是敏捷的。领导者积极参与，聘请外部教练，将敏捷改进作为团队目标，定期召开敏捷实施会议，组织敏捷相关分享投资不够。要想实现有效的、可持续的敏捷实施，不仅要考虑团队的辅导，还要考虑其他方面。这可能涉及到系统架构和组织架构的演进。一般来说，遗留系统是阻碍业务敏捷性的因素。此外，还需要建立内部辅导机制和实践社区，让员工不断学习。最重要的，还要考虑企业的绩效管理。现有的绩效考核是否在阻碍敏捷文化的推广，或者能否促进敏捷文化的建立。系统架构改造实践社区、内部教练绩效管理系统改造敏捷实施有套路敏捷已有近20年的历史。对于这样一个快速发展的软件开发领域，这是敏捷取得长足进步的很长一段时间。事实上，企业可能面临的任何问题似乎都是敏捷的。问题不在于解决方案不存在，而是企业在采用此类解决方案时过于谨慎和保守。企业担心实施敏捷带来的变化会对组织产生太大影响。企业需要系统地将敏捷集成到他们的工作方式中，并转变为敏捷思维。在这个敏捷实施之旅中，企业并不孤单。有很多企业的经验可以借鉴，我们这次的调研系统地收集了很多企业的经验，总结了一些可以借鉴的通用实施措施。首先，企业必须克服以下方面的挑战：需求和架构、繁琐的流程和企业文化。我们发现，企业采用敏捷的步伐通常是在团队层面实施敏捷，然后端到端交付敏捷，最后在企业层面实现敏捷。最后，敏捷企业应考虑以下措施：简化流程投资自动化确保领导参与建立改进目标使组织文化和绩效管理更符合敏捷理念企业选择。实施敏捷不是关于时尚，而是关于跟上“最好和最伟大”的趋势。“企业不实施敏捷就是等死，实施敏捷不对就是找死。“实施敏捷是生存的根本行动，没有敏捷，就很难实施任何其他战略举措，比如数字化转型。希望我们的总结和反思能为正在实施或将要实施敏捷的企业提供有价值的参考和指导，让大家少走一些弯路，早日实现企业级敏捷。也期待在评论中分享大家的观察和思考。【本文为专栏作者《ThoughtWorks》原稿，微信♂：Thinkworker，转载请联系原作者】点此阅读作者更多好文
