🗂 "Теневой бэклог", который работает В прошлом посте мы определились, что техдолг - это неизбежность. Теперь вопрос на миллион: как его разгребать, не останавливая продуктовую разработку? Главная ошибка, которую я вижу постоянно - попытка держать техдолг "в уме" или смешивать его с продуктовым бэклогом, где он вечно тонет под натиском "срочных фич". 🛠 Мой рецепт: Отдельный Технический Бэклог Это должен быть ваш личный (командный) реестр всех проблем. Не свалка, а рабочий инструмент. Чтобы он жил, я внедряю четкий пайплайн, похожий на продуктовый: 🔹 Backlog (Входящие). Сюда кидаем всё: и мелкий рефакторинг, и идеи по переезду на новую БД. 🔹 To Discuss (На обсуждение). Зона для груминга. Мы собираемся (например, раз в две недели) и смотрим: актуально? Сколько стоит исправить? Что горит? 🔹 Ready for Development (Бери и делай). 🌟 Самый важный статус. Тикеты тут уже оценены и понятны. 💡 Зачем это нужно? Психология проста: когда у разработчика появляется свободный час (или настроение пофиксить что-то техническое), он не должен тратить время на выяснение "а что там надо сделать?". Он заходит в Ready for Development, берет задачу и пилит. ⚡️ Три ситуации, где это критически важно: 1. Когда приходит новый человек в команду (отличный способ погрузиться в проект). 2. Когда бизнес-задачи "зависли" в аналитике, и у команды простой. 3. В рамках "Technical Day" или выделенной квоты времени (об этом в следующем посте!). У вас есть отдельная доска для техдолга, или все живет в комментариях TODO в коде? 😉 #Agile #JiraTips #DevelopmentProcess #AlexKolpakov #FreshIT 🌐 Навигация по каналу 🌐 👨‍💻 Fresh IT. Join!