就算企业领导人提倡企业组织需要更敏捷更灵活，他们也无法强行要求敏捷性。你的CIO和IT领导人可以对他们称为敏捷方法标准的一套实践、指标和职责实行标准化，但是无法强行要求每个人都采用敏捷文化和理念。

你可以选择敏捷工具，利用开发运营(DevOps)实践加大自动化力度，并支持平民数据科学计划，但是你无法强行采用并强要员工开心。IT运营部门可能在运行混合多云架构，但这并不一定意味着成本得到了优化，或者基础架构就可以神奇地自动扩大或缩减规模。

因此，如果你希望敏捷流程迅速实行标准化，通过改用敏捷架构神奇地解决技术债务，或者立即转变成敏捷工作方式，那么你会大失所望。敏捷性不是免费、廉价或轻松就能得到的。你无法在时间表固定的甘特图上管理敏捷性。

虽然我认为敏捷性主要是一种自下而上的转变，但这并不意味着开发人员、工程师、测试人员、敏捷专家及IT团队的其他成员可以独立地提升敏捷性。整个团队必须协同工作，承认要兼顾的取舍，并在效益方面达成共识的情况下制定敏捷运营原则。

因此，如果敏捷性不能强行要求，又需要所有人付出努力，那么组织如何变得更敏捷?以下是IT部门的所有人可以协同提升敏捷性的几个方法。

为敏捷方法正名

本人所著《驾驭数字化》的第2章主要阐述了基础的敏捷实践以及更全面的敏捷规划流程，这种流程包括分配角色和职责，规划多迭代开发周期(sprint)待办事项，以及预估方法实行标准化。我与试图采用敏捷理念和文化的团队合作时，我们会确立版本发布管理准则、架构标准、敏捷原则以及提升敏捷性的其他准则。

但这无法刻板僵硬地部署推行。不同的组织自有不同的业务战略、组织结构、组织文化、人才、合规要求以及新旧架构的组合。考虑何时何地运用不同的敏捷实践时，这些因素异常重要。

比如说，一家大型组织可能有团队为领导人希望快速开发并发布给员工的移动应用程序开发API。第二个团队可能在竭力改造一套复杂的遗留系统，该系统关系到一家受严格监管和审查的跨国公司能否正常运营。

这两个团队是否应该遵循相同、规范且严格控制的敏捷实践?这肯定会制约API团队;如果采用的敏捷方式更民主、自我组织，许多决定交由API团队处理，那么毫无疑问API团队会更愿意(而且可能表现出色)。另一方面，若为处理复杂的关键业务遗留系统的团队赋予太大的自由度，那会带来更大的风险。

目标和约束方面的差异是力求敏捷性的组织必须培养这种文化的原因之一：定义敏捷性原则时，要提出“为什么”并给出答案。如果领导人只规定方式，却不解释原因，员工就不太可能采用基本实践。解释敏捷原则(尤其是解释原因)可以帮助团队在何时、何地以及如何运用敏捷实践方面做出更合理的决定。

通过数据运营和数据治理加快机器学习

我喜欢蜘蛛侠的这句名言：“能力越大，责任越大。”每家组织都希望自己的数据科学家、数据可视化专家和平民数据分析员能不断获取洞察力，进而帮助决策。但是这种能力还要求数据团队、分析团队和机器学习团队采用积极主动的数据治理和数据运营(DataOps)实践，以满足组织在数据质量、安全、隐私、主数据管理和数据集成等方面的要求。

因此，分析团队竭力变得更加敏捷，经常拿出成果，并增加分析中使用的数据集的数量，同时数据团队必须基于合规要求和不断变化的业务预期目标，夯实底层的数据处理基础。

这种敏捷性不是免费或通过强行规定就能获得的。只有跨部门团队认识到敏捷性的重要性，并协同工作以改善分析交付和数据处理基础，数据和分析流程才会日趋完善。这里有几个例子：

平民数据科学计划要求各参与部门在发布新的数据可视化之前，定义并维护数据目录和定义。

数据科学团队记载机器学习模型、定义漂移参数，并基于定义的生命周期维护生产级模型。

数据集成团队和数据质量团队将分析团队视为客户或利益相关者。他们定期审查分析团队执行的数据管理工作，评估和调整数据模型和集成机制，以减少下游数据处理。

所有获准处理数据的团队定期审查数据安全、合规和隐私要求方面的变化。他们列出安全、数据或技术债务等方面的不足，为补救工作确定轻重缓急。

数据运营团队和云运营团队主动提升监测、容量规划和基础架构自动化的级别，以满足数据处理和分析团队越来越高的性能要求。

敏捷性是通过协作，并兼顾想要完成的工作与需要完成的工作来获得的。否则，这新一代的大数据、机器学习和自助式商业智能(BI)计划很容易带来一大堆新的数据债务、数据孤岛和数据安全风险。

完善开发运营实践时运用客户理念

采用开发运营文化和实践的组织在努力解决一个横亘几十年的IT悖论：如何授权敏捷团队对生产环境进行小幅、频繁、低风险的更改，以满足用户并改善业务，又不影响可靠性、安全性、性能以及其他运营服务级别?

开发运营实践和工具弥补了IT变更管理流程方面的不足，这些不足会导致重大事件、需要根本原因分析的复杂问题、导致部署延迟的糟糕基础架构依赖项以及长期性安全问题。开发运营成功的几个例子如下：

• 使用私有云和公有云的组织借助安全的基础架构即代码，使环境的部署和拆除实现自动化。
• 敏捷开发团队借助左移的持续集成/持续交付(CI/ CD)管道，使测试实现自动化，并简化构建和部署工作。更高级的团队在管道中加入了安全验证，并积极采用开发安全运营(devsecops)。
• IT运营团队加大监测和部署人工智能运营(AIOps)平台的力度，以改善可见性和事件响应，从而改进管理复杂的无服务器部署、微服务架构和混合多云网络这一能力。

这些都是解决IT敏捷和运营悖论的战略性要素，但是如果没有一项战略就盲目开展这些计划，可能导致没有业务价值的IT结果。更为糟糕的是，它有时可能导致IT部门在自动化方面过度投入，影响了完成业务优先事项。

比如说，假设你在更新改造一款遗留的三层应用软件，同时将其转移至公有云，你就要决定实施哪种级别的自动化。应该如何定义什么足够好?又该如何为开发运营方面的改进定义成功标准?

有一些问题和参数有助于回答这个问题。一些人可能称之为服务等级需求，另一些人可能称之为非功能性需求。在一些情况下，高度参与的利益相关者会需要每天发布和99.999%的可靠性。而在另一些情况下，让利益相关者积极定义需求会比较困难。

任何一种情况都带来了挑战，但是敏捷性所需的共同点是首先定义客户、客户角色和成功标准。如果利益相关者的规范性过强，将他们列出的需求与业务层面上很合理的需求区分开来很重要。如果他们的需求没有明确定义，将成功标准记入文档特别重要。

许多组织定义产品管理或业务关系管理方面的职责，以记录和共享目标角色、成功标准和业务需求。将这种客户理念引入到开发运营团队和实践是一条最佳实践，将帮助组织确定要投入于哪些方面的自动化、进行多大的投入。

总之，无法强行要求敏捷性。只有加强领导人和参与者的协作，才能获得敏捷性。敏捷团队必须按照自我组织的原则和标准来运营。他们必须兼顾业务需要的改进与解决数据、运营和技术债务所需的工作。设置优先级、定义成功标准以及确定什么是最小可行产品，需要定义客户角色，并了解客户的需求和价值。

当组织采用这些类型的实践时，就不必强行要求敏捷性。敏捷性成为了共同的价值观和完成工作的标准方法。