Quale quantità di tempo dovrebbe essere speso per i bug rispetto allo sviluppo originale? [chiuso]

La percentuale di equilibrio della capacità totale allocata per correggere i difetti è uguale alla velocità di iniezione dei difetti .

Molti fattori possono influenzare questo tasso, tra questi, naturalmente: quale tipo di prodotto sta sviluppando il team, quali tecnologie e pratiche tecniche usano, il livello di abilità del team, la cultura aziendale, ecc.

Considerando la squadra B, se creano in media 8 unità di rilavorazione per ogni 10 unità di lavoro che completano, allora lavorando queste 8 unità creerai nuove 6.4 unità di rilavorazione. Possiamo stimare lo sforzo totale che alla fine dovranno spendere come somma di una progressione geometrica:

10 + 8 + 6.4 + 5.12 + ...

Il numero di bug diminuirà in modo esponenziale con il tempo, ma la squadra B ha un tale coefficiente nel loro esponente che andrà a zero molto lentamente. In realtà, la somma dei primi tre termini della serie precedente è solo 24.4; dei primi cinque, 33.6; dei primi 10, 45; dell'intera serie, 50. Quindi, sintesi della squadra B: tasso di iniezione del difetto, 0,8; sviluppo di funzionalità, 10/50 = 20%; correzione dei difetti, 80%. 20/80 è la loro allocazione di capacità sostenibile.

Al contrario, la squadra A è molto più in forma. La loro progressione è simile a questa:

40 + 10 + 2,5 + 0,625 + ...

La somma di questa serie è 53 1/3, quindi l'allocazione dello sviluppo delle caratteristiche della squadra A è 40 / (53 1/3) = 75% e l'allocazione dei difetti è del 25%, che corrisponde al loro tasso di iniezione del difetto di 10 / 40 = 0,25.

In realtà, tutti i termini della serie A della squadra dopo i primi tre sono trascurabilmente piccoli. Ciò che significa in termini pratici è che la Squadra A può probabilmente distruggere tutti i loro bug con un paio di rilasci di manutenzione, mentre la seconda versione è piuttosto piccola. Ciò crea anche l'illusione che il team qualsiasi possa farlo. Ma non la squadra B.

Ho pensato a questa equivalenza durante la lettura di il nuovo libro di David Anderson, "Kanban" . (Il libro è su un tema diverso, ma affronta anche problemi di qualità.) Quando si discute della qualità del software, Anderson cita questo libro, di Capers Jones, "Valutazioni software, benchmark e best practice" :

"... nel 2000 ... la qualità del software misurato per i team nordamericani ... variava da 6 difetti per punto funzione a meno di 3 punti su 100, un intervallo da 200 a 1. Il il punto medio è di circa 1 difetto per punti da 0,6 a 1,0, il che implica che è comune per i team spendere più del 90% dei loro sforzi per correggere i difetti. "Cita un esempio fornito da uno dei suoi colleghi di un'azienda spende il 90% delle volte a correggere i bug.

La fluidità con cui Anderson passa dalla velocità di iniezione del difetto all'allocazione della capacità di fissaggio del defext ( richiesta di fallimento è il termine per esso) suggerisce che l'equivalenza delle due cose è ben nota al software ricercatori di qualità e probabilmente è stato conosciuto per qualche tempo.

Le parole chiave nella linea di ragionamento che sto cercando di presentare qui sono "equlibrium" e "sostenibile". Se togliamo la sostenibilità, allora c'è un modo ovvio per imbrogliare questi numeri: fai la codifica iniziale, poi passa al codice da qualche altra parte e lascia la manutenzione agli altri. O esegui il debito tecnico e scaricalo su un nuovo proprietario.

Ovviamente, nessuna assegnazione particolare si adatta a tutte le squadre. Se decidiamo che il 20% deve essere speso per i bug, allora, se una squadra ha un tasso di iniezione di difetto ultra-basso, non avrà semplicemente abbastanza bug per riempire il tempo, e se una squadra ha avuto un tasso molto alto, i loro bug continuerà ad accumularsi.

La matematica che ho usato qui è molto semplice. Trascuravo le cose come i costi di transazione (riunioni di pianificazione e stima, post mortem, ecc.), Che influirebbero in qualche modo sulle percentuali. Ho anche omesso le equazioni che simulavano il mantenimento di un prodotto e lo sviluppo di un altro contemporaneamente. Ma la conclusione è ancora valida. Fai quello che puoi, in termini di pratiche tecniche, come test unitari, integrazione continua, revisioni del codice, ecc., Per ridurre il tasso di iniezione dei difetti e, di conseguenza, la domanda di guasti. Se riesci a creare un solo bug per ogni 10 funzionalità, avrai molto tempo libero per sviluppare nuove funzionalità e soddisfare i tuoi clienti.

Dovresti dedicare del tempo a un bug solo se ciò che ottieni dalla correzione è maggiore rispetto a quello che investi.

Usa una matrice come la seguente (orizzontale - tempo richiesto per correggere il bug, verticale - tipo di bug - impatto sugli utenti)

              | Few hours | Many hours
--------------+-----------+-------------------------
Minor problem | Might fix | Fix only if time permits
--------------+-----------+-------------------------
Major problem | Fix       | Fix

Esempio di problemi:

              | Few hours                            | Many hours
--------------+--------------------------------------+---------------------------------
              | Window moves 1px every 10            | Windows is painted incorrectly 
Minor problem | times when you open the application. | every 100th time the app is open.
              | Fix is: handle window resize event   | Fix: Change the graphical engine.
--------------+--------------------------------------+---------------------------------
Major problem | Application crashes when opening     | Poor performance when >100 users 
              | SQL connection.                      | are connected (unusable app)
              | Fix: Fix invalid query + add nice    | Fix: change architecture + DB
              | message                              |

La matrice può essere più complessa con diversi livelli di gravità, sforzo, rischi, ecc.

Puoi anche creare una classifica per ogni bug e correggerli in base alla classifica. Qualcosa come:

Bug priority = Risk x Severity x Effort

* Potrebbe essere (1-x) per alcuni operandi, a seconda della scala scelta:)

Quindi, per rispondere alla tua domanda: dipende dal tipo di bug, tempo disponibile / budget, ecc.

È altamente variabile, non solo (ovviamente) sull'esperienza e la qualità del team, e sulla difficoltà del progetto (non è lo stesso fare una nuova applicazione web standard di un nuovo kernel del sistema operativo), ma anche sul approccio gestionale che userete.

Ad esempio, su un modello a cascata è possibile impostare con precisione il primo bug nella prima fase di test, ma su un ambiente agile può essere difficile sollevare una riga che dice "da qui in poi, stiamo correggendo i bug", come le caratteristiche può cambiare (e per me non è giusto contare un cambiamento di funzionalità come un bug)

Dall'esperienza, dico che è SEMPRE sottovalutato, e molto facilmente può passare la stessa quantità di ore rispetto al "progetto originale".

La risposta veramente corretta sarebbe zero ore su correzioni di bug, perché il tuo codice è perfetto. : -)

Realisticamente, non posso dire di aver mai sentito qualcuno chiedere o offrire quel tipo di rapporto. Questo non vuol dire che alcune aziende non tengono traccia del tempo sia per lo sviluppo che per la manutenzione. Ma lo sviluppo di un'applicazione è un periodo di tempo così breve rispetto alla manutenzione che la maggior parte delle aziende non torna indietro e calcola tale rapporto. Probabilmente sono più preoccupati di sapere perché un'app richiede manutenzione e applica tali risultati a nuove applicazioni.

Avere un criterio troppo ampio per quello che è un bug può quasi raddoppiare il tuo tempo. Un manager troppo zelante che pensa che la richiesta di un client di ingrandire un pulsante (hanno problemi con il mouse) è un ottimo modo per aumentare il numero di bug che abbiamo corretto. Ci vorranno solo pochi secondi per risolvere perché non è necessario prendere in considerazione, testare, ricompilare e distribuire una patch. Oh, e viene conteggiato due volte come una nuova funzione.

Il più grande fattore determinante per questo è se stai lavorando con una nuova tecnologia o una esistente. Se stai lavorando con qualcosa di nuovo e sviluppo di qualcosa che non è stato fatto o è stato fatto un paio di volte in circostanze diverse, passerai molto tempo a correggere i bug e far funzionare il tuo progetto nel modo che desideri . Frequentemente i bug saranno il risultato del lavoro in un angolo, e avrai bisogno di fare una quantità significativa di lavoro per ristrutturare ciò che hai fatto. Inoltre, molti bug nasceranno da una comprensione incompleta delle aspettative degli utenti e dall'inconsapevolezza degli sviluppatori dei casi limite.

Se stai lavorando su una tecnologia consolidata, la maggior parte dei problemi saranno stati risolti dalle biblioteche o dalle pratiche nella community e dovresti essere in grado di cercare, acquistare o chiedere la tua via d'uscita da eventuali bug che corri in.

Sul sofware critico, un rapporto 1: 1 non è inusuale. Per i test unitari da solo, ho visto gli indicatori menzionare 1 giorno di test unitario per ogni 10 righe di codice.

Penso che questa domanda sia di parte: parte dal presupposto che correggere bug sia una fase simile rispetto allo sviluppo di nuove funzionalità . Questo non è il caso.

Un buon sviluppatore non impiegherà molto tempo a eseguire il debug del codice poiché il suo codice sarà privo di bug dall'inizio. Un cattivo sviluppatore impiegherà molto tempo a eseguire il debug del suo codice perché non può creare astrazioni adeguate per risolvere problemi reali.

Nota che gli sviluppatori dovrebbero testare autonomamente il proprio codice. È responsabilità del loro lavoro fornire codice privo di bug. Quindi è difficile separare il codice dal debug.

È anche una questione di priorità. Durante lo sviluppo, il tempo necessario per correggere un bug è correlato in modo esponenziale al tempo trascorso dal momento in cui hai inserito il bug nel codice. Quindi correggere i bug dovrebbe essere una priorità maggiore rispetto allo sviluppo di nuove funzionalità.

Quindi, invece di parlare di "tempo trascorso sui bug", dovresti parlare di "tempo trascorso sui test" (test di integrazione, test di accettazione degli utenti ...)

Penso che tu abbia ragione: non otterrai una metrica significativa a causa dell'elevato numero di fattori che influenzano.

Se aiuta posso dire che i progetti su cui lavoro (spazio aziendale, sistemi complessi di grandi dimensioni, integrazione con altri sistemi) hanno un rapporto di circa 3: 2. La maggior parte di questi non sono errori con il codice - più spesso errori con le interfacce. Ad esempio, i sistemi A e B comunicano tra loro tramite l'interfaccia X. Gli sviluppatori del sistema A interpretano l'interfaccia X in modo leggermente diverso rispetto agli sviluppatori del sistema B. Ne deriva la commedia.

Un'osservazione da fare è che lo sviluppo di codice e test / correzione di bug del codice non dovrebbero essere due fasi distinte. Se provi mentre sviluppi il "costo" del bug fixing è inferiore.

Ho un punto di vista puramente pratico: cosa impedisce di più l'utilità pratica del progetto? Se si tratta di bug nelle funzionalità esistenti, è necessario correggere i bug. Se manca funzionalità, si dovrebbe fare lo sviluppo originale, quindi tornare indietro e correggere i bug una volta implementate le funzionalità mancanti più gravi. Ciò richiede familiarità con i casi d'uso. Un bug che blocca il programma in alcuni casi angusti potrebbe essere una priorità inferiore rispetto a miglioramenti minori dell'usabilità che interessano tutti. Un piccolo inconveniente nella funzionalità più comunemente utilizzata potrebbe essere più importante di una funzionalità che avvantaggia solo le persone che stanno spingendo il tuo software agli estremi.