Как расположить по приоритетам ошибки?

Я согласен с людьми из FogBugz, что это должно быть очень простым: http://fogbugz.stackexchange.com/questions/352/priority-vs-severity

Я сделал до этой схемы, которую я нахожу легко запомнить:

• pS: секунды имеют значение, например, сервер горит
• pM: минуты имеют значение, например, что-то не работает
• pH: часы имеют значение, т. Е. Не ложатся спать, пока это не будет сделано
• pd: дни имеют значение, т. Е. Нормальный приоритет
• pw: недели имеют значение, т. Е. Более низкий приоритет
• pm: месяцы имеют значение, т. Е. Не спешат
• py: годы имеют значение, т. Е. Может быть / когда-нибудь, т. Е. Список пожеланий

Это примерно соответствует схеме Debian: http://www.debian.org/Bugs/Developer#severities

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

PS: Вы также можете выбрать промежуточные срочности, такие как «pMH» для промежутков между «значениями минут» и «значениями часов». Или «pHd» находится между «важными часами» и «важными днями» - примерно, «буквально не тяните за это всю ночь, но не работайте над чем-либо еще, пока это не будет сделано».

Я использую следующие категории как для функций, так и для ошибок:

1. Showstopper, программа (или основная функция) не будет работать
2. Должна иметь, значительную часть клиенты будут обеспокоены этим
3. Будет, некоторые клиенты будут обеспокоены
4. Приятно иметь, некоторые клиенты хотят этого

Обычно вы планируете исправить 1 , 2 и 3, но 3 часто откладывается до следующего выпуска из-за нехватки времени.

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

Лично я предпочитаю двухуровневую модель серьезности / приоритета. Я знаю аргументы для одного уровня, но в местах, где я работал, я обычно видел, как двухуровневая иерархия работает лучше

Степень серьезности устанавливается командой поддержки (на основе данных от клиента). Приоритет устанавливается клиентом (с участием команды поддержки).

Для серьезности я использую:

1 - блокировщик / шоу остановлено
2 - основная функциональность недоступна (или фактически недоступна), практическая работа вокруг невозможна
3 - Основная функциональность недоступна (или ...), возможен обходной путь
4 - Незначительная функциональность недоступна (или фактически недоступна), невозможен обходной путь
5 - Незначительная функциональность недоступна (или ... ), обойти можно
6 - Косметика или другое тривиальное

Тогда для приоритета я просто использую High, Medium, Low, но все, что от 3 до 5 уровней работает (намного больше, чем это чуть более верх).

Затем я обычно заказывал сначала по Приоритету, а затем по степени серьезности. Важно то, что клиент имеет самое важное мнение. Если они говорят, что способ, которым их логотип печатается в отчете, является наивысшим приоритетом, то это то, на что смотрится, НО это просматривается после высокого приоритета другого клиента, который останавливает их вход в систему.

Вообще говоря, я бы не стал выпускать какие-либо проблемы с высоким приоритетом или проблемы со средним приоритетом со степенью серьезности 1 - 4. Очевидно, что в идеальном мире вы бы все исправили, но мне никогда не удавалось иметь такую ​​возможность.

Что касается стандарта, руководство IEEE по классификации для программных аномалий , хотя я не уверен, насколько широко это принято. IEEE 1044.1-1995

Серьезность (устанавливается отправителем при отправке дефекта)

• Наивысший (5): потеря данных, возможное повреждение оборудования или сбой, связанный с безопасностью
• Высокий (4): Потеря функциональности без разумного обходного пути
• Средний (3): Потеря функциональности с разумным обходным путем
• Низкий (2): Частичная потеря функции или набор функций (функция по-прежнему соответствует проектным требованиям)
• Самая низкая (1): косметическая ошибка

Приоритет (корректируется разработкой, управлением и контролем качества во время дефекта оценка)

• Наивысший (5): система практически не работает с этим дефектом.
• Высокий (4): дефект будет серьезно влиять на способность компании продавать и обслуживать эту систему.
• Средний (3): компания потеряет часть денег, если этот дефект присутствует в системе, но, возможно, более важно соблюдать график. Исправить после выпуска.
• Низкий (2): не откладывайте выпуск, но исправьте эту проблему впоследствии.
• Самый низкий (1): исправить, если позволяют время и ресурсы.

Оба числа вместе создают номер приоритета риска (RPN). Просто умножьте серьезность с приоритетом. Более высокий результат означает более высокий риск. 25 определяет окончательный дефект бомбы. 1 можно сделать во время простоя или если кому-то скучно и нужно что-то сделать.

Первая цель: дефекты с наивысшим или высоким рейтингом любого вида должны быть исправлены до выпуска. Вторая цель: дефекты с RPN> 8 должны быть устранены перед выпуском продукта.

Это, конечно, немного искусственно, но помогает дать всем сторонам (поддержка, контроль качества / тестирование, инжиниринг и менеджеры по продуктам) инструмент для установления приоритетов, не нарушая мнение другой стороны.

Я работаю над системами центра аварийного управления, так что этот набор уровней ошибок немного, ну ... экстремальный :

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

Это не в моей голове. Если вам интересно, это от крайности к минимуму: -)

• Use priority levels that deliberately have nothing to do with severity or impact, and describe only the conceptual position of the bug in the schedule. This field will determine which bugs get worked on, so it needs to be very clear that the facts of the bug aren't open for negotiation.

• Use severity levels that deliberately have concrete, verifiable definitions, that have nothing to do with scheduling or priority. I've worked successfully with the severity definitions used by the Debian BTS, generalised to apply to programming projects in general.

That way, the severity is much more a matter of verifiable fact, independent of a statement of priority. The priority is then free to be tweaked up and down by negotiation or whatever, without affecting the factual information in the severity field.

Attempting to conflate both “severity” and “priority” into a single field will lead to soul-draining arguments and wasted time. The bug reporter needs a firm guide of fact to determine how “bad” the bug is, and this needs to be easily agreed on by independent parties. The priority, on the other hand, is the correct target for negotiation and scheduling games.

Я думаю, что это масштаб, который мы использовали в предыдущем задании:

1. Вызывает потерю файлов или нестабильность системы.
2. Сбой программы.
3. Функция не работает.
4. Функция не работает, но есть обходные пути.
5. Косметическая проблема.
6. Запрос на улучшение.

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

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

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

В нашем документе эти ошибки могут иметь высокий приоритет, если они «наносят ущерб бренду», то есть если ошибка в макете находится в логотипе или в одном из продуктов, поэтому она серьезна - если это просто абзац на странице, который находится на расстоянии 2 пикселя, это не так.

Один из вариантов - заставить владельца продукта определить приоритет ошибки. Хотя существует некоторая общая интуиция о том, насколько «плохая» ошибка, владелец продукта может быть ответственным за установку порядка точности (т. Е. Ошибка A должна быть исправлена ​​до ошибки B и т. Д.).

Более подробная информация (четкая и краткая), которая может быть предоставлена ​​владельцу продукта, может помочь этому человеку в принятии таких решений (т. Е. Сколько пользователей столкнулись с ошибкой, какие функции недоступны в результате ошибки и т. Д.) )

Замените систему отслеживания ошибок на fogbugz и полностью избавьтесь от поля серьезности.

См. Приоритет против серьезности

1. Must be done now
2. Must be done before we ship
3. Minor annoyance (Doesn't prevent the user from exercising the functionality)
4. Edge case/Remote/Tester-from-Mordor scenario

Well I just made that up... my point being categorizing bugs should not be a weekly hour+ long ritual..
IMHO, prioritizing acc to a flowchart is wasted time. Fix bugs in Cat#1 and #2 - as quickly as they surface. If you find yourself swamped by bugs, slow down and reflect. Defer Cat#3 and Cat#4 if the schedule doesn't permit or higher priority items override.
Важно то, что у всех вас есть общее понимание этой серьезности и ожидаемого качества. Не позволяйте соблюдению святых стандартов X, что мешает вам предоставлять то, что хочет заказчик ... рабочее программное обеспечение.

• Тестер сообщает, что сломано
• Разработчик оценивает, сколько работы ему нужно будет починить
• Заказчик решает бизнес-ценность, то есть приоритет.

«Это там было сделано».

Я обсуждал это снова и снова, по разным проектам. Мы пытались сочетать приоритет с серьезностью, но урок, который я усвоил: не сочетайте серьезность с приоритетом !

У нас было много мозговых штурмов и встреч, которые заканчивались словами " вот оно ». Было создано множество руководящих документов, которые были распространены между разными «сторонами», но через некоторое время мы обнаружили, что в конце концов это не сработало. Разные "стороны" думают об ошибках по-разному: наша служба поддержки имеет другое понимание приоритетов, чем команда разработчиков или отдел продаж.

Наличие и серьезности, и уровня приоритета очень быстро приведет к большой путанице, потому что:

• при использовании чисел (от 1 до 5) никто не будет знать, что означает каждое число
• что, если проблема имеет наивысший возможный приоритет, но наименьшую возможную серьезность - и я уверен, что это произойдет!
• что если кто-то снизит серьезность, нужно ли ему также уменьшить приоритет?

«Так что же тогда делать?»:

• Используйте только один вид индикатора для «уровня» проблемы: Не неважно, как вы это называете.

• Используйте числа (например, 1–5, но может быть более или менее в зависимости от ваших потребностей), чтобы четко обозначить важность, но объедините его с ключевым словом, чтобы оно ясно, что это значит (например, «приятно иметь», «показать пробку»). Для некоторых людей приоритет 1 означает наибольшее значение, для других 5 -> поэтому необходимо ключевое слово, чтобы указать, что означает число.

• Проведите различие между «нормальной проблемой» и «красным предупреждением». В нашем случае «Red Alert» необходимо немедленно устранить и немедленно запустить в производство. Нормальная проблема будет следовать за нормальным потоком развертывания-тестирования-разработки. Приоритет / серьезность / как вы его называете должны быть установлены только для обычных проблем и будут игнорироваться для «красных предупреждений». *> На практике «Red Alert» может стать

  «Обычной проблемой»: служба поддержки обнаружил серьезную ошибку и создал 'Красная тревога'. Но через некоторое время расследование мы обнаружили эти данные стал "поврежденным" в базе данных так как он был вставлен туда напрямую а не через приложение. *

• Выберите хороший инструмент, позволяющий настраивать поток; но большинство инструментов это делают.