Зачем нам нужны как приоритет, так и серьезность?

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

Я знаю, как их устанавливать, классифицировать и т. Д. Я знаю, что IEEE / ISO требуют этого. Я просто не понимаю, почему.

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

Дата и время ошибки

Ошибка: обработка в конце года полностью испортит вашу базу данных. Это явно серьезная ошибка.

Дата: 15 декабря. Ошибка имеет очень высокий приоритет.

Дата: 1 февраля. Ошибка с низким приоритетом.

Случайный запуск ракеты

Ошибка: управляющее программное обеспечение МБР испытывает рвоту при переходе с 28 февраля на 1 марта в годы, кратные 4. Результатом является незапланированный запуск.

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

Случайные «плохие» слова на экране

Ошибка: сообщения, переполняющие их пространство на экране, приводят к непреднамеренной светской ссылке на Боба. (Реальный мир: у нас были люди, работающие в отделе "Final Ass". "Ass" = "Assembly".)

К сожалению, завтра вы устраиваете презентацию, в которой получение продажи является для компании случайным. Вы делаете презентацию кому-то по имени "Боб". Серьезность: очень низкая. Приоритет: очень высокий.

Вы написали:

Я имею в виду, это нужно исправить быстро или нет.

Это правильно. Если вы похожи на большинство компаний, ваши ресурсы ограничены. Либо у вас недостаточно людей, чтобы решить все проблемы, либо у вас недостаточно времени.

Учитывая тот факт, что ошибка либо должна быть исправлена ​​быстро, либо нет, и у вас есть много ошибок, которые нужно исправить, «приоритет» отвечает на вопрос «какую из них я исправляю первой»?

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

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

Если вы работаете в команде, где «высокая серьезность == высокий приоритет», все это не имеет значения, и вам не нужны оба показателя. В конце концов, это всего лишь инструменты. Ваша команда должна решить, как их использовать. Для вашей команды может не иметь смысла использовать оба.

ИМХО, ставить и Приоритет, и Серьезность - это просто бюрократия.

На практике вам просто нужна одна мера «важности». Зачастую для него используется приоритет, а серьезность используется в качестве технического термина, такого как «высокий = сбой системы или делает ее непригодной для использования», «средний = ошибочное поведение, потенциально вредный», «низкий = неприятный, раздражающий, но безвредный»

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

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

Необходимость приоритета очевидна: это знать, в каком порядке должны обрабатываться сообщения об ошибках. Другой, как обычно, ИМХО, это бюрократия. Зачем тебе это? Это очевидно бесполезно для сортировки, потому что приоритет делает это. И последствия (описание серьезности) описаны в отчете об ошибке в любом случае.

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

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

В дополнение к другим ответам рассмотрим следующий сценарий: исправление ошибки A займет 30 минут и имеет «низкую» серьезность; Исправление ошибки B может занять более 2 недель и иметь «высокую» серьезность. Кроме того, ошибка B может потребовать много обсуждений и координации в команде разработчиков и, возможно, вне команды; ошибка A может быть немедленно исправлена ​​одним разработчиком. Прекрасно установить более высокий приоритет для ошибки А.

Конечно, «серьезность» и «приоритет» могут интерпретироваться по-разному.

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

Что мне не нравится в «серьезности», так это то, что она относится только к ошибкам, а не к функциям. Может быть лучше иметь единый список всех вопросов, упорядоченных по приоритету и сложности, так как более полезно решить, «над чем я буду работать дальше?».

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

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

На этапе проектирования требования сосредотачиваются на том, действительно ли предлагаемое решение, если оно реализовано правильно, действительно решает задание на проектирование (проверка) и проверяет, была ли реализация фактически реализована без дефекта (проверка)

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

Ключевым моментом является то, что то, как ваша конкретная компания решает оценить ее серьезность и принять решение о приоритете, не определяется стандартом ISO. Это коммерческая и управленческая проблема, которую компания должна решить и задокументировать.

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

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

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

По причине сильно различаться приоритет и серьезность:

Простой пример Представьте себе, что у вас есть узкое место, которое предотвращает масштабирование вашей системы - некоторый алгоритм имеет сложность O (N ^ 3), где N - количество хранилищ клиента. Клиент говорит, что в следующем году откроет 200 новых магазинов, и необходимые расчеты (распределение товаров, планирование транспортировки и т. Д.) Не будут выполнены вовремя. Но на данный момент у этого клиента всего 30 магазинов, и ресурсов достаточно. Задача оптимизации этого алгоритма (до O (N ^ 2) или лучше) определенно важна (вы потеряете клиента, если не будете реализованы), но, вероятно, не срочно: у вас есть несколько месяцев для реализации нового алгоритма.

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

Конечно, оба параметра унифицированы с использованием некоторой метрики (формальной или неформальной) для создания краткосрочного плана работы, поскольку последний является одномерным (последовательность задач). Но в долгосрочной перспективе они не должны быть объединены.