Управление рисками в баг фиксинге

Когда багов много, а дата релиза приближается, то цена исправления каждого бага возрастает. Можете ли вы быть уверены в том, что исправление одного бага не станет причиной возникновения другого?  Существует много факторов, которые нужно учитывать для того, чтобы правильно ответить на даный вопрос. Но даже если вы учтете все факторы, а скорей почти все, вы не можете гарантировать, что фикс проблемы не создаст вам новую, может быть, серьезнее чем та, которую вы пытаетесь исправить сейчас. В моей практике было достаточно случаев когда исправление мажорной проблемы приводило к возникновению критичной или даже блокирующей ошибке в системе.

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

Для того, чтобы понять важность бага, следует ответить на три вопроса:

1. Какова будет стоимость данной ошибки для пользователя,  если ошибка все еще присутствует  в системе? (User Risk)

2. Какова будет стоимость исправления данной ошибки? (Development Risk)

3. Какова будет стоимость проверки исправлений? (Quality Risk)

Каждый из ответов может принимать значения
1. Низкая (Low)
2. Средняя (Medium)
3. Высокая (High)

Тогда каждый баг можно описать как Bug ID (User Risk, Development Risk, Quality Risk). Поэтому решения по каждому из багов можно принимать на основе полученных оценок рисков. Например, Bug XX (H, L, L) должен быть одобрен на устранение,  и ни в коем случае Bug YY (L, H, H).

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