Все статьи
Как считать инженерные и DevOps-практики в деньгах и метриках
Дата: 30.05.2022
В 2021 начался новый тренд в Agile — применение технических практик. Выровняв процессы и починив продуктовую часть, компании занялись частью технической. Команды вдруг массово захотели внедрить все, что только можно из SAFe, XP и LeSS. Непонятно только, сколько это действительно стоит, что это действительно даст в измеримых цифрах и что действительно поменяется, кроме мифического «качества», которое «стало лучше».
Доклад на конференции Enterprise Agile Russia 2021 29 ноября 2021 года.
Добрый день! Меня зовут Андрей Булов, я из компании Quantori. В профессиональном IT я более 16 лет. Все 16 лет я разрабатываю, проектирую и занимаюсь DevOps. И примерно десять лет назад, сходив на доклад Асхата (прим. ред. — Асхат Уразбаев, основатель компании ScrumTrek), я решил заняться менеджментом, Agile. И 10 лет занимаюсь поставкой и дорос до Delivery-менеджера. И такой биполярный дуэт помогает договариваться моему менеджеру с технарем, и на стыке рождаются интересные вещи.Добрый день! Меня зовут Андрей Булов, я из компании Quantori. В профессиональном IT я более 16 лет. Все 16 лет я разрабатываю, проектирую и занимаюсь DevOps. И примерно десять лет назад, сходив на доклад Асхата (прим. ред. — Асхат Уразбаев, основатель компании ScrumTrek), я решил заняться менеджментом, Agile. И 10 лет занимаюсь поставкой и дорос до Delivery-менеджера. И такой биполярный дуэт помогает договариваться моему менеджеру с технарем, и на стыке рождаются интересные вещи.
О чем я буду говорить? Мы много раз слышали про операционный поток, про то, как бизнес доставляет ценность конечному потребителю, получает за это деньги. Однако, этот поток зависит от Development Value Stream — от потока разработки. Если ваш бизнес зависит от IT, то ускорения поставки ценности вам нужно будет его оптимизировать или хотя бы понимать, что там все хорошо и не становится хуже.
Поток разработки не отличается от подобных — там есть Process Time, Lead Time и всякие другие знакомые метрики. Но тем не менее, он специфичен. Там есть специфика под названием «Девелоперские практики», или «Практики разработки», или «DevOps-практики». Считается, что их использование может существенно ускорить поток и улучшить качество. Но, я считаю, что эти практики не всегда так. Если мы бездумно используем все возможные практики и не считаем их, то мы обязательно получим увеличение стоимости разработки и снижение скорости поставки ценности.
Проблемы потока разработки
Основные причины, почему кто-то хочет вмешаться в поток разработки — это низкий Lead Time или плохое качество. Глобально, корневых причин тоже две:
- поток неправильно построен изначально;
- поток неправильно оптимизируется.
Что значит неправильно поставленный поток? Когда вы начинаете разработку чего-то, вы просто собираете группу технарей, и они как-то начинают работать. Они приносят к вам все свои детские энтерпрайзные травмы, стартапные идеи, личные наработки. Из всего этого получается какой-то свой особый поток и процесс. Либо же процесс просто наследуется от организации: было в каком-то соседнем проекте, это будет работать. К сожалению, такой старт ведет к проблемам. Если не выявлять бизнес-требования и ограничения для девелоперского потока, то получается некий усредненный набор практик, которые непонятно зачем нужны и часто вредят, чем приносят пользу конкретно этому бизнесу в этом контексте. Самое забавное, что мы пытаемся это наладить через взаимодействие внутри команды — «давайте соберемся, ретроспективу сделаем».
Вторая проблема – это неправильная оптимизация потока. Например, бизнес спускает проблему в команду — «У нас все медленно. У нас плохое качество!». Команда собирается на ретроспективу, сидит, думает. Вдруг, кто-то сам умный говорит: «А давайте попробуем Code Review! Я на прошлой работе пробовал, и у нас это заработало!». Команда соглашается: «Ладно, вроде, умный парень, давайте попробуем». В этом случае возможны три исхода:
- Практика покрывает корневую причину, становится лучше.
- Практике не решает глобальную проблему, но субъективно становится немного лучше.
- Практика не работает и команда ее выбрасывает на ближайшем ретро.
Но только мало кто считает это «стало лучше» и почти никто не считает, где и что «стало хуже».
Техническая гипотеза
Я считаю, что введение любой практики разработки или DevOps ничем не должно отличаться от бизнесового эксперимента. По сути, если вы хотите ввести какую-то практику, вы должны прописать гипотезу, по которой вы измерите результат введения этой практики и посчитаете, сколько это будет стоить. Если вы считаете сквозь свой операционный поток, и он обмазан всеми метриками, то почему то же самое не должно применяться к потоку разработки?
Как же создать техническую гипотезу?
Для начала нам нужен сам поток, контекст и цели бизнеса. Применение любой практики разработки или DevOps без выявления текущего потока и контекста – это просто ткнуть пальцем в небо.
Выявление потока и измерение метрик
Выявление текущего потока разработки можно сделать с помощью Kanban/SAFe практик. После построения потока, необходимо определить и снять его метрики. Для начала нам хватит Process Time и Lead Time. Уже с ними можно будет проводить эксперименты. Однако, я считаю, что хороший поток разработки должен измеряться так называемый DevOps-метриками, которые выбраны исходя из целей бизнеса и решаемой проблемы. Например, если бизнесу нужно как можно быстрее поставлять ценность конечному пользователю (на продуктивное окружение), то правильными будут вот такие метрики:
Теперь, когда мы определились с метриками, давайте посмотрим практики.
Например, есть такие практики как Code review и TDD (прим. ред. — Test-Driven Development — разработка через тестирование). Они, влияют на одну и ту же метрику, но находятся на разных этапах потока поставки ценности и решают совершенно разные проблемы. Но хорошо, а если собрать все эти практики, например, BDD, TDD, тест-автоматизацию, code review — станет ли от этого меньше багов и улучшится ли метрика? Далеко не факт. А вот время поставки ценности и затраты на разработку точно вырастут.
Пример №1
У нас есть команда разработки. Это хорошая Scrum-команда, хорошие технари, работают на внутреннем проекте для бэк-офиса. У них очень неплохой поток, однако, одна из трех поставок стабильно подает. И это не нравится бизнесу. Это не нравится бэк-офису и так далее.
Какой сюда подорожник мы можем приложить? Классическое решение — сделать дополнительную фазу тестирования или покрыть все автотестами». Поможет ли это? Скорее всего да, но это будет дорого стоить на первоначальном этапе и точно сделает поток медленней из-за необходимости их поддержания.
Поговорив с командой, выясняем, что они работают в одной кодовой базе, в одном окружении, и они постоянно задевают код друг друга. Поэтому делаем более дешевую гипотезу. Допустим, мы считаем, что мы вводим такую штуку, как Code Review. И мы считаем, что в текущем потоке команда работает хорошо, и введение Code Review поможет им смотреть на код и не нарушать функционал друг друга. Это даст нам уменьшение времени простоев. И мы стремимся за четыре спринта достигнуть таких показателей.
Мы считаем, что это увеличит наш Process Time и Lead Time на четыре часа. То есть наша команда каждую фичу будет делать в среднем на восемь часов дольше. По стоимости это разовый тренинг. И самое главное — ваша стоимость разработки вырастает на восемь часов. То есть средняя стоимость сотрудника, помноженная на эти восемь часов.
Перекроет ли это удорожание постоянные падения релизов?
Пример №2
Более сложный пример, более провокативный. Есть поток поставки ценности – это legacy-приложение, которое вполне себе работает, оно как-то поставляется. Но есть проблема в частоте поставки. Это происходит только раз в месяц. Бизнес это, вроде как, не устраивает, потому что все ускоряется, идет вперед. И как вы помните наша основная метрика – это Time-to-Market и это Lead Time.
Что происходит дальше? Дальше мы думаем над гипотезой. Как увеличить частоту поставки? Конечно, внедрить CI/CD. Но в чем проблема? Когда мы внедряем CI/CD и говорим технарям: «Да, давайте внедрять», — однако, никто не думает про стоимость и про уменьшение Capacity команды, которая из этого следует. А нам надо это прописать в гипотезе. Поэтому мы прописываем выгоду бизнеса от увеличения скорости и уменьшения времени обучения на наших фичах на рынке.
И наша ключевая метрика очень хорошая и, вроде бы, влияние на поток хорошее, но посмотрите, сколько это реально стоит. Помимо того, что нам нужно вместе платить за GitLab, за конвейер CI/CD, также нам нужно оторвать команду на кучу времени. Эатот объем работы нельзя спрятать где-то в разработке, как это обычно просят владельцы продукта. Это работа, которую нужно делать и она явно замедлит поток поставки, создаст разовые и постоянные затраты. Плюс недополученная прибыль от фич, которые не будут сделаны.
Стоят ли эти затраты уменьшения Lead Time? И через сколько они окупятся?
Так что если вы вводите практики бездумно и отдаете это на откуп в команду, то в лучшем случае у вас просто вырастет стоимость разработки, и ничего не произойдет, а в худшем — это будут общие муки и большие расходы.
Поэтому используйте практики правильно и прикладывайте к этому голову, оптимизируйте свой поток.
Видео и слайды
