Devops

Agile и DevOps:

DevOps - это Agile, применяемый за пределами команды разработчиков программного обеспечения. Но реальный вопрос в том, кто в матче выигрывает?

В одном углу у нас есть сертифицированный мастер Scrum , известного своим друзьям как экстремальный программист, а его детям - как  папа LeSS SAFe  ... Agile!

В другом углу у нас есть машина Lean-культуры, которая непрерывно поставляет свою инфраструктуру как код, он называет свою левую руку разработчиком и свою правую руку операциями ... DevOps!

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

Многие думают, что Agile означает Scrum, а DevOps означает непрерывное предоставление. Это чрезмерное упрощение создает ненужную напряженность между Agile и DevOps, поэтому вы можете быть удивлены, обнаружив, что они лучшие друзья!

Нельзя отрицать историческую связь между DevOps и Agile. Когда Патрик Дюбуа и Эндрю Клэй Шафер попытались соединиться на конференции Agile 2008 по «гибкой инфраструктуре», родилась связь с DevOps.

Хотя позже Патрик придумал термин «DevOps», конференция по Agile  продолжает отмечать эту связь треком DevOps. Но давайте углубимся в историю и рассмотрим практические связи между Agile и DevOps, когда мы посмотрим ниже поверхности Scrum и постоянного предоставления.

                                                              

В Agile больше, чем в Scrum

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

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

В сообществе DevOps те, кто имеет опыт Agile, признают, что scrum полезен для отслеживания запланированной работы. Можно запланировать некоторую работу в оперативном режиме: выпустить релиз крупного изменения системы, перейти между центрами обработки данных или выполнить обновление системы. Но большая часть операций незапланированная: резкие скачки производительности, перебои в работе системы и нарушение безопасности. Эти события требуют немедленного ответа. Нет времени ждать, когда элементы будут расставлены по приоритетам в списке необходимых требований (backlog) или для следующего сеанса планирования спринта. По этой причине многие команды, которые пришли, чтобы принять мышление DevOps, смотрят за пределы Scrum на Канбан. Это помогает им отслеживать оба вида работы и помогает им понять взаимодействие между ними. Или они используют гибридный подход, часто называемый Scrumban или Kanplan (канбан с списком необходимых требований (backlog)).

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

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

  

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

В Atlassian мы осознали, что это помогает выполнять две разные роли для продуктов, которыми мы управляем. Владельцы наших продуктов хорошо разбираются в функциях, которые нужны пользователям, но они не так хороши в сопоставлении этих функций с нефункциональными возможностями, такими как производительность, надежность и безопасность. Таким образом, некоторые продукты SaaS в Atlassian также имеют владельца сервиса, который отвечает за приоритетность этих нефункциональных возможностей. Время от времени двум владельцам, возможно, приходится заниматься какой-то «конной торговлей», но большую часть времени они могут работать  независимыми командами.

Возможно, это не единственный способ «усилить обратную связь» с операциями, но он помогает преодолеть слишком распространенную предвзятость владельцев продукта в отношении функций. Такой подход с двумя владельцами - не единственный путь к DevOps. Важно понимать эти нефункциональные характеристики как «функции» и возможность планировать и расставлять приоритеты, как и любую функциональную пользовательскую историю.

ТВИИТ:

Пока DevOps не станет мейнстримом, это не будет органичным результатом scrum. #DoDevOps

В конечном счете, ни одно из этих критических замечаний в отношении Scrum не является полностью присущей самому Scrum. Как и во всех Agile-методах, в Scrum есть встроенный механизм «улучшения процессов», называемый ретроспективами. Следовательно, разумно полагать, что некоторые команды Scrum используют DevOps в качестве источника вдохновения и используют ретроспективу Scrum в качестве возможности для настройки и адаптации к DevOps. Однако просто практично понять, что большинству команд нужна инъекция сторонних идей. Пока DevOps не станет мейнстримом (возможно, тем что преподавали в школе), DevOps не будет органичным результатом Scrum. Будет ли команда задействовать тренера Agile или DevOps,  вероятно,  это не имеет значения, если этот человек может принести опыт в автоматизацию при создании, тестировании и развертывании программного обеспечения.

DevOps - это больше, чем непрерывное предоставление

Когда все сделано правильно, дисциплина  постоянного предоставления (Continuous Delivery (CD)) помогает ограничить работу в процессе, а автоматизация развертывания помогает снять ограничения. Таким образом,  постоянное предоставление (CD) помогает команде разработчиков выполнять и предоставлять чаще и с более высоким качеством, вместо того, чтобы выбирать между ними. Однако так же, как команды, сосредоточенные только на Scrum, могут упустить более широкий контекст Agile, так и команды, сосредоточенные на постоянном  предоставлении, могут упустить более широкий контекст DevOps. Практика использования постоянного предоставления  напрямую не решает проблемы в общении между бизнесом и командой разработчиков программного обеспечения. Если у бизнеса годовой цикл планирования, ориентированный на бюджет, то команде, выполняющей каждый коммит (фиксацию кода) в производство, возможно, придется ждать месяцы, прежде чем бизнес сможет отреагировать.

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

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

Три пути

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

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

 

Непрерывное предоставление (CD) ориентировано на Первый путь: автоматизация потока от разработчиков до операторов. Автоматизация играет очевидную роль в ускорении развертывания системы. Но системное мышление - это нечто большее, чем просто автоматизация.

Второй путь характеризуется практикой «Разработчики тоже носят пейджеры». Хотя буквальное использование пейджеров может и не понадобиться, это означает втягивание разработчиков в оперативные задачи. Это помогает разработчикам понять последствия своего выбора при разработке. Например, это может вдохновить разработчиков размещать сообщения журнала в лучших местах и делать эти сообщения более значимыми. Это не просто осознание. Разработчики также привносят свое внутреннее понимание системы в поиск и устранение неисправностей, поэтому решение может быть найдено и реализовано быстрее.

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

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

DevOps - это Agile, применяемый вне группы разработчиков программного обеспечения

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

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

ТВИИТ: DevOps стремится донести это гибкое отношение к изменениям до новой аудитории: ИТ-операций. #DoDevOps

Эти люди застряли, пытаясь запустить хрупкие системы, которые также являются наиболее важными для бизнеса. Поскольку они наиболее важны для бизнеса, они также необходимы для наиболее срочных изменений. Таким образом, эта  идея  Agile  охвата изменений не является «изменением ради перемен». Речь идет о привлечении разработчиков к ответственности за качество их изменений при одновременном повышении общей способности обеспечивать ценность для бизнеса. Этот акцент на бизнес-ценность является еще одним аспектом, разделяемым Agile и DevOps.

Наконец, ни Agile, ни DevOps сами по себе не являются бизнес-целями. Оба являются культурными движениями, которые могут вдохновить вашу организацию лучшими средствами для достижения ваших целей. Agile и DevOps работают лучше в комбинации, чем как противники. Хитрость в том, чтобы избежать конфронтации между этими двумя идеями, состоит в том, чтобы понять более глубокие ценности и принципы, на которых они основаны. Быстрые, но узкие определения приводят к разрозненному мышлению. Теперь, когда вы знаете, что Agile больше, чем Scrum, и DevOps больше, чем постоянная доставка, вы готовы попробовать мощную комбинацию Agile + DevOps.

По материалам Agile Coach "DevOps"