Abbiamo implementato Scrum con successo negli ultimi 5 mesi. Tuttavia, siamo a 3 settimane di distanza da PROD senza mai eseguendo test di integrazione end-to-end. AHIA! Ho bisogno di aiuto. Senza affrontare le cause di questo (in questo punto), dobbiamo ora pianificare l'iterazione corrente, che consiste in piccoli miglioramenti e MOLTE correzioni di bug ancora sconosciute. Come si spiega questo scenario? Come pianifichi la tua iterazione per correggere i bug ancora da trovare?
Scrum o no, la correzione dei bug è praticamente impossibile da prevedere. Il meglio che credo tu possa fare è:
Quindi dovresti assicurarti che la prossima volta inizi a testare presto e correggi i bug mentre vai. Tutte le metodologie sensate, agili o meno, richiedono di correggere bug noti prima di progredire con nuove funzionalità. Inoltre, dovresti tenere conto di quanto tempo è stato speso per correggere ogni funzionalità, in modo da poter migliorare la stima per l'implementazione della funzionalità in stato di debug in futuro.
La stima e il bugfix sono ben coperti da Joel Spolsky in Pianificazione basata sull'evidenza e Correzione di errori hardware difficile . Non è legato a Scrum, ma penso che sia abbastanza generale che si applichi molto.
How to account for a bug fixing iteration? How do you plan your iteration to fix bugs yet to be found?
Riguardo a un "bug fixing iteration". I bug trovati non dovrebbero essere trattati diversamente dalle storie. Collabora con il team per stimare lo sforzo (i punti della storia) per correggere ogni bug e lavorare con il proprietario / cliente del prodotto per decidere se il bug dovrebbe andare nella successiva iterazione.
Riguardo a "bug ancora da trovare". Preferibilmente, il team sta trovando e risolvendo i problemi ogni iterazione. Se non lo sei, parla di questo nella tua prossima retrospettiva. Se la qualità del prodotto è così bassa che la pubblicazione non è possibile, sposta immediatamente i migliori " bug finder " per trovare bug (non risolvere). Se la qualità è abbastanza elevata da fornire una versione beta per selezionare gli utenti, fallo. Se non è possibile, fornire almeno demo live di utenti che discutono di aree deboli che si consiglia di migliorare.
Non pianifichiamo 'correzioni di errori', ma pianifichiamo iterazioni di test di sistema prima di ogni release. Il test di sistema è l'integrazione, la regressione e verifiche reali su tutte le parti del prodotto. I tester testano il prodotto (un sistema legacy abbastanza grande) e gli sviluppatori correggono eventuali bug rilevati. Se non vengono rilevati errori, iniziamo a esaminare le pianificazioni delle caratteristiche per il prossimo progetto o a lavorare su miglioramenti interni.
Attualmente, prevediamo sei settimane di test di sistema dopo il blocco del codice (per un progetto di cinque mesi, incluso il test di sistema), per accertarci che tutto funzioni. Questo è al di sopra di tutti i test eseguiti durante le iterazioni di implementazione.
Devi definire una serie di criteri di "rilascio". Questi potrebbero includere:
ecc.
Poi alla fine di ogni iterazione in cui alcuni testano (manualmente o scrivendo test automatici) qualcuno e altri correggono il controllo per vedere se hai soddisfatto i tuoi criteri. Se hai quindi rilasciato, se non lo fai vai per un'altra iterazione.
Ci dovrebbe essere la possibilità di un override su questo e spesso i numeri grezzi non presentano un'immagine realistica dell'applicazione. Potresti avere un paio di difetti veramente seri, ma si manifestano solo in rare condizioni con cui puoi convivere a breve termine.
Un modo per farlo è scrivere storie per i test di integrazione, durante i quali scrivi nuove storie per eventuali bug che trovi, quindi correggi le storie di errori nella successiva iterazione.
Un altro modo per farlo è semplicemente creare una storia che dice "Risolti bug trovati nei test di integrazione". Dalle versioni precedenti dovresti avere un'idea di quanti problemi si trovano di solito e di quanto siano difficili da risolvere, quindi puoi assegnare punti storia basati su tale conoscenza. Potresti forse dividerlo in componenti se questo lo rende più gestibile. C'è sempre un'incertezza inevitabile in questo. Aggiungi punti storia aggiuntivi per renderlo conto.
Probabilmente ti sei reso conto in ritardo che il modo migliore è incorporare un piccolo test di integrazione in ogni iterazione, se possibile. Congratulazioni per averlo riconosciuto e per migliorare il tuo processo un po 'per la tua prossima versione.