Perfecting the Agile Operating Model

ByAlok Uniyal,哈里·凯尔·休斯（Harry Keir Hughes）， 2019年8月|报告|9分钟阅读|本文的电子邮件|Download
现任银行不适合敏捷的工作方式和现代软件开发操作。孤立的组织结构和效率低下的应用程序开发阻碍了障碍。为了提高软件开发效率，提高质量并降低风险，敏捷性和更快的发展必须成为新规范。在六部分系列的第二篇文章中，我们讨论了一家领先的银行如何重新配置​​其独立，跨职能的产品团队具有所有权和自治权来“计划，构建和运行”创新的软件解决方案。

Introduction

2016年，一家领先的全球银行使用DevOps来改变其IT运营。在18个月的时间里，软件释放频率增加了40％以上，测试工作减少了70％。

在本系列的第一篇文章中，DevOps被定义为一种方法，可快速，敏捷的软件开发和可扩展，可靠的操作1。我们还总结了这种方法的好处。

This article describes how the traditional operating model was redesigned so that DevOps teams could group together to work agilely. The dialogue among all software delivery teams, IT operations staffers and business stakeholders had to change significantly to ensure that the Agile operating model was successful2。

一切如何开始

每个DevOps转换都必须确保对IT景观的变化与总体业务目标保持一致。然后，这些目标成为了团队领导者努力的变革的催化剂。

The bank envisioned three goals to catalyze this IT transformation:

  1. 通过直接节省和吸收逆风来优化成本的重大优化
  2. Sizable improvement in IT quality and service stability
  3. 关键绩效指标提高了10％以上

该银行开发了六个能够推动其转型的功能

前两个功能 - 操作模型重新设计和企业敏捷性 - 是本文的重点。

需要重新设计操作模型

大多数现任银行都不适合敏捷的工作和DevOps。技术工程师和其他IT角色在传统组织结构中的业务范围内分组。这些业务流由用于构建和运行应用程序的服务功能支持（见图1）。

Figure 1. Products and services were traditionally delivered by applications managed by multiple lines of business

Products and services were traditionally delivered by applications managed by multiple lines of business

With this design, products or services (such as payments) are delivered through applications managed by multiple business groups. This discourages collaboration between teams, encouraging them to form silos. Teams feel they have to raise barriers between themselves to communicate with each other (referred to as “support models”).

The bank enlisted Infosys support to rethink this operation for its South American operations, so that it could support a DevOps model of application life cycle management and redefine 15 business-critical services (covering over 100 applications).

根据Gartner Research的说法，组织变革是允许Devops蓬勃发展的关键：“与人有关的因素往往是最大的挑战，而不是技术。”3

At the bank, the entire operating model was reconfigured, with agility as a primary design principle for its new DNA.

The new, improved operating model

The new operating model took full advantage of DevOps.

Along with bringing people together in one unit and removing silos, DevOps requires software development practices that combine software development with technology operations to shorten the development life cycle. Business objectives are closely aligned with every stage of the process. Features, fixes and updates are delivered in a cyclical fashion, and each change improves on the one before it. This iterative feedback loop ensures rapid feedback, and quality is kept front and center.

The core principle for the redesign was, simply put, “What you build, you run!” Small DevOps teams of approximately 15 people each were created.

Figure 2. In the Agile operating model, self-governed teams deliver a product or service

在敏捷的操作模型中，自治团队提供产品或服务

In Figure 2, each line of business houses multiple agile teams, known as Pods, with support functions integrated into daily activities.

These self-contained, cross-functional product teams have complete ownership and autonomy to “plan, build and run” innovative solutions for the business. Support personnel no longer have barriers like ticketing systems and operation-level agreements. Rather, they are part of the DevOps team. By partaking actively in an application’s life cycle, support personnel have joint ownership in the team’s outcomes, which encourages collaboration and, ultimately, accountability.

What exactly is a Pod?

  • Self-sufficient and self-sustainable agile team that has the autonomy to build and run its product or service, along with complete accountability for its performance
  • Cross-functional and cross-skilled resources collectively working to achieve the sprint and release goals (sprint and release are terms associated with the agile way of working)
  • Consists of 10-20 people, depending on the complexity and number of applications or services delivered
  • 以无缝的方式驱动DevOps模型，并具有全包业务开发，测试和运营的结构
  • Teams work on a single, integrated product backlog, compared to multiple project teams working on multiple project or application backlogs

图3.由15人组成的多元化和熟练团队运送与敏捷工作方式保持一致的产品

由15人组成的多样化和熟练的团队交付了与敏捷工作方式保持一致的产品

这些敏捷，多浪费和自我管理的团队每天共同实现共同的目标。

从一开始就将关注业务成果的重点根深蒂固。这使得产品所有者可以以一种使业务意义的方式实现DevOps的价值，从而完善团队对客户价值的理解，以发展能力并进一步实现组织变革4。

Since teams comprise people in both business and technology, workflow and communication become more transparent. An intrinsic understanding of the product or service also develops.

Building and fixing everything together in a series of sprints accelerates customer feedback and reduces friction, cost and risk.

Operations-as-a-Service as the new normal

Development and operations do not overlap in a traditional operating model. One team designs, develops and tests the application or service, and another set of individuals manages the operations and infrastructure component.

随着操作 - 服务（OAA）的操作，软件环境将自动部署到生产中。OAAS还可以监视并维护系统，在需要时应用补丁程序和安全更新。

With the new agile operating model in place, the operations engineer (see Figure 3) performs the tasks and activities once managed by the run and operations teams in the traditional model.

The agile team’s integrated product backlog brings together tasks such as monitoring, incident resolution, problem investigation and configuration management. The product owner then prioritizes these tasks for the operations engineer to complete.

Mature agile teams

一个成熟的团队非常敏捷，主要通过产品所有者展示高水平的业务参与度。这种协作水平并不容易实现，并且可能需要数月的时间才能学会有效合作。

The bank leveraged the disciplined agile framework to help foster this working culture. This framework provides a blueprint for lightweight guidance at the team level. Teams are driven to succeed as objectives and targets are transparent throughout the process. Progress for each sprint is measured collectively through KPIs such as increased deployment frequency, increased deployment success rate and a faster mean time to restore (MTTR).

看板and scrum delivery methods were made available to the agile teams within the bank enterprise, and the teams could choose the most appropriate delivery approach — or even a combination of multiple delivery models (e.g., scrumban).

操作模型是如何开发的？

手工挑选的银行员工和Infosys Agile DevOps专家组成了计划部署团队。每个团队成员都有专业知识，经验和敏捷性的要素，可以改变银行的文化，从而导致复杂的景观。

图4.银行工作人员遮蔽了Infosys团队学习和优化敏捷的工作方式

Bank staff shadowed the Infosys team to learn and optimize agile ways of working

The external team was chosen based on their respective fields of knowledge: agile coaches, DevOps automation experts, test automation experts, KPI consultants and service management experts. Each lead or expert was tasked with their own workstream to help bank members learn the ropes, through shadowing and on-the-job learning.

This structure enabled the transformation to progress quickly and infuse new ways of working throughout the teams. Extended members of the team also quickly became knowledgeable about the new working culture. This ultimately helped sustain transformation post Infosys exit.

True agility in the operating model requires a DevOps philosophy to take root. This is demonstrated as collaboration and cross-functional thinking, and must be embedded in day-to-day activities.

There must also be a willingness to fail, with buy-in from key stakeholders within the company supporting the long-term transformation. Unfortunately, this was not initially the case at the bank as the DevOps transformation began (Article 5 in the series describes how this was rectified).

DevOps is not a one-time rethinking of the operating model, but a successively improving change in culture and capabilities.

With that in mind, refrain from creating a separate DevOps team that works separately from the rest of the organization. Silos should be removed within IT as DevOps is rolled out, and business leads should be invested in the results of the process5。

下一篇文章看了DevOps工具框架work that was used within this operating model. The concept of DevOps as a practice is introduced, along with progressive DevOps tools that improve on the quality of code reviews.

Download