Ответ
Да, в Agile-среде это стандартная практика. В моем опыте работа по спринтам часто подразумевает переоценку бэклога. Мой подход — быстро адаптироваться, сохраняя контроль над техническим долгом.
Как я это делаю:
- Уточняю контекст: Первым делом я выясняю причину смены приоритета и новые ожидания по срокам.
- Фиксирую состояние: Если нужно отложить текущую задачу, я обязательно коммичу рабочий код (даже если он не завершен) с понятным сообщением и создаю задачу на доработку позже.
- Оцениваю влияние: Смотрю, не затронет ли новая задача те же модули, что и предыдущая, чтобы использовать наработки.
Например, если во время разработки API для отчетов приоритет смещается на срочное исправление в модуле аутентификации, я ставлю текущую работу на паузу, переключаюсь на исправление, а затем возвращаюсь к отчетам, имея четкую точку продолжения.
Ответ 18+ 🔞
Ну вот, опять эти ваши Agile-танцы с бубнами. Работаешь себе спокойно, пишешь код, как вдруг — бац! — приоритеты поменялись, и всё, что ты делал, теперь по боку. Ёпта, классика жанра, да? Как будто на дворе не 2024-й, а какой-нибудь 2002-й, когда все только про гибкие методологии узнали и носились с ними, как с писаной торбой.
Ладно, не буду гнать волну. На самом деле, за годы работы я эту карусель уже изучил вдоль и поперёк. Главное — не охуеть от внезапного поворота и не наломать дров. У меня свой чёткий план, как не превратить код в помойку, когда от тебя требуют прыгнуть с одной фичи на другую.
Как я обычно выкручиваюсь, чтобы не облажаться:
- Сначала врубаюсь, что за пиздец. Серьёзно. Прежде чем метаться, я выясняю, какого хуя всё поменялось. Что за новая задача, почему она такая срочная и, самое главное, когда её, блядь, надо сдать. Без этого контекста — это просто бег по кругу, волнение ебать.
- Фиксирую всё, как есть, даже если это говно. Это святое. Даже если мой текущий код выглядит как манда с ушами и недоделан наполовину — я его коммичу. Обязательно. И пишу в сообщении что-то вроде
WIP: Полупидорская реализация отчётов. Остановился на валидации.И тут же в трекере создаю задачу-напоминалку, чтобы потом не забыть, с какого места продолжать. Иначе через неделю сам от себя охуеешь, пытаясь вспомнить, на чём остановился. - Прикидываю, не пересекается ли новый геморрой со старым. А то бывает же — бросаешь ты свой API для графиков, а тебе подсовывают срочный фикс в том же самом модуле расчётов. Так вот, если пересекается — это даже хорошо, можно часть наработок переиспользовать. Если нет — ну, хуй с горы, начинаем с чистого листа.
Вот тебе живой пример, чтобы было понятнее: Сижу я, значит, допиливаю красивый API для генерации отчётов. Всё идёт по плану. И тут прилетает менеджер с глазами, как у испуганной мартышлюшки: «Срочно! В модуле аутентификации дыра, пользователи не могут зайти! Отчёты подождут». Раньше я бы начал материться про доверия ебать ноль. Сейчас я делаю так:
- Коммичу весь свой полуготовый код по отчётам с тегом
[PAUSED]. - Создаю в бэклоге задачу «Доделать валидацию в ReportsAPI» и прикрепляю к ней ссылку на тот коммит.
- Быстро смотрю, не трогал ли я в своих отчётах что-то рядом с аутентификацией. Нет? Ну и хуй с ним.
- Полностью переключаюсь на поиск и исправление этой ебанькой дыры в логине.
А когда пожар потушен, я просто возвращаюсь к той задаче в бэклоге, открываю свой старый коммит и чётко вижу, с какой строчки кода мне продолжать. Никакой магии, просто дисциплина и понимание, что в этой Agile-кухне такое случается постоянно. Главное — не превращать проект в большую хитрожопую свалку технического долга.