У технического долга есть много определений. Самое короткое и самое ёмкое из них: это то, что мешает команде работать с заданной скоростью. Заданная скорость - это скорость реализации задач, взятая командой в начале проекта, когда технический долг минимален или совсем отсутствует.
Чем плох технический долг?
Один из эффектов, который имеет технический долг - он замедляет разработку. Причём, эффект этот увеличивается со временем. И увеличивается настолько неизбежно, что даже есть популярное сравнение технического долга с денежным кредитом, а возрастание его эффекта замедления разработки - с процентами по денежному кредиту. Чем дольше мы не отдаём долг, тем больше процентов нам нужно будет заплатить.
Другой эффект - не менее важный - технический долг может лишать команду веры в проект. Нет веры - нет команды. Я видел много примеров того, как там, где не хотели устранять технический долг, так как не считали это "первоочередной задачей на данном этапе", начинали один за другим увольняться люди. Одной из причин своего уволнения все они называли "отсутствие порядка (на проекте, в коде, архитектуре, аналитике, процессах)".
Как выявить технический долг?
Источниками информации о техническом долге являются:
1. Команда. Каждый участник команды может рассказать о том, что его "бесит" в существующей системе или процессе разработки, что мешает ему работать быстрее и лучше.
2. Метрики: системы, пользователей, команды, кода.
3. Логи.
4. Отчёты об ошибках.
5. Тесты.
6. Статические анализаторы кода.
7. Команда поддержки.
Как начать устранять технический долг?
Технический долг не любят отдавать. Чтобы его не отдавать, про него предпочитают не знать (если не знаем о проблеме, то её "не существует").
Поэтому первое, что нужно сделать для того, чтобы начать закрывать технический долг - это выявить, что именно является техническим долгом на вашем проекте.
Примеры того, что может быть техническим долгом:
- архитектура системы или приложения,
- отутствие тестов,
- отсутствие документации,
- отсутствие процесса обновления зависимостей,
- отсутствие регламента разработки,
- отсутствие удобного инструмента работы с логами,
- отсутствие инструментов для работы с метриками: системы, пользователей, команды, кода,
- отсутствие инструмента для работы с ошибками (инцидентами),
- отсутствие инструментов статического анализа кода,
- отсутствие необходимых инструментов для разработки и тестирования.
Следующим шагом необходимо посчитать стоимость для компании:
- технического долга (сколько человеко-часов займёт его устранение)
- эффекта технического долга (сколько человеко-часов в месяц, квартал, полгода, год компания потеряет в случае неустранения технического долга, какими могут быть иные последствия неустранения технического долга).
Далее, исходя из расчётов стоимости, нужно приоритизировать технические долги. Наибольший приоритет будет иметь технический долг, который оказывает наибольший негативный эффект.
Затем необходимо составить план постепенного устранения технических долгов - разбить большие задачи на задачи поменьше и обозначить разумные сроки и приемлемые способы устранения долгов.
Какие есть способы устранения технического долга?
Я знаю о следующих способах:
1. Выделять 20% времени на задачи устранения технического долга. Например, каждая пятница целиком посвящается работе по задачам технического долга.
2. Периодически выделять целый спринт на решение задач технического долга.
3. Найти "героя" (разработчика, тестировщика, аналитика), в чьи обязанности будет входить исключительно работа по задачам технического долга.
4. Выбирать сменяемого "дежурного", в чьи обязанности в течение спринта будет входить исключительно работа по задачам технического долга.
5. "Партизанить" - включать выполнение задач по устранеию технического долга в задачи по реализации бизнес-функций или исправлению ошибок.
Если знаете другие способы - будет классно, если напишете о них в комментариях.