Технический долг. Мы обязаны ему многим, в частности, он позволяет нам выпускать что-то в продакшен. Соглашаясь на технический долг мы осознанно решаем сделать что-то хуже, чем могли бы, но зато сейчас. Но есть и другая сторона медали, если долг не отдавать, то поддерживать и расширять нашу информационную систему будет сложнее.
Совсем плохо, когда технический долг создается, но об этом знает только разработчик, который его создает. Немного лучше, когда в коде присутствует какой-то
// TODO. Еще лучше, когда этот компромисс обсуждается с командой, вы принимаете информированное решение и создаете задачу исправить это в бэклоге.И вот приходит момент, когда в бэклоге десятки таких задач и взгляд на них вызывает у вас отчаяние. Кажется это уже не исправить. Как быть?
Технический долг можно приоритизировать. Нас опять выручит матрица.
1. Собираем митинг и рисуем матрицу. По горизонтали — какие усилия нужно приложить (effort), по вертикали — какой эффект это даст для проекта (impact).
2. Теперь проходимся по бэклогу и обсуждаем тикеты. Каждый из них располагаем на матрице. Какой из тикетов сделать легко и это окажет большое позитивное влияние? А может есть такие, которые делать месяц, а результат будет минимальным?
3. Когда все обсудили и визуализировали, решаем, что мы готовы взять в ближайшую итерацию. А high impact + high effort проекты лучше разбить на меньшие задачи.
4. Теперь мы готовы обслуживать технический долг. Вы великолепны ⭐️.
Замечательно, когда приоритизация технического долга является одним из ритуалов команды и выполняется регулярно. Например, раз в месяц.
⬛️ Еще раз — технический долг это не плохо, это просто данность разработки программного обеспечения. Дальше может оказаться, что ваш долг вовсе и не долг, а “особенность” и никому не мешает. Чтобы понять, что именно нужно обслуживать, нужно регулярно приоритизировать технический долг.
Как вы работаете с техническим долгом? Делитесь в комментариях.
#софтскиллы
