Разница между Severity и Priority

14.12.2009 10:04

Многие команды часто сталкиваются с вопросом: что есть Severity (важность) и чем эта характеристика отличается от Priority (приоритет)?

При планировании работ на проекте нас интересуют следующие вопросы:

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

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

Проблемы Severity

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

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

Severity является лишь одним из критериев, влияющих на приоритезацию работ на проекте.

Приоритезация работ

Наиболее эффективная приоритезация осуществляется с участием всех заинтересованных лиц в проекте: заказчиков (или их посредников, например, владельцев продукта) и членов команды (аналитиков, тестировщиков, разработчиков). При обсуждении приоритетов необходимо учитывать такие критерии:

востребованность функциональности пользователями продукта. Целесообразно удовлетворять потребность большей части пользователей, чтобы в том числе, не расфокусировать усилия и не размыть функциональность продукта.
срочность, то есть когда обсуждаемая функциональность уже нужна и когда она перестанет быть актуальной.
зрелость понимания функциональности заказчиком и членами команды. Пожелание может быть сформулировано поверхностно, его невозможно реализовать без предварительного уточнения. Команда еще не обсуждала с заказчиком проект пользовательского взаимодействия и плохо себе представляет каким образом стоит реализовать функциональность.
техническая возможность быстро реализовать требуемую функциональность, возможно сперва следует развить архитектуру или дизайн приложения с целью поддержки будущих (аналогичных) пожеланий пользователей.
тестируемость определяет техническую возможность и понимание командой каким образом тестировать и что именно проверять в реализуемой функциональности.
наличие контракта, по которому вы обязаны решать те или иные запросы пользователей, например, на основе SLA.

Добавьте к этому списку и важность (Severity) с развернутым описанием ее истинной причины, если она не укладывается в перечисленные выше.

Попробуйте сейчас!