Случаи, когда нам выпадает честь оживить и отрефакторить старый продукт, валяющийся на полке, случаются редко. Как правило, резать приходится по живому: вносить правки в запутанную легаси головоломку и при этом вносить так, чтобы ничего не разломать, чтобы не закопать на задачу несколько спринтов и самому при этом не сгореть. Задачка не из легких.
Благо, что есть стратегические решения, которые позволят регулярно заниматься рефакторингом и организовать работу над техдолгом даже в интенсивно развивающемся проекте. Нужно последовательно договориться с командой о трёх вещах и внедрить их в свои процессы.
1. Техдолг учитывается в объёме спринта
Это базовое правило, без которого нельзя двигаться дальше. Мы об этом уже говорили, но это настолько важно, что стоит повторить. Команда должна понимать, что инвестиция времени в техдолг — инвестиция в скорость доставки фичей в будущем, а также — в стабильность приложения. И то и другое — благо для пользователей, и, следовательно, для бизнеса.
Однако заниматься одним лишь техдолгом не получится. Если не релизить новые фичи, то в обозримом будущем закончатся проблемные куски кода. Ну а если релизить только новые фичи, то со временем делать это будет все сложнее и сложнее, time-to-market будет взлетать экспоненциально.
Именно поэтому в живом проекте техдолг и бизнес-фичи существуют в связке. И бэклог они должны наполнять так же вместе. Можно даже договориться о пропорции. Например, можно начать с 10% времени команды. То есть за двухнедельный спринт (10 рабочих дней), у разработки есть ровно 1 день на то, чтобы разобрать велосипеды и костыли.
Если мы внедрили это правило и договорились об учете техдолга при планировании спринта, у нас есть согласованная возможность приводить в порядок свой проект.
2. Задачи на рефакторинг декомпозированы
Идеально, когда можно взять техдолговую задачу между делом: пока вы ждёте чего-либо от бэкенда, согласующих менеджеров или смежных команд. Если получится добиться такого уровня декомпозиции, то на техдолг будет уходить время простоя. То самое время, когда мы злимся на других за их нерасторопность. Не лучше ли вместо злобы сделать хоть что-то полезное?
Декомпозиция — ответственность того, кто задачу заводит, но привлекать коллег не запрещается. Идеальный размер таски — до 8 часов. Меньше — лучше. Больше — в исключительных случаях, потому что редко в проектах встречается настолько большое окно «ничего-не-делания».
Если мы внедрили это правило и плюс-минус точно оценили техдолг, мы имеем возможность с пользой использовать временные промежутки любого размера.
3. У задач на техдолг есть приоритет
К этому моменту у нас есть право делать рефакторинг в рабочее время и какой-то список декомпозированных до удобоваримого размера задач. Последняя деталь — приоритизация. В конце-концом, основная цель — не занять себя чем-то, а занять себя чем-то полезным. Приятно же, когда мы видим и ощущаем эффект от проделанного рефакторинга.
Для этого задачам стоит присвоить приоритет. Удобно разбить плоский техдолговый список на категории по-важности. В своем проекте мы использовали цвета светофора
- Красные задачи — критически важное, брать в первую очередь
- Желтые — хорошо бы сделать, но сроки не горят
- Зеленые — хотелки команды, которые почти ни на что не влияют
В качестве альтернативы можно поднимать карточки в списке. Выше — приоритетнее. Да и вообще можно как угодно. Главное, чтобы это было понятно команде.
Что в итоге
Если мы договорились обо всех этих вещах с командой и получили согласование от бизнеса, у нас есть легальное право тратить рабочее время на задачи, которые не приносят денег здесь и сейчас. При этом мы имеем возможность брать задачи прогнозируемого размера, чтобы контролировать то время, на которое мы оставляем бизнес. И, в конце-концов, мы знаем как максимизировать пользу потраченного времени, ведь задачам присвоен приоритет.
Теперь ничто не помешает проводить рефакторинг развивающемся и кипящем жизнью проекте. Желаю успехов!
