Технический долг — это работа, которую команда должна сделать в будущем, чтобы сегодня выполнить задачу быстрее. Если говорить проще, то это, действительно, настоящий долг перед системой: в угоду скорости мы делаем работающий вариант, но не тратим время на доведение его до совершенства — откладываем эту работу на будущее.
Технический долг — это нормально, хотя его лучше просто не создавать. Но совершенно избежать технического долга не получится. Его нужно минимизировать и не откладывать на нижние строки бэклога. Кажется, что время исправить код будет когда-то потом, сначала нужно сделать важные функции. Только вот долг имеет свойство накапливаться, а системе приходится за это платить: тогда новые фичи не увидят клиента, потому что команде экстренно придется исправлять старые ошибки, забыв о свободных вечерах и выходных.
В книге 'The Essential Guide to Software Development Team Metrics’ выделяются 7 метрик, которые особенно важны при работе с сокращением технического долга. О них и поговорим.
Новые и закрытые баги
Отслеживайте, сколько открытых и закрытых багов есть у команды. Это помогает определить скорость, с которой команда исправляет ошибки.
Метрика является индикатором общего технического долга и показывает, движется ли команда в правильном направлении с точки зрения общего качества кода.
Процент приоритетных ошибок
Это простая метрика показывает соотношение количества текущих высокоприоритетных ошибок к общему количеству ошибок. Высокий приоритет определяет сама команда: она оценивает степень влияния багов на клиентов или продукт в целом.
Этот показатель помогает отследить и качество продукции, и технический долг. Если приоритетных багов становится больше в общем потоке ошибок, это красный сигнал для команды — нужно проверить критерии готовности историй, пересмотреть наборы тестов и прорабатывать требования лучше.
Ticket churn
Эта метрика показывает, сколько карточек было возвращено из графы "Done" обратно в "In Progress". Это не только возвращенные в данном спринте истории, но и истории на переделку — те, что снова появляются на планировании, хотя команда их уже делала.
Высокий уровень возврата может указывать на увеличение технического долга, а это влияет на скорость работы команды и качество продукта.
Bug burndown
Команды разработчиков и тестировщиков используют burndown-диаграммы для багов, чтобы понять незакрытые ошибки и прогнозировать время исправления на основе средней скорости. Когда команда не следит за сжиганием багов, она рискует потерять контроль над общим качеством кода. Если исправлять ошибки непоследовательно, стараться пофиксить баги быстро и внезапно, это может привести к чрезмерному накоплению технического долга.
Процент покрытия тестами
Это процент всех строк кода, которые проверяются тестами. Эта метрика относится к тому, насколько эффективно организован процесс тестирования при разработке продукта. Как правило, покрытие должно находиться в диапазоне 80-90%.
Покрытие кода не измеряет качество продукта, оно помогает определить проводятся ли действия для достижения качественного продукта.
Если процент покрытия тестами падает со временем, выделите больше ресурсов для разработки через тестирование (TTD). Постоянное тестирование устраняет проблемы с качеством и сокращает технический долг, а это помогает команде стать более гибкой в будущем.
Время отклика приложения
Нужно постоянно отслеживать среднее время, которое необходимо, чтобы страницы проекта были доступны конечным пользователям. Метрика помогает команде определить, когда необходимы важные обновления продукта или инфраструктуры, чтобы решения работали бесперебойно.
Обычно мониторинг проводится командами DevOps. Время отклика имеет решающее значение для успеха продукта. Продукт может быть полезен пользователям, но они начнут искать аналог в другом месте, если до вашей разработки нелегко добраться. Увеличение времени отклика часто предполагает рост технического долга: краткосрочные решения создают долгосрочные проблемы и перегружают систему. Чтобы уменьшить время загрузки, нужно провести немало мероприятий на разных уровнях проекта. Это ещё раз напоминает о том, как важно не забывать о техническом долге.
А каким способом ваша команда борется с техническим долгом?
