Управляемый технический долг

Перевод статьи Mathias Verraes «Managed Technical Debt»

tl;dr Следует проводить различие между управляемым и неуправляемым техническим долгом.

Alberto Brandolini сказал на IDDD Belgium (цитирую по памяти):

Мы всегда плохо объясняли понятие «технический долг» бизнесу (менеджменту — прим. перев). Если у вас есть долг перед банком, то вы можете поговорить с кем-то, обсудить условия и согласовать план выплат. Но технический долг больше похож на долг перед мафией: они приходят ночью, приставляют пушку к вашей голове и хотят свои деньги обратно прямо сейчас.

Greg Young, с другой стороны, говорил о некоторых случаях, когда технический долг не обязан восприниматься, как что-то плохое. Бизнес берёт займы всё время. Они — мощный инструмент, чтобы провести инвестиции сейчас и заплатить за них потом. Это фундаментальный аспект нашей экономики.

Костыли

Я очень сильно раздражаюсь, когда какой-нибудь нетехнический специалист предлагает мне наставить костылей, чтобы успеть к дедлайну. Или ещё хуже: когда так делает менеджер, выросший из разработчика. Технический долг — это часто то, что тормозит проект в первую очередь. И как консультант, всё больше и больше специализирующийся на «проблемных проектах», я видел много говнокода, который приводит проекты к остановке.

При этом я сам всё время советую командам делать костыли. Но есть различие. Я знаю код проекта очень хорошо. Я знаю, где возникнут проблемы и где это будет под контролем. Я знаю, что покрыто тестами, какие части причиняют нам боль и какие части просто не элегантны. И самое важное: когда я увеличиваю технический долг, я знаю, как от него избавляться, и я провожу рефакторинг так скоро, как только сочту это необходимым. Я добавляю в код комментарии, подсказывающие, как изменять этот код, и часто я вешаю стикер в бэклог. Как только новый код напирается на старые костыли, я поднимаю приоритет этой задачи в бэклоге.

Технический долг на карте проекта (внизу)

Командная дисциплина

Когда есть такое противоречие во мнениях как в цитатах выше, то часто оказывается, что проблема в языке. Один термин и два понятия. Чтобы сделать неявное явным, я бы хотел предложить чётко различать управляемый технический долг и неуправляемый технический долг. Первый определяется как технический долг, при котором выполняется большинство из следующих условий:

Для неуправляемого технического долга, с другой стороны, выполняется большая часть противоположных условий:

Как мы управляем этим

(Дополнение от 12 сентября 2013)

Фото выше показывает карту историй (story map — прим. перев.) проекта, и нижняя часть — это карта технического долга, в колонках по категориям (синие стикеры). Зелёные стикеры имеют оцененный приоритет и этот приоритет регулярно меняется: всякий раз, когда мы находим, что что-то тормозит нас, стикеры поднимаются вверх. Рано или поздно они перемещаются на Канбан-доску, чтобы быть добавленными в спринт. Мы неформально используем правило «три удара и ты рефакторишь», но по большей части полагаемся на чутьё, опыт и обсуждения, которые помогают нам решить, что что-то требует исправлений — например, когда мы верим, что будущие истории (имеются ввиду примеры использования — прим. перев.) будут затронуты.

Визуализация карты историй и технического долга в данном случае является отличным способом снизить стресс: конечно, у нас ещё куча работы впереди, но она никогда не выглядит неуправляемой.

Дополнение от переводчика

(UPD 01.07.2014)

Недавно Mathias Verraes подготовил небольшую презентацию на тему технического долга для очередного DDD Workshop. Ничего экстраординарного, скорее, красивые картинки в дополнение к статье, но приятно. Думаю, будет логичным вставить её в этом посте.

comments powered by Disqus
Система Orphus