Статьи всегда легче читать от лица рассказчика, поэтому давайте так и сделаем.
Привет, Хабр!
Я — Алексей Диянов, технический директор Nedra Digital. Мы — IT в нефтегазовой отрасли. Компании чуть больше трёх лет. Мы быстро выросли как в численности персонала, так и в количестве проектов, но не избежали классических проблем в виде трудностей внутренней коммуникации, регулярного тушения пожаров и принятия управленческих решений на основе субъективного мнения.
Поговорим о наблюдаемости качества разработки. Нужно ли измерять всё, что поддается измерению? И если нужно, то с чего начать, где брать исходные данные и с какими инженерными метриками работать, чтобы повысить управляемость разработки в будущем?
Наш период роста совпал с пандемией SARS-CoV-2. Тогда всем пришлось перейти на удалёнку, и менеджменту IT-производства нужно было понимать, что происходит в командах, но для этого не было подходящих инструментов.
В качестве решения мы внедрили систему сбора и анализа инженерных метрик. Данные собирали из системы контроля версий и трекера задач, затем анализировали и таким образом получали представление о производительности. Потом научились выявлять задержки, проблемные области и оценивать качество кода на потоке.
Давайте разберем наш подход. Как мы искали решение, что измеряли, и что впоследствии перестали измерять. Как собирали статистику, что визуализировали. Почему полезно системно смотреть на процессы разработки в инженерных командах?
Внутри Nedra Digital
В нашем послужном списке более 100 успешно реализованных проектов и 300+ сотрудников. Большая часть — люди, которые делают софт.
Поскольку мы IT в нефтянке, наши решения разбиты по доменам, которые в общей сложности покрывают апстрим нефтегазового сектора:
Разведка: интерпретация данных, построение моделей и полный цикл геологического моделирования.
Геология и разработка: интерпретация данных и построение моделей, формирование оптимальных схем разработки, оптимизация портфеля проектов.
Бурение: инженерное проектирование скважин, полный цикл контроля бурения с предиктивными решениями, оптимизация программы бурения и аналитика КПЭ.
Добыча: центр оперативного мониторинга / интегрированных операций, интегрированное планирование операций и технических режимов, подбор оборудования и управление осложнениями.
Данные: интегрированное хранение и управление геологическими и геолого-промысловыми данными, интеграция данных и контроль качества.
У нас матричная оргструктура с функциональными блоками. А уже из блоков мы подбираем людей на проектные задачи.
Средний размер одной команды — 7-10 человек, а самих команд порядка 25. И в какой-то момент стало сложно отследить климат внутри, синхронизироваться и понять, что происходит в каждой из них. Привычные методы управления не работали, нужна была система, помогающая менеджменту измерять температуру внутри каждой команды, чтобы принимать решения. Мы попробовали собрать такую систему. Сразу договорились делать всё итеративно, чтобы быстро менять то, что не подошло.
Мониторинг и типовые метрики
На рынке управления, мониторинга софта и инфраструктуры есть готовые решения. Основной принцип их работы сводится к тому, что администраторы систем получают информацию об отклонениях поведения системы или процесса не тогда, когда всё упало, и шумят пользователи, а проактивно. Таким образом, есть запас времени, чтобы устранить или снизить критичность возникшей проблемы.
Нам хотелось сделать внутри компании нечто похожее. Посмотрев на рынок и изучив разные подходы, мы не смогли найти что-то, на 100% подходящее под нас, хотя вроде ничего сверхъестественного не требовалось, и пошли пилить свой велосипед.
Обратили внимание на четыре классические метрики DoRa от Google:
Lead time — время, необходимое на реализацию задачи от ее возникновения до поставки в прод.
Deploy frequency — частота развертывания именно в контур, где пользователь может этим всем воспользоваться.
Change fail percentage — процент неуспешных развертываний.
Time to restore — время на восстановление после сбоя.
Согласно подходу, если управлять эффективностью, наблюдая за этими метриками, компания становится более эффективной как на рынке, так и в технологической сфере.
Также отметили подход компании GitLean. Они предлагают собирать исходные данные из Git — коммиты, комментарии, время, и всё, что с этим связано, затем агрегировать по метрикам, строить гипотезы и группировать по трём категориям: дисциплина, прогнозируемость, качество.
Задачи системы мониторинга
Определившись с подходом к работе с метриками, сформулировали цель: системно повышать качество производства. Мы понимали, что если не видим, что происходит в команде или внутри производства, то не можем этим управлять.
Метрики сигнализируют и помогают заранее выявить проблему. Это ни в коем случае не прямой показатель, приводящий к увольнению/поощрению сотрудника, а только дополнительный инструмент для принятия решений. Числа важны только тогда, когда мы знаем, как их использовать, сами по себе они бесполезны.
Разработка системы. Версия 0.1
На первом этапе мы искали способы улучшить качество и скорость работы. Если конкретнее, как повысить объективность оценки команды, уменьшить субъективность, а также автоматически отслеживать соблюдение регламентов работы. Начали с внедрения автоматизированного сбора метрик из систем учета компании, с помощью которого планировали оценивать как в целом команды — эффективность, производительность, — так и результаты отдельных разработчиков.
Для этого автоматически и на регулярной основе измеряли дисциплину, качество и скорость работы команд по целому набору метрик из Git и JIRA (данные по коммитам и тикетам). Полученные показатели сравнивали с ожидаемыми эталонными значениями.
Сбор данных
Прежде чем собирать метрики, нужно было решить две проблемы:
Унифицировать процессы работы, в нашем случае — сделать так, чтобы все команды работали с Jira и Bitbucket.
Научить команды делать единообразные коммиты по SemVer с правильными комментариями. На базе этого родился регламент выпуска релизов.
После этого мы определили порядка 30 ключевых метрик по трём категориям: дисциплина, производительность, качество. На тот момент нам казалось, что 30 метрик — это немного.
Начали собирать данные — выгрузили историю из Git и Jira, завели эталонные показатели для каждой метрики и провели расчёты:
значение конкретной метрики;
сравнение с целевыми эталонными показателями;
рейтинг по каждой метрике;
среднее значение по всем метрикам.
Схематично выглядело так:
Из Jira мы собирали историю по задачам на Python бэкенде, из Bitbucket — историю по коммитам. В Python бэкенде производилась магия по калькуляции значений по метрикам и сохранялась в СУБД. После этого с помощью Grafana на дашбордах отображались необходимые показатели. Проектные команды и руководители различного рода и уровней имели возможность как обратиться к дашборду, так и получать оповещения об отклонениях.
Получилась кастомная разработка в очень простом варианте.
Теперь разберём категории и метрики, которые являются основными для каждой из категорий.
Метрики: дисциплина
Для нас дисциплина — это соблюдение правил работы с Git, code guidelines, «гигиена» работы с учётными системами (с Jira и Git).
Критерии оценки выглядели так:
Для нас хорошо, даже идеально, когда:
Задачи в спринте с оценкой 100%, то есть все задачи оценены в любой момент времени спринта.
Все задачи декомпозированы длительностью не более, чем 2-4 дня.
Наличие «вбросов» новых задач в спринт стремится к 0.
Количество высокоприоритетных задач в спринте не превышает 20%.
Работу с учетными системами мы оценивали так:
Мы оценивали работу по таким критериям:
В каждом коммите должна присутствовать Jira-метка, как основание для изменения кодовой базы. Число таких коммитов должно стремиться к 90%.
Структура веток, формат тегов и структура репозитория также должны совпадать с шаблонами компании.
Объём технического долга в любой момент времени в бэклоге и в бэклоге спринта должен стремиться к 20%.
Мы считали, что это хорошо. Вот как всё выглядело в Grafana:
Это дашборд категории «Дисциплина», на котором приведены метрики работы одной команды и общий кумулятивный показатель. Здесь много показателей и есть описание того, что они обозначают, но на самом деле непонятно, всё ли хорошо с командой.
Метрики: производительность
Производительность — это показатели, влияющие на поставку продукта в срок.
Так выглядят критерии оценки:
При оценке производительности было важно, чтобы:
Частота поставки в прод была не реже одного раза в двухнедельный спринт.
Время на исправление критических issues в проде — не более четырёх часов.
Объём задач, реализованных в спринт, должен превышать 80% из запланированного.
Время проведения code review pull request не должно превышать восемь часов от появления самого кода до его принятия.
Смотрим дашборд, пытаемся определить всё ли хорошо с командой.
Метрики: качество
Третья категория — показатели поставки продукта с достаточным качеством.
Здесь важно:
Сколько возвратов реального функционала, 0 — это идеально.
Как много незакрытых критичных issues в спринте. И сколько их на стороне заказчика.
Сколько зря написанного кода (тот самый churn-код), когда разработчик постоянно меняет один и тот же метод или класс. Чем меньше такого кода, тем лучше и правильнее.
Снова пытаемся определить насколько всё хорошо с командой.
Вроде бы 100%, а значит работа качественная! Но на самом деле правильного ответа дашборды не дают.
Дальше расскажу, какие выводы можно сделать на основе этих данных.
Учимся работать с метриками
Собрав все метрики, нарисовав крутые дашборды, сделав алерты и прочее, мы пошли к руководителям команд, чтобы обсудить подход и услышали много интересного:
У нас и так всё хорошо, зачем вы нам это предлагаете?
Давайте замерим всё подряд, посмотрим, что получилось!
Давайте будем замерять ещё метрики, нам ваши не интересны, нужны свои.
Как «продавали» метрики и что слышали в ответ
Напомню, что на старте было более 30 метрик. Люди вроде бы воодушевились и хотели еще больше, при этом не до конца понимая, что со всем этим делать.
На все эти вопросы мы отвечали целями, которые ставили — не делать метрики ради метрик, а сделать работу эффективней, научившись мониторить показатели результата.
Изучаем итоги исследования
Теперь о промежуточных выводах версии 0.1, которые мы вынесли из исследования статистики по метрикам.
Метрики действительно помогают отслеживать результаты, но важно понимать конечную цель работы с ними. Помимо основного эффекта, мы теперь знаем, как выглядят ситуации, когда:
Разработчик заскучал.
Представьте, что ваш ведущий разработчик месяц не делает коммиты в код — наверное, это плохо. Например, так мы выявили человека, который стал смотреть на рынок, не будучи в отпуске.
Разработчик выгорает.
Противоположная история — помимо рабочего времени разработчик постоянно пишет код, делает коммиты, PR и пр. Человек не может постоянно находиться в таком состоянии. Рано или поздно он выгорит, и это тоже негативный сценарий.
Разработчик «тащер».
Это значит, что разработчик берет на себя больше задач. Возможно, его стоит как-то поощрять, но напомню, у нас среди основных целей не было сделать инструмент, который может поощрять или увольнять. Задачи можно делать хорошо, а можно делать много, без опоры на качество.
Есть неопределённость в целях итерации.
Мы научились понимать, когда в целях итерации есть неопределённость. Когда цель сформулирована, всё хорошо, выполнили 100% от запланированного и на дашборде все зеленое, но на выходе цель не достигаем, хотя сделали все задачи. Увидеть это позволяет агрегация меток.
Задача непонятна или неверно сформулирована.
Когда нет совпадения в формулировке задачи и результате, или запланированное и фактическое время на реализацию сильно расходятся, или происходит постоянно тот самый churn кода, когда разработчик сначала вроде понял, пошёл, сделал, потом ещё раз понял, снова сделал, а потом понял, что понял и сделал снова, и т.д.
Есть BusFactor и риск утраты экспертизы.
Классическая история, когда только один разработчик владеет всей кодовой базой. В случае его внезапной болезни или отпуска, он унесёт с собой всю экспертизу.
В репозитории структура кода не соответствуют DevOps-практикам в компании.
Например, когда команда готова выдать релиз и кажется, что всё сделано и работает на локальных машинах, приходят люди, которые знают, как правильно выставить всё это на стенд (где должны находиться параметры, ключи, сертификаты, Jenkins джобы и пр.), и говорят, что нужно все переделать. И приходится. Так что лучше об этом узнавать заранее.
Тестировщики не заводят баги, потому что договариваются с разработчиками.
Ещё один эффект, который мы заметили. Это плохо потому, что не дает возможности системно работать над багами.
Делаем выводы и меняем тактику
Напомню нашу основную цель: системно повышать качество производства, а не работать ради KPI. Первая версия системы работы с метриками не позволяла достичь цели, но мы узнали много интересного про самих себя.
Например, чем больше метрик мы пытались отслеживать, тем больше сил на работу с ними тратили. По данным из дашборда в Grafana не было понятно, как чувствует себя команда. Приходилось анализировать каждую метрику. Совокупный фактор 66%, к сожалению, ни о чём не говорил.
Эталонные значения и зелёные/красные индикаторы не работали. Мы определили для себя пороговые значения для хорошей оценки. Одна команда может выполнять норматив, а другая в него не укладывается, но выдает результат, который требуется пользователю или заказчику.
Сбор статистики по всем метрикам только косвенно указывает на проблемы, но не показывает картину целиком.
Вывод: работать с метриками нужно системно, с пониманием значений и тенденций.
Разработка системы. Версия 0.2
Итак, мы посмотрели итоги и решили доработать подход во второй итерации. Из тридцати метрик, которые ранее отслеживали, выбрали шесть показателей для измерения температуры команд:
Lead Time — время, необходимое на реализацию истории от ее возникновения до завершения, и оно не должно увеличиваться по консервативному прогнозу.
Cycle Time — время на реализацию задачи в разработке. Если задача находится где-то в анализе, в DevOps, в тестировании, она за границами этого времени.
Velocity или план-факт — сколько команда запланировала реализовать задач, и сколько фактически реализовала.
Количество критических дефектов, выявленных либо у нас в контуре в конвейере, либо в производстве. Оно естественным образом не должно увеличиваться.
Процент неоцененных задач в этапе.
Процент задач в бэклоге, не имеющих привязки к какому-либо этапу.
Два последних параметра нужны нашему проектному офису, чтобы лучше управлять этапами, бэклогом и всем процессом разработки.
Стратегия работы с новым набором метрик
Каждая из шести выбранных метрик может отклоняться от среднего или эталонного значения. Это не математическая модель, а реальная жизнь. Как и в любом процессе, эти показатели тоже подвержены вариативности.
Главная задача как руководителей, так и людей в наших командах разработки — понять, в какой момент нужно что-то предпринять. Например, Velocity может немного снизиться или увеличиться, а через итерацию вернутся в норму. Как не упустить критичный период?
Мы выработали стратегию по работе со значениями метрик:
Строить контрольные карты Шухарта по метрикам для каждой команды.
В них рассчитываются средние значения, верхние и нижние граничные значения на исторических данных той самой метрики.
Наблюдать динамику по командам.
Здесь мы не просто смотрим текущий статистический срез (зеленый, красный), а наблюдаем, что меняется со временем.
Получать структуру вариаций (общие и специальные).
Для специальных причин вариаций, когда по диаграмме Шухарта есть выбросы, формируем гипотезы по причинам возникновения и идем чинить в команды.
Для общих причин — вместе с командами, например, на ретро, системно формируем планы по повышению эффективности и именно системно работаем над улучшением этих показателей.
Как эффект — результаты работы команд, где внедрен подобный подход, поддаются прогнозированию и, что самое важное, системному повышению качества.
Примеры работы со значениями метрик
Приведу пример карт Шухарта для мифических команд X и Y. На графиках 12 итераций, на которых снимались показания одной метрики и выстраивались контрольные карты Шухарта:
Синий график — значение измерения по итерациям.
Голубой — среднее значение.
Красный и зеленый — нижняя и верхняя границы.
Среднее значение и верхняя/нижняя границы высчитывались из статистики по предыдущим итерациям.
Команда X с показателями Lead Time, Velocity и критическими дефектами с точки зрения Деминга, Шухарта и людей, которые этим очень долго занимались, находится в статистически управляемом состоянии. Но лично меня смущает цифра среднего значения критичных дефектов, варьирующаяся в районе 85. Здесь видно, что срочно что-то менять не требуется, но нужна работа в долгую для корректировки процесса. Возможно, что-то не так в самой команде.
Те же самые показатели команды Y имеют выбросы. Часть их значений находятся выше или ниже порогового значения. Это и есть специальные причины вариаций, при появлении которых необходимо принимать какие-то меры для возвращения системы в статистически управляемое состояние.
Выводы
Когда на растущем объеме производства и растущем количестве сотрудников привычные методы управления работают неэффективно. В нашем случае, например, имело смысл обратиться к метрикам и статистике и посмотреть, о чём говорят цифры. С некоторыми оговорками:
Метрики — это дополнительный инструмент управления, их замеры не должны приводить к увольнению или к прямому поощрению. Это не KPI.
Числа становятся полезными только тогда, когда мы понимаем, как их использовать. Возможно, для корректной работы с ними потребуется несколько итераций. Сами по себе числа бесполезны, их нужно смотреть в системе с другими факторами.
Метрики проектной команды должны стать некими маркерами стабильности, сами проектные команды должны уметь с ними работать.
Результаты работы команд, где внедрен подобный подход, поддаются прогнозированию и системному повышению качества.
На старте работы с метриками может возникнуть соблазн выбрать сразу много и замерить всё, что только можно. Не тратьте понапрасну время: сфокусируйтесь на том, что действительно интересно и полезно с точки зрения вашего процесса и ищите способы работать с этим системно.
