Allocazione del tempo di correzione dei bug

Question

Ci è stato chiesto da un cliente di darci una stima del tempo su ogni singolo bug che abbiamo.

Anche se abbiamo una pianificazione prestabilita per la correzione dei bug e abbiamo assegnato tempo per esso, non abbiamo un'allocazione di tempo per ciascuno dei bug che abbiamo. Semplicemente, abbiamo dato la priorità ai nostri bug e ci siamo assicurati che i bug con la massima priorità saranno risolti nel tempo assegnato.

Non sono un fan dell'allocazione di tempo ai bug, semplicemente perché:

1. Di solito è impreciso. È molto difficile capire quanto tempo ci vorrebbe per risolvere.
2. Perdita di tempo.
3. Influisce sulla qualità del codice
4. Crea più bug a lungo termine (Potremmo perdere alcune cose nel nostro tentativo di completarlo entro la scadenza).

Come dovremmo affrontare questo problema in cui non vogliamo fornire il numero di ore per bug, ma solo un lasso di tempo su quali bug verranno corretti?

Come dedichi tempo ai tuoi bug? È efficace? Vale la pena il tempo e lo sforzo?

Answer 1

L'unica risposta che posso dare è di essere estremamente conservatore. Indovina quanto tempo ci vorrà e moltiplica la tua ipotesi per quattro. Usalo come preventivo. Come hai detto, è molto difficile capire quanto tempo ci vorrà per risolvere, ed è meglio dire che ci vorrà più tempo di quanto non sia effettivamente essere catturati "infrangendo la scadenza". perché non eri abbastanza conservatore.

Answer 2

La società per cui lavoro spesso riceve richieste irragionevoli dai nostri clienti. La cosa fondamentale da ricordare è che i clienti vogliono essere ben informati. Abbiamo trovato il modo migliore per farlo è in termini di rapporti sullo stato.

Quindi, per prima cosa facciamo un ottimo lavoro nel spiegare la nostra posizione. Nel tuo esempio, questo sarebbe qualcosa del genere:

  

Abbiamo un programma prestabilito per correggere i bug nel nostro progetto, che storicamente abbiamo una buona esperienza di rispetto dei tempi previsti. Tuttavia, il processo di dettaglio del tempo necessario per la risoluzione di ciascun bug è soggetto a errori. Saremo lieti di fornirti aggiornamenti settimanali (o due volte alla settimana o ogni giorno a seconda del cliente) sui bug che sono stati corretti e le correzioni che sono state testate.

Tuttavia, credo che sia utile provare a stimare quanto tempo impiegherà ogni bug a correggere. La ragione di ciò è che devi capire quale sarà il tempo totale necessario per correggere tutti i bug. Non sarai in grado di ottenere un preventivo accurato se non disponi di un preventivo per il tempo necessario per la riparazione delle singole parti. Queste possono essere stime approssimative, ovviamente (stimate non più di passare un'ora a cercare il problema) - non si vuole perdere troppo tempo a stimare. Quindi in genere conto un ulteriore 20%. Supponiamo quindi che le stime per i bug siano di 3 giorni, 5 giorni e 2 giorni. Quindi riferirei al cliente che dovremmo essere in grado di correggere i bug in 12 giorni. Quindi, ovviamente, potrebbe essere necessario aggiungere più tempo per testare e reimballare il prodotto prima di poterli consegnare.

Answer 3

Non pensarci in termini di stima del tempo necessario per correggere i bug, perché non è possibile stimarli correttamente.

Pensaci in termini di gestione della rabbia del cliente . Se dici loro che i bug non ci vorranno del tutto per risolvere e finiranno per richiedere 3 mesi, il tuo cliente sarà felice con te adesso e furioso con te in futuro.

Se dici che i bug richiederanno 3 mesi per essere corretti e che in realtà impiegheranno 3 mesi per risolverli (cosa che faranno), il tuo cliente sarà furioso ora e felice con te in futuro.

Di solito dico che i bug non impiegheranno affatto tempo (2-3 giorni sembrano essere un buon numero di pacificazione).

Answer 4

Dovrebbe essere lo stesso che stimare qualsiasi altra attività che hai. Dividilo nei compiti più piccoli possibili e stimali nel modo più preciso possibile con il riempimento per l'imprevisto. Quindi assegna loro un intervallo in modo da non essere bloccato ad una data specifica per attività che non sono ben definite. Non c'è differenza tra la stima del tempo per correggere un bug e la stima del tempo per implementare una funzionalità con requisiti nebulosi.

Answer 5

Hai ragione, le stime sono generalmente inaccurate.

Forse vuoi chiedere loro quanto costa ogni bug se non viene risolto. Quindi puoi eseguire il calcolo appropriato per capire se dovrebbero mai essere corretti e quanto tempo tu (o realisticamente, loro) possono permettersi di dedicare a ciascun bug.

Answer 6

Perché non scegliere più bande per la gravità dei bug, ad es. 1 ora, 1/2 giorno, 1 giorno, 1 settimana e assegnazione contro di loro. Generalmente avrai la sensazione di avere un bug - quelli per i quali non hai idea, metti il ??caso peggiore ad esso!

Non credo che ti piacerebbe stimare a un livello più fine di quello, per i motivi che hai citato (impiegare troppo tempo per indagare, ecc.)

Non credo sia una perdita di tempo. Il tuo cliente vuole sapere più del numero di bug e della loro priorità: vogliono avere un'idea di quanto lavoro rimane.

In nessun caso questo dovrebbe comportare la generazione di più bug. Non dovresti affrettarti a risolvere il problema. Se hai stimato 1 giorno e ci sono volute 10 ore, va bene. Se hai stimato 1 settimana e ci sono volute 2 ore, buon risultato!

Questo è semplicemente un esercizio di stima!

Answer 7

Di solito concorderemo quali bug devono essere corretti per una versione particolare, e quindi definire un lasso di tempo per correggere tutti i bug. Per ogni singolo bug c'è molta incertezza / variabilità in quanto tempo potrebbe essere necessario correggere, ma ciò tende a fare la media con un numero maggiore di bug. Per alcuni bug che ritieni richiederanno più tempo, potrebbe essere possibile fornire alcune stime, ad es. se devi scrivere un simulatore o un framework di test per esso.

Answer 8

Se si tratta di bug che sono stati trovati e segnalati, allora dovresti essere in grado di sviluppare una stima sul tempo per risolverlo (e il tempo per ripetere il test). La fiducia del preventivo sarà probabilmente proporzionale al tempo impiegato per il preventivo, forse spiegare questo costo al cliente.

Se ci sono un certo numero di segnalazioni di piccoli bug correlate, forse potresti comprimerle in un rapporto omnibus. Ciò potrebbe evitare che il client tenti di scegliere quali bug correggere in base esclusivamente a stime individuali.