Технический долг внутри Scrum-команды
Узнайте, как технический долг влияет на Scrum-команды, почему спринты стабилизации не работают, и как с помощью Definition of Done поддерживать чистоту и надежность кодовой базы.
Технический долг не имеет ничего общего с бухгалтерскими уловками. Это накопленный балласт, возникающий из-за компромиссов, отсутствия автотестов, устаревших библиотек и хрупкой архитектуры. Когда команды закрывают на него глаза, любая последующая доработка обходится вдвое дороже и длится втрое дольше. В Scrum к техническому долгу нередко относятся как к капризам погоды, словно это происходит с командой извне. На самом деле технический долг создается прямо внутри Sprint. Руководство по Scrum возлагает на Разработчиков полную ответственность за обеспечение качества через соблюдение Definition of Done. Если долг накрывает вас с головой, значит, ваш Definition of Done не работает.
Definition of Done как потолок долга
Definition of Done представляет собой формальное обязательство, гарантирующее, что Increment соответствует требуемым критериям качества продукта. Если элемент отвечает этому стандарту, долг не проникает в продакшен. Ослабляя Definition of Done ради формального достижения Sprint Goal, команды берут кредит под грабительские проценты.
Надежный Definition of Done четко фиксирует условия, при которых код считается завершенным. Если пользовательская история отмечена как готовая без интеграционных тестов или сканирования безопасности, вы вовсе не закончили раньше срока. Вы лишь перенесли неоплаченную работу на следующий месяц. Со временем такие отложенные задачи создают скрытое сопротивление, снижая темп будущих Sprint. Строгий Definition of Done работает как ограничитель, не позволяющий низкому качеству стать привычной нормой.
Как команды порождают технический долг
Долг не возникает сам по себе. Команды идут на осознанные уступки во время Sprint, часто поддаваясь иллюзии высокой скорости. Вот самые распространенные способы создания долга в Scrum-командах:
- Отказ от модульных и автоматических интеграционных тестов ради сдачи элемента Backlog до завершения Sprint.
- Сохранение устаревших схем баз данных и создание громоздких переходных слоев вместо проведения миграций.
- Игнорирование предупреждений компилятора, устаревших методов и зависимостей, пока обновление не превратится в опасную операцию.
- Жесткое кодирование бизнес-логики или конфигурационных параметров ради быстрого выполнения одного критерия приемки.
Почему спринты рефакторинга обречены на провал
Когда груз долга становится непосильным, команды часто просят выделить спринт стабилизации или спринт рефакторинга. Это антипаттерн. В Руководстве по Scrum нет итераций для наведения порядка. Каждый Sprint обязан приносить ценный, пригодный к использованию Increment. Двухнедельный период, за который разработчики не создают новых функций и не приносят ощутимой пользы клиентам, практически невозможно обосновать перед стейкхолдерами. Более того, это приучает команду писать небрежный код в обычных Sprint в надежде на спасительную уборку в будущем.
Вместо выделения специальных периодов на уборку разбирайтесь с долгом инкрементально. Используйте правило бойскаута, оставляйте кодовую базу чище, чем она была до вас. Каждый раз, когда вы открываете модуль для добавления функции, проводите рефакторинг смежного кода, дописывайте недостающие тесты и обновляйте интерфейсы. Такой подход встраивает выплату долга в стандартный процесс разработки продукта и избавляет от необходимости выпрашивать отдельные окна на техническое обслуживание.
Отображение долга в Product Backlog
Некоторые виды долга слишком масштабны, чтобы устранить их попутным рефакторингом в рамках одной пользовательской истории. Миграция на новую версию крупного фреймворка или замена системы аутентификации требуют тщательного планирования. Таким крупным техническим инициативам самое место в Product Backlog, наряду с пользовательскими функциями.
Разработчики должны взаимодействовать с Product Owner, описывая подобную работу через призму бизнес-ценности. Если сказать Product Owner, что сервис нужно просто переписать, велик шанс получить отказ. Если же объяснить, что текущий сервис оформления заказа вызывает десять сбоев у клиентов в день и блокирует подключение новых платежных шлюзов, необходимость вложений становится очевидной. В конечном счете технический долг является продуктовым риском, а управление им требует полной прозрачности.