Навіщо нам потрібні і пріоритет, і серйозність?

Я розумію, що вони визначають, але чи справді корисно віднести їх до знайдених проблем? Я маю на увазі, це потрібно або швидко виправити, або ні.

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

Абсолютно можливо, щоб ці значення відрізнялися. Якщо вам потрібно продати важливе державне агентство, яке вимагає високої продуктивності, але ніколи не використовуватиме модуль X, то для виправлення незначної помилки наявності бази даних швидше, ніж сильної помилки в модулі X, є багато ділового сенсу. В основному, технічні причини - не єдиний фактор, коли ви ведете бізнес із програмним забезпеченням .

Помилки з датою та часом

Помилка: обробка в кінці року повністю пошкодить вашу базу даних. Це явно сильна помилка.

Дата: 15 грудня. Клоп дуже пріоритетний.

Дата: 1 лютого. Помилка має низький пріоритет.

Випадковий запуск ракети-помилки

Помилка: програмне забезпечення управління ICBM спрацьовує, коли проходить з 28 лютого по 1 березня через роки, що ділиться на 4. Результат - безпрограшний запуск.

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

Навмисні «погані» слова на екрані

Помилка: Повідомлення, що переповнюють їх простір на екрані, призводять до появи ненавмисної неправдивої посилання на Боба. (Справжній світ. У нас були люди, які працюють у відділі "Заключна дупа". "Ass" = "Assembly".)

На жаль, завтра ви робите презентацію, де продажі є продажем або перервою для компанії. Ви робите презентацію комусь на ім'я "Боб". Тяжкість: Дуже низька. Пріоритет: Дуже високий.

Ви написали:

Я маю на увазі, це потрібно або швидко виправити, або ні.

Це правильно. Якщо ви схожі на більшість компаній, однак ваші ресурси обмежені. Або у вас недостатньо людей, щоб вирішити всі проблеми, або у вас недостатньо часу.

Враховуючи той факт, що помилку потрібно швидко виправити, чи ні, і у вас є багато помилок, які потрібно виправити, "пріоритет" відповідає на питання, "який я повинен виправити спочатку"?

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

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

Якщо ви в команді, де "висока ступінь серйозності == високий пріоритет", нічого з цього не має значення, і обидві показники вам не потрібні. Зрештою, це просто інструменти. Ваша команда повинна вирішити, як ними користуватися. Для вашої команди може не мати сенсу використовувати обидва.

ІМХО, і пріоритет, і серйозність - це лише бюрократія.

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

Зазвичай пріоритет йде рука об руку з суворістю. Кілька зустрічних прикладів - це "неприємність, коли всі завжди скаржаться" або "аварія, що сталася один раз в екзотичному середовищі".

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

Необхідність пріоритету зрозуміла: знати, в якому порядку слід вирішувати звіти про помилки. Інший, як зазвичай, ІМХО - це бюрократія. Чому? вам це потрібно? Це, мабуть, марно для сортування, тому що це робить пріоритет. А наслідки (опис тяжкості) так чи інакше описані у звіті про помилку.

Я навіть думаю, що це шкідливо, тому що дає менше зрозуміти, яка помилка важливіша:

• Деякі можуть подумати, що "критична" помилка має більш високий пріоритет, ніж "високий пріоритет".
• Деякі користувачі, які повідомляють про помилку, можуть плутати серйозність та пріоритетність
• ... взагалі, це швидше додає плутанини щодо того, в якому порядку потрібно боротися з помилками

Окрім інших відповідей, врахуйте цей сценарій: помилка A займе 30 хвилин для виправлення та має «низьку» ступінь тяжкості; помилка B може зайняти 2+ тижнів, щоб виправити та мати високу тяжкість. Крім того, помилка B може зайняти багато дискусій та координації в команді розробників і, можливо, поза командою; помилка A може бути виправлена ​​одним розробником негайно. Цілком чудово встановлювати більш високий пріоритет на помилку А.

Звичайно «суворість» та «пріоритетність» можуть тлумачитися по-різному.

У невеликому трекері помилок, який я створив для власного використання, я замість цього віддав перевагу «складність» та «пріоритет», де проблеми високої гостроти завжди мали б найвищий пріоритет, і я можу вирішити відкласти роботу над ними на основі складності.

Одне, що мені не подобається в «серйозності», - це те, що воно стосується лише помилок, а не функцій. Можливо, краще мати єдиний перелік усіх питань, упорядкованих за пріоритетністю та складністю, оскільки більш безпосередньо корисно вирішити, «над чим я працюю далі?».

Я розробив та впровадив процеси в програмній компанії, що отримала сертифікат ISO9001: 2007. Стандарти були оновлені з 2007 року, тому можуть бути додаткові вимоги, про які я не знаю ... однак:

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

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

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

Ключова частина полягає в тому, що те, як ваша конкретна компанія вирішує оцінити її серйозність та приймати рішення щодо пріоритетності, не визначається стандартом ISO. Компанія вирішує і документує питання комерційного та управління.

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

Серйозність помилки - лише одна точка даних. Вплив на споживача - ще одна точка даних. Також є зусилля, щоб виправити, дефектний вік, комерційне життя, що залишається в продукті, та будь-який інший фактор, який компанія вирішує включити у своє прийняття рішень. Єдине, що не повинно бути зафіксовано як "присутній дефект для менеджера продукту для вирішення пріоритету", оскільки це лише визначає повноваження для прийняття рішення і не визначає процес, за яким вони слідують для прийняття рішення.

Я маю перевагу щодо визначення пріоритетності, яке є упередженим щодо досягнення високих темпів невеликих і важливих змін, оскільки це, здається, забезпечує найкращий стимул до загальної надійності продукту. Це означає, що для серйозної помилки, яка потребує багато роботи, щоб її виправити, знадобиться її робота, розбившись на менші шматки, щоб отримати достатній пріоритет для планування.

З причини сильно відрізнятись пріоритетом та суворістю:

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

Приклад 2: додаток виходить з ладу систематично, але ця версія вимикається через кілька днів через оновлення або міграцію. Виправлення є терміновим, оскільки збої дійсно впливають на досвід користувачів, але мають малу важливість.

Звичайно, обидва параметри уніфіковані за допомогою певної метрики (формальної чи неофіційної) для створення короткострокового плану роботи, оскільки останній є одновимірним (послідовність завдань). Але в перспективі вони не повинні бути єдиними.