Как определить приоритеты ошибок?

Ответ 1

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

• Используйте уровни серьезности, которые преднамеренно имеют конкретные, поддающиеся проверке определения, которые не имеют никакого отношения к планированию или приоритету. Я успешно работал с определениями серьезности, используемыми Debian BTS, обобщенными для применения к проектам программирования вообще.

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

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

Ответ 2

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

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

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

Ответ 3

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

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

Ответ 4

Некоторые вещи, которые мы использовали раньше. Мы разделили рейтинг дефектов на приоритет и степень серьезности.

Тяжесть (задается отправителем при подаче дефекта)

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

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

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

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

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

Это, конечно, немного искусственно, но помогает дать всем сторонам (Support, QA/Test, Engineering и Product Managers) инструмент для определения приоритетов, не сдувая мнение другой стороны.

Ответ 5

"Было ли это сделано".

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

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

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

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

"Итак, что вы должны делать?":

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

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

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

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

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

Ответ 6

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

Ответ 7

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

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

Ответ 8

• Должно быть сделано сейчас
• Должно быть сделано, прежде чем мы отправим
• Незначительное раздражение (не препятствует использованию пользователем функциональности)
• Экземпляр/сценарий удаленного/тестер-из-Мордора

Хорошо, я только что сделал это... моя точка в классификации ошибок не должна быть недельным часом + длинным ритуалом.
ИМХО, приоритет в соответствии с блок-схемой - это потраченное впустую время. Исправлены ошибки в Cat # 1 и # 2 - так быстро, как они появляются. Если вы оказались завалены ошибками, замедлитесь и задумайтесь. Отложите Cat # 3 и Cat # 4, если расписание не разрешает или переопределяет приоритеты.
Важно то, что у всех вас есть общее понимание этой серьезности и ожидаемого качества. Не позволяйте соблюдению святых стандартов X замедлить вас от доставки того, что хочет клиент... рабочее программное обеспечение.

Ответ 9

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

Уровень важности устанавливается командой поддержки (на основе ввода от клиента). Приоритет устанавливается клиентом (с помощью команды поддержки).

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

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

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

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

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

Ответ 10

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

Ответ 11

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

Ответ 12

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

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

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

Ответ 13

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

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

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

Ответ 14

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

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

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

Ответ 15

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

Я составил эту схему, которую мне легко запомнить:

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

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

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

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