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

Dal punto di vista del business, 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 utile per dare la priorità a una caratteristica importante al di sopra del bugfix.

Ma dal punto di vista tecnico, i bug possono essere più critici, perché indicano un errore in una fondazione su cui potrebbe essere utilizzato / compilato un altro codice, nel qual caso l'errore è "contagioso" e aggiunge costo per la manutenzione futura. Quindi non che fissa un bug è un debito tecnico che richiede la gestione, mentre non l'implementazione di una funzione non ha realmente un costo in corso. Ma il livello del 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. Dal momento che non tutti i bug sono uguali in termini di gravità, per prima cosa si dà la priorità ai bug più importanti. Quindi più bug risolvi, più basso è il valore marginale del fixing successivo. Ma se il livello raggiunto non è mai stato risolto, il bug non vale la pena, è una decisione commerciale piuttosto che una decisione tecnica.

Ecco un buon riferimento

link

Do you fix bugs before writing new code? The very first version of Microsoft Word for Windows was considered a “death march” project. [...] because the bug fixing phase was not a part of the formal schedule [...]

Microsoft universally adopted something [...] the highest priority is to eliminate bugs before writing any new code [...] In general, the longer you wait before fixing a bug, the costlier (in time and money) it is to fix.

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

Un buon modo per gestirlo sarebbe definire una quantità di tempo allocato per gestire i problemi del backlog. Ciò non farebbe impazzire quanto Microsoft, ma assicurerà una certa quantità di risoluzione dei problemi futuri, se non sono già il tuo problema, anche se al cliente non interessa davvero.

In an effort to convince our product owner about this concept, I could not find any good resources.

Supponendo che lavori per un'organizzazione commerciale, ci sarà sicuramente qualcuno che è a conoscenza di Analisi costi-benefici .

La tua organizzazione ha una quantità limitata di risorse per sviluppatori e un elenco infinito di cose utili da fare. Queste cose benefiche includono 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 contro questa lista infinita, 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 infatti mai.

Se stai cercando un approccio più strutturato qui, puoi 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 corretto e cosa no.

Vedi anche questi due post qui su Ingegneria del software:

Risoluzione di quali bug offriranno il massimo vantaggio in termini di costi

Quasi tutti i bug segnalati sono un bug ad alta priorità

Non tutti gli aspetti non intenzionali o indesiderati del comportamento del software sono bug. Ciò che è importante è garantire che il software abbia una gamma di condizioni utili e documentate in cui è possibile 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 emette un numero falso se il risultato è più 9,95 ma meno di 10,00, più di 99,95 ma meno di 100,00, ecc. Se il programma è stato scritto allo scopo di elaborare numeri il cui prodotto era compreso tra 3 e 7 e non sarà mai chiamato a processarne altri, il suo 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 di azione ragionevoli:

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

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

L'approccio n. 1 eliminerebbe il bug. L'approccio n. 2 potrebbe rendere il progresso meno adatto per alcuni scopi rispetto a quello che altrimenti potrebbe essere, ma se non è necessario che i programmi gestiscano i valori problematici che potrebbero non essere un problema.

Anche se l'impossibilità di gestire correttamente i valori da 99.95 a 100.0 è il risultato di un errore di programmazione [ad es. decidendo di produrre due cifre a sinistra del punto decimale prima di arrotondare a un posto dopo, ottenendo così 00.00], dovrebbe essere considerato un bug solo se il programma sarebbe altrimenti specificato come producendo output significativo in questi casi. [Per inciso, il problema di cui sopra si è verificato nel codice printf Turbo C 2.00; in quel contesto, è chiaramente un bug, ma il codice che chiama il printf difettoso sarebbe bacato solo se potesse produrre uscite nelle gamme problematiche].

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

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

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 potrebbe pensare che sia troppo piccolo per cambiare, ma l'azienda riconoscerebbe il potenziale danno che potrebbe causare al marchio e la relativa facilità nel fissare alcuni caratteri.

D'altra parte, potresti avere un bug che sembra importante, ma è difficile da correggere e riguarda solo una quantità trascurabile di utenti. Per esempio. un link a un pulsante secondario è rotto per gli utenti che utilizzano una versione legacy di Google Chrome e può anche avere Javascript disabilitato.

Altre ragioni per il business NON aggiustare un bug potrebbe essere che il tempo investito avrebbe ripagato il progetto in un tempo inaspettato, o che il tempo dello sviluppatore sarebbe stato meglio speso lavorando su altre correzioni / codifiche. Potrebbe anche darsi che il bug sia abbastanza piccolo da poter essere pubblicato e poi essere corretto in un secondo momento.

Spero che questo spieghi un po 'meglio il concetto! Starei certamente lontano dal pensare a questo in termini generali - ogni bug è unico e dovrebbe essere trattato come tale.

Because as you go on the priority list of bugs, the use case which causes that bug becomes more obscure, or the customer satisfaction gained gets lower.

Quindi il loro "argomento" è in realtà

If you ignore the bug long enough, the User will forget what the problem was or find some way to work around it.

I bug dovrebbero avere la priorità e gestire "in ordine" proprio come nuove Richieste di funzionalità (ma, discutibilmente, oltre a quest'ultima).