Как начать DevOps-трансформацию

Наш эксперт, Андрей Александров, рассказал про опыт проведения DevOps-трансформаций на конференции по управлению проектами и предпринимательству Whale Rider 2018, которая проходила в 2018 году в Москве и затрагивала темы, связанные с построением команд, бизнес-процессов, управление разработкой, стратегией, финансами и инвестициями.

В докладе рассмотрены:

1. DevOps как набор практик, которые помогают сокращать время выхода на рынок (Time to Market) и повышать стабильность продуктов. DevOps был представлен не как набор инструментов, а как прикладной подход к снижению количества сбоев в продакшене, уменьшению страха инженеров перед изменениями и ускорению проведения бизнес-экспериментов. Также подчеркивалось, что DevOps можно рассматривать шире — как способ системно находить и устранять ограничения в процессе производства программного обеспечения, даже если отдельные практики по тем или иным причинам не подходят организации;
2. План действий для трансформации: выбрать продукт или сервис, с которого начинается работа, определить всех владельцев и участников, имеющих отношение к этому сервису, построить совместно Value Stream Map, создать временную экспертную команду (Enabling team), устранить выявленные ограничения и рассказать о полученных результатах. Отмечалось, что этот процесс является цикличным и может последовательно применяться к разным сервисам и процессам по мере масштабирования трансформации внутри компании;
3. Проведение Value Stream Mapping с целью визуализации всех этапов разработки — от появления идеи до доставки ценности конечному пользователю. Подчеркивалось, что карта должна строиться коллективно с участием представителей разных ролей и подразделений, так как только совместная работа позволяет получить полную и достоверную картину происходящего, выявить реальные задержки, очереди, ручные операции и точки принятия решений;
4. Метрики VSM: Lead Time (длительность ожидания и прохождения этапов), Value Added Time (время полезной работы), %C/A (процент принятой и корректной работы). Делался акцент на том, что для старта трансформации достаточно этого минимального набора метрик, так как именно они позволяют объективно зафиксировать текущее состояние процесса и измерять эффект от вносимых изменений;
5. Примеры создания текущего (AS-IS) и желаемого (TO-BE) Value Stream Map, которые используются для выбора конкретного ограничения, с которого имеет смысл начинать изменения. Подчеркивалось, что целевое состояние должно формироваться на основе измерений и реалистичных целей, а не абстрактных ожиданий или лучших практик без учета контекста компании;
6. Создание временной экспертной Enabling команды с целью обхода ограничений текущих процессов без остановки основной разработки продукта. В докладе подробно рассматривались состав и принципы работы такой команды: кросс-функциональный набор участников, отдельные правила работы, отказ от существующей бюрократии и KPI, фокус исключительно на устранении выбранного ограничения. Отдельно отмечалась роль привлечения внешних экспертов при работе со сложными или legacy сервисами;
7. Примеры найденных проблем и решаемых задач на основе реальных измерений: сокращение Lead Time тестирования с 4 дней до 1 часа, сокращение Value Added Time тестирования с 2 дней до 3 часов, сокращение Lead Time деплоя с 5 часов до 10 минут за счет изменения процессов и автоматизации доставки изменений.

Подробнее в презентации записи выступления:

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

Не забывайте подписываться на наш канал Enabling.team Insights, чтобы оставаться в курсе технологических трендов.