Как происходит работа с багами и доработками в спринте

Что проверяют

Умеете ли вы отличать срочное от важного и не ломать спринт каждым новым сообщением в чате. Следом обычно спрашивают, чем severity отличается от priority и что вы делаете, если посреди спринта прилетает критичный баг с прода.

Как отвечать

Разделите три потока, у них разная логика:

• баг в задаче текущего спринта: QA нашёл ошибку в фиче, которую ещё не приняли. Это не новая задача, а возврат в работу, история не закрывается, пока баг не исправлен;
• баг с прода: заводится тикет и проходит триаж. Severity говорит, насколько сломано, priority говорит, как срочно чинить. Блокер вроде неработающей оплаты берут сразу хотфиксом, остальное идёт в бэклог и на ближайшее планирование;
• доработка: изменение требований или новое пожелание. В текущий спринт она попадает только через продакта и обычно в обмен на другую задачу, иначе план срывается.

Чтобы срочные баги не ломали план, команды заранее оставляют запас ёмкости спринта или назначают дежурного, который разбирает входящее.

Про фронтенд добавьте конкретику. Хороший баг-репорт содержит шаги, браузер и его версию, устройство и размер экрана, скриншот или видео, ошибки из консоли. Ошибки с прода удобно собирать через Sentry с загруженными source maps: тогда стектрейс указывает на ваш исходник, а не на минифицированный бандл. Прежде чем чинить, воспроизведите: многие баги живут только в Safari на iOS или только на медленной сети.

Исправление закрепляйте тестом, который падал бы до фикса: юнит-тест на Vitest или Jest с Testing Library либо сценарий в Playwright.

Где спотыкаются

Путают severity и priority. Опечатка в названии продукта на главной почти ничего не ломает, но чинить её нужно срочно.

Берут правки от дизайнера или менеджера из личных сообщений и делают молча. В спринте появляется работа, которую никто не видит и не оценивал.

Закрывают баг фразой «у меня не воспроизводится», не проверив браузер, устройство и данные пользователя из репорта.