Как правило, все знают про severity и priority, но практически никто не говорит об urgency (срочности).

Например, если есть критичный баг S1 и его не нужно срочно исправлять, то у него может быть более низкий приоритет, к примеру - P2, а менее критичный баг S2, но который нужно исправить срочно — может иметь более высокий приоритет P1.

Формула приоритета

Приоритет — не что иное, как произведение критичности бага на срочность исправления.

Теперь, когда на собеседовании вас спросят, "а чем отличается severity от priority" - можете рассказать про формулу приоритета и urgency.

Кстати говоря, формула приоритета справедлива не только для багов, но и для любых продуктовых или технических задач, только вместо критичности будет использоваться importance (важность).

В Jira, в зависимости от процессов в конкретной команде/компании для задач с типом Bug может устанавливаться как priority так и severity, и автор дефекта должен уметь правильно определять значения. Если с определением критичности у QA-инженеров вопросов возникнуть не должно, то со срочностью исправления не все так просто, поскольку этот показатель, напрямую связан с приоритетами бизнеса, задачами и sprint goals.

Управление приоритетом

Фактически, на срочность исправления может влиять владелец продукта, технический руководитель и вся команда в целом. Наверное, вы сталкивались с ситуацией, когда дефекты, которые были занесены вами, были переоценены product-owner'ом или technical-lead'ером.

Я, как QA-инженер, ответственный за качество, и максимально приближенный к потребностям пользователя хочу, чтобы баги исправлялись быстрее и в больших количествах, но такой подход может не получить поддержку со стороны владельца продукта и бизнеса. И на первый взгляд, если баги не берутся в работу — может показаться, что команда разработки, бизнес и product-owner не заинтересованы в качественном продукте, но это скорее ложное предубеждение, поскольку владелец продукта имеет больше вводных и видит картину в целом.

Если с небольшим количеством багов проблема срочного исправления не стоит остро, то с ростом нужно будет решить какие баги брать в работу в первую очередь, собственно, этот вопрос решает правильная приоритизация.

Дам несколько рекомендаций, которые помогли мне навести порядок в общем беклоге и опишу способы решения типовых проблем, с которыми столкнулся.

Если багов скопилось много — время пройтись по списку и переоценить их

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

Технический спринт

Если багов скопилось слишком много — можно организовать технический спринт, на котором вся команда займётся исправлением багов.

Пирамида приоритизации

Мы знаем, что по-хорошему, в текущий спринт не рекомендуется добавлять новые задачи, но критические дефекты должны исправляться чем быстрее, тем лучше.

Баги с высоким приоритетом P0-P1 могут автоматически добавляться в текущий спринт и браться в работу любым из участников распределенной команды разработки. А баги с более низким приоритетом P2-P4 могут попадать в следующие спринты, пропорционально приоритету. Значение приоритета может означать спринт, в котором баг будет взят в работу.

Пирамида приоритетов показывает как сроки исправления, так и количественное соотношение.

Баг в спринте, но его не исправляют

О зависших багах стоит напомнить команде на стендапе, а если есть риск того, что баг может переехать в следующий спринт, возможно стоит задуматься о корректировке приоритета на более низкий, а при достижении самого низкого приоритета — принять решение о закрытии бага с резолюцией won't fix. При принятии такого решения стоит вспомнить о Zero Bug Policy, и постараться принимать решение не только в момент зависания дефекта, но и на этапе создания в будущем.

Если есть свободное время и желание, то можно разобраться и исправить баг самостоятельно. Это крутой способ прокачать свои навыки, но такой способ возможен только в кросс функциональных командах. И готовьтесь к пристрастному код-ревью со стороны разработчиков.

Теневые спринты

Я встречался с теневыми спринтами, когда разработчик или группа разработчиков исправляла баги не находящиеся в спринте и передавала на тестирование. Как правило, это было связано с тем, что менее приоритетные баги не могли попасть в спринт, а разработчик, реализуя новый функционал или проводя рефакторинг мог махом исправить несколько багов.

В этом подходе может слегка перегружаться ответственный за тестирование, и могут страдать продуктовые показатели команды, ввиду того, что работа не учитывается в объём стори-поинтов, заложенных в спринт.

Скрытый конфликт интересов

Если продукт находится на раннем этапе развития, а продуктовых задач слишком много, высока вероятность, что product-owner, несмотря на заинтересованность в качестве — будет отдавать предпочтение продуктовым задачам. Здесь нужно соблюсти баланс и обсудить этот момент с командой, чтобы и качество не просело и количество продуктовых задач, доставленных в продакшн было в норме.