Развитие продукта всегда сопровождается техническим долгом, потому что не все фичи можно сделать качественно за выделенное на реализацию этой фичи время. В таком подходе есть свою плюсы и минусы, но если технический долг не гасится, то добавление новых фичей в продукт становится всё сложнее.
Если интересно, как мы учились работать с техническим долгом, то добро пожаловать под кат.
Немного теории
Что такое технический долг? Технический долг — работы, если их не сделать, несут ущерб невидимый для пользователя (ручная настройка фичи, нечитаемые/отсутствие логов).
Результат погашения технического долга не виден пользователю, но повысит качество продукта (надежность, безопасность, скорость разработки, стабильность).
Каждый берет, то, что ему ближе
Когда продукт новый, тех. долга у него немного. Из-за этого у нас не было какого-то механизма ранжирования задач, которые попадают в технический долг, как не было механизма для погашения, кроме собственного энтузиазма разработчиков. Принцип бойскаута — это про нас. На самом деле, всё было не столь радужно.
Все задачи были беспорядочно собраны на одной доске, где было трудно понять, насколько та или иначе задача важна.
Гасился тех. долг не столько в рамках обычных задач, сколько в рамках дежурства — это когда один из разработчиков команды делает не продуктовые задачи, а отвечает на вопросы других команд или делает какие-то срочные задачи, не связанные с развитием продукта.
Из-за отсутствия механизма ранжирования задач, каждый брал то, что интересно ему. А из-за отсутствия процесса, который позволял бы задачам дойти до боевых серверов, такие задачи часто застревали где-то в районе code-review или тестирования (ведь основные задачи всегда более приоритетны!)
Собственный велосипед для ранжирования
Мы не стали брать какую-то готовую систему оценки, которую кроме того, что применить, нужно еще и подстроить для себя, а сделали собственную.
Каждую из задач технического долга мы оценивали по 4 критериям:
Повторяемость — как часто мы сталкиваемся с этой проблемой. (0 — очень редко, раз в полгода, 5 — каждый день)
Скорость доставки — как данная задача повлияет на скорость доставки других фичей. (скорость разработки, время тестирования, время деплоймента, предсказуемость разработки) (0 — не влияет, 5 — экономит очень много времени)
Влияние на время оперирования (расходы на эксплуатацию, нагрузка на сервер, безопасность) (0 — не влияет, 5 — серьезно снижает расходы и риски оперирования)
Уровень технической инвестиции (0 — это не инвестиция, 5 — техническая инвестиция для большого ряда задач)
Каждую задачу мы оценили в привычных для нас story points, чтобы оценить сложность.
Исходя из этих параметров, мы можем посчитать условное TechDebt Value, на основе которого задачи ранжируются (чем больше, тем важнее).
В формуле можно заметить коэффициенты X, Y и Z. Они нужны для того, чтобы в каждый момент времени мы могли повлиять на наш скоринг — если для текущего состояния продукта нам больше важна скорость доставки, то сделать X больше чем Y и Z и всё в таком духе.
Таким образом, мы смогли отсортировать задачи на доске технического долга от наиболее важных, до наименее важных.
Самое сложное в этом процессе — собрать команду и вместе оценить все задачи тех. долга по каждому критерию.
А что же с гашением? Здесь постарались договориться с нашим владельцем продукта, чтобы часть задач технического долга делалась в рамках спринта, на равне с продуктовыми задачами.
Упрощаем процесс
Поняв, что текущая оценка достаточно сложная и долгая, мы решили отказаться от неё.
Но чем заменить?
Решили оценить влияние на техническое состояние продукта одним числом, так, как делаем это с оценкой в story point — на основе сравнения с другими задачами. Не важно, влияет это на оперирование или на скорость доставки, если влияют одинаково, то и оценка будет одна и та же.
Раз в квартал оцениваем все задачи — учитывая, количество технического долга и количество разработчиков, за час каждый может оценить 10-15 задач. Если кто-то не согласен с оценкой, обсуждаем.
Процесс погашения тоже претерпел изменения.
Среди задач, всегда есть какие-то совсем простые. Чтобы не занимать место в спринте (оно ограничено нашим capacity), решили собрать из них новую доску. В рамках любой продуктовой задачи, можно сделать и какую-нибудь маленькую задачу, улучшив продукт.
Теперь, кроме того, что задачи мы берем в спринт, какие-то небольшие задачи закрываются в рамках других задач.
А дальше?
Мы находимся на последнем из описанных этапов. Пока рано делать выводы, насколько он успешен, главное, что механизм есть, он работает и приносит пользу команде и продукту.
