Comments 6
"Балансировка бэклога", который позволяет командам самим определять, сколько времени они могут выделить на устранение технического долга
Как мне кажется, этот подход работает, потому что вы уже выросли и у вас уже есть продукт, который достиг, или почти достиг, точки кипения по скорости разработки/деплоя и т.д.
А как быть, или чтобы вы посоветовали, оглядываясь назад, когда идет фаза активного роста и техдолг создается вот прямо сейчас в угоду новых фич и развития проекта?
Все же "балансировка бэклога" подходит как раз для молодых проектов. Когда разработка настолько динамичная, что горизонт планирования задач постоянно меняется и вынуждены менять задачи на ходу. Балансировка как раз помогает, не привызываться к каким-то квотам бэклога, не ограничивать себя при выборе что делать: фичи или техдолг. Сейчас критичные фичи, в след иттерации (конденции, "спринт") заполняем техническими задачами. Это прозрачно и для команды, и для менеджеров, меньше раздражения.
А вот альтернатива с квотам ("20% на техдолг"), увы, эффективно работает, когда процессы разработки настолько зрелые, что по каждой команде считаются емкость (estimates) бэклога за иттерацию. И за счет емкости бэклога понятно сколько это 20% и действительно будут ли они сделаны.
Более конкретно отвечая на вопрос - а как лучше делать на совсем ранней стадии проекта может даже стартапа. По опыту, лучше сначала сосредоточиться на ключевых фичах, поставить продукт на какие-то рельсы, выпустить MVP или полную версию, а техническими задачами заняться через полгода, ну край год, после старта проекта. (но не затягивать!) И воспользоваться тактикой балансировки.
Спасибо @michaem Супер статья, прочел влет. Однако, отмечу важный момент про техдолг. Решение на устаревших технологиях не является техдолгом согласно его определению в этой статье. Кстати и Фаулер, популяризатор этого понятия в разработке ПО, и родоначальник этого термина Каннингем тоже не подразумевали этого. На примере - ставя новые оглобли на карету - я вроде использую устаревшую технологию, но решение не содержит никакого техдолга.
И далее в статье все упоминания, в т.ч. и про фатальные промахи, были именно про ошибки в коде, а не про то что версия устарела.
После прочтения созрел вопрос к автору, а есть ли ПО по отслеживанию техдолга? Типа как в продуктах sonar, но только что бы речь шла не про отслеживание ошибочных паттернов программирования, а о более высоком уровне абстракции слежения за разработкой кода?
Как это работает с практической точки зрения. Есть команда сотрудников, они пишут код неважно какого качества. Если бизнес разрастается - всё начинает тормозить. Нанимают спецов и архитекторов со ставкой x2 - чтобы те разгребли гуано, которое наспех сколотило предыдущее поколение. Всё покрывается метриками, тестами, анализаторами. Через 3-6-12 месяцев тормозить перестаёт, опытная команда разбегается, из спецов оставляют кого-нить чтобы больше не пускали костыли в код. Со временем всё устаканивается, тут уже на сцену выходят адепты JSDD (Job Safety Driven Development) неявно заражая всех остальных, проходит время, и, если бизнес опять таки каким-то чудом умудряется подрасти - процесс повторяется снова)
Я считаю вы большие молодцы, еще лет 40 и вы приблизитесь к уровню PlayMarket
Просто у вас хватает ресурсов, когда их не хватает, то хоть на изнанку вывернись
Как мы победили техдолг в RuStore