Хабр, привет! Меня зовут Дима, и я — деливери-менеджер технического отдела «Автомакон». Сегодня хочу рассказать, как мы пересмотрели подход к управлению техническим долгом и чего добились благодаря этому.
Что такое технический долг?
Технический долг — ошибки или неоптимальные решения, которые накапливаются в продукте в процессе разработки. Одни из них практически незаметны, а другие могут серьезно влиять на стабильность и производительность системы. Обычно такие проблемы фиксируются в бэклоге и устраняются по мере возможностей команды.
Мы пошли дальше стандартного определения и включили в понятие технического долга такие аспекты, как:
повышенное потребление ресурсов сервера;
долгое время выполнения процедур;
несоблюдение стандартов разработки, созданные архитектором совместно с командами разработки правила работы в стеке SQL;
доработки для работы под высокой нагрузкой.
В этой статье я расскажу о двух этапах оптимизации работы с техническим долгом, которые помогли нам сделать этот процесс управляемым, эффективным и прозрачным, а также настроить адекватное общение между его участниками.
Этап 1. Оптимизации техдолга: управляемый подход к техдолгу
Наша система функционирует под высокой нагрузкой и имеет множество взаимосвязанных объектов. Для повышения стабильности мы создали рабочую группу, включающую архитектора и менеджера.
Как это работало:
Архитектор анализировал проблемы с точки зрения расширенного определения техдолга, описывал их и предлагал решения, а затем передавал в работу менеджеру для создания задачи на команду разработки.
Менеджер создавал задачи для команды разработки и контролировал выполнение.
Каких результатов удалось добиться:
Критические угрозы стабильности были под контролем.
Однако, накопление бэклога задач стало неконтролируемым.
Чтобы техдолг сгорал быстрее, чем накапливается, мы ввели правило резервирования времени: 30% от месячного времени команд отводилось на задачи технического долга.
Также была внедрена приоритизация по задачам решения техдолга:
Критичный приоритет — ошибка оказывает значительную нагрузку на систему.
Высокий приоритет — ограниченная масштабируемость функциональности системы при планируемом росте нагрузки.
Средний приоритет — проблемы с производительностью, которые могут усугубиться при увеличении нагрузки на сервис.
Низкий приоритет — незначительные архитектурные недоработки.
Этап 2. Оптимизации техдолга: стандартизация и структурирование
Первый этап прошел успешно и дал свои результаты, но выявил две новые проблемы:
Отсутствие стандартизации описания задач.
Неконтролируемый рост бэклога.
Разберем каждую проблему и ее решение подробно.
После первого этапа оптимизации техдолга столкнулись с проблемой отсутствия стандартизации описания задач:
Первичное обращение архитектора требовало уточнений. Заказчик указывал на проблему и конечное решение. Далее в работу вступал менеджер, уточнял требования к выполнению и составлял подробное описание задачи.
Для того, чтобы решить эту проблему, мы создали шаблон для описания задач с четкой структурой — с разделением описания задачи на пункты: с отдельными пунктами для dor, dod, описания проблемы и цели задачи.
Результат нас порадовал — время на доработку задач сократилось, уменьшилось количество встреч для уточнений отдельных пунктов.
Также нам пришлось решить проблему с неконтролируемым ростом бэклога. При анализе архитектор обнаруживал проблему, приоритезировал и давал рекомендации по исправлению. При этом не занимался оценкой задачи в часах и встраиванием в бэклог команды. При таком подходе в бэклоге могла оказаться большая и комплексная задача с высоким приоритетом, выполнение которой в течение двух недель было невозможным.
Чтобы решить эту проблему, в каждой команде выделили ответственного за первичную оценку задач. Ограничение участников ускорило передачу задачи в команду. Создался круг людей, вовлеченных в процесс создания и решения техдолга. Он перестал быть чем-то страшным и непонятным. Началось встраивание задач в процессы команд.
К тому же, задачи технического долга не имели точки принятия обязательств. Они попадали в бэклог команд и должны были сразу поступать в работу. Это справедливо для задач с высоким и критичным приоритетом, но задачи с обычным и ниже приоритетом могли подождать. При этом возникал дополнительный конфликт между заказчиком и командой разработки – участники по-разному оценивали критичность задач. Чтобы избежать подобных споров, организовали регулярные встречи для обсуждения уже существующих задач с командами с предоставлением пруфов критичности в задачах с высоким приоритетом.
Начали тестировать груминг задач для их декомпозиции. Гипотеза подтвердилась — сложные задачи декомпозируются, а непонятные делаются понятнее. Благодаря такому подходу ускорилось прохождение задач через бэклог, снизилось количество конфликтов между командами и заказчиками.
Что дальше?
Оптимизация работы с техдолгом — это непрерывный процесс. Моя конечная цель сделать его масштабируемым на другие процессы и прозрачным для всех участников.
Надеюсь, наш опыт будет вам полезен. Поделитесь своими вариантами решения проблем, связанных с техдолгом.
