Технический долг в Scrum и других гибких подходах негативно влияет на способность команды достичь целей. Чем больше накопленных проблем в коде, тем меньше желания у разработчиков делать рефакторинг.
Рассмотрим, какие этапы в Scrum помогут специалистам оптимизировать работу с техдолгом.
Немного про Scrum
Методика является эвристической. Она построена на постоянном обучении и адаптации к изменчивым факторам. Согласно Scrum, в начале проекта разработчики на 100% не знают, как написать правильный код, но они будут получать знания из опыта. В структуре Scrum заложена та свобода, с которой специалисты могут менять приоритеты в циклах релиза.
В гибком подходе есть 3 артефакта: бэклог продукта, бэклог спринта и инкремент. Но стоит добавить 4-ый — «костыли» в коде.
Воздействие устаревших компонентов и нереализованных функций на проект:
- замедление скорости разработки;
- частые неполадки и ошибки;
- ухудшение качества продукта;
- увеличение затрат на разработку.
Как помочь команде
Независимо от того, являетесь ли вы Scrum-мастером или разработчиком, нужно знать, как управлять техническим долгом. Наши рекомендации:
Осознание проблемы
Объясните команде, что техдолг является препятствием, которое необходимо решить для обеспечения долгосрочной эффективности и устойчивости проекта.
Широкое понимание технического долга
Проведите обучающие сессии и презентации о причинах появления техдолга. Прежде чем делать рефакторинг, разработчики должны знать, какие аспекты проекта могут быть улучшены.
6 критериев, по которым можно выявить технический долг, мы рассказали в прошлой статье.
Создание технического бэклога
Невозможно сразу устранить все проблемы технического долга. Вместо этого команда должна создать технический бэклог, в котором будут описаны все недостатки и необходимые улучшения.
Установка приоритетов
Решите, какие задачи или области требуют наиболее срочного вмешательств. Это может включать создание списка задач или использование методик приоритизации, таких как фреймворк 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-команды.
