Автор статьи: Дмитрий Курдюмов

Участвовал в Аджайл-трансформациях в крупнейших компаниях в России (Альфа банк, МТС, Х5 retail group), с международным опытом в стартапе зарубежом.

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

Но что именно представляют собой инженерные метрики и как они могут помочь вам и вашей команде?

В этой статье я постараюсь ответить на эти вопросы:

? Что такое инженерные метрики и какова их цель

? Как они связаны с продуктивностью

? Как извлечь из них максимальную пользу

Понимание инженерных метрик

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

Что такое инженерные метрики

В более широком смысле инженерные метрики - это количественные показатели, которые предоставляют информацию о различных аспектах процесса разработки.

Они могут охватывать широкий спектр областей, таких как:

? Качество: метрики, такие как количество ошибок, покрытие тестами и дефекты, ушедшие в продакшен.

? Эффективность: метрики, такие как скорость, время выполнения (Lead time) и время цикла (Cycle time).

? Операционная эффективность: метрики, связанные с развертыванием, такие как частота развертывания или время от коммита до развертывания.

? Сотрудничество и динамика команды: информация из времени отклика на код-ревью или количества комментариев на pull request.

? Надежность: показатели, такие как среднее время восстановления (MTTR) или процент отказов.

?️ Техническое здоровье: метрики, связанные с техническим долгом и поддерживаемостью кода.

⚡ Производительность: показатели, такие как время отклика, простои серверов и задержка.

? Опыт разработчиков: метрики, такие как DevEx и опросы удовлетворенности разработчиков.

Цель инженерных метрик

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

Вот более детальный взгляд на их основные задачи:

• Понимание производительности: помогают командам и менеджерам понять, насколько хорошо работает процесс разработки.

• Улучшение со временем: отслеживая тенденции, команды могут выявлять области, требующие улучшения и принимать меры.

• Поддержка принятия решений: метрики предоставляют данные для обоснованного принятия решений, таких как распределение ресурсов на исправление дефектов кода.

• Согласование с бизнес-целями: метрики обеспечивают, чтобы усилия по разработке способствовали достижению более широких бизнес-целей.

• Установка и отслеживание целей: команды могут устанавливать конкретные цели и измерять прогресс в их достижении с помощью метрик.

• Коммуникация прогресса: метрики предоставляют общий язык для отчетности о состоянии проекта перед заинтересованными сторонами.

• Повышение морального духа: наблюдение за улучшениями в метриках может мотивировать и повышать моральный дух команды.

• Оптимизация ресурсов: метрики помогают эффективно распределять ресурсы, уделяя внимание областям, требующим большего внимания.

• Обеспечение качества: метрики, связанные с качеством кода и тестированием, обеспечивают соответствие программного обеспечения высоким стандартам.

Наряду с этими целями, инженерные метрики на протяжении многих лет выполняли еще одну задачу: попытку измерения производительности.

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

История метрик

SLOC (начало 50-х годов)

Все началось с метрики "Source Lines of Code" (SLOC). Она была введена, когда такие языки программирования, как FORTRAN и ASM, были популярны. Эти языки были ориентированы на строки и использовали перфокарты, где одна карта равнялась одной строке кода. Это облегчало подсчет и служило видимой мерой продуктивности программиста.

Velocity (начало 90-х годов)

В начале 90-х годов начало развиваться движение Agile, и вместе с ним появились первые Agile-фреймворки. Scrum, вероятно, самый известный Agile-фреймворк, включил Velocity как метрику для измерения объема работы, которую команда разработки может выполнить за определенный промежуток времени, обычно в течение спринта. Velocity часто выражается в story points, что является относительной мерой усилий, необходимых для выполнения задачи.

Cycle Time (конец 90-х годов)

В разработке программного обеспечения время цикла (Cycle Time) обычно относится к времени, необходимому команде разработки для завершения одной итерации или цикла работы от начала до конца.

Velocity vs Cycle Time

Хотя Cycle Time может показаться похожим на Velocity, он предоставляет информацию о скорости выполнения задач/функций, в то время как Velocity измеряет общую производительность команды за фиксированный промежуток времени.

DORA (2014-2022)

DORA (DevOps Research and Assessment), авторы которой - Николь Форсгрен, Джез Хамбл и Джин Ким, включает набор ключевых метрик, известных как "Четыре ключевые метрики". Эти метрики помогают организациям оценивать и количественно измерять эффективность их DevOps-практик, и были разработаны на основе обширных исследований в области DevOps и доставки программного обеспечения.

Четыре ключевые метрики включают:

1. Время выполнения изменений (Lead Time for Changes):

   • Что это такое: измеряет, сколько времени требуется для преобразования идеи или запроса в рабочую функцию в системе.

   • Почему это важно: короткое время выполнения означает более быстрые отклики на потребности клиентов и рыночные запросы.

2. Частота развертывания (Deployment Frequency):

   • Что это такое: отслеживает, как часто в систему добавляются новые изменения кода или функции.

   • Почему это важно: высокая частота развертывания показывает способность быстро и надежно выпускать изменения.

3. Процент отказов (Change Failure Rate):

   • Что это такое: вычисляет процент изменений кода, которые вызывают проблемы или должны быть отменены.

   • Почему это важно: низкий процент отказов означает качественное тестирование и меньший риск проблем для клиентов.

4. Среднее время восстановления (MTTR):

   • Что это такое: измеряет, как быстро команда может исправить и восстановить работу после неожиданных проблем.

   • Почему это важно: низкое среднее время восстановления показывает эффективную реакцию на инциденты и меньший ущерб для клиентов.

На основе их исследований, высокоэффективные организации обычно демонстрируют более короткое время выполнения, более высокую частоту развертываний, более низкий процент отказов и более короткое среднее время восстановления.

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

В 2018 году DORA была приобретена Google, и их исследования продолжаются, при этом ежегодно публикуются новые данные.

SPACE (2021)

В то время как DORA предоставляла эмпирический способ измерения продуктивности инженерной деятельности между организациями, в 2021 году те же авторы опубликовали фреймворк SPACE, с целью дать более целостное представление о продуктивности инженерной деятельности.

SPACE предоставляет 5 измерений метрик:

1. Удовлетворенность (Satisfaction): Отражает ощущения разработчиков по поводу нагрузки на код-ревью и возможностей для обучения.

2. Производительность (Performance): Измеряет скорость ревью как на индивидуальном уровне, так и на уровне команды, с учетом политики команды.

3. Активность (Activity): Считает общее количество код-ревью, завершенных индивидуально за установленный период времени.

4. Коммуникация и сотрудничество (Communication and collaboration): Оценивает глубину и качество ревью как меру взаимодействия команды.

5. Эффективность и поток (Efficiency and flow): Оценивает влияние времени ревью на рабочий процесс и пропускную способность системы, балансируя прерывания и общую скорость доставки.

DevEx (2023)

Недавно (в апреле 2023 года) некоторые из авторов DORA и SPACE выпустили еще одну интересную работу, представляющую так называемый фреймворк DevEx.

В то время как DORA стремилась предоставить эмпирический способ измерения производительности, и, следовательно, продуктивности команды разработчиков, а SPACE сделать его более всеобъемлющим, DevEx каким-то образом признает, что измерение продуктивности - это нелегкая задача.

Как следует из названия, DevEx фокусируется на опыте разработчиков и изучает три измерения, влияющих на него.

1. Петли обратной связи (Feedback loops): Петли обратной связи важны для эффективной разработки, так как они определяют, как быстро и эффективно следуют ответы на действия. Быстрые петли обратной связи необходимы для плавных рабочих процессов, в то время как медленные могут вызывать сбои и задержки. Организации должны работать над сокращением петель обратной связи, оптимизируя инструменты и процессы.

2. Когнитивная нагрузка (Cognitive load): Когнитивная нагрузка относится к умственным усилиям, необходимым разработчикам для выполнения задач. Высокая когнитивная нагрузка, часто вызванная плохо документированным кодом или сложными системами, может замедлить работу разработчиков и увеличить риск ошибок. Для улучшения опыта разработчиков команды должны снижать ненужные препятствия.

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

Фреймворк DevEx также предоставляет идеи о том, что измерять и как это измерять.

Как взять максимум от инженерных метрик?

Как мы уже поняли, мир инженерных метрик может быть довольно сложным, особенно когда дело касается измерения таких вещей, как продуктивность.

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

Несколько советов по тому как лучше использовать метрики: 

? Оставайтесь на уровне системных метрик: некоторые метрики, такие как время простоя, время отклика, задержка, легко понять и они справедливы. Каждому инженеру нравятся эти метрики, потому что они понятны и все с ними согласны. Вы можете их сравнивать, не вызывая проблем.

? Командные метрики лучше, чем индивидуальные: когда дело касается измерения продуктивности вашей команды, лучше смотреть на то, как работает вся команда, а не отдельные люди.

? Не используйте метрики для обвинений: метрики предназначены для помощи, а не для создания конфликтов. Вместо того чтобы использовать их для доказательства чьей-то неправоты, используйте их для поиска способов улучшения. Это инструменты для улучшения, а не для обвинений.

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

? Обучайте свою команду: убедитесь, что ваша команда понимает, почему вы используете метрики и как они могут способствовать их улучшению. Все должны быть на одной волне относительно того, почему метрики важны и как они могут помочь команде добиться успеха.

? Держите все просто: не теряйтесь в море метрик. Сосредоточьтесь на нескольких ключевых метриках, которые имеют наибольшее значение для успеха вашей команды. Слишком много метрик могут стать запутанными и подавляющими.

В заключение, помните, что метрики - это не всё.

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

Используйте своё чутьё и прислушивайтесь к тому, что говорит ваша команда.

Если понравилась статья, переходите в мой телеграм канал.

Также всем, кто начинает свой путь в роли технического директора, рекомендую бесплатное мероприятие «Stand UP CTO. Открытый микрофон. 3 спикера курса». На этом открытом уроке разберём:

• на чем спотыкаются все новички в должности: bus factors, костыли предшественников;

• как не разорваться среди задач, которые нужны здесь и вчера;

• типичные ошибки и как точно не надо делать;

• уроки, которые мы выносим из своих ошибок.

Записаться на урок можно на странице курса «Технический директор».