Risolvendo quali bug daranno maggiori benefici in termini di costi [chiuso]

Il tipico sistema di tracciamento dei bug ha due, forse tre campi che identificano il rapporto costo beneficio bug:

1. Priorità (assegnata dal proprietario dell'attività commerciale)
2. Gravità (classificazione del bug - fondamentale per il basso)
3. Ore stimate (un'ipotesi su quanto tempo ci vorrà)

Come puoi notare, questo identifica quale bug è il più importante su cui lavorare.

Il sistema presentato in PEF / REV: una metrica di tracciamento dei bug multidimensionale aggiunge maggiori informazioni sul business e componenti dello sviluppatore per il bug vantaggio in termini di costi.

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

PEF è identificata dall'azienda:

• P ain - Quanto è doloroso il bug
• E ffort: quanto impegno ci vuole per aggirare il bug
• F requisito - Con quale frequenza si verifica il bug

REV viene dallo sviluppatore:

• R isk: quanto è rischiosa la correzione per il sistema
• E ffort: quanta fatica c'è per correggere l'errore
• V erifiability - Quanto è facile verificare la correzione di bug

Se, ad esempio, si verifica un incidente raramente facile da aggirare (attivare il salvataggio automatico), potrebbe essere un PEF di 7,1,1 (punteggio 9). Mentre risolverlo 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 soluzione banale (1,1,3 - punteggio 5).

In questo esempio, il fastidio sembra essere una migliore soluzione di costo / beneficio 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: Crashing, Fastidioso, Cosmetico (potrebbero essere chiamati 1, 2, 3 - non importa) e quindi fare una stima generale del tempo necessario per correggere ogni bug ( tutti i bug devono avere una stima aggiornata approssimativa in ogni momento.

Quando si risolvono i bug Crashing > Fastidioso > Estetica e quindi faccio semplicemente un "lavoro più breve prima" per ottenere il massimo throughput possibile.

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

Una nota di cui potresti aver bisogno è che dovresti davvero vivere fino al quinto punto su Il test di Joel - questo potrebbe essere influenzato dalle dimensioni del team e dalla distribuzione tra le varie questioni "locali", ma generalmente è un segnale 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 della correzione. Le prove unitarie o funzionali possono indicare qualcosa nel progetto che deve essere cambiato, e quindi correggere in anticipo sarebbe più facile e meno costoso che dopo. Il test di sistema o di integrazione può indicare qualcosa che interessa una più ampia varietà di clienti. Inoltre, i test degli standard, sebbene spesso non critici per un ampio gruppo di clienti, possono portare a una perdita di certificazione se non vengono corretti e hanno un impatto negativo sul business.

Detto questo, solo perché una particolare organizzazione di test ha fallito un test non dovrebbe automaticamente rendere un bug "critico". Ad esempio, potrebbe esserci la tentazione di dire qualcosa come "tutti i test di sistema devono passare prima della spedizione, quindi qualsiasi test di sistema che fallisce porta automaticamente a un bug critico / di elevata severità". Si spera che nessuna organizzazione faccia questa affermazione (i buoni criteri di uscita del test sono una discussione diversa), ma il punto è che la "gravità" del bug dovrebbe essere giudicata dal suo impatto sul cliente, sul prodotto o sull'immagine aziendale piuttosto che sul luogo o quando è scoperto

Un modo possibile per affrontare questo è fare una distinzione tra "gravità" e "urgenza". Ad esempio, quando la data di rilascio si avvicina, ci può essere la pressione del tempo per determinare se un bug apparentemente di minor gravità potrebbe interessare un grosso gruppo di clienti, dando al bug una maggiore "urgenza" e aumentando il lavoro su quel bug sopra (alcuni) altri a almeno fino a quando tale determinazione può essere fatta. Un giusto equilibrio tra i due, insieme all'esperienza e al buon giudizio, aiuterebbe a dirigere dove vengono spesi tempo e sforzi.

Oltre a ciò che altri hanno detto sulla classificazione dei bug, ecc, considera anche l'Afferent Coupling (Ca) per determinare il livello di criticità che un particolare bug potrebbe rappresentare. Se si ha un bug in un modulo con un alto numero di Ca, potrei cercare di correggere quello per primo in quanto potrebbe avvantaggiare altri componenti nel 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: link ).

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

Non puoi determinare il costo effettivo di tutti i bug. Alcuni puoi, per molti è molto difficile da quantificare. Ad esempio, supponiamo di avere un bug che risulta in tutto il testo sui pulsanti leggermente disallineati. Rende il tuo prodotto 1.0 un po 'sciatto. Ciò non causa l'arresto anomalo del programma o la perdita di dati da parte degli utenti. Probabilmente un bug piuttosto economico, vero?

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

Quindi, non devi solo considerare il costo di un bug specifico in termini di costi che è necessario correggere e l'impatto diretto sull'utente, ma devi considerarlo nel contesto più ampio di come influenza la percezione del tuo 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 visitare un altro sito sul Web che contiene un articolo su come Apple ha spostato il "1" sull'icona del calendario su un pixel o due. Se fai una ricerca vedrai diversi articoli negativi su questo piccolo piccolo insetto. Ovviamente, questo non ha influenzato direttamente la linea di fondo di Apple, ma si promuovono come l'apice del buon design, quindi avere un bug di progettazione influenza quella percezione, anche se solo leggermente.