С одной стороны — сертифицированный 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 первый уровень маневренности — «акцент на ценности», когда команды должны сосредоточиться на прозрачности и согласованности. Без этого уровня маневренности непрерывная поставка может легко превратиться в бесконечный цикл технических усовершенствований, не несущих достаточной ценности для бизнеса. Команда может выполнять работы быстро и качественно, однако сам продукт будет иметь низкую ценность для конечных пользователей и бизнеса. Даже если продукт нравится достаточному количеству пользователей, оценить его низкую ценность возможно только на более высоком уровне корпоративного портфеля. Маневренность очень важна — без нее сложно сопоставить технические методы с возможностями. Это особенно актуально для команд с устаревшей базой кода, не имеющей автоматизированных тестов или подходящего для частого развертывания дизайна. В контексте устаревшего кода трансформация с целью непрерывной поставки может занимать годы. Поэтому намного важнее уметь продемонстрировать преимущества для бизнеса.
Три метода
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.
Связывайте инструменты с помощью автоматизации
Возможно, самой большой проблемой при работе с несколькими инструментами является частая смена контекста и связанные с этим задержки. Если вы прервались на задачу, не связанную с кодом, для возврата к рабочему процессу могут потребоваться часы. По этой причине все больше сотрудников используют автоматизацию при взаимодействии с поставщиками Git и в инструментах управления работой. Вот три главных правила автоматизации.
- Если создан коммит и задача имеет статус To Do (Предстоит сделать), изменить ее статус на In Progress (В работе). Перейти к правилу.
- При слиянии запроса pull изменить статус на Done (Завершено). Перейти к правилу.
- Если выполнить сборку в Jenkins не удалось, добавить комментарий в Jira и сообщить команде в Slack. Перейти к правилу.
Эти и сотни других правил автоматизации можно найти в библиотеке шаблонов Jira Automation.
Начните бесплатно с помощью шаблона плана проекта DevOps
Разрабатывайте и развертывайте приложения, а также управляйте ими с помощью открытого подхода к инструментам.
