Quale quantità di tempo dovrebbe essere dedicata ai bug rispetto allo sviluppo originale? [chiuso]

Questa domanda è un po 'astratta, ma spero che qualcuno possa indicarmi la giusta direzione.

La mia domanda è: quanto tempo ci si può aspettare di dedicare ai bug di un progetto software in relazione al tempo di sviluppo originale. Mi rendo conto che ci sono un numero enorme di fattori determinanti che entrano in gioco, ma speravo in una ripartizione tipica o media.

Ad esempio, se il Progetto A richiede 40 ore per il completamento e altri 10 bug di correzione, questo progetto avrebbe un rapporto 4: 1.

Se un altro progetto (B) impiega 10 ore per essere completato, ma altri 8 sui bug, avrebbe un rapporto di 5: 4.

È un concetto documentato / ricercato?

AGGIORNARE

Grazie per tutte le risposte informative. Capisco che è impossibile stabilire uno standard per questo tipo di metrica a causa di tutte le variabili e i fattori ambientali coinvolti. Prima di assegnare una risposta, vorrei sapere se questa metrica ha un nome concordato in modo da poter effettuare ulteriori ricerche. Vorrei arrivare a un punto in cui posso capire le misure necessarie per generare me stesso le metriche e alla fine elaborare uno standard di base per il mio progetto.

La percentuale di equilibrio della capacità totale assegnata alla correzione del difetto è uguale alla velocità di iniezione del difetto .

Molti fattori possono influenzare questo tasso, tra questi, ovviamente: 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, lavorare con queste 8 unità creerà nuove 6,4 unità di rilavorazione. Possiamo stimare lo sforzo totale che dovranno eventualmente impiegare come somma di una progressione geometrica:

10 + 8 + 6.4 + 5.12 + ...

Il numero di bug diminuirà esponenzialmente nel tempo, ma la squadra B ha un tale coefficiente nel suo esponente che andrà a zero molto lentamente. In realtà, la somma dei primi tre termini della serie sopra è 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 funzionalità, 10/50 = 20%; correzione dei difetti, 80%. 20/80 è la loro allocazione di capacità sostenibile.

Al contrario, il Team A ha una forma molto migliore. La loro progressione è simile a questa:

40 + 10 + 2,5 + 0.625 + ...

La somma di questa serie è 53 1/3, quindi l'allocazione di sviluppo delle caratteristiche del Team A è 40 / (53 1/3) = 75% e l'allocazione per la correzione dei difetti è del 25%, che corrisponde alla loro velocità di iniezione del difetto di 10/40 = 0,25 .

In realtà, tutti i termini della serie del Team A dopo i primi tre sono trascurabilmente piccoli. Ciò che ciò significa in termini pratici è che il Team A può probabilmente eliminare tutti i loro bug con un paio di versioni di manutenzione, la seconda versione è piuttosto limitata. Questo crea anche l'illusione che qualsiasi squadra possa farlo. Ma non la squadra B.

Ho pensato a questa equivalenza mentre leggevo il nuovo libro di David Anderson, "Kanban" . (Il libro tratta di un argomento diverso, ma affronta anche problemi di qualità.) Quando discute della qualità del software, Anderson cita questo libro, di Capers Jones, "Valutazioni del software, benchmark e migliori pratiche" :

"... nel 2000 ... misurato la qualità del software per i team nordamericani ... variava da 6 difetti per punto funzione a meno di 3 per 100 punti funzione, un intervallo da 200 a 1. Il punto medio è circa 1 difetto per Da 0,6 a 1,0 punti funzione. Ciò implica che è comune che i team impieghino più del 90 percento del loro sforzo per correggere i difetti. "Cita un esempio fornito da uno dei suoi colleghi di un'azienda che trascorre il 90% del tempo a correggere i propri bug .

La fluidità con cui Anderson passa dalla velocità di iniezione del difetto all'allocazione della capacità di correzione del defext ( il termine richiesta è il fallimento ) suggerisce che l'equivalenza delle due cose è ben nota ai ricercatori di qualità del software ed è probabilmente nota da qualche tempo .

Le parole chiave nel 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 vai al codice da qualche altra parte e lasci la manutenzione ad altri. Oppure accumuli il debito tecnico e lo scarichi su un nuovo proprietario.

Ovviamente, nessuna allocazione particolare andrà bene per tutte le squadre. Se decretiamo che il 20% deve essere speso per i bug, quindi, se una squadra ha un tasso di iniezione di difetti ultra-basso, semplicemente non avrà abbastanza bug per riempire il tempo e se una squadra aveva un tasso molto alto, i loro bug continuerà ad accumularsi.

La matematica che ho usato qui è molto semplificata. Ho trascurato cose come i costi di transazione (riunioni di pianificazione e stima, post mortem, ecc.), Che avrebbero influenzato in qualche modo le percentuali. Ho anche omesso le equazioni che simulano il sostegno 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 la velocità di iniezione del difetto e, di conseguenza, la tua richiesta di fallimento. Se riesci a creare un solo bug per ogni 10 funzionalità, avrai molto tempo libero per sviluppare nuove funzionalità e soddisfare i tuoi clienti.

Sfortunatamente credo che questo rapporto sia molto variabile in un dato progetto. Sarà drasticamente influenzato dal tuo ambiente, lingua, strumenti, dimensioni del team ed esperienza.

Dovresti dedicare tempo a un bug solo se ciò che guadagni dalla correzione è maggiore di ciò che investi.

Utilizzare una matrice come la seguente (orizzontale - tempo richiesto per correggere l'errore, verticale - tipo di errore - 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 persino creare una classifica per ogni bug e risolverli in base alla classifica. Qualcosa di simile a:

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, dal tempo / budget disponibili, ecc.

È altamente variabile, non solo (ovviamente) sull'esperienza e sulla qualità del team e sulla difficoltà del progetto (non è lo stesso fare un'altra applicazione web standard rispetto a un nuovo kernel del sistema operativo), ma anche sull'approccio di gestione userò.

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

Per esperienza, dico che è qualcosa 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 errori 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 dei tempi di sviluppo e manutenzione. Ma lo sviluppo di un'applicazione è così breve rispetto alla manutenzione che la maggior parte delle aziende non torna indietro e calcola quel rapporto. Probabilmente sono più preoccupati di sapere perché un'app richiede manutenzione e di applicare tali risultati a nuove applicazioni.

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

Il più grande fattore determinante per questo è se stai lavorando con una nuova tecnologia o con una esistente. Se stai lavorando con qualcosa di nuovo e stai sviluppando qualcosa che non è stato fatto o che è stato fatto più volte in diverse circostanze, passerai molto tempo a correggere bug e far funzionare il tuo progetto nel modo che preferisci . Spesso i bug saranno il risultato di lavorare in un angolo, e dovrai fare una notevole quantità di lavoro per ristrutturare ciò che hai fatto. Inoltre, molti bug deriveranno da una comprensione incompleta delle aspettative degli utenti e dall'inconsapevolezza da parte dello sviluppatore dei casi limite.

Se stai lavorando su una tecnologia consolidata, la maggior parte dei problemi sarà stata risolta dalle biblioteche o dalle pratiche della comunità e dovresti essere in grado di cercare, acquistare o chiedere a Google di risolvere eventuali bug.

Su un software critico, un rapporto 1: 1 non è insolito. Solo per i test unitari, ho visto gli indicatori menzionare 1 giorno di test unitari per ogni 10 righe di codice.

Penso che questa domanda sia parziale: parte dal presupposto che la correzione dei bug sia una fase simile 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 è in grado di creare astrazioni adeguate per risolvere problemi reali.

Si noti che gli sviluppatori dovrebbero testare autonomamente il proprio codice. È responsabilità del loro lavoro fornire codice privo di bug. Quindi è difficile separare la codifica 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. Pertanto, la correzione dei bug dovrebbe avere una priorità maggiore rispetto allo sviluppo di nuove funzionalità.

Quindi, invece di parlare di "tempo dedicato ai bug", dovresti parlare di "tempo dedicato ai test" (test di integrazione, test di accettazione dell'utente ...)

Penso che tu abbia ragione: non otterrai metriche significative a causa del suo numero di fattori influenti.

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

Un'osservazione da fare è che lo sviluppo del codice e il testing / correzione di errori del codice non dovrebbero essere due fasi distinte. Se si verifica man mano che si sviluppa il "costo" della correzione dei bug è inferiore.

Prendo 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 mancano funzionalità, è necessario eseguire 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 arresta in modo anomalo il programma in alcuni casi angolari strani può essere una priorità inferiore rispetto a miglioramenti minori dell'usabilità che interessano tutti. Un piccolo bug fastidioso nella funzionalità più comunemente usata può essere più importante di una funzionalità che avvantaggia solo le persone che spingono il software al limite.