Привет, Хабр! Когда-то мы использовали метрику «Вроде бы стало лучше» для оценки качества наших релизов. Но потом мы решили довериться чему-то более надёжному. В этой статье я расскажу о том, как искал гайд по метрикам, не нашёл и создал свой.
Бывает ли у вас такое, что вы делаете вроде бы полезную работу для проекта, но не понимаете, приносит ли это пользу? Вот и мы когда-то писали автотесты, но не могли объективно сказать, стали ли лучше релизы монолита и других сервисов, в которых ведётся активная разработка.
Я посмотрел в интернете и почему-то не нашёл статей или готовых гайдов о том, как выбирать правильные метрики, как их собирать и что с ними дальше делать. Но пока искал информацию, нашёл полезные видео и статьи, которые помогли мне справиться с этой непростой задачей. Ссылки на них будут появляться в статье.
Надеюсь, что эта статья будет полезной для тех, кто задумался об измерении чего угодно на своем проекте, но не знает, с чего начать. В статье содержится личный опыт, информация из статей, видео и платных курсов.
Перед вами чек-лист из 11 шагов, который поможет внедрить всё и не упустить ничего.
Поймите, для чего вы хотите начать измерять что-либо. Измерять просто так, ради измерений, не имеет смысла.
Мы, например, хотели знать, как движемся к целям по качеству, которые поставили себе ранее. Ещё мы хотели видеть динамику показателей после приложенных усилий. Сами по себе цифры текущего состояния ничего не значат. Это просто цифры. Но, наблюдая цифры в динамике, мы можем видеть влияние наших действий.
Вам нужно понять, к чему вы стремитесь. Сократить время тестирования? Сократить количество критичных багов в проде? Повысить тестовое покрытие?
В моём случае с определением целевых показателей проблем не возникло, так как в нашей компании есть цели по качеству. Эти цели и стали основой будущих метрик. Наши цели:
Подумайте, как вы поймёте, что движетесь к целевым показателям.
На этом этапе работы мне помогла статья «Самые важные метрики QA».
Важно! Не берите сразу много метрик. Три-четыре для начала достаточно. Когда процесс наладится, сможете добавить ещё, если это потребуется.
Много метрик сложно менеджерить. Растёт вероятность, что система не взлетит. А если процесс не взлетит с первого раза, то в следующий раз начинать будет сложнее, так как у вас и сотрудников за плечами будет негативный опыт.
Разные показатели можно считать в разных единицах измерения. Сразу нужно выбрать, чтобы у всех метрик была одна единица измерения, иначе можно столкнуться с непониманием и неправильным толкованием.
С этим пунктом у нас возникли проблемы. Время релиза мы считали в часах, включая ночные часы, но за исключением выходных дней. При этом целевое значение было –? релиз за 4 часа. Довольно часто случались ситуации, когда мы создавали ветку release-xxx в 16:00 сегодняшнего дня, а заканчивали в 10:00 следующего дня. В нашей метрике считалось 18 часов, но по факту, активные действия проводились всего 3 часа, если не меньше.
Если бы мы продолжали считать таким образом, то никогда не достигли бы показателя «4 часа» по нашей метрике. Встав перед выбором, увеличить цель до 12 часов или брать в учёт только рабочие часы, мы выбрали второе.
В видео «Простые метрики тестирования на практике» спикер предложил крутой способ анализа метрик на пригодность.? Нужно ?ответить на 9 вопросов по каждой метрике и принять решение.
После такого нехитрого анализа сразу становится ясно, нужна ли вам эта метрика или нет. Появляется более глубокое понимание самой метрики и её ценности для компании и вас.
Покажите выбранные метрики тем, кого они будут затрагивать. Обсудите ограничения, которые вы выяснили на этапе анализа, а также способы их устранения или хотя бы снижения. Особенно важно получить согласие и одобрение тех, кто эти метрики будет собирать и заполнять.
Свои метрики я обсуждал в 3 этапа: с тестировщиками, разработчиками и продакт оунерами. Только после того, как все дали явное согласие, что эти метрики показывают качество системы, я смог перейти к следующему шагу.
Люди не будут вчитываться в таблицы и смотреть динамику самостоятельно. Поэтому вам нужно позаботиться о наглядности.
Я сделал таблицу в Google Sheets, написал формулы и довольный хотел презентовать таблицу коллегам. Наш CTO предложил визуализировать эти метрики. Точнее сделать так, чтобы за 15 секунд было понятно текущее состояние системы: стало ли лучше по сравнению с прошлым спринтом или качество снизилось.
Совместными усилиями мы визуализировали показатели. Потом я попросил людей рассказать, что они увидели на этом графике. Судя по ответам, цели мы добились.
Вот как выглядит визуализация метрики «Качество релизов». Всё наглядно, сразу видно, как сейчас и как было, превышает ли количество проблем количество релизов, стало лучше или хуже по сравнению с предыдущими релизами. В идеальном графике, синяя линия должна стремиться к бесконечности, а красная должна стремиться к 0.
Визуализация отношения «проблемных релизов» к общему количеству релизов
Важно наладить процесс сбора метрик, поработать над периодичностью. Если процесса не будет, то ваш дашборд потеряет актуальность и умрёт. Важно, чтобы были заинтересованные лица, которые будут этим заниматься. Но если вы озаботились этим, значит заинтересованное лицо уже есть.
Какой бы ни был красивый ваш дашборд, люди не будут туда ходить и смотреть на метрики. Один раз все посмотрят, так как это что-то новенькое, но не на постоянной основе.
Нужно смотреть на метрики, на их основании принимать решения. Можно использовать метрики, как дополнительный аргумент в пользу написания дополнительных тестов или фокусировке на техническом долге, а не на бизнес фичах и т.д.
Максимально автоматизируйте сбор метрик. Если вы используете популярные TaskMS и TestMS системы контроля версий, системы CI/CD, скорее всего, у них у всех есть открытое API, с помощью которого можно легко вытаскивать эту информацию. Если не умеете сами, просите помочь разработчиков. Возможно, для этого придется изменить некоторые процессы. Это нормально. И это малая цена за те преимущества, которое вы получите, начав собирать метрики.
Например, у нас есть бот, которой помогает релизменам катить релиз и сокращает их рутинные действия.
Принимать решения, которые повлияют на качество продукта, основываясь на ваших внутренних чувствах – плохая затея. Чувства могут обмануть и подтолкнуть вас к неправильному решению. Поэтому просто заведите метрики и систему оценки качества.
Но помните, что заведение метрик – как заведение питомца. Кроме профита от общения с новым другом, вы получаете определённую ответственность и обязательства перед ним. Поэтому заводите метрики осознанно, с пониманием их необходимости и готовностью к преодолению сложностей, ожидающих вас на пути.
Бывает ли у вас такое, что вы делаете вроде бы полезную работу для проекта, но не понимаете, приносит ли это пользу? Вот и мы когда-то писали автотесты, но не могли объективно сказать, стали ли лучше релизы монолита и других сервисов, в которых ведётся активная разработка.
В поисках метрик
Я посмотрел в интернете и почему-то не нашёл статей или готовых гайдов о том, как выбирать правильные метрики, как их собирать и что с ними дальше делать. Но пока искал информацию, нашёл полезные видео и статьи, которые помогли мне справиться с этой непростой задачей. Ссылки на них будут появляться в статье.
Надеюсь, что эта статья будет полезной для тех, кто задумался об измерении чего угодно на своем проекте, но не знает, с чего начать. В статье содержится личный опыт, информация из статей, видео и платных курсов.
За секунду до создания системы измерения качества
До того, как мы решили создать систему метрик качества, мы уже на постоянной основе измеряли:
Как можно увидеть, измеряли мы только то, что связанно с монолитом. Для остальных сервисов не измеряли ничего.
- Время, потраченное на релиз монолита (с момента создания релизной ветки до мержа этой ветки в мастер).
- Количество откатов релиза монолита на мастер из-за багов.
- Время нахождения в Stop the Line.
- Количество запусков стейдж пайплайна монолита в TeamCity со всеми автотестами, пока он не стал зелёным.
Как можно увидеть, измеряли мы только то, что связанно с монолитом. Для остальных сервисов не измеряли ничего.
Внедряем систему измерения качества за 11 шагов
Перед вами чек-лист из 11 шагов, который поможет внедрить всё и не упустить ничего.
Шаг 1. Определите цель своих измерений
Поймите, для чего вы хотите начать измерять что-либо. Измерять просто так, ради измерений, не имеет смысла.
Мы, например, хотели знать, как движемся к целям по качеству, которые поставили себе ранее. Ещё мы хотели видеть динамику показателей после приложенных усилий. Сами по себе цифры текущего состояния ничего не значат. Это просто цифры. Но, наблюдая цифры в динамике, мы можем видеть влияние наших действий.
Шаг 2. Определите целевые показатели
Вам нужно понять, к чему вы стремитесь. Сократить время тестирования? Сократить количество критичных багов в проде? Повысить тестовое покрытие?
В моём случае с определением целевых показателей проблем не возникло, так как в нашей компании есть цели по качеству. Эти цели и стали основой будущих метрик. Наши цели:
- Релиз монолита занимает не более 4-х часов.
- 0 хотфиксов и откатов в монолите, сайте и мобильных приложениях.
Шаг 3. Определитесь с метриками
Подумайте, как вы поймёте, что движетесь к целевым показателям.
На этом этапе работы мне помогла статья «Самые важные метрики QA».
Для нашей системы я выбрал такие показатели
- Время на релиз. Этот показатель измеряет время (в рабочих часах) между мержом ветки предыдущего релиза в мастер и мержом текущего релиза в мастер.
Это время мы разбили на 4 этапа: подготовка стенда, озеленение стейдж пайплайна, ручное регрессионное тестирование, деплой на прод.
Мы разбили это время на этапы, чтобы детально видеть последствия наших действий и иметь возможность точно определить бутылочное горлышко в нашем процессе.
Этапы метрики «Время на релиз» - Коэффициент «Проблемных релизов» для всех сервисов. Это отношение «проблемных релизов» к общему количеству релизов, всё это умноженное на 100%. «Проблемный релиз»? – ?это релиз, в котором был откат релиза, хотфикс или датафикс.
Отношение проблемных релизов к общему количеству релизов - Плотность хотфиксов на сервис для монолита? –? отношение количества хотфиксов на сервис к общему количеству хотфиксов.
- Время ручного регресса для мобильного приложения. Это время от начала ручного регресса, до его завершения.
Важно! Не берите сразу много метрик. Три-четыре для начала достаточно. Когда процесс наладится, сможете добавить ещё, если это потребуется.
Много метрик сложно менеджерить. Растёт вероятность, что система не взлетит. А если процесс не взлетит с первого раза, то в следующий раз начинать будет сложнее, так как у вас и сотрудников за плечами будет негативный опыт.
Шаг 4. Определитесь с единицами измерения
Разные показатели можно считать в разных единицах измерения. Сразу нужно выбрать, чтобы у всех метрик была одна единица измерения, иначе можно столкнуться с непониманием и неправильным толкованием.
С этим пунктом у нас возникли проблемы. Время релиза мы считали в часах, включая ночные часы, но за исключением выходных дней. При этом целевое значение было –? релиз за 4 часа. Довольно часто случались ситуации, когда мы создавали ветку release-xxx в 16:00 сегодняшнего дня, а заканчивали в 10:00 следующего дня. В нашей метрике считалось 18 часов, но по факту, активные действия проводились всего 3 часа, если не меньше.
Если бы мы продолжали считать таким образом, то никогда не достигли бы показателя «4 часа» по нашей метрике. Встав перед выбором, увеличить цель до 12 часов или брать в учёт только рабочие часы, мы выбрали второе.
Шаг 5. Анализ выбранных метрик на пригодность
В видео «Простые метрики тестирования на практике» спикер предложил крутой способ анализа метрик на пригодность.? Нужно ?ответить на 9 вопросов по каждой метрике и принять решение.
Анализ метрики «Время на релиз» на пригодность
- Цель измерения. Этот показатель должен быть связан с бизнес-целью. Метрика «Время на релиз» связана с бизнес-целью? – ?релиз за 4 часа.
- Для кого эта метрика предназначается. Кто будет смотреть на эту метрику? Продакт оунер, разработчики, менеджеры, тестировщики, скрам-мастера?
На эту метрику «Время на релиз» будет смотреть продакт оунер (потому что ему важно понимать, сколько релизов за спринт мы успеваем выкатить), разработчики (потому что они хотят понимать, когда их код будет на проде) и тестировщики (так как время на тестирование напрямую влияет на эту метрику). - На какой вопрос пользователя отвечает метрика. Сформулируйте вопросы, на которые получаете ответы с помощью этой метрики. Метрика «Время на релиз» отвечает на вопрос «Как часто мы релизимся?»
- Сформулируйте идею метрики и её описание. Кратко, но понятно опишите метрику. Метрику «Время на релиз» я описал так: «Мы хотим релизиться как можно чаще, эта метрика покажет, насколько быстро мы релизимся. Время на релиз?–?это время в рабочих часах с 9:00 до 18:00, без учёта выходных и праздничных дней. Началом релиза считается? создание релизной ветки или мерж предыдущего релиза в мастер, окончанием релиза?считается? вливание релизной ветки в мастер. Разбейте время на отдельные этапы, например: подготовка к релизу, прохождение автотестов, ручное тестирование, выкладка на прод»
- Необходимые условия. Здесь перечислите условия или ограничения для сбора метрик. Кто, когда, откуда будет брать данные для метрик. В моём случае я знаю, где смотреть релизы всех частей. Монолит?–?мерж ветки release-ххх в мастер. Сайт?–?картохи в Kaiten.io на релизной доске. Приложения?–?пока не знаю, но буду выяснять"
- Исходные измерения. Вот с этим пунктом я не разобрался и не знаю, как его описать. Кто понял или знает, о чём тут может идти речь, напишите в комментах.
- Укажите формулу расчёта метрики. Для метрики «Время на релиз»: сколько времени в рабочих часах прошло с момента мержа предыдущего релиза в мастер до мержа текущего релиза в мастер (без учета выходных и праздников). В итоге получаем рабочие часы, которые потратили на релиз.
- Критерии принятия решения. Определите, что вы будете делать, когда увидите изменения этой метрики. Опишите свою реакцию. Мой ответ по метрике «Время на релиз»: «Реагировать на метрику нужно поиском бутылочных горлышек и устранением этих узких мест»
- Периодичность. Как часто будем собирать метрику. Нашу метрику мы собирались чекать еженедельно, но по факту делаем это чаще.
После такого нехитрого анализа сразу становится ясно, нужна ли вам эта метрика или нет. Появляется более глубокое понимание самой метрики и её ценности для компании и вас.
Шаг 6. Согласуйте метрики с заинтересованными лицами
Покажите выбранные метрики тем, кого они будут затрагивать. Обсудите ограничения, которые вы выяснили на этапе анализа, а также способы их устранения или хотя бы снижения. Особенно важно получить согласие и одобрение тех, кто эти метрики будет собирать и заполнять.
Свои метрики я обсуждал в 3 этапа: с тестировщиками, разработчиками и продакт оунерами. Только после того, как все дали явное согласие, что эти метрики показывают качество системы, я смог перейти к следующему шагу.
Шаг 7. Визаулизируйте результаты
Люди не будут вчитываться в таблицы и смотреть динамику самостоятельно. Поэтому вам нужно позаботиться о наглядности.
Я сделал таблицу в Google Sheets, написал формулы и довольный хотел презентовать таблицу коллегам. Наш CTO предложил визуализировать эти метрики. Точнее сделать так, чтобы за 15 секунд было понятно текущее состояние системы: стало ли лучше по сравнению с прошлым спринтом или качество снизилось.
Совместными усилиями мы визуализировали показатели. Потом я попросил людей рассказать, что они увидели на этом графике. Судя по ответам, цели мы добились.
Вот как выглядит визуализация метрики «Качество релизов». Всё наглядно, сразу видно, как сейчас и как было, превышает ли количество проблем количество релизов, стало лучше или хуже по сравнению с предыдущими релизами. В идеальном графике, синяя линия должна стремиться к бесконечности, а красная должна стремиться к 0.
Визуализация отношения «проблемных релизов» к общему количеству релизов
Шаг 8. Соблюдайте периодичность сбора метрик
Важно наладить процесс сбора метрик, поработать над периодичностью. Если процесса не будет, то ваш дашборд потеряет актуальность и умрёт. Важно, чтобы были заинтересованные лица, которые будут этим заниматься. Но если вы озаботились этим, значит заинтересованное лицо уже есть.
Шаг 9. Снова и снова информируйте людей о полученных результатах
Какой бы ни был красивый ваш дашборд, люди не будут туда ходить и смотреть на метрики. Один раз все посмотрят, так как это что-то новенькое, но не на постоянной основе.
Мы решаем эту проблему тремя способами
- Рассказ о метриках на общей части нашего спринт ревью.
- Вывод графиков на монитор в коридоре, который все видят каждый день, чтобы цифры и графики всегда были перед глазами.
- Публикация в Slack краткой сводки из дашборда. Главное, при публикации таких сводок показывать динамику: стало лучше или хуже по сравнению с предыдущим спринтом. А если публиковать это перед командными ретро, то это может подкинуть ребятам тем для обсуждения.
Шаг 10. Анализируйте и принимайте решения
Нужно смотреть на метрики, на их основании принимать решения. Можно использовать метрики, как дополнительный аргумент в пользу написания дополнительных тестов или фокусировке на техническом долге, а не на бизнес фичах и т.д.
Шаг 11. Автоматизируйте
Максимально автоматизируйте сбор метрик. Если вы используете популярные TaskMS и TestMS системы контроля версий, системы CI/CD, скорее всего, у них у всех есть открытое API, с помощью которого можно легко вытаскивать эту информацию. Если не умеете сами, просите помочь разработчиков. Возможно, для этого придется изменить некоторые процессы. Это нормально. И это малая цена за те преимущества, которое вы получите, начав собирать метрики.
Например, у нас есть бот, которой помогает релизменам катить релиз и сокращает их рутинные действия.
Итоги и выводы
Принимать решения, которые повлияют на качество продукта, основываясь на ваших внутренних чувствах – плохая затея. Чувства могут обмануть и подтолкнуть вас к неправильному решению. Поэтому просто заведите метрики и систему оценки качества.
Но помните, что заведение метрик – как заведение питомца. Кроме профита от общения с новым другом, вы получаете определённую ответственность и обязательства перед ним. Поэтому заводите метрики осознанно, с пониманием их необходимости и готовностью к преодолению сложностей, ожидающих вас на пути.
pyrk2142
Я бы добавил чуть ли не нулевой пункт — избегайте «законов льва» (если лев устанавливает законы, то он будет есть всех абсолютно легально). Необходимо очень четко понимать, кем и в чьих интересах создаются метрики и любые способы оценивания.
Условно, если на абстрактный проект наняли тупых или слабых разработчиков, то все метрики, придуманные ими, будут показывать приемлемую динамику или просто будут нормально (или хорошо, зависит от наглости) выглядеть. Если команда, которой заплатили за разработку качественного продукта, постоянно допускает большой технический долг, то будет ли она создавать метрики и методы оценки проблем, которые скажут, что она не справляется? А если от метрик зависит повышение/зарплата/премии? То у всех все хорошо, вот только пришлось тратить миллионы на доработку готового продукта, за который программистам уже заплатили.
e-ivanchenko Автор
Да, вы правы, это важное замечание. Необходимо понимать кто и зачем создает метрики.
Мы создавали метрики не для того, чтобы кого-то наказывать или кому-то показывать что у нас все хорошо. Мы действительно хотим создавать качественный продукт и поэтому решили это качество измерять.
pyrk2142
Это довольно неплохо. Единственное, что я бы добавил, что стоит понимать, кто именно «мы». Это можете быть конкретно вы, часть команды, команда, несколько команд или произвольный набор людей. Приходилось сталкиваться с ситуациями, когда кто-то действительно хочет сделать достойный продукт, вокруг ему поддакивают, но в реальности хотят легкую премию и индексацию зарплаты.
e-ivanchenko Автор
Инициаторами введения метрик во всех продуктах и публичное их отображение были руководители it-направления в компании. Я был полностью за, так как мы некоторые показатели в монолите уже замеряли и следующим шагом логично было бы собирать их не только в монолите, но и в других сервисах тоже.
А начали собирать метрики в монолите тестировщики и разработчики, без чьих-либо указаний, больше года назад.