Capisco cosa determinano ma è davvero utile assegnarli a quelli trovati? Voglio dire, è necessario o risolto in fretta o meno.
So come impostarli, categorizzarli ecc. So che IEEE / ISO richiedono di farlo. Non vedo perché.
È assolutamente possibile che tali valori differiscano. Se si ha una vendita da fare a un'agenzia governativa importante che richiede prestazioni elevate ma non utilizzerà mai il modulo X, allora ha molto senso per risolvere un errore di disponibilità del database minore prima di un grave errore nel modulo X. Fondamentalmente, le ragioni tecniche non sono l'unico fattore quando esegui un software business .
Bug: l'elaborazione di fine anno danneggerà completamente il tuo database. Questo è chiaramente un bug grave.
Data: 15 dicembre. Il bug ha una priorità molto alta.
Data: 1 febbraio. Il bug ha bassa priorità.
Bug: il software di controllo ICBM esplode quando si passa dal 28 febbraio al 1 ° marzo negli anni divisibili per 4. Il risultato è un lancio non controllato.
Questo è un bug grave che può esistere. Priorità molto bassa, tuttavia: esiste una possibilità realistica che il software sia in uso quando viene attivata la condizione?
Bug: i messaggi che invadono il loro spazio sullo schermo generano un riferimento profano involontario a Bob che appare. (Mondo reale: avevamo persone che lavoravano nel reparto "Ass finale". "Ass"="Assemblea".)
Sfortunatamente, domani stai facendo una presentazione dove ottenere la vendita è make-or-break per l'azienda. Stai facendo la presentazione a qualcuno di nome "Bob". Gravità: molto basso. Priorità: molto alto.
Hai scritto:
I mean, it is either required to fixed quickly or not.
È corretto. Se sei come la maggior parte delle aziende, tuttavia, le tue risorse sono limitate. O non hai abbastanza persone per risolvere tutti i problemi o non hai abbastanza tempo.
Dato che un bug deve o essere riparato velocemente o no, e hai molti bug che devono essere corretti, "priority" risponde alla domanda "quale posso risolvere prima"?
La severità, d'altra parte, è un indicatore utilizzato dalla persona che imposta la priorità. Dal punto di vista dello sviluppatore, la gravità è un punto controverso. Dal punto di vista di chi assegna il lavoro, la severità è un'informazione importante che aiuta nel processo decisionale.
Naturalmente, tutto questo è un'informazione molto generale. Se sei un team con un backlog di bug incredibilmente lungo, priorità e severità significano qualcosa di completamente diverso rispetto a quando sei in una squadra con un database di bug quasi vuoto.
Se ti trovi in una squadra in cui "alta severità == alta priorità" nessuna di queste cose è importante e non hai bisogno di entrambe le metriche. Alla fine della giornata, questi sono solo strumenti. Il tuo team deve decidere come usarli. Per il tuo team potrebbe non avere senso usare entrambi.
IMHO, mettendo sia Priority che Severity è solo burocrazia.
In pratica, hai solo bisogno di una misura di "importanza". Spesso viene utilizzata la priorità e la severità viene quindi utilizzata come termine tecnico come "high = arresta il sistema o lo rende inutilizzabile", "media = comportamento bacato, potenzialmente dannoso", "basso = fastidio, fastidioso ma innocuo"
Di solito, la priorità va di pari passo con la gravità. Alcuni esempi contrari sono una "seccatura in cui tutti si lamentano sempre" o un "incidente avvenuto una volta in un ambiente esotico".
... ma, alla fine, come sviluppatore (o manager, ecc.) devi solo sapere in quale ordine devi correggere / migliorare le cose, tutto qui. Quindi una misura è sufficiente.
Il bisogno di priorità è chiaro: è sapere in quale ordine devono essere affrontate le segnalazioni di bug. L'altra, IMHO come al solito, è la burocrazia. Perché ti serve? È apparentemente inutile per l'ordinamento perché la priorità lo fa. E le conseguenze (descrizione della gravità) sono comunque descritte nella segnalazione di bug.
Penso che sia dannoso perché rende meno chiaro quale bug sia più importante:
Oltre alle altre risposte, considera questo scenario: il bug A richiede 30 minuti per risolverlo e ha un livello di gravità basso; l'errore B può richiedere più di 2 settimane per risolverlo e avere una gravità "elevata". Inoltre, l'errore B può richiedere molta discussione e coordinamento nel team di sviluppo e, forse, al di fuori del team; il bug A può essere corretto immediatamente da single dev. È perfettamente corretto impostare una priorità più alta sul bug A.
Naturalmente "severità" e "priorità" possono essere interpretati in modi diversi.
In un piccolo bug tracker che ho fatto per mio uso preferivo invece "difficoltà" e "priorità" in cui i problemi di severità avrebbero sempre avuto la massima priorità, e potrei decidere di ritardare il loro lavoro in base alla difficoltà.
Una cosa che non mi piace di 'severità' è che si applica solo ai bug e non alle funzionalità. Potrebbe essere meglio avere un'unica lista di tutti i problemi ordinati per priorità e difficoltà in quanto è più direttamente utile decidere "a cosa lavoro lavorerò il prossimo?".
Un semplice esempio. Immagina di avere una posizione ristretta che impedisce il ridimensionamento del tuo sistema - alcuni algoritmi hanno complessità O (N ^ 3), dove N è il numero di negozi del cliente. Il cliente dice che aprirà 200 nuovi negozi il prossimo anno e che i calcoli necessari (distribuzione delle merci, pianificazione dei trasporti, ecc.) Non saranno terminati in tempo. Ma attualmente questo client ha solo 30 negozi e le risorse sono sufficienti. Il compito di ottimizzare questo algoritmo (su O (N ^ 2) o meglio) è sicuramente importante (perderai il client se non implementato), ma probabilmente non urgente: hai qualche mese per implementare il nuovo algoritmo.
Un esempio opposto: salva alcuni dati temporanei, che possono essere ricalcolati in poche ore, dalla cancellazione automatica. È urgente perché verrà eliminato in pochi minuti, ma non è importante perché il ricalcolo è disponibile e piuttosto economico. (Sì, questo non è formalmente un "bug", ma le analogie possono essere facilmente definite.)
Naturalmente, entrambi i parametri sono unificati usando una certa metrica (formale o informale) per produrre un piano di lavoro a breve termine, perché quest'ultimo è monodimensionale (sequenza di compiti). Ma nella visione a lungo termine non devono essere unificati.