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

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

Ian Buchanan Ian Buchanan
Просмотр тем

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

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

Конечно, все это очень преувеличено. Может показаться, что между agile и DevOps нет совсем ничего общего. Более того, обе концепции не поддаются определению, так как у каждой есть собственный жаргон и слоганы. Agile как старшая концепция определена более однозначно, однако люди впадают в самое настоящее отчаяние при виде множества определений концепции DevOps. Отсутствие четкого определения привело к смешению этих понятий.

Многие думают, что agile — это Scrum, a DevOps — это непрерывная поставка. Такое чрезмерное упрощение приводит к никому не нужным трениям между agile и DevOps. Вы, наверное, очень удивитесь, когда узнаете, что они лучшие друзья.

Между DevOps и agile, определенно, есть связь — так сложилось исторически. Связь с DevOps появилась в 2008 году на конференции Agile Conference. Тогда Патрик Дюбуа и Эндрю Клэй Шейфер попытались наладить контакт в рамках выступления по теме «Agile-инфраструктура». И хотя позже Патрик придумал термин DevOps, Agile Conference продолжает чтить эту связь с линией развития DevOps. Но давайте пойдем дальше и рассмотрим практические связи между agile и DevOps, то есть изучим Scrum и непрерывную доставку более подробно.

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

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

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

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

Основной причиной столь широкого распространения Scrum является отсутствие предписанных технических методов. Простота управления Scrum — вот что особенно важно для команды. На смену конкурирующим приоритетам от различных источников пришел единый набор приоритетов в бэклоге. А непомерные объемы незавершенной работы превратились в план, ограниченный фактическими возможностями команды, которые проверены временем. При сочетании этих двух факторов команда может выйти на новый уровень производительности. Однако из-за отсутствия технических методов — проверок кода, автоматизированных приемочных тестов и непрерывной интеграции — команды могут ощущать некоторую «скованность движений».

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

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

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

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

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

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

Методика непрерывной поставки не решает проблемы коммуникации между бизнесом и командой разработчиков ПО напрямую. Если бизнес руководствуется годичным циклом планирования, который определяется бюджетом, команда, передающая каждый коммит в рабочую среду, может ждать реакции бизнеса долгие месяцы. Слишком часто подобные реакции принимают скачкообразный характер. Это проявляется, например, в отмене проекта или, что еще хуже, в удвоении штата проектной команды (так как большой приток новых людей носит разрушительный характер).

В рамках модели Agile Fluency Model первый уровень маневренности определяется как «акцент на ценности». На этом уровне команды должны сосредоточиться на прозрачности и согласованности. Без этого уровня маневренности непрерывная поставка может легко превратиться в бесконечный цикл технических усовершенствований, не несущих достаточной ценности для бизнеса. Команда может выполнять работы быстро и качественно, однако сам продукт будет иметь низкую ценность для конечных пользователей и бизнеса. Даже если продукт нравится достаточному количеству пользователей, оценить его низкую ценность возможно только на уровне более крупного корпоративного портфеля. Маневренность очень важна — без нее сложно сопоставить технические методы с функциями. Это особенно актуально для команд с устаревшей кодовой базой, которая не подвергается автоматическим тестам или не предполагает частое развертывание. Из-за устаревшего кода трансформация с целью реализации непрерывной поставки может занимать годы. Поэтому намного важнее уметь продемонстрировать преимущества для бизнеса.

Три метода

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

Первый метод Системное мышление Упор делается на производительности системы в целом, а не на производительности отдельных видов работ или отделов; применяется как к подразделениям, так и к отдельным пользователям.
Второй метод Укрепление циклов обратной связи Создаются циклы обратной связи «справа налево». Цель практически каждой инициативы по усовершенствованию процесса — создать более быстрые и интенсивные циклы обратной связи, чтобы необходимые исправления можно было вносить непрерывно.
Третий метод Культура непрерывного обучения и экспериментирования Создается культура, в рамках которой поощряются две вещи — стремление к непрерывному экспериментированию и умение рисковать и учиться на ошибках; также прививается понимание того, что повторение и практика — неотъемлемые составляющие мастерства.

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

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

Третий метод — осуществлять инкрементальные изменения в системе в целом, а не в отдельных приложениях, движущихся по конвейеру. Другими словами, можно относительно легко узнать, сколько времени отнимает автоматизация, и использовать инфраструктуру с возможностью масштабирования для ее дальнейшего совершенствования. Сложнее понять, каким образом передача ответственности между должностями или организациями влияет на задержки. Это значит, что команды «выполняют проверки и адаптируются» в течение всего процесса доставки. Для этого они ищут возможности улучшения взаимодействия между людьми. Таким образом, непрерывная поставка подразумевает стремление к адаптации и совершенствованию. Если команда не будет пытаться понять, как повысить свою эффективность, и изменить свое поведение, процесс непрерывной поставки также не будет развиваться. Команда должна чувствовать, что у нее есть силы для решения собственных проблем.

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

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

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

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

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

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

В итоге ни agile, ни DevOps как таковые не являются целью бизнеса. Эти подходы — культурные движения, предоставляющие вашей организации лучшие средства для достижения целей. Для большей эффективности agile и DevOps лучше сочетать, а не противопоставлять. Чтобы избежать конфронтации между этими двумя идеями, нужно понять глубинные ценности и принципы, на которых они основаны. Лежащие на поверхности, но узкие определения ведут к разобщенному мышлению. Теперь, когда вы знаете, что agile — это не просто Scrum, а DevOps — это не просто непрерывная поставка, вы готовы воспользоваться мощной комбинацией agile + DevOps.

продолжение темы
Agile Teams