Пятый пост о багах. Первый, второй, третий, четвертый.

Сегодня поговорим о груминге. Представим себе бэклог, в котором у нас есть 100500 багов с приоритетами.

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

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

Тут нам на помощь приходит несколько дополнительных полей:

— Severity, его мы уже определяем в процессе расчета приоритета, поэтому никаких проблем с его заполнением не должно возникнуть.

— Массовость: Опять же вычисляем в рамках приоритета.

— Окружение: prod или test? Баги на проде там уже есть, баги на тесте рискуют появится на проде.

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

Для удобства заводим эти поля в Jira, Трекере, Ноушне или любом другом таск-менеджере.

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