扩展敏捷和DevOps以实现数字化转型

在组织层面对产品和服务的开发和交付流程进行全面的检查有助于确保数字化的成功。
许多组织都将敏捷软件开发和DevOps视为了数字化转型过程中的关键步骤。

但是在许多情况下，这些转变是由较小的团队在处理的，因此限制了它们可能产生的总体影响。在整个组织中更广泛地推广这些实践可以通过在更大的范围内修改流程来获得显著的收益。但实现这一飞跃是具有挑战性的。
敏捷是一种开发方法，涉及自组织和跨职能团队之间的以及与软件最终用户之间的协作，旨在提高软件和服务开发的质量和速度。
与此同时，DevOps则能够将软件开发和IT运营结合在一起，缩短开发周期，并提供高质量的应用程序的持续交付。
将这些方法结合在一起可以加速数字化转型，并对如何完成工作产生重大影响--特别是在将它们扩展到涉及更多用户和项目的情况下。这里有一些关于在一定规模上成功使用敏捷和DevOps的技巧。
文化为王
作为数字化转型的一部分，那些在寻求扩展敏捷和DevOps的公司必须建立一种文化，这种文化应该包括对这些软件开发方法的责任和所有权的共享。
“DevOps的技能和DNA必须在整个组织中被广泛传播，”能源和自动化产品供应商施耐德电气的首席数字官HerveCoureil表示。“它必须成为公司文化的一部分。”
为了达到这个目标，公司不能将敏捷和DevOps的责任局限于一小部分专家。“提供符合DevOps最佳实践的版本是整个团队的责任，而不只是一个人的责任，因为这个人可能成为一个单一的失败点，”Coureil说。
在施耐德，“实施敏捷和DevOps的愿景是试图转变公司的整体运营模式”，Coureil说。“我们正在应用敏捷实践，在组织的所有功能之间建立持续而透明的沟通流，包括项目组合管理、财务管理、产品管理、产品工程、体系结构、专业服务和终端消费者。”
在2019年初，施耐德创建了一个敏捷转型办公室，以帮助团队更快地交付数字化产品，提高质量，并减少浪费。“我们正在采用‘Wave和Spike’方法来扩大整个公司的转型规模，”Coureil说。“在Wave中选择的任何产品或一组产品都应用了利用敏捷的Scrum和看板、DevOps CI/CD(持续集成和持续交付)、持续反馈和精益的项目组合管理实践等新操作模型的所有方面。”
另外，该公司为团队提供了研讨会来获得Scrum实践经验，另外还提供了教练来帮助团队改进他们对敏捷的使用。施耐德的所有开发项目现在都已经利用了敏捷框架方法。
衡量你的改进
仅仅在组织中扩展敏捷和DevOps部署是不够的。企业还需要衡量这些举措在扩张的每一个阶段所带来的价值。
“你需要用当前状态基线定义关键性能的度量，并不断迭代度量和进展，”Coureil说。“从了解现有的团队角色和工作实践开始，了解他们是如何工作的，以及哪里需要改进。”
施耐德有几个团队在使用瀑布开发模型--瀑布模型是将项目活动分解为线性的、连续的阶段，每个阶段都依赖于前一个阶段的交付--但都过渡到了Scrum敏捷流程框架。
“我们有其他的团队在实践Scrum的部分内容，但内容并不一致，”Coureil说。“我们创建了一个团队自我评估模板，帮助团队理解敏捷的最佳实践，他们自己的实践，以及他们需要做什么来进行改进。”
IT服务提供商Insight Enterprises使用了诸如技术进步、产品线趋势、资源消耗、产品质量、性能和业务成果等度量指标，
高级数字化转型架构师Jonathan Parnell说，要检查的具体因素包括流程的时间、减轻问题的时间、修复产品缺陷的成本，以及其他因素。
在人员/文化方面，管理层还需要关注团队动态、流程开销、可信度、士气和动机方面的趋势。
抵制部署过多工具的诱惑
帮助企业开发DevOps的产品并不缺乏，其中很多都是有用的。但重要的是要防范工具数量的膨胀。
“有太多的参考工具会导致团队之间的不同行为，并限制共享的文化，”Coureil说。“这会加大采用最佳实践和标准的难度，增加我们的潜在网络安全***，并阻碍规模的缩减。”
施耐德的核心DevOps架构师会负责维护工具堆栈，不断地丰富它以覆盖新的用例，并在需要时进行更改。“这需要一个永久性的技术观察，”Coureil说。
为了提高生产效率并保证安全性，施耐德维护了一个用于相互协作的DevOps工具栈，它涵盖了一系列的技术和场景，包括基于云的应用程序和用于物联网应用程序的传感器。
尽早并经常性地确保安全和治理
在敏捷和DevOps项目开始时就考虑安全措施是很重要的，因为这样就不会引起可能影响开发生命周期的问题。
“不管我们的发布和部署有多快，安全都不会是唯一的瓶颈问题，速度和可伸缩性也会是一个制约因素，”Parnell说。“有时候信任的程度和动机会严重失调。因为并不是价值流中的每个人都能够感受到安全的责任。”
在Insight，开发的重点一直就是业务的最终用户。“从技术上来说，我们通常忽略了一个关键的观点，即把安全性视为质量的一部分，而把违反安全性的行为视为缺陷的一部分，”Parnell说。“我们必须一路返回，在持续集成中解决这个问题。”
该公司实施了许多基于安全的元素，包括考虑到威胁建模和其他安全措施的策略驱动开发。
“我们花了一年多的时间来实现这一点，因为我们所承担的技术债务并不是从安全开始的，而是从传播‘安全文化’所需的认知开始的。”Parnell说。
敏捷和DevOps的治理也很重要。“要避免将敏捷转化为‘每个人都可以做自己想做的事情’的陷阱，”金融服务提供商万事达的首席技术官Steve Bagby表示。“这只会导致混乱，扼杀你运营和保护系统的能力，以及阻碍你最终服务客户的能力。”
几年来，万事达卡一直围绕着敏捷原则来组织其工程团队。“由于我们所做的几乎所有的事情都是作为服务来交付的，出于需要，可操作性建设一直就是其中不可分割的一部分，”Bagby说。
将构建、部署和运行应用程序的职责集成在一起有一个明显的好处，“每个人都会有自己的利害关系，并且需要对团队负责，”Bagby说。
强调培训
要在组织中广泛地部署敏捷和DevOps，就需要有大量精通这些方法并准备在开发过程中进行必要更改的员工。
“需要尽早并经常性的进行训练，包括面对面的课堂训练和练习场景，”Coureil说。“我们在全球进行了数十次课堂实践培训，以便建立一个基础。然后，我们会让教练进行小型的培训，以强化最佳实践。”
所有的培训内容都可以在一个交互式的学习门户中获得，以便跨团队的进行重用，Coureil说。“每个人都可以添加自己的评论和内容来提高学习效果。”他说。
Insight为其敏捷和DevOps项目创建了一个12到15人的跨职能团队，还有包括开发人员、数据库管理员和来自IT运营、网络、安全和业务部门的代表。
“这个团队进行了一系列的初始研讨会，以便使敏捷和DevOps的概念、基础、最佳实践和命名法以及与其他相关的学科得到统一和支持，”Parnell说。“这是至关重要的。没有这些基本的一致性，实现流动性就几乎是不可能的。”
Insight很快发现，跨职能团队代表了业务的各个方面，他们的动机可能各不相同，在某些情况下甚至是完全相反的。“主要是那些想要速度和灵活性的开发人员，但不包括那些需要稳定性和安全性的开发人员，”Parnell说。“通过整合来自指标中的客观证据，它最终成为了进攻(利用机会)和防守(管理风险和不确定性)的最好的平衡。”
分享最佳实践
前面提到的一些步骤也涉及到了实践的共享。但值得一提的是，这对于在整个组织中成功地扩展敏捷和DevOps是多么的重要，并且需要有一种额外的机制来实现这一点。
保险公司Liberty Mutual Insurance已经创建了一个敏捷实施办公室，它可以帮助不同的开发团队随着时间的推移在敏捷和DevOps中变得成熟。
“我们还从Liberty外部聘请了经验丰富的人才，比如Scrum master，以便将最佳实践引入并嵌入团队，”公司的高级副总裁兼托管服务总经理MarkCressey表示。
“在某些情况下，他们承担了这项工作，在大多数情况下，他们将指导我们在转型过程中引进的内部Scrum大师，”Cressey说。“不要让每个球队都朝着自己的方向前进，这真的很重要。通过关于敏捷、敏捷转型和DevOps的外部知识来支持他们是我们成功的关键。”
分享经验还意味着可以从团队中听取他们的进展或是可能出现的任何问题。“从0到100%的敏捷并不是在一条直线上的，”Cressey说。“但在整个过程中，我们听取了团队的意见，当我们需要根据反馈来采取不同的策略时，我们就会这么做。”我们可以暂停或重置任何给定的区域或练习，以便获取有关哪些有效哪些无效的关键反馈。”
从高层获得支持
对于那些原生使用这些方法的组织来说，扩展敏捷和DevOps可能是很自然的事情。但对于许多对这些概念相对陌生的人来说，来自高管的支持是成功的关键。
“每个人都说他们想要或者已经是敏捷的。但为了真正做到这一点，高管们必须完全接受这个概念，”金融服务公司CapitalOne的小型企业与国际业务首席技术官MarkMathewson表示。
“在我的工作中，我发现管理人员必须能够支持预算、能力规划等各方面的工作。”Mathewson说。
Capital One已经进行了7年的大规模的技术转型，通过转型，它全面重塑了自己的人才和文化、人们的工作方式以及技术基础设施。“我们转向了一个100%的交付软件敏捷模型，并建立了一个规模庞大的工程组织，”Mathewson说。
该公司花了三年的时间来转向云计算、扩展DevOps、采用开源，并最终能够开始利用由此带来的灵活性。Capital One现在正将注意力转向标准化和持续交付。
“在过去，开发者对产品的参与大多在交付运营后就结束了，”Mathewson表示。“但现在我们正在实践一种新的DevOps方法，我们的开发人员对这些产品有了更多的所有权，并且能够对正常运行时间、可支持性和监控变得更加积极主动。”