Risolvere quali bug daranno il massimo beneficio in termini di costi [chiuso]

Volevo farmi un'idea di classificare i bug in base a quanto è facile da risolvere e a quanti benefici mi daranno. ad esempio, se esiste un bug che richiederà un'ora (chiusura del doppio file, ecc.) per risolvere un altro che richiede un giorno (errore di segmentazione). Ma se risolvere il primo bug non è molto importante, probabilmente lavorerò sul secondo.

Esistono documenti di ricerca che classificano i bug in base al rapporto costi-benefici o metriche simili?

Diciamo che è possibile classificare i bug in base alle caratteristiche dei bug, ad es. Vulnerabilità della sicurezza, errore di memoria, errore logico ecc. Sull'altra dimensione potrebbero esserci parametri come difficoltà (facile, medio, difficile). Ci sono altre dimensioni che dovrei cercare. Per semplificare le cose, posso presumere due cose:

1. Ogni programmatore nel team è ugualmente in grado di risolvere qualsiasi bug
2. Non c'è scadenza

Il tipico sistema di tracciamento dei bug ha due, forse tre campi che identificano il rapporto costi-benefici dei bug:

1. Priorità (assegnata dal proprietario dell'attività)
2. Gravità (classificazione del bug - da critico a basso)
3. Ore stimate (indovinate quanto tempo ci vorrà per fare)

Come notate, questo identifica su quale bug è quello importante su cui lavorare.

Il sistema presentato in PEF / REV: una metrica di tracciamento dei bug multidimensionale aggiunge ulteriori informazioni sul business e sui componenti degli sviluppatori a vantaggio dei costi dei bug.

Tutti i valori sono su una scala 1 .. N (stesso valore massimo per ciascuno).

PEF è identificato dall'azienda:

• P ain - Quanto è doloroso il bug
• E Ffort - Quanto sforzo necessario per aggirare il bug
• Requisito F: con quale frequenza si verifica il bug

REV viene dallo sviluppatore:

• R isk - Quanto è rischiosa la correzione del sistema
• E ffort - Quanto impegno c'è per correggere il bug
• V erificabilità - Quanto è facile verificare la correzione dei bug

Se, ad esempio, si verifica un arresto anomalo raramente che è facile aggirare (attivare il salvataggio automatico), potrebbe essere un PEF di 7,1,1 (punteggio 9). Durante la correzione può comportare una modifica a un modulo principale e avere un REV di 9,3,2 (punteggio 14).

D'altra parte, potresti avere un fastidio che è sempre lì (3,3,9 - punteggio 15) che ha una correzione banale (1,1,3 - punteggio 5).

In questo esempio, il fastidio sembra essere una cosa migliore in termini di costi / benefici su cui lavorare.

Il problema che stai descrivendo è molto comune e la risposta migliore potrebbe essere "usa il tuo istinto".

Di solito divido i bug in tre categorie: crash, fastidioso, cosmetico (potrebbero essere chiamati 1, 2, 3 - che non importa davvero) e poi scrivo una stima complessiva sul tempo necessario per correggere ogni bug (tutti i bug devono avere una stima approssimativa aggiornata in ogni momento).

Quando risolvo i bug Arresto anomalo> Fastidioso> Cosmetico e poi faccio semplicemente un "lavoro più breve prima" per ottenere il massimo throughput iniziale possibile.

Trovo MOLTO difficile calcolare qualsiasi tipo di vantaggio finanziario diretto dalla risoluzione di qualsiasi bug, a meno che non si tratti di un lavoro retribuito con obiettivi molto ristretti.

Una nota di cui potresti aver bisogno è che dovresti davvero essere all'altezza del quinto punto di The Joel Test - questo potrebbe essere influenzato dalla dimensione del team e dalla distribuzione tra vari altri problemi "locali" - ma è generalmente un segno di buone pratiche.

Un'altra considerazione potrebbe essere il tipo di test o organizzazione di test che scopre il bug, quando si cerca di determinare l'impatto e il costo del bug e correggere. I test unitari o funzionali possono indicare qualcosa nel progetto che deve essere modificato, e quindi correggerli in anticipo sarebbe più facile e meno costoso di quelli successivi. I test di sistema o di integrazione possono indicare qualcosa che interessa una più ampia varietà di clienti. E i test sugli standard, sebbene spesso non critici per un ampio sottogruppo di clienti, possono portare a una perdita di certificazione se non corretti e avere un impatto negativo sul business.

Detto questo, solo perché una particolare organizzazione di test ha un fallimento del test non dovrebbe automaticamente rendere un bug "critico". Ad esempio, potrebbe esserci la tentazione di dire qualcosa del tipo "tutti i test di sistema devono passare prima della spedizione, quindi qualsiasi test di sistema che fallisce si traduce automaticamente in un bug critico / severo". Si spera che nessuna organizzazione faccia questa affermazione (i buoni criteri di uscita dal test sono una discussione diversa), ma il punto è che la "gravità" del bug dovrebbe essere valutata in base al suo impatto sull'immagine del cliente, del prodotto o dell'azienda piuttosto che su dove o quando è scoperto.

Un modo possibile di affrontare è quello di fare una distinzione tra "gravità" e "urgenza". Ad esempio, mentre si avvicina la data di rilascio, può esserci una pressione del tempo per determinare se un bug apparentemente di gravità inferiore potrebbe interessare un ampio sottoinsieme di clienti, conferendo al bug una maggiore "urgenza" ed elevando il lavoro su quel bug sopra (alcuni) altri su almeno fino a quando non sarà possibile effettuare tale determinazione. Un giusto equilibrio tra i due, insieme all'esperienza e al buon senso, aiuterebbe a dirigere dove vengono spesi tempo e fatica.

Oltre a ciò che altri hanno detto sulla classificazione dei bug, ecc., Considera anche di considerare Afferent Coupling (Ca) per determinare il livello di criticità che un determinato bug potrebbe rappresentare. Se hai un bug in un modulo con un elevato conteggio di Ca, potrei cercare di risolverlo prima perché potrebbe beneficiare altri componenti del sistema. Ca ti aiuta a determinare il livello di responsabilità e i moduli responsabili con bug in essi danneggiano l'intera applicazione (leggi di più su Ca qui: http://www.ibm.com/developerworks/java/library/j-cq04256/index.html ).

Con questo in mente, tendiamo a classificare i bug e a metterli in priorità in base al loro impatto sul cliente. Il cliente varierà, ma coinvolgerli nella discussione alla fine determinerà quali bug dovrebbero essere corretti sugli altri. Non è una vera scienza, ma come gruppo intero tendiamo a giungere a un consenso sulla priorità e la categorizzazione dei bug, ognuno ha input su quelli "grandi" (tutti gli stakeholder possono dare input) e da lì impiliamo e creiamo.

Non è possibile determinare il costo effettivo di tutti i bug. Alcuni è possibile, per molti è molto difficile da quantificare. Ad esempio, supponiamo che tu abbia un bug che provoca un leggero disallineamento di tutto il testo sui pulsanti. Rende il tuo prodotto 1.0 un po 'trasandato. Ciò non causa l'arresto anomalo del programma o la perdita di dati da parte degli utenti. Probabilmente un bug piuttosto economico, giusto?

Ora, cosa succede se ogni tuo cliente nota questo problema e ogni revisore lo menziona nelle recensioni del tuo prodotto. E se questo bug si ripercuotesse dalla versione 1.0 alla 1.1 e 1.2. La tua azienda potrebbe ora avere la reputazione di essere un po 'sciatta nel controllo di qualità. Quanto potrebbe costare questo semplice bug in termini di potenziali vendite perse per la tua azienda per prodotti futuri? Oppure, in che modo ciò potrebbe influire su una recensione del tuo prodotto: il tuo prodotto potrebbe soddisfare perfettamente le esigenze dei tuoi clienti, ma ottiene solo un 9 su 10 perché sembra un po 'sciatto.

Pertanto, è necessario non solo esaminare il costo di un bug specifico in termini di costi da correggere e impatto diretto sull'utente, ma è necessario considerarlo nel contesto più ampio di come influisce sulla percezione del prodotto sul mercato e in che modo tale percezione influisce sulle vendite future.

Questo può sembrare inverosimile ma non lo è. Nel momento in cui scrivo questo, puoi andare su un altro sito Web che contiene un articolo su come Apple ha spostato l '"1" sull'icona del suo calendario sopra di un pixel o due. Se fai una ricerca, vedrai diversi articoli negativi su questo piccolo bug. Naturalmente, questo non ha influenzato direttamente i profitti di Apple, ma si promuovono come l'apice del buon design, quindi avere un bug di design influisce su quella percezione, anche se solo leggermente.