Про приоритизацию багов |
22.06.2023 00:00 |
Автор: Куликов Дмитрий Как правило, все знают про 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, и постараться принимать решение не только в момент зависания дефекта, но и на этапе создания в будущем. Если есть свободное время и желание, то можно разобраться и исправить баг самостоятельно. Это крутой способ прокачать свои навыки, но такой способ возможен только в кросс функциональных командах. И готовьтесь к пристрастному код-ревью со стороны разработчиков. Теневые спринты Я встречался с теневыми спринтами, когда разработчик или группа разработчиков исправляла баги не находящиеся в спринте и передавала на тестирование. Как правило, это было связано с тем, что менее приоритетные баги не могли попасть в спринт, а разработчик, реализуя новый функционал или проводя рефакторинг мог махом исправить несколько багов. В этом подходе может слегка перегружаться ответственный за тестирование, и могут страдать продуктовые показатели команды, ввиду того, что работа не учитывается в объём стори-поинтов, заложенных в спринт. Скрытый конфликт интересов |