Что такое жизненный цикл задачи (тикета) в разработке?

А, слушай, смотри, вот эта вся хуйня с тикетами — это ж как священный ритуал, блядь. Как будто ты не баг заводишь, а ребёнка крестишь, ёпта. Нужно пройти все эти круги ада, иначе в рай не пустят, то есть в прод не выкатят.

Представь, ты нашёл баг. Ты такой: «О, сука, смотрите, кнопка «Отправить» вместо данных письмо ненависти мне в личку шлёт!». И ты создаёшь тикет. Это этап NEW. Всё, ребёнок родился, блядь. Лежит, сопит, и все вокруг думают: «А не придумал ли он?».

Потом приходит старший тестировщик, смотрит, тыкает пальцем и говорит: «Да, хуйня. Воспроизводится». Это CONFIRMED. Теперь баг официально существует, его признали. Теперь его уже нельзя просто так взять и забыть, это как задолженность по алиментам, блядь.

Дальше — священный акт передачи. Ты кидаешь тикет разработчику. Он смотрит, матерится, но берёт в работу. IN PROGRESS. Это момент, когда он начинает ковыряться в коде, искать, где же эта, блядь, строчка, которая всё сломала. У него лицо сосредоточенное, он уже мысленно посылает нахуй того, кто это писал (часто — себя трёхмесячной давности).

Вот он что-то там починил. «Всё, готово!» — и ставит статус FIXED. Ага, щас. Это как если бы сантехник сказал «починил», а ты ещё кран не пробовал открыть. Он считает, что его работа закончена. А для нас, тестировщиков, она только начинается, вот в чём, блядь, парадокс!

Ты берёшь билд, начинаешь проверять. Это VERIFIED. И тут два пути, как в сказке про богатыря: направо пойдёшь — баг пофикшен, налево пойдёшь — он всё ещё там, хитрая жопа.

Если баг исправлен — ура! Статус CLOSED. Тикет отправляется в цифровую Валгаллу, где томятся все почившие баги. Всё, конец истории.

НО! А если нет? Если ты нажимаешь на ту же кнопку, а она тебе вместо письма теперь гороскоп на завтра шлёт? Вот тут-то и наступает момент истины, блядь! Ты делаешь Reopen. Это священный ритуал возвращения души из загробного мира. Ты такой: «Воскресай, ублюдок, мы тебя не долечили!». И тикет с позором летит обратно в IN PROGRESS. Разработчик снова матерится, но уже громче.

А бывает, разработчик посмотрит и скажет: «Это не баг, это фича» или «На твоей оси браузера не воспроизводится, иди нахуй». И выставляет статус WON'T FIX или REJECTED. Вот тут нужно либо смириться, либо начинать holy war, доказывая, что это всё-таки пиздец, а не фича.

С фича-стори (Story) та же песня, только длиннее. TO DO — все про неё знают, но делать не начинают. IN PROGRESS — начали. Потом обязательный этап — CODE REVIEW. Это когда другие разработчики смотрят код и говорят: «А чё это тут у тебя, мудила, 100500 вложенных циклов? Переделывай». Без этого этапа — никуда, иначе потом всем овердохуища работы.

Потом READY FOR TEST. Ага, готово. Как пирог из духовки. А мы его пробуем. IN TESTING. И если пирог с гвоздями — обратно на кухню, сука, перепекать!

Практическое значение для нас, QA? Да всё просто, как три копейки, блядь! Если ты не будешь следить за этим цирком, то:

1. Баги будут висеть в FIXED, но не проверенные. Потом выкатится релиз, и окажется, что нихуя не фиксед.
2. Фичи будут уходить в прод, минуя ревью кода или тестирование. А потом весь прод встанет колом, и виноваты будем мы, потому что «пропустили».
3. Ты никогда не будешь знать, что по-настоящему готово, а что нет. Бэклог превратится в свалку, где всё перемешано: живое, мёртвое и «вроде работающее».

Короче, этот жизненный цикл — наш скелет, каркас, на котором всё держится. Без него — анархия, бардак и пиздец. А с ним — хоть какая-то видимость порядка, чтобы понимать, на каком этапе вся эта ебаловальная катавасия находится.