Как справиться с техническим долгом в Scrum
Технический долг в Scrum и других гибких подходах негативно влияет на способность команды достигать целей. Чем больше накопленных проблем в коде, тем меньше желания у разработчиков делать рефакторинг.
Рассмотрим, какие этапы в Scrum помогут специалистам оптимизировать работу с техдолгом.
Немного про Scrum
Методика является эвристической. Она построена на постоянном обучении и адаптации к изменчивым факторам. Согласно Scrum, в начале проекта разработчики на 100% не знают, как написать правильный код, но они будут получать знания из опыта. В Scrum заложена та свобода, с которой специалисты могут менять приоритеты в циклах релиза.
В гибком подходе есть 3 артефакта: бэклог продукта, бэклог спринта и инкремент. Но стоит добавить 4-ый — «костыли» в коде.
Воздействие устаревших компонентов и нереализованных функций на проект:
- замедление скорости разработки;
- частые неполадки и ошибки;
- ухудшение качества продукта;
- увеличение затрат на разработку.
Как помочь команде
Независимо от того, являетесь ли вы Scrum-мастером или разработчиком, нужно знать, как управлять техническим долгом. Наши рекомендации:
Осознание проблемы
Объясните команде, что техдолг является препятствием, которое необходимо решить для обеспечения долгосрочной эффективности и устойчивости проекта.
Широкое понимание технического долга
Проведите обучающие сессии и презентации о причинах появления техдолга. Прежде чем делать рефакторинг, разработчики должны знать, какие аспекты проекта могут быть улучшены.
Создание технического бэклога
Невозможно сразу устранить все проблемы техдолга. Вместо этого команда должна создать технический бэклог, в котором будут описаны все недостатки и необходимые улучшения.
Установка приоритетов
Решите, какие задачи или области требуют наиболее срочного вмешательств. Это может включать создание списка задач или использование методик приоритизации, таких как фреймворк RICE. Он учитывает 4 фактора: Reach (охват пользователей), Impact (влияние), Confidence (уверенность в оценке) и Effort (усилия, необходимые для выполнения задачи). Чтобы рассчитать показатель RICE, просто перемножьте показатели охвата, воздействия и уверенности, а затем разделите результат на показатель усилий. Задачи с более высоким рейтингом имеют более высокий приоритет.
Например, команда обдумывает разработку 2 новых фич: A и Б. Фича А может оказать большое влияние на выручку компании (воздействие 9) и охватить большую аудиторию (охват 7), но для этого потребуется много работы (усилие 8), и команда не очень уверена, что у нее хватит компетенций (уверенность 6). Фича Б оказывает умеренное влияние на доход (воздействие 6), охватит лишь небольшую аудиторию (охват 4), но требует меньше ресурсов (усилие 5), и разработчики уверены, что справятся (уверенность 9).
Фича А: (7 х 9 х 6) / 8 = 47,25
Фича Б: (4 х 6 х 9) / 5 = 43,2
По итогу фича А является более важным проектом.
Также для приоритизации можно использовать Матрицу Эйзенхауэра.
Планирование итераций
На спринте составьте план действий, который охватывает все необходимые изменения для устранения техдолга: регулярный аудит и код-ревью, рефакторинг, обновление инструментов, фреймворков и библиотек. Один из способов управления техническим долгом – его постепенное устранение в рамках каждой итерации.
Ретроспектива и улучшение процесса
Выясните, почему возникли проблемы с техническим долгом: нехватка времени, неправильная архитектура, неоптимальный код, отсутствие автоматических тестов и другое. Команда должна совместно предложить способы, чтобы обновить процессы разработки или внедрить новые инструменты и технологии.
Поддержка команды в соответствии с установленными приоритетами
Проводите регулярные обзоры и давайте обратную связь, помогайте команде в преодолении возможных препятствий.
Работа со стейкхолдерами
Поддерживайте открытую и прозрачную коммуникацию с владельцем продукта. Объясните ему проблемы, связанные с техдолгом, убедите его в необходимости установки приоритетов в данной области. Регулярное информирование руководителя о прогрессе поможет ему лучше понять ситуацию и принять соответствующие решения.
«Чтобы приоритезировать задачи, мы используем постановку ограниченного количества целей на спринт и организацию фильтров на доске Jira для выделения задач, включаемых в цели. Также используем груминг бэклога, проводим встречи лида разработки, аналитика и продукт-оунера раз в 2 недели до планирования. Закрываем неактуальные задачи.
Для устранения технического долга мы используем квоты в спринте на задачи. Каждый разработчик может инициировать работу по техдолгу, заведя задачу в бэклог. Лид разработки грумит данные проблемы. Разработчики добавляют описания, чтобы донести ценность для бизнеса, дают верхнюю оценку работам и выносят на обсуждение с продукт-оунером для наполнения квоты спринта по техдолгу».
Как перестать растрачивать время разработчиков
Добавить в спринт дополнительные 10–20% времени разработчиков на возврат техдолга весьма непросто. Лучше всего бороться с «костылями» в коде помогают автоматизированные инструменты.
К примеру, система CodeAche сама находит проблемные места в коде, помогает отследить эффективность работы и достичь баланса между разработкой и бизнесом.
CodeAche имеет единое окно для контроля качества разработки. Это дашборд для руководства, который дает возможность влиять на разработку. Можно закрыть десятки задач в управлении IT-проектами: от контроля эффективности команд до мониторинга качества и сложности кода.
Обзор проекта
Принимайте решения на основании данных анализа, планируйте время на ликвидацию техдолга.
Метрики
Отслеживайте и управляйте направлениями изменения техдолга в проекте.
Трекер задач
Отслеживайте задачи во встроенном таск-трекере. Заводите задачи непосредственно из найденной проблемы и сокращайте время на исправление, создавая задачи по схожим проблемам.
Профили анализа
Управляйте наборами правил для анализа кода и задавайте условия по которым будет проходить проверку.
Пользователи и группы
Управляйте организацией, добавляйте специалистов и создавайте группы пользователей.
Технический долг — это неизбежная часть разработки программного обеспечения. Однако с помощью правильных подходов и практик его воздействие на проект можно минимизировать. Накопленные проблемы в коде, отложенные задачи и другие временные решения могут усугубить проблемы коммуникации и создать разрозненность. Хорошее управление техдолгом абсолютно необходимо для современной Scrum-команды.