Ответ
Приоритезация багов основывается на системе факторов, часто формализованной в метриках или соглашениях команды. Ключевые критерии:
1. Критичность (Severity) Влияние бага на работу системы и пользователей.
- Blocker/Critical: Приложение падает, данные теряются, ключевой функционал полностью недоступен.
- Major: Серьезная ошибка, но есть обходной путь (workaround).
- Minor/Trivial: Косметические проблемы, опечатки, не влияющие на функциональность.
2. Приоритет (Priority) Срочность исправления с точки зрения бизнеса.
- High: Баг блокирует релиз или критически влияет на большое число пользователей.
- Medium: Проблему нужно решить в ближайшем спринте.
- Low: Исправление может быть отложено.
3. Частота воспроизведения (Reproducibility)
- 100%: Баг воспроизводится всегда — высокий приоритет.
- Интермиттентный: Воспроизводится при определенных условиях — требует анализа.
4. Влияние на пользователей (User Impact)
- Количество затронутых пользователей.
- Важность затронутого функционала (например, оплата vs настройка профиля).
5. Сложность и риск исправления (Effort/Risk)
- Простые и безопасные исправления часто делаются быстрее.
- Сложные правки в legacy-коде требуют более тщательного планирования и тестирования.
Пример приоритезации в тикете (Jira/GitLab):
[SEVERITY: Blocker, PRIORITY: High]
Заголовок: Система падает при нажатии кнопки "Оплатить" в корзине.
Описание: Воспроизводится в 100% случаев для пользователей с определенным типом карты.
Влияние: Блокирует все покупки. Критично для бизнеса.На практике команды часто используют матрицу Severity vs Priority или формулы, учитывающие несколько факторов, чтобы объективно ранжировать баги в бэклоге.