C'è un vantaggio marginale nel correggere i bug [chiuso]

Ho sentito da un ex collega che non tutti i bug devono essere corretti, poiché man mano che si scende l'elenco prioritario dei bug, il caso d'uso che causa quel bug diventa più oscuro o la soddisfazione del cliente acquisita diminuisce. Ma devi ancora dedicare molto tempo a correggere quel bug.

Nel tentativo di convincere il nostro product owner a questo concetto, non sono riuscito a trovare buone risorse. Tutto quello che ho potuto trovare sono state le discussioni sull'esistenza o meno di un costo marginale nello sviluppo del software.

C'è davvero un vantaggio marginale nel correggere i bug? C'è un termine diverso che spiega questo concetto?

Dal punto di vista aziendale, una correzione di bug non è diversa da una richiesta di funzionalità. Ha un certo costo nei tempi di sviluppo e ha un certo valore per i clienti. Se un bug non è critico, può essere assolutamente logico dare la priorità a una caratteristica importante al di sopra della correzione.

Ma da un punto di vista tecnico, i bug possono essere più critici, poiché indicano un errore in una base su cui potrebbe utilizzare / costruire altro codice, nel qual caso l'errore è "contagioso" e aggiunge costi alla manutenzione futura. Quindi non correggere un bug è un debito tecnico che richiede una gestione, mentre la mancata implementazione di una funzionalità non ha costi costanti. Ma il livello di debito tecnico sostenuto da un bug dipende molto dalla natura del bug.

Tutti questi fattori dovrebbero essere presi in considerazione quando si stabiliscono le priorità.

Per quanto riguarda se c'è un vantaggio marginale nel correggere i bug: questo è un dato di fatto. Dal momento che non tutti i bug hanno la stessa gravità, naturalmente dai la priorità ai bug più importanti per primi. Quindi più bug correggi, più basso è il valore marginale di correzione del prossimo. Ma se raggiunge il livello in cui è stato corretto il bug non vale la pena, è una decisione commerciale piuttosto che una decisione tecnica.

Ecco un buon riferimento

http://www.joelonsoftware.com/articles/fog0000000043.html

Correggi i bug prima di scrivere un nuovo codice? La primissima versione di Microsoft Word per Windows era considerata un progetto di "marcia della morte". [...] perché la fase di correzione dei bug non faceva parte del programma formale [...]

Microsoft ha adottato universalmente qualcosa che [...] la massima priorità è eliminare i bug prima di scrivere qualsiasi nuovo codice [...] In generale, più si aspetta prima di correggere un bug, più costoso (in termini di tempo e denaro) è quello di risolvere .

Puoi essere sicuro che più a lungo saranno presenti questi bug, più tempo ci vorrà per risolverli una volta che diventano la priorità. Quindi, invece di avere subito un vantaggio, stai evitando una perdita più costosa in futuro.

Un buon modo per gestirlo sarebbe definire una quantità di tempo allocata per la gestione dei problemi di backlog. Questo non farebbe impazzire come ha fatto Microsoft, ma garantirà una quantità di problemi futuri da risolvere, se non sono già il tuo problema anche se al cliente non importa davvero.

Nel tentativo di convincere il nostro product owner a questo concetto, non sono riuscito a trovare buone risorse.

Supponendo che tu stia lavorando per un'organizzazione commerciale, ci sarà sicuramente qualcuno che è a conoscenza dell'analisi costi-benefici .

La tua organizzazione ha una quantità limitata di risorse per sviluppatori e un elenco infinito di cose utili da fare. Tali vantaggi comprendono sia l'aggiunta di nuove funzionalità sia la rimozione di bug esistenti: la rimozione di un bug migliora il software, proprio come l'aggiunta di una nuova funzionalità.

Quindi, ovviamente, ci sono decisioni da prendere su come allocare questa risorsa finita a questo elenco infinito, e non è particolarmente sorprendente che il risultato sia che alcuni bug non vengono corretti in questo momento, o la prossima settimana, o il prossimo anno, o in fatto mai.

Se stai cercando un approccio più strutturato qui, potresti provare il sistema PEF / REV che assegna i numeri alle visualizzazioni utente e programmatore di un bug, come punto di partenza per decidere cosa viene risolto e cosa no.

Vedi anche questi due post qui su Ingegneria del software:

Risolvere i bug che daranno il massimo beneficio in termini di costi

Quasi ogni bug segnalato è un bug ad alta priorità

Non tutti gli aspetti involontari o indesiderati del comportamento del software sono bug. Ciò che è importante è garantire che il software abbia una gamma utile e documentata di condizioni in cui si può fare affidamento per operare in modo utile. Si consideri, ad esempio, un programma che dovrebbe accettare due numeri, moltiplicarli e produrre i risultati e che genera un numero falso se il risultato è superiore a 9,95 ma inferiore a 10,00, superiore a 99,95 ma inferiore a 100,00, ecc. Se il programma fosse stato scritto allo scopo di elaborare numeri il cui prodotto era compreso tra 3 e 7 e non verrà mai chiamato a processarne altri, fissarne il comportamento con 9,95 non lo renderebbe più utile per lo scopo previsto. Potrebbe, tuttavia, rendere il programma più adatto per altri scopi.

In una situazione come quella sopra, ci sarebbero due linee d'azione ragionevoli:

1. Risolvi il problema, se è così pratico.

2. Specificare intervalli in cui l'output del programma sarebbe affidabile e dichiarare che il programma è adatto solo per l'uso su dati che sono noti per produrre valori all'interno di intervalli validi.

L'approccio n. 1 eliminerebbe il bug. L'approccio n. 2 potrebbe rendere i progressi meno adatti per alcuni scopi di quanto potrebbe altrimenti essere, ma se non è necessario che i programmi gestiscano i valori problematici, ciò potrebbe non costituire un problema.

Anche se l'incapacità di gestire correttamente i valori da 99,95 a 100,0 è il risultato di un errore di programmazione [ad es. Decidere di emettere due cifre a sinistra del punto decimale prima di arrotondare a un punto dopo, ottenendo quindi 00,00], dovrebbe essere considerato solo un bug se il programma sarebbe altrimenti specificato come produrre output significativi in ​​tali casi. [Per inciso, il suddetto problema si è verificato nel codice printf Turbo C 2.00; in quel contesto, è chiaramente un bug, ma il codice che chiama il printf difettoso sarebbe difettoso solo se potesse produrre output negli intervalli problematici].

In senso lato, sì, non tutti i bug devono essere corretti. Si tratta di analizzare il rapporto rischio / beneficio.

Ciò che generalmente accade è che il business avrà un incontro con i lead tecnici e le parti interessate per discutere di bug che non sono ovviamente nella pila del "bisogno di risolvere". Decideranno se il tempo (= denaro) investito nella correzione del bug varrà la pena per l'azienda.

Ad esempio, un "bug minore" potrebbe essere un leggero errore di ortografia / grammatica nella sezione Termini e condizioni di un sito Web. L'individuo che ha sollevato questo aspetto potrebbe ritenerlo troppo piccolo per cambiare, ma l'azienda riconoscerebbe il potenziale danno che potrebbe causare al marchio e la relativa facilità di fissare alcuni personaggi.

D'altra parte, potresti avere un bug che sembra importante, ma è difficile da correggere e interessa solo una quantità trascurabile di utenti. Ad esempio, un collegamento pulsante secondario viene interrotto per gli utenti che utilizzano una versione legacy di Google Chrome e anche Javascript disabilitato.

Altri motivi per cui il business NON risolve un bug potrebbe essere che il tempo investito riporterebbe indietro il progetto inaspettatamente, o che il tempo dello sviluppatore sarebbe meglio speso lavorando su altre correzioni / codifica. Potrebbe anche essere che il bug sia abbastanza piccolo da poter essere pubblicato e quindi risolto in un secondo momento.

Spero che questo spieghi il concetto un po 'meglio! Eviterei sicuramente di pensarci in termini generali: ogni insetto è unico e dovrebbe essere trattato come tale.

Perché man mano che si procede nell'elenco prioritario dei bug, il caso d'uso che causa quel bug diventa più oscuro o la soddisfazione del cliente acquisita diminuisce.

Quindi il loro "argomento" è in realtà

Se si ignora il bug abbastanza a lungo, l'utente dimenticherà il problema o troverà un modo per aggirare il problema.

I bug dovrebbero essere prioritari e trattati "in ordine" proprio come le nuove Richieste di funzionalità (ma, probabilmente, oltre a queste ultime).