В этой статье я расскажу вам об одном из самых важных и широко распространенных терминов “Technical Debt”, а также о причинах его возникновения и подходах к управлению им.
Что означает Technical Debt в Agile?
Technical Debt (Технический долг) – это концепция в процессе разработки программного обеспечения, которая отражает последствия, когда команда, мотивированная быстрым завершением продукта, вместо выбора правильных архитектурных подходов, осознанно выбирает относительно “простой” подход в надежде на будущий Refactoring.
Какие последствия влечет за собой Technical Debt
Увеличение непредсказуемости
Одна из характеристик технического долга – то, что он растет непредсказуемым, нелинейным образом, и каждое добавление нового поля может повлиять на непрерывность бизнеса. В какой-то момент технический долг достигает своеобразной “критической массы”, где продукт становится неуправляемым или хаотичным. В переломный момент даже небольшие изменения в продукте становятся невозможными или требуют очень много времени.
Увеличенное Time to market
Чем больше технический долг сегодня, тем медленнее будет скорость команды завтра. Чем медленнее становится команда, тем медленнее происходит доставка нового продукта пользователю. Поэтому, несмотря на то, что команда быстро продвигается вперед, беря технический долг в краткосрочной перспективе, это может очень скоро замедлить команду и, более того, привести к потере конкурентного преимущества.
Увеличенные расходы на Development и Support
С ростом технического долга растут расходы на Development и Support. То, что раньше было простым и дешевым, теперь становится сложным и дорогим. При наличии растущего количества технических долгов даже небольшие изменения становятся очень дорогими.
Атрофия продукта
Когда организация прекращает добавление новых функций или исправление дефектов с целью исправления технического долга, существующий продукт становится все менее привлекательным для потенциальных пользователей. В результате продукт начинает атрофироваться и просто перестает быть интересным.
Что вызывает Technical Debt?
Жесткие Deadline-ы и давление со стороны бизнеса
Технический долг в большинстве случаев вызван давлением бизнеса с целью соблюдения важных Deadline-ов.
Искусственное увеличение производительности команды
Ситуация, когда команда имеет поставленную цель, которая должна быть выполнена к дате X. Команда говорит, что достижение данной цели к указанной дате невозможно. Бизнес не отступает, поэтому команда вынуждена искусственно/необоснованно увеличить скорость и в этом процессе закрыть глаза на накопление технического долга.
Исключение процесса тестирования
Иногда считается, что если убрать процесс тестирования из SDLC, это ускорит процесс. Конечно, это миф. С одной стороны, команда должна работать с подходом Built in quality, но без обеспечения качества технический долг будет расти еще больше.
Новый технический долг “надстроен” на старом долге
Очевидно, технический долг влияет и на масштабирование кода. Соответственно, любой новый неправильный подход, который основан на или использует старый технический долг, похож на “карточный домик”, который может рухнуть в любой момент.
Как управлять Technical Debt?
Первое, что нужно знать, это то, что управление техническим долгом и ответственность за него полностью лежит на стороне Development team. Поделюсь несколькими техниками управления техническим долгом:
Будьте прозрачны в отношении технического долга. Визуализируйте технический долг так, чтобы каждый мог иметь доступ к этой информации в любое время. Также, регулярно обсуждайте технический долг на церемонии Sprint Review, чтобы заинтересованные стороны знали о существовании долга. Это упростит управление ожиданиями и рисками заинтересованных сторон.
Используйте инструменты измерения. Это может быть DORA, SQALE, измеритель покрытия Unit Test-ов и автоматизации тестирования. Если это не удается, как минимум посчитайте количество дефектов.
Обязательно включите задачи технического долга в Sprint Backlog и посвятите 15-20% Capacity команды таким типам задач.
