Технический долг или Право на выбор

Действительно правда, что наше внимание фокусируется сильнее на предметах и явлениях которые ближе к нашим тактическим задачам. Оно, так сказать получает дополнительную «привязку» на такие объекты. Работая над возвращением технического долга, за последние несколько дней увидел множество статей\постов на эту тему. Такое чувство, что только ленивый об этом не писал :). Не буду пересказывать то, что написано здесь и здесь, а сосредоточусь на прикладном аспекте вопроса.

Давайте оттолкнёмся от уже общепринятого термального элемента — спринта.
Обсуждая ту или иную задачу, у Вас есть два пути её решения:

1. «Quick Win» — чаще предлагается менеджментом, характерен быстрым достижением результата за счёт этого самого технического долга, когда «заплатка» лучше чем дизайн.
2. «Long way» — в противоположность первому, имеет место быть, когда у Вас достаточно ресурсов и Вы смогли убедить руководство в необходимости прототипирования, UML-ирования и бла, бла, бла :)

Невозможно сформулировать правила на все случаи жизни — где лучше применять первый, а где второй метод. Тут, так сказать «up to you and your project». Главное чтобы решение было взвешенным и удовлетворяло обе стороны на текущем этапе проекта.

Но самое интересное впереди.
С пунктом 2 всё понятно — у Вас карт-бланш и если Вы провалили сроки, то делаем себе харакири down-level senior->professional и читаем мат часть.

А вот пункт 1 и есть Ваш Инь-Ян. Принимая его, Вы делите задачу на две части: первая будет реализована в этом спринте, вторая — когда-то потом. Так вот часто, очень часто, всегда о второй части забиваютзабывают.

«Я как бы за равенство полов, но только не в моём гареме», поэтому выработал следующую стратегию:

1. При выборе «Quick Win» стратегии, задача разбивается на две (crt.fopen vs boost.iostreams)
2. Для обех задач очерчивается объём работы (read settings vs preferences.subsystem) и производиться оценка (1m/h vs 4m/h)
3. Первая часть заносится в текущий спринт вторая в back-log проекта
4. Перед началом следующего спринта, анализируется возможность возврата долгов по некоторым пунктам и производиться переоценка по оставшимся долгам.

Каков выхлоп:

1. Всегда перед глазами величина технического долга.
2. Дисбаланс новые фичи\долг на спринте используется как параметр риск-менеджмента
3. И крамольная фраза «Ну я же говорил ...» уже не просто сотрясание воздуха.

Можно говорить о техническом долге, как о тезисе, который достаточно широко распространён и выражет мнение о необходимости постоянного рефакторинга кода. Его отголоски можно найти и в ISO в пунктах, касающихся постоянного улучшения ISO 9001:2008 8.2. И как часть нашего мироощущения в разразе цена\качество.

Но есть проекты, цель которых возврат технического долга предыдущих разработчиков и в таких случаях двойная долговая вложенность и как следствие, часто «хочется нажраться в гов.. и сбацать пару старых хитов» :)

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU