У вас есть Agile и нет DevOps? У вас нет Agile 🤷♂️
Всем привет! Я Станислав Тибекин, управляющий партнер и CVO компании Nixys. Мы помогаем выстраивать процессы DevOps, DevSecOps, MLOps. Многие компании, разрабатывающие свои digital-продукты, уверены, что работают по Agile. Хотелось бы рассказать, почему это зачастую не так и почему сегодня невозможно существование Agile без DevOps.
Что такое Agile: история, принципы и практика
История
Давным-давно, на заре коммерческой разработки ПО, была популярна «каскадная модель разработки» или Waterfall. В компаниях были отделы и каждый занимался своим делом. Отдел аналитики собирал требования с заказчиков, писал по ним спецификации, отдавал их дизайнерам. Отдел дизайна делал дизайн и отправлял продукт в разработку. Хмурые парни в черных худи писали программу, отдавали прототип в тестирование, фиксили баги и вот… Спустя какое-то время (нередко значительное) какой-нибудь отдел менеджеров отдавал финальную версию заказчику. Заказчик хватался за голову, вносил правки, просил всё переделать, и история повторялась.
У такого подхода были плюсы. Большая часть требований была известна на старте, стороны заранее оценивали сроки и бюджет, прикидывали менеджмент и т.д. Создавалось обманчивое впечатление, что проект под контролем.
Хватало и минусов. Планирование на больших отрезках получалось неточным, заказчик 60-80 % времени не видел никакого результата, участники команд сидели в разных кабинетах и вникали в проект только на своих этапах. Как правило, с течением времени такие проекты превращались в неповоротливых монстров, накапливали огромное количество технического долга, который было нереально пофиксить — долго и дорого (и больно). Но самое грустное для бизнеса — не было возможности быстро менять продукт под требования рынка. Внедрение новых функций, исправление неэффективных решений занимало много времени.
Минусы становились всё очевиднее и появились активисты, которые предложили другую философию. Так появился Agile. Постепенно разрозненные мысли оформились в Agile-манифест — 12 принципов гибкой разработки программного обеспечения.
Принципы и практика
Зная минусы Waterfall, вы и сами можете предположить, какие изменения предлагали создатели Agile. Первое и главное — сократить время разработки, чтобы обеспечить заказчику конкурентное преимущество. Поставлять ПО быстро, регулярно, выпускать обновления в кратчайшие сроки. Второе — минимизировать технический долг. Систематически анализировать возможные способы улучшения эффективности и постоянно стремиться к техническому совершенству и качеству проектирования.
Для достижения таких результатов предлагалось изменить формат взаимодействия между всеми сторонами проекта: заказчиками, разработчиками, менеджерами и т. д. Бизнес и разработка должны регулярно взаимодействовать друг с другом, обсуждать прогресс, сложности, корректировать работу, что называется «в полете». Вместе с тем самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд — а значит, не стоит впадать в микроменеджмент и бюрократию.
На практике эти идеи реализовались в виде спринтов (ограниченных по времени итераций разработки), планирования очередности решения задач (так появился бэклог), Agile-ролей (Team Lead, Project Lead, Scrum-мастер, Product Owner и др.), традиции ежедневных митингов, ретроспектив и т.д.
Agile: ожидания / реальность (и при чем тут всё-таки DevOps)
Поделюсь той болью, с которой к нам чаще всего приходят клиенты. Вот заказчик, он создает продукты, которые разрабатываются разными командами. Эти команды живут каждая по своим правилам, как шайки пиратов. Но претензий к командам нет — у каждого продукта есть роадмап, разработчики ему следуют, создают какие-то тикеты в джире, что-то делают, выдают результаты. И вроде как все даже работают по Agile: спринты, бэклоги, метрики, но….
Вот продукт доходит до предрелизного состояния. А релизить на прод может только условный Василий, самый опытный (и самый занятой) разработчик. Вот у Васи появляется время, он заходит на сервер ручками, всё выкатывает, обновляет и вдруг… Что-то где-то отваливается, и даже не там, где ждали, но что делать — непонятно. Черный ящик, одним словом. И так каждый релиз.
Парадоксальная ситуация: заказчик говорит, что у него есть Agile, но есть ли он, если каждый релиз превращается в танец с бубном, и проводить его «как можно чаще» (следуя Agile-манифесту) нереально? Да и на стремление к техническому совершенству не похоже.
Такие случаи «лечатся» сменой подхода со стороны разработки и со стороны инфраструктуры. Ну и, конечно, внедрением DevOps. Например, разработка должна вестись только через репозитории, архитектура должна быть микросервисной, а изменения структуры базы данных должны делаться через код, не вручную.
Со стороны инфраструктуры и DevOps необходимо обратиться к технологиям и инструментам контейнеризации (например, Docker), чтобы экономить время и не поднимать каждый раз виртуальные машины. Использовать оркестраторы, такие как Kubernetes, для более гибкого управления контейнерами. Не разворачивать сервера руками, а автоматизировать этот процесс — через подход Infrastructure-as-Code. Разделять окружения на окружение разработки, окружение тестирования, окружение продакшена — это даст возможность быстро реализовывать и тестировать новые фичи и эффективно отлавливать ошибки до выхода в продакшен или быстро откатывать обновление (одной кнопкой), если что-то пошло не так.
Ключевая идея настоящего перехода на Agile — это унификация процессов разработки и деплоя на уровне компании. Для этого нужно автоматизировать процессы и предложить команде универсальные и удобные инструменты. Только после внедрения DevOps можно сказать, что вы работаете по принципам Agile.
Если к концу статьи вы поняли, что ваш Agile не аджайлистый, то не расстраивайтесь. Могу посоветовать статью «С чего начать DevOps?», в ней тема внедрения DevOps описана подробнее.
Или — обращайтесь к нам :) Мы проведем бесплатный аудит вашей IT-инфраструктуры, выявим недостатки. Поможем их устранить либо настроим с нуля простую, удобную и эффективную систему.
Буду рад вашим мыслям в комментариях. До встречи!