Perché abbiamo bisogno sia della priorità che della gravità?

Capisco cosa determinano, ma è davvero utile assegnarli a problemi rilevati? Voglio dire, è necessario ripararlo rapidamente o no.

So come impostarli, classificarli, ecc. So che IEEE / ISO richiedono di farlo. Non vedo proprio il perché.

È assolutamente possibile che questi valori differiscano. Se hai una vendita da fare a un'importante agenzia governativa che richiede alte prestazioni ma non utilizzerà mai il modulo X, allora ha molto senso commerciale correggere un errore minore di disponibilità del database prima di un grave errore nel modulo X. In sostanza, tecnici ragioni non sono l'unico fattore quando si esegue un software di business .

Bug di data e ora

Bug: l'elaborazione di fine anno corromperà totalmente il tuo database. Questo è chiaramente un bug grave.

Data: 15 dicembre. Il bug ha una priorità molto alta.

Data: 1 febbraio. Il bug ha una priorità bassa.

Lancio accidentale del bug missilistico

Bug: il software di controllo ICBM si attiva quando va dal 28 febbraio al 1 marzo in anni divisibili per 4. Il risultato è un lancio senza comandi.

È un bug tanto grave quanto può esistere. Priorità molto bassa, però - c'è qualche possibilità realistica che il software sarà utilizzato quando la condizione viene attivata?

Invertite "cattive" parole sullo schermo

Bug: i messaggi che traboccavano del loro spazio sullo schermo provocano un riferimento profano involontario alla comparsa di Bob. (Mondo reale: avevamo persone che lavoravano nel dipartimento "Final Ass". "Ass" = "Assembly".)

Sfortunatamente, domani farai una presentazione in cui ottenere la vendita è una svolta per l'azienda. Stai presentando la presentazione a qualcuno chiamato "Bob". Gravità: molto bassa. Priorità: molto alta.

Hai scritto:

Voglio dire, è necessario ripararlo rapidamente o no.

È 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 essere riparato rapidamente o no e che hai molti bug che devono essere corretti, "priorità" risponde alla domanda "quale devo risolvere per primo"?

La gravità, d'altra parte, è un indicatore utilizzato dalla persona che imposta la priorità. Dal punto di vista di uno sviluppatore la gravità è un punto controverso. Dal punto di vista di quello che assegna il lavoro, la gravità è un'importante informazione che aiuta nel processo decisionale.

Naturalmente, tutto ciò è un'informazione molto generale. Se sei un team con un arretrato di bug incredibilmente lungo, priorità e gravità significano qualcosa di completamente diverso rispetto a un team che ha un database di bug quasi vuoto.

Se fai parte di un team in cui "alta severità == alta priorità" nulla di tutto ciò è importante e non hai bisogno di entrambe le metriche. Alla fine, questi sono solo strumenti. Il tuo team deve decidere come usarli. Per la tua squadra potrebbe non avere senso usare entrambi.

IMHO, mettere sia la priorità che la gravità è solo burocrazia.

In pratica, hai solo bisogno di una misura di "importanza". Spesso, viene usata la priorità per questo, e la gravità viene quindi usata come termine tecnico come "alto = crash del sistema o lo rende inutilizzabile", "medio = comportamento errato, potenzialmente dannoso", "basso = fastidio, fastidioso ma innocuo"

Di solito, la priorità va di pari passo con la gravità. Alcuni esempi contrari sono un "fastidio in cui tutti si lamentano sempre" o un "incidente che si è verificato una volta in un ambiente esotico".

... ma, alla fine, come sviluppatore (o gestore, ecc.) devi solo sapere in quale ordine dovresti sistemare / migliorare le cose, tutto qui. Quindi è sufficiente una misura.

La necessità di priorità è chiara: è sapere in quale ordine devono essere affrontate le segnalazioni di bug. L'altro, IMHO come al solito, è la burocrazia. Perché ne hai bisogno? È apparentemente inutile per l'ordinamento perché la priorità lo fa. E le conseguenze (descrizione della gravità) sono comunque descritte nella segnalazione di bug.

Penso anche che sia dannoso perché rende meno chiaro quale bug è più importante:

• Alcuni potrebbero pensare che un bug "critico" abbia una priorità maggiore rispetto a un bug "ad alta priorità".
• Alcuni utenti che segnalano un bug possono confondere la gravità e la priorità
• ... nel complesso, aggiunge piuttosto confusione sull'ordine in cui gli insetti dovrebbero essere affrontati

Oltre ad altre risposte, considera questo scenario: il bug A richiederà 30 minuti per essere risolto e ha una gravità "bassa"; il bug B può richiedere più di 2 settimane per essere risolto e avere una gravità "elevata". Inoltre, il bug B può richiedere molte discussioni e coordinazioni nel team di sviluppo e forse al di fuori del team; il bug A può essere risolto immediatamente da un singolo sviluppatore. Va perfettamente bene impostare una priorità più alta sul bug A.

Naturalmente "severità" e "priorità" possono essere interpretate in diversi modi.

In un piccolo inseguitore di bug che ho realizzato per uso personale ho preferito invece "difficoltà" e "priorità" in cui i problemi di alta gravità avrebbero sempre avuto la massima priorità e potrei decidere di ritardare a lavorarci in base alla difficoltà.

Una cosa che non mi piace della "gravità" è che si applica solo ai bug e non alle funzionalità. Potrebbe essere meglio avere un unico elenco di tutti i problemi ordinati per priorità e difficoltà poiché è più direttamente utile decidere "su cosa lavorerò dopo?".

Ho progettato e implementato processi in un'azienda software certificata ISO9001: 2007. Ci sono stati aggiornamenti allo standard dal 2007, quindi potrebbero esserci requisiti aggiuntivi di cui non sono a conoscenza ... tuttavia:

Lo standard ISO9001 mira a garantire che la vostra azienda progetta e implementa processi con circuiti di feedback per migliorare il processo quando vengono identificati difetti di prodotto e di processo.

Durante la fase di progettazione i requisiti si concentrano sul fatto che la soluzione proposta, se implementata correttamente, risolva effettivamente il brief di progettazione (convalida) e controlla se l'implementazione è stata effettivamente implementata senza difetti (verifica)

Nel circuito di feedback, quando vengono identificati i difetti, non è sufficiente che vengano registrati. Un difetto deve anche essere valutato per gravità e priorità di rilavorazione.

La parte fondamentale è che il modo in cui la tua azienda decide di valutarne la gravità e di prendere decisioni sulla priorità non è definito dallo standard ISO. È un problema commerciale e di governance che l'azienda decide e documenta.

Come è scritto nello standard come requisito, ogni azienda certificata avrà un processo per valutare la gravità di un difetto e un processo per determinare la priorità del lavoro per correggere il bug. Sono sicuramente due decisioni separate che devono essere prese.

La gravità del bug è solo un punto dati. Impatto sul cliente È un altro punto dati. C'è anche uno sforzo per correggere, l'età del difetto, la vita commerciale rimanente nel prodotto e qualsiasi altro fattore che l'azienda decide di includere nel suo processo decisionale. L'unica cosa che non dovrebbe essere scritta come "difetto attuale al product manager per decidere la priorità" in quanto ciò definisce solo l'autorità per prendere la decisione e non definisce il processo che seguono per prendere la decisione.

Ho una preferenza per la definizione delle priorità che è orientata a fornire un alto tasso di piccoli e importanti cambiamenti, poiché questo sembra fornire il miglior impulso all'affidabilità complessiva del prodotto. Ciò significa che un grave bug che richiederà molto lavoro per essere risolto avrebbe bisogno di essere suddiviso in blocchi più piccoli per avere priorità sufficiente per essere programmato.

Per motivi di forte differenza tra priorità e gravità:

Un semplice esempio Immagina di avere un posto ristretto che impedisce il ridimensionamento del tuo sistema: alcuni algoritmi hanno una complessità O (N ^ 3), dove N è il conteggio dei negozi del cliente. Il cliente afferma che aprirà 200 nuovi negozi l'anno successivo e che i calcoli necessari (distribuzione delle merci, pianificazione dei trasporti, ecc.) Non saranno completati in tempo. Ma attualmente questo cliente ha solo 30 negozi e le risorse sono sufficienti. Il compito di ottimizzare questo algoritmo (su O (N ^ 2) o superiore) è sicuramente importante (perderai il client se non implementato), ma probabilmente non urgente: hai qualche mese per implementare il nuovo algoritmo.

Esempio 2: un'applicazione si arresta in modo sistematico, ma questa versione si disattiva in pochi giorni a causa dell'aggiornamento o della migrazione. La riparazione è urgente perché gli arresti anomali influiscono davvero sull'esperienza dell'utente, ma è di scarsa importanza.

Naturalmente, entrambi i parametri sono unificati utilizzando una metrica (formale o informale) per produrre un piano di lavoro a breve termine, poiché quest'ultimo è monodimensionale (sequenza di attività). Ma a lungo termine non devono essere unificati.