Agile и DevOps: друзья или враги?

DevOps — это agile-методология, применяемая не только в командах разработчиков ПО. Остается узнать, кто же победит?

Иэн Бьюкэнэн Иэн Бьюкэнэн

С одной стороны — сертифицированный мастер по Scrum, которого друзья зовут Extreme Programmer, а дети — LeSS SAFe DAD... Agile!

А с другой — настоящая машина по поддержанию культуры бережливой разработки, выполняющая непрерывную доставку инфраструктуры в качестве кода! Ее левую руку зовут Dev, а правую Ops... DevOps!

Although I've taken the hype to an extreme, the sound bites about Agile and DevOps can make them sound like very different ideas. Compounding the confusion, both concepts seem to defy definition, even as they have their own jargon and slogans. As the elder, Agile may be less vague, but it's certainly common for people to become frustrated with the myriad of definitions for DevOps. The lack of definition has lead to some common conflation. 

Many people think Agile means Scrum and DevOps means Continuous Delivery. This oversimplification creates an unnecessary tension between Agile and DevOps so you may be surprised to find that they are best friends!

There's no denying the historical connection between DevOps and Agile. When Patrick DuBois and Andrew Clay Schafer tried to connect at the Agile 2008 Conference about "Agile Infrastructure", the connection to DevOps was born. Although Patrick later coined the term "DevOps", the Agile Conference continues to honor this connection with a DevOps track. But let's dive deeper than history and consider the practical connections between Agile and DevOps, when we look below the surface of Scrum and Continuous Delivery.

Agile — это нечто большее, чем Scrum

В одних командах Scrum превращает постоянную изматывающую борьбу в продуктивную и результативную командную работу. В других — привносит объективность и целеустремленность на смену правилам и непосильным обязательствам. Его также можно принять как догму. Если же в силу ограничений, накладываемых бизнес-условиями или непосредственной работой, требуется что-то другое, agile-команды могут воспользоваться базовыми принципами Scrum, после чего оценить свои методики и адаптироваться, тем самым повысив свою эффективность. Это особенно важно, когда Scrum применяется не при разработке программного обеспечения, а в других сферах.

Планирование внеплановой работы

In the DevOps community, those with Agile experience acknowledge that scrum is useful for tracking planned work. Some work in operations can be planned: releasing a big system change, moving between data centers, or performing system upgrades. But much of the work of operations is unplanned: performance spikes, system outages, and compromised security. These events demand immediate response. There's no time to wait for the items to be prioritized in a backlog or for the next sprint planning session. For this reason, many teams that have come to embrace DevOps thinking, look beyond Scrum to Kanban. This helps them track both kinds of work, and helps them understand the interplay between them. Or, they adopt a hybrid approach, often called Scrumban or Kanplan (kanban with a backlog).

In many ways, the key to Scrum's wide adoption may be that it prescribes no technical practices. Scrum's lightweight management practices often make a big difference for a team. Where there was once competing priorities from multiple masters, there is now a single set of priorities in the backlog. And where there was once too much work in progress, there is now a plan constrained by what time has shown is really possible. In combination, these can take a team to new levels of productivity. However, the team may find themselves constrained by the lack of technical practices, such as coding reviewsautomated acceptance tests, and continuous integration.

В других agile-процессах, например экстремальном программировании, прослеживается четкое видение того, как технические методы должны влиять на способность команды поддерживать постоянный темп и обеспечивать прозрачность и видимость для руководства и всех заинтересованных сторон. Некоторые Scrum-команды пытаются переместить технические задания в бэклог. Хотя это решение вписывается в концепцию Scrum, на практике быстро возникает довольно серьезная проблема: все дело в пристрастности владельца продукта в вопросе возможностей. Владелец продукта должен быть технически подкованным, в противном случае он не сможет оценить технические методы в плане соотношения «цена/качество». Если же технические задания проникают в сферу операций для большей надежности, производительности и безопасности, задача для владельца продукта становится еще сложнее.

Владельцы продукта и владельцы сервиса

В Atlassian мы пришли к выводу, что для сопровождения наших продуктов лучше иметь две разных роли. Наши владельцы продукта прекрасно понимают, какие функции нужны пользователям, но им довольно сложно сопоставить эти функции с нефункциональными возможностями, такими как производительность, надежность и безопасность. Поэтому у некоторых SaaS-продуктов в Atlassian также есть владельцы сервиса, ответственные за расстановку приоритетов среди нефункциональных возможностей. Время от времени два владельца встречаются и обмениваются информацией (что выгодно обеим сторонам), но большую часть времени они могут работать в независимых командах. Это позволяет не только укрепить обратную связь от операторов, но и преодолеть распространенные предубеждения в отношении владельцев продукта и функций. Подход с двумя владельцами — это не единственный путь к DevOps. Важно рассматривать эти нефункциональные характеристики в качестве функций и уметь планировать и ранжировать их, как и любую функциональную пользовательскую историю.

В конечном счете вся эта критика Scrum не относится к Scrum напрямую. В Scrum, как и во всех agile-методиках, есть встроенный механизм совершенствования процессов — ретроспективы. Таким образом, вполне логично предположить, что некоторые scrum-команды будут использовать DevOps в качестве источника вдохновения, а ретроспективы Scrum — как возможность внести изменения и двигаться в направлении DevOps. Однако очевидно, что большей части команд нужен приток идей извне. До тех пор пока DevOps не станет мэйнстримом (или даже не станет учебной дисциплиной), он не будет восприниматься естественным продолжением Scrum. Неважно, к какому тренеру обращается команда — по agile или DevOps, — главное, чтобы этот специалист обладал опытом автоматизации в области создания, тестирования и развертывания программного обеспечения.

DevOps — это не только непрерывная доставка

When done well, the discipline of Continuous Delivery (CD) helps to limit work in progress, while the automation of deployment helps to elevate constraints. In this way, CD helps a software team deliver more frequently and with higher quality, instead of having to choose between the two. However, just as teams focusing only on Scrum can miss the broader context of Agile, so too can teams focusing on Continuous Delivery miss the broader context of DevOps.

The practice of CD does not directly address problems in communication between the business and a software team. If the business has a year-long, budget-driven planning cycle, then a team delivering every commit into production may still have to wait months before the business can react. All too often those reactions come as step-functions, like canceling the project, or worse doubling the project team (because a large influx of new people is disruptive).

The Agile Fluency Model indicates the first level of fluency as "Focus on Value", where teams focus on transparency and alignment. Without this fluency, CD can easily devolve into an endless cycle of technical improvement that yields no appreciable value to the business. A team might get good at delivering fast with high quality, but for a product that has low value for end-users or the business. Even when there are many users who say good things, that assessment of low value might only be possible at a larger business portfolio level. Without this important fluency, it is hard to weigh technical practices against features. This is particularly important for a team with a legacy codebase, that may not have automated tests or a design suitable for frequent deployment. In a legacy context, a CD transformation may take years. So it's that much more important to be able to demonstrate business benefit.

Три метода

DevOps — это не просто автоматизация конвейера развертывания. По мнению Джона Олспоу, основа DevOps — «операторы, думающие как разработчики, и разработчики, думающие как операторы». Развивая эту мысль, Джин Ким назвал три метода, отражающих базовые принципы DevOps.

Первый метод Системное мышление emphasizes the performance of the entire system, as opposed to the performance of a specific silo of work or department — this can be as large as a division or as small as an individual contributor.
Второй метод Укрепление циклов обратной связи Создаются циклы обратной связи «справа налево». Цель практически каждой инициативы по усовершенствованию процесса — сократить и укрепить циклы обратной связи, чтобы необходимые исправления можно было вносить непрерывно.
Третий метод Культура непрерывного эксперимента и обучения Создается культура, в рамках которой укрепляются две вещи — стремление к непрерывному экспериментированию и умение рисковать и учиться на ошибках; также прививается понимание того, что повторение и практика — неотъемлемые составляющие мастерства.

 

Непрерывная доставка ориентирована на первый метод: автоматизация потоков от разработки (dev) к операциям (ops). Роль автоматизации в укреплении системы развертывания невозможно переоценить. Но системное мышление — это нечто большее, чем автоматизация.

The Second Way is characterized by the practice, "Devs wear pagers too."  Although the literal use of pagers may not be necessary, it means pulling developers into operational issues. This helps developers understand the consequences of their development choices. For example, that can inspire developers to put log messages in better places and to make those messages more meaningful. It's not just about awareness. Developers also bring their internal understanding of the system to troubleshooting efforts, so a resolution can be found and implemented faster.

The Third Way is about making incremental experiments in the system as a whole, not just as changes to the application moving through the pipeline. In other words, it's relatively easy to see how long automation takes and to use increasingly powerful infrastructure to keep improving it. It's harder to understand how the hand-offs between roles or organizations introduces delays. This means teams "inspect and adapt" across the whole delivery workflow, looking for opportunities to improve human collaboration. For that matter, CD requires a habit of adapting and improving. If the team doesn't reflect on how to become more effective, and then tune and adjust its behavior on anything else, then CD will not grow and thrive either. The team needs to feel empowered to solve their own problems.

Каждая ретроспектива в Scrum — это возможность совершенствовать методы и инструментарий. Но если команда не будет использовать открывающиеся перед ней возможности для решения краткосрочных и долгосрочных технических проблем, она будет просто ждать, пока владелец продукта поместит задачи по непрерывной доставке в бэклог, чего никогда не случится.

DevOps — это agile-методология, применяемая не только в командах разработчиков ПО

Scrum, как правило, соответствует следующему принципу agile-методологии: «Изменения требований приветствуются даже на поздних этапах разработки. Agile-процессы используют изменения для обеспечения конкурентного преимущества клиента».

Непрерывная доставка, как правило, соответствует следующему принципу agile-методологии: «Самая важная задача — удовлетворить требования клиента в результате быстрой и непрерывной доставки ценного программного обеспечения».

Это значит, что agile-методология в большей степени посвящена входящим и исходящим изменениям, а не таким процедурам, как летучки и планирование спринтов. На деле в манифесте agile-методологии содержится еще 10 других принципов. Эти принципы стоит рассматривать как единое целое, не выделяя лишь некоторые из них. В совокупности эти принципы показывают отношение к изменениям, свойственное как agile, так и DevOps.

Эти ребята зашли в тупик, пытаясь использовать хрупкие — но невероятно важные для бизнеса — системы. Ввиду их значимости для бизнеса, подобные системы также требуют максимально быстрого внесения изменений. Идея agile-методологии о принятии изменений, как таковая, не подразумевает внесения изменений ради самих изменений. Она предполагает ответственность разработчиков за качество вносимых изменений при одновременном повышении общей способности наращивать бизнес-ценность. Эта ориентированность на бизнес-ценность представляет собой еще одну общую черту agile и DevOps.

Finally, neither Agile nor DevOps are business goals in and of themselves. Both are cultural movements that can inspire your organization with better means for achieving your goals. Agile and DevOps work better in combination, than as adversaries. The trick to avoiding confrontation between these two ideas is to understand the deeper values and principles upon which they are formed. Quick, but narrow, definitions lead to siloed thinking. Now that you know there's more to Agile than Scrum, and there's more to DevOps than CD, you're ready to try the powerful Agile + DevOps combination.