Метрики используют для оценки, отражения динамики и выявления слабых мест в процессе разработки. Как их внедрять и применять здесь и сейчас? А если у вас в команде проблемы с процессами, может вам и не до метрик? Раз вы видите проблемы, то, наверное, как-то их оцениваете, измеряете, пусть и условно. Как решаются проблемы и появляются метрики, на примере одного из проектов рассказывает QA-специалист SimbirSoft Виктор.

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

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

Дело было осенью. Шел четвёртый месяц работы над MVP. 

Все команды, забыв о квартальном планировании, трудились над срочным запуском продукта. Я подключился к проекту на этапе вывода MVP. К слову, тот запуск был образцово-показательным. Но не обошлось без потерь: по разным причинам ушли QA-специалист и скрам-мастер. Однако на проекте остались крутые и вовлеченные люди, которые приобрели и сохранили весь пережитый опыт. 

Что мы имели на входе? 

• Высокая нагрузка на поддержку и развитие двух продуктов. 

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

• За время разработки MVP скрам начал превращаться в канбан – не было спринтов и графика релиза. 

Налицо – проблемы с тестированием, которые были не критичны на этапе запуска MVP, но могли сказаться на продукте в дальнейшем. Но известное не значит понятое. Если для QA очевидны проблемы с тестированием и даже их причины, это не значит, что они также понятны для владельца продукта, скрам-мастера и команды. Это мне и предстояло подсветить.

Проблем мало не бывает — первые метрики

В команде проекта сначала было два QA-специалиста. MVP встретил один, ожидая расширения команды. Я подключался на помощь, совмещая еще с одним проектом. Время на передачу дел съел релиз MVP и проблемы с доступами. Задач на проверку было невпроворот. Проблемы накапливались:

• недостаточное время на регресс;

• не оформленная и не актуализированная тестовая документация;

• отсутствие онбординга — медленное погружение в сочетании с предыдущей проблемой;

• недостаточное время на изучение задач.

Для меня, как для QA, причины этого были ясны: не было фича фриза. На ретро я так и сказал: «У нас фича фриз – это не отрезок, а просто точка на планировании, одно название». По идее к его началу все доработки должны быть проверены и оформлены в релиз, то есть пройдены тесты. Но это сложно представить, если задачу на первое тестирование отдают в день старта фича фриза, не говоря уж о тех, которые всё ещё находятся в разработке. Это прямая угроза релизу. 

Вдобавок к этому, с выводом MVP и отсутствием квартального планирования (активность, которая предполагает приоритизацию и план от бизнеса), возник парадокс срочных релизов. На «снежный ком» чрезмерного количества задач и неточных сроков накладывалось желание команды быстрее решить проблемы пользователей. В итоге между релизами возникали промежуточные релизы отдельных доработок. В такой обстановке любая проблема пользователя могла вырасти в хотфикс, даже та, которая появилась не в результате последнего релиза. И это еще не всё... 

• Возможные дефекты, ретест, подготовка к релизу, рефакторинг и риски не учитывались. 

• Командные активности накладывались на регрессионное тестирование. 

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

• На регрессионном тестировании были пропущены сценарии. 

• Не хватало погруженности в продукт. Шутки про тестирование «на коленке» и ad-hoc-тестирование релиза были в тему. Как итог – ошибки на проде. 

• При всех потраченных нервах и релизах «по велению клиента» ни бизнес, ни команда не понимали, когда работа над фичей закончится и пользователь её получит.

Какие уж тут метрики? Кто их будет снимать и зачем? Первое решение – подсветить бизнесу недостаток ресурса для тестирования и потенциально большое число дефектов после вывода MVP. Это было сделано сразу. 

Заручившись поддержкой команды, решил бороться за фича фриз, к которому должны быть успешно проверены задачи релиза. Пришлось разъяснять, что:

• завершённая задача — протестированная задача;

• тестирование — часть процесса разработки;

• если задача не проверена до фича фриза, она не попадает в релиз.

На следующем шаге подсветил руководителю QA-отдела и SEM'у (Systems Engineering Manager) проекта проблемы с планированием, приоритетами и составом релизов. Например, на доске могло висеть около 50 дел, некоторые из них переходили от спринта к спринту. Это осложнялось тем, что постоянно добавлялись задачи с высоким приоритетом, а команда не понимала, сколько задач может успеть. Чтобы наладить процесс разработки, пяти разработчиков, аналитика и QA-команды не хватало.

«Организованная команда может работать и без скрам-мастера», – сказала нам SM перед уходом. — Когда скрам подключится, в вашу команду он добавится в последнюю очередь»

Тем не менее, несколько метрик всё же было:

• дефекты, пропущенные с теста;

• дефекты сборки релиза (конфликты и забытые задачи);

• дефекты регресса;

• исправлено/осталось;

• средняя фактическая вместимость, чтобы ориентироваться при планировании.

• и «вишенка» на проекте, чтобы подбодрить команду, – дни без хотфикса:)

Метрики = воркфлоу

Нас услышали и скрам-мастер пришел в команду. Пару спринтов это была выделенная роль — SEM подключался на командные активности. А затем появился отдельный специалист. В этот период выявили проблемы на уровне команды. Низкая предсказуемость — главная из них. А неверная работа в Jira решалась настройкой и обучением. Другие упоминать не будем, так как часто даже самые критичные вопросы решаются очень просто. Скажем только, что любые ошибки в процессах не дают перейти к более сложным и точным метрикам.

Теперь команда видела свои проблемы и риски, связанные с ними. Всем было очевидно, что страдала поставка ценности. И это должно было быть исправлено. Главным артефактом, вокруг которого была построена работа по отладке процесса, стал график сгорания cпринта или «бёрндаун». В нашей версии — это был «бёрнап», поскольку именно борьбе с «ап» уделялось особое внимание.

Подготовили «общие» правила:

• донести решения до команды, чтобы они были ей приняты – времени на вывод проблем самой командой у нас не было;

• создать дашборд с метриками в Jira:

  • сгорание спринта;

  • статусы инцидентов с прода;

  • число незакрытых дефектов.

• начинать дейли с обсуждения дашборда;

• обсуждение рисков для релиза на дейли позволяет не терять фокус;

• не берём задачи без оценки в спринт после старта, а если очень надо, то берём с оценкой и понимаем, сколько можем не успеть;

• каждый заводит задачи из Miro в Jira, чтобы все оценённые задачи были добавлены до старта спринта;

• фичатоглы обязательны для независимой поставки фичей с зависимостями — всё, что сделала команда, сгорает;

• настройка Jira — например, на доске статусы задач «Готово к публикации» и «Готово» объединить в одну колонку, чтобы стори пойнты сгорали, когда тестирование завершено.

Но это не всё. SEM, скрам мастер, QA lead, аналитик и QA-команда провели серию встреч, чтобы разобраться с менее тривиальными вопросами. Например, как снизить число задач, которые передаются на тестирование и возвращаются на доработку после проверки приоритетного, позитивного сценария. 

Решили:

• Для анализа заводить баг-репорты со специальной меткой. 

• Груминг бэклога и онлайн-планирование проводить с камерами — повышалась вовлеченность всех участников, не получалось отвлекаться. 

• По сложным задачам собирать созвоны с аналитиком для прогона user story. 

• Не брать задачи в тестирование, пока их не посмотрит дизайнер. Эта активность на проекте  была необходима для повышения качества UI\UX и переиспользуемости дизайн-систем на фронте.

Отдельно расскажем про найденное решение по рефакторингу и другим техническим задачам. Ранее их брали в работу во время фича фриза и они не закрывались, стори пойнты не сгорали в спринте, так как QA были заняты проверкой релиза, и перетекали в следующий спринт. Мы стали думать, как посчитать, сколько сделано по факту в конкретном спринте, как планировать следующие. Определили, что задачи, которые могут не завершиться в спринте, нужно добавлять из бэклога, не указывая оценку. Кажется, что это противоречит предыдущим решениям: все оценивать и измерять. Но «не указывать оценку» не конфликтует с «не брать без оценки». Оценка указывается в Jira в тот момент, когда QA понимает, что в данном спринте она закроется. Таким образом:

• Команда фокусируется на целях спринта — задачах с оценкой.

• Разработчики при необходимости добавляют задачу из бэклога и не сидят без дела.

• QA имеют возможность без рисков для бизнесовых задач планировать тестирование технического долга.

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

Метрики без вычислений

Стали регулярно подсчитываться скорость, прогнозируемость и вместимость спринта. На доску заводили договорённости команды, риски, зависимости, цели спринта и цели PI (квартального планирования). Задачи делили на технические и бизнесовые, которые также разделяли на приоритетные и неприоритетные. Последние позволяли добиться менее жесткого планирования, чтобы учесть риски. 

Мы пришли к такому выводу, что иногда самая простая вещь, которую вся команда понимает одинаково, гораздо полезнее, чем цифры и проценты. Например, договоренности, риски и цели, заведенные на доску с задачами. Договоренность, которая находится в «TO DO», цель спринта среди задач, риск, который не сработал и перемещен в «Done», – такие метрики состояния, фокуса спринта не включишь в отчёт, но они помогают отлаживать рабочий процесс.

Ошибки и нерешённые проблемы в процессе

Возможно, ошибок было больше, но сейчас хочу назвать одну. Однажды брошенное по неосторожности «долг по тестированию» применительно к незавершённым задачам так прилипло, что все долги повисли на QA. На практике, конечно, проверять реализацию задачи должен не только QA, но и вся команда. И это нужно было обосновать. Мы обратили внимание, в частности, на нехватку тестового стенда, регулярные проблемы с деплоем и задачи, которые не проходят смоук. Разбор всех проблем был полезен. Но если бы «долг» не давил, то наш путь к метрикам был бы легче.

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

Итог

Наш путь к метрикам занял 5 спринтов. Но результаты стоили этого:

• Стали известны вместимость, скорость, прогнозируемость.

• Мы шестой с момента введения метрик спринт отработали со 100% закрытых задач и 97,5% в следующем — там сработал известный риск, зависимость от другой команды.

• Команда поставила цель сохранить прогнозируемость на уровне 90% при положительной динамике в скорости.

• Стали подниматься вопросы о ценности и обратной связи от пользователей.

• Команда оказалась самой готовой к внедрению time-to-market. 

• Была поставлена цель подготовить регрессионные тест-кейсы к автоматизации, а ранее речь могла идти только об актуализации и ведении тестовой документации.

Этот путь научил команду тому, что:

• Метрики отражают проблемы, по ним оценивают рост эффективности. 

• При этом они тесно связаны с воркфлоу. 

• Сложность метрик растёт вместе с командой,

• А начинается весь путь с малого – с проактивной позиции QA, специалиста по обеспечению качества.

С выводом MVP, который сделали за два месяца, проект не остановился, продукт продолжили развивать. Были решены многие проблемы, накопившиеся за время работы со сжатыми сроками. Проделанная работа над ошибками позволила команде шагнуть в сторону оптимизации и эффективности.  Эта работа заняла почти полгода. Немалый срок. Но всё относительно. Главное – на этом не останавливаться, поскольку впереди time-to-market.

А вам приходилось выстраивать метрики на проектах? Будем рады, если вы поделитесь своим опытом в комментариях

Больше кейсов и полезных материалов для владельцев продуктов - в нашем ВК и Telegram.

Познакомиться с нашими проектами поближе можно здесь.