Доброго времени, Хабр! Меня зовут Эдвард. В сфере обеспечения качества я с 2012 года. Последние 7 лет работаю в Т-Банке, начинал со старшего специалиста по тестированию бэкэнда и работал в Т-Инвестициях. А сейчас занимаю позицию QA Head управления разработки социальных платформ.
Расскажу о том, как мы формировали подход по работе с техническим долгом, зачатки которого в нашей компании стали появляться еще в 2022. Также, покажу примеры визуализации метрик по техническому долгу в разрезе причин его возникновения и оставлю рекомендации по устранению каждой из причин формирования технического долга.
Проблема и формирование потребности
Начиная с 2018 года бизнес-линия Т-Инвестиций переживала бурный рост, продукт динамично развивался, стремительно увеличивал клиентскую базу и обрастал новой функциональностью.
Между тем под капотом незаметно для нас самих начал формироваться технический долг. Это достаточно опасное явление, которое может привести к серьезной деградации сервисов, особенно когда нет какого-либо контроля и визуализации.
Профессия QA была первопроходцем в работе с техническим долгом. Завершающий этап в нашем жизненном цикле разработки — тестирование, и часто бывало, что QA приходилось жертвовать некоторыми процессами в пользу скорости выпуска бизнесовых задач. Ниже представлен таймналайн развития подхода по работе с техническим долгом.
Мы долго шли к формированию определения, что такое технический долг. В итоге получили следующее утверждение:
Технический долг — это бэклог задач, который формируется из-за пренебрежения качеством разработки в пользу большего количества фич, а еще это следствие отклонения от нормы процессов внутри команды и внеплановых изменений приоритетов бизнеса.
Технический долг на примерах — часть или вид бэклога, который формируется в результате:
Нехватки времени или ресурсов. Пример: бизнес требует срочного выпуска задач, в результате не успеваем покрыть функциональность автотестами.
Отклонения от нормы процессов разработки. Пример: договоренности по процессам в команде нарушаются, выпуск фичи происходит без ранее оговоренной автоматизации или тестов производительности.
Изменения в архитектуре. Пример: переработан дизайн приложения, в связи с чем нужно производить актуализацию тестовой модели.
Устаревания программной и системной архитектуры из-за роста программной базы. Ранее принятые решения начинают конфликтовать с новыми требованиями.
Проблемы планирования, в результате которых, команды могут быть вынуждены жертвовать качеством.
Мы осознавали, что наш технический долг не визуализирован, растет и никак не контролируется. Это было серьезной проблемой, так как количество дефектов ПО начало сильно возрастать.
У нас сформировалась гипотеза о том, что при росте технического долга растет и количество дефектов, но вслепую мы никак не могли определить влияние и точно ли оно есть? Нужны были пруфы.
Гипотеза — чем больше технического долга, тем больше вероятность появления дефектов. Так ли это?
Мы определили специальный тип задачи, чтобы начать визуализировать и контролировать технический долг и добавили к нему поля для разметки причины возникновения технического долга и его типа.
Tech Debt — унифицированный тип задачи в Jira, под которым ведем технический долг.
Tech Debt Causes — поле, в котором заполняем причину возникновения технического долга. Оно содержит причины, с которыми нужно работать командам, чтобы сокращать формирования технического долга.
Tech Debt Type — поле, в котором заполняем тип технического долга. Позволяет провести классификацию технического долга в разрезе профессии. Детализировать конкретный вид работ, которые необходимо выполнить в рамках сжигания технического долга. А также тип показывает наибольшую уязвимость какого-либо из процессов.
Далее на основе своего опыта мы собрали причины, по которым чаще всего формируется технический долг. Каждое из значений таблицы используется в поле со списком для построения метрик.
Tech Debt Causes | Описание |
Изменение приоритетов бизнеса | Бизнес концентрирует техническую команду на выпуске задач, и задачи выпускаются без автоматизации, без необходимых оптимизаций со стороны разработки, без должного описания требований и так далее |
Недостаток ресурсов | Ситуация, когда на проекте в определенный момент отсутствует ресурс сотрудника для какой-либо из ролей (для разработки документации/авто-тестов и так далее). Сотрудник мог заболеть, взять отгул или отпуск, уволиться. |
Недостаточно экспертизы | Не хватает навыков, опыта для проведения нового вида работ. Например, во время разработки бизнес-задачи было недостаточно знаний для применения окончательного решения. Необходимо провести RnD, чтобы понять, как решить проблему. Чаще всего мы выносим такое из бизнес-задач, чтобы не тормозить их. Заводим задачу в техдолг на исследование и внедрение конечного решения. |
Инфраструктура | Ситуация, когда недоступна часть тестового стенда, недостаточно ресурсов железа, нет возможности проверки интеграции, есть проблемы со стабильностью приложений, не удается провести деплой приложения, взаимоблокировки команд и так далее. |
Устаревшее решение | В этот вид причин попадают задачи, когда мы заменяем свое временное решение на постоянное. Чаще всего такая причина формируется в условиях, когда нужно быстро создать продукт и проверить гипотезу. |
Архитектура | К этой причине, относятся задачи технического долга, в результате глобальных изменений на проекте: изменений в архитектуре системы, дизайна приложений, распиливания монолита на микросервисы, переезда на новую функциональную платформу, изменения в цветовых схемах (mobile + web) и тому подобное. Каждое из таких глобальных изменений может значительно увеличить бэклог технического долга, но при этом дает повод задуматься о качестве текущих процессов архитектуры и проектировании более качественных решений. |
Мониторинг | Отсутствие должного уровня логирования приводит к пропуску дефектов, которые могут привести к потенциальной деградации системы. |
Мы собрали ряд возможных типов технического долга, которые становятся следствием той или иной причины. Каждое из этих значений используется в построении метрик и может показать уязвимость соответствующего процесса.
Tech Debt Type | Описание |
QA. Производительность | - Отсутствие ресурсов или навыков проводить тестирование производительности, когда нет описания требований к производительности систем - Отсутствие тестов производительности - Необходимость создания или актуализации профиля производительности |
QA. Инфраструктура | - Расхождение тестового стенда от продакшена при нагрузочном тестировании - Расхождение версий приложений - Необходимость отладить интеграции - Доработки core и back-office - Расширение тестового стенда - Актуализация моков и заглушек - Переезд в K8s |
QA. Рефакторинг | - Массовое изменение автотестов - Добавление новых тестовых библиотек - Изменение структуры проекта - Добавление новых фич от команды SDET - Оптимизация скорости прогона и так далее |
QA. Актуализация авто-теста | Требуется актуализация авто-тестов |
QA. Разработка авто-теста | Требуется разработка авто-тестов |
QA. Разработка тест-кейса | Требуется разработка тест-кейсов |
QA. Актуализация тест-кейса | Требуется актуализация тест-кейсов |
QA. Актуализация тестовой модели | Требуется актуализация проверок в случае, если основная функциональность претерпит значительные изменения |
QA. Документация | Требуется доработка тестовой документации, например тест-стратегии, тест-планов, чек-листов, тест-кейсов. Нужна документация и статьи по использованию инструментов для тестирования, сбора и анализа метрик |
После того как на регулярной основе начали проводить разметку, мы получили первые данные, которые в каком-то смысле стали для нас инсайтами и помогли продвинуться на таймлайне на следующий этап.
Разметка позволила отобразить все то, что было скрыто от наших глаз. Это можно в какой-то степени сравнить с айсбергом, когда на поверхности видно лишь верхушку опасного природного явления.
Пример визуализации метрик при использовании разметки
График динамики дефектов и технического долга — одно из первых подтверждений корреляции объема технического долга и дефектов.
Как анализируем график и на что обращаем внимание:
Оранжевая линия — это размер текущего технического долга QA, на конкретную дату.
Желтая и красная линии — тенденция по дефектам на продакшене и тестовом окружении. Важно отслеживать их тренд.
Если технический долг QA не растет, но при этом количество дефектов возрастает, нужно проанализировать процессы обеспечения качества и выработать план мероприятий shift-left внутри команды.
График подтверждает гипотезу о том, что, чем больше у технического долга, тем больше дефектов. И наоборот, чем меньше техдолга, тем меньше дефектов.
У нас есть внутренняя договоренность со стороны CTO, что 20% времени выделяется на сжигание техдолга для уменьшения количества дефектов и технического совершенствования.
Как анализируем график и на что обращаем внимание:
Бирюзовая линия — количество выпущенных бизнес-задач. График имеет линейный тренд, так как бизнесовые таски — это регулярная активность команд, за счет которой компания повышает качество сервисов и счастье клиента, предоставляет новое бизнес-велью и зарабатывает.
Оранжевая линия — размер текущего технического долга QA на конкретную дату. При выстроенных процессах она будет хорошо показывать тенденцию к снижению количества задач технического долга. Это будет говорить о том, что технический долг снижается, как снижается и количество потенциальных дефектов.
Если на графике виден рост технического долга QA, это повод задуматься о том, чтобы начать перестраивать процессы в команде. Важно фокусироваться на сжигании, чтобы снижать вероятность появления новых дефектов.
Желтая линия — это коэффициент, который показывает отношение количества задач технического долга в открытых статусах, то есть незавершенных, к количеству выпущенных бизнес-задач, по которым был релиз.
Коэффициент показывает, как много генерируется технического долга по отношению к постоянно нарастающей функциональности. Если линия Ratio, которая показывает текущее соотношение закрытых бизнесовых задач к открытым задачам техдолга QA, снижается, это хороший знак. Обратная ситуация будет говорить о том, что нужно улучшать процессы работы команды для устранения технического долга.
Важно отслеживать график по количеству бизнес-задач и стараться выпускать их без формирования техдолга QA. В идеальной картине мира мы должны стремиться, чтобы наш коэффициент был близок к значению 0.
Причины возникновения технического долга
Визуализация причин возникновения технического долга у одной из команд внутри нашего управления.
Как анализируем графики и на что обращаем внимание:
Разбивка помогает ответить на вопрос, по какой из причин чаще всего формируется технический долг QA. В первую очередь нужно концентрироваться и начинать с устранения самых массовых причин возникновения техдолга.
Важно вовремя замечать рост случаев, произошедших по одной причине, относительно других. Может быть так, что, если какая-то из причин возникает значительно чаще других, это означает появление новой процессной проблемы в команде. В таком случае нужно на ближайшем дейли обсудить с командой динамику роста техдолга QA по этой причине, провести приоритизацию и сформировать план по сжиганию.
Периодически нужно пересматривать актуальность и приоритет задач техдолга QA по тем причинам, где количество задач в моменте не столь значительное, чтобы не допускать роста технического долга.
Тип технического долга
Тип технического долга — это следствие определенной причины. Основной смысл в том, чтобы увидеть, какой тип технического долга преобладает, чтобы понять, на чем стоит сконцентрироваться командам.
Как анализируем графики и на что обращаем внимание:
Отслеживаем преобладающий тип технического долга. С точки зрения процессов скопление определенного типа технического долга может подсветить уязвимость данного процесса.
Если какой-то тип технического долга QA начал значительно расти относительно других, необходимо на ближайшем дейли обсудить с командой динамику роста техдолга QA по этому типу, провести приоритизацию и сформировать план по сжиганию.
В примере на графике у команды большая часть техдолга связана с автотестами и инфраструктурой — более 60%. Определенно стоит уделить внимание автоматизации, подключить разработчиков и отдел devOps, чтобы помогли со стабилизацией инфраструктуры или тестовых контуров.
После того как процесс с техдолгом поставили на рельсы в QA, возникла идея масштабировать процесс на профессии DEV и SA.
После анализа возможных причин в профессиях DEV и SA, получилось так, что в большинстве они пересекаются с причинами QA.
Нам необходимо было учесть особенности профессии, чтобы масштабировать процесс и сформировать список с типами техдолга в DEV и SA.
Тип технического долга | Описание |
Dev. Performance | Оптимизация скорости обработки, требуется устойчивость к нагрузке |
Dev. Рефакторинг | Массовое изменение в структуре приложения/проекта |
Dev. Мониторинг и информирование | Логирование, дежурства, алертинг |
Dev. Инфраструктура | Выделение железа, разворачивание приложений, проброс коннектов. |
SA. Документация | Требуется создание/актуализация спецификации, диаграмм бизнес-процессов и так далее |
В типах техдолга DEV и SA есть пересечения со списком QA, но некоторые значения мы все же добавили. Мы подходим к важному этапу: технический долг — ответственность всей команды.
После того как приняли правило, что техдолг общекомандный, мы начали постепенно стирать границы и более тесно взаимодействовать между профессиями.
Например, разработчики могут помогать с автотестами и тестами производительности, а QA-инженеры — брать на себя ответственность за инфраструктуру, разворачивание приложений и мониторинг.
Получился некий next gen нашего процесса, который показывает более высокую вовлеченность каждой профессии в процесс по сжиганию технического долга.
После того как построили график в разрезе профессии, получили новые знания о том, что технический долг DEV может значительно превышать технический долг остальных профессий. За этим важно следить и регулярно приоритизировать, так как это напрямую может повлиять на количество дефектов на продуктиве и в целом на производительность систем.
По наблюдениям, технический долг в системной аналитике не столь значителен. Но уровень технического долга разработки может быть следствием того, что в спецификации допускаются ошибки или недоработки. Получается, что системные аналитики могут влиять на формирование технического долга не напрямую.
График может быть примером для визуализации состояния технического долга отдела или управления.
Чем больше выпускается бизнес-задач, тем больше растет количество ПО и тем важнее иметь контроль над техническим долгом. С каждым месяцем мы видим, что объем технического долга находится в диапазоне от 5 до 15% от общего объема бизнес-задач. Хорошим показателем считается, если объем генерируемого технического долга будет менее 5% или технический долг вовсе не генерируется.
После того как мы успешно внедрили процесс и отобразили картину по состоянию технического долга на уровне управления, соседние бизнес-линии начали переиспользовать наше решение.
Рекомендации по устранению причин возникновения технического долга
В данном разделе, мы пройдемся по каждой из причин, и расскажу варианты и способы работы над ними, чтобы в конечном итоге полностью их устранить.
Причина — изменение приоритетов бизнеса.
Рекомендации:
Принять за правило 20% времени команд выделять под технический долг.
Сформировать аргументацию и выводы для представителей бизнеса на основе собранных данных по техническому долгу. При большом росте техдолга возрастает количество дефектов, и это может в целом влиять на счастье клиента.
Причина — недостаток ресурсов.
Рекомендации:
Принять за правило, что техдолг — это ответственность команды.
Вовлекать в сжигание техдолга членов команды.
T-Shape погружать представителей профессий в специфику работы друг друга. QA-инженерам попробовать разрабатывать код продукта, разработчикам начать больше вовлекаться в качество кода, например при помощи Unit-tests. Аналитикам можно вовлекаться в тестирование, продумывать и помогать с тест-кейсами.
Регулярно приоритизировать, чтобы сжигать наиболее важный техдолг при ограниченном ресурсе команды.
Причина — недостаточно экспертности.
Рекомендации:
Отправлять сотрудников на обучение, внешние конференции, митапы, доклады. Возможно, проблема уже была решена. Это касается всех профессий.
Проводить внутренние исследования.
Разрабатывать внутренние курсы.
Формировать базу знаний/руководства.
Причина — проблемы с инфраструктурой.
Рекомендации:
Организовать инфраструктуру — это важная часть работы любой из ИТ-команд. Нужно активно привлекать devops на уровне отдела или управления, закрепить за собой сотрудника или группу сотрудников, которые обеспечат эту поддержку.
Настроить алертинг тестовых контуров, который позволит отправлять нотификации по текущему состоянию. В случае возникновения проблем стараться сразу их чинить.
Причина — устаревшее решение.
Рекомендации:
Проработать процесс тестирования гипотез для минимизации решений, которые впоследствии будут сняты с эксплуатации.
Искать компромиссы с бизнесом при проектировании новых решений.
Избегать потенциальной работы «в стол».
Причина — глобальное изменение архитектуры или дизайна.
Рекомендации:
Сформировать архитектурный комитет для проработки решений. Каждую бизнес-потребность пропускать через архитекторов для грамотного построения системы.
Формировать внутренние шаблоны и стандарты по дизайну, чтобы отсекать отсутствие единообразного стиля
Ввести разработку ADR, как обязательную практику.
Причина — недостаточный мониторинг.
Рекомендации:
Внедрить дополнительные уровни логирования.
Сформировать дашборд по текущему состоянию систем и интеграций между ними.
Каждая причина имеет свое влияние и следствие. Общая рекомендация в том, чтобы заранее превентивно не допускать возникновения той или иной причины, стараться выявлять их на ранней стадии. Это позволит значительно повысить эффективность работы и качество разрабатываемых продуктов.
Техническая составляющая визуализации метрик по техническому долгу
В данном разделе я хотел бы немного затронуть техническую составляющую визуализации метрик. Вероятно, кто-то из вас, читателей, захочет построить себе подобные графики.
Расскажу верхнеуровнево про текущий вариант визуализации метрик, о которых говорил в статье. Сразу скажу, это далеко не единственное решение, которое можно было организовать внутри нашей компании, да и в целом на рынке достаточно много различных инструментов и возможностей для отображения метрик.
Задачи мы ведем в системе Jira, в том числе задачи и разметку по техническому долгу. В Jira есть возможность строить дашборды и некоторые графики, но функциональность имеет ограничения. В целом для построения чего-либо базового этого будет достаточно, но, если нужно строить отношения, расчеты и прочее, без кода на SQL не обойтись.
Для повышения производительности, стабильности работы, безопасности и централизованного хранения данных настроена ежесуточная репликация базы данных Jira.
Данные из репликации распределяются по внутренним витринам, что позволяет обеспечить быстрый доступ к этим данным, к ключевой информации благодаря их узкой специализации. Это сокращает время обработки запросов, снижает нагрузку на хранилище. Это особенно важно при высокой активности пользователей. Также витрины обеспечивают один источник с достоверной информацией. Все сотрудники пользуются одинаковыми сведениями, хранящимися централизованно в одном месте, без необходимости сопоставлять данные.
Метрики строятся при помощи SQL-запросов, благодаря которым мы формируем данные для визуализации и отображения. Metabase имеет встроенный редактор и возможность визуализировать данные сразу после выполнения запроса.
Metabase подключен и настроен к нашим внутренним витринам данных. В сети есть много видео и различного рода ресурсов, включая официальную документацию по настройке данного инструмента.
Каждый график на дашборде чаще всего представляет собой отдельный атомарный SQL-запрос, разработанный вручную. Далее Metabase позволяет отобразить наборы данных в разном представлении. Это может быть гистограмма, линейный график, пироговая диаграмма и многое другое.
Подводя итоги по технической составляющей визуализации, мы получаем такую связку: Jira + реплика БД Jira + Внутренние витрины + SQL-запросы + Metabase.
Выводы
Технический долг важно визуализировать, осознать его размер на текущий момент, иначе можно случайно «столкнуться с айсбергом».
Технический долг влияет на количество дефектов и, как следствие, на общее качество ПО в целом.
Технический долг — это ответственность команды. Также это позволяет идти в сторону Т-Shape, более тесного взаимодействия профессий между собой.
Рекомендуется выделять 20% времени на сжигание технического долга.
Важно регулярно заниматься приоритизацией и сжиганием технического долга, тогда сервисы будут качественнее.
Расскажите, как контролируется технический долг в вашей компании? Какие причины технического долга выделены и каковы способы их устранения? Какие варианты визуализации используете? Будет очень интересно почитать комментарии.