Come rendere conto di una correzione dell'errore?

9

Abbiamo implementato Scrum con successo negli ultimi 5 mesi. Tuttavia, siamo a 3 settimane da PROD senza mai fare test di integrazione end-to-end. AHIA! Ho bisogno di aiuto. Senza affrontare le cause di ciò (a QUESTO punto), dobbiamo ora pianificare l'attuale iterazione, che consiste in miglioramenti minori 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 bug planning

— Pomario
fonte

16

"Abbiamo implementato Scrum con successo ... senza mai fare test di integrazione end-to-end." Mi dispiace di aver sbagliato. Avresti dovuto essere in grado di spedire alla fine di ogni iterazione.

— xsace,

3

@xsAce è un'iterazione di 6 mesi

— Bart

3

La domanda in sé è buona, ma la descrizione del processo mi fa sentire che neghi quanto bene funzionano le cose. Se non fai altro, comunica al PO che la squadra non può impegnarsi a una data di rilascio in questo momento. Il meglio che puoi fare è impegnarti con lui a concentrarti su una valutazione della qualità nella prossima iterazione. Avere una seria discussione di gruppo alla prossima retrospettiva.

— GuyR

1

Analizzando la tua storia di domande relative a Scrum su questo sito, è chiaro che la tua azienda non sta facendo "niente del genere" come Scrum e invece sembra un team di persone molto più a suo agio e familiarità con lo sviluppo di Waterfall. Non che Waterfall sia intrinsecamente "cattivo", ma solo riconoscere quando al management piace usare parole come "Agile", "Scrum", "Sprint", "Backlog" e "Planning Poker" come parole d'ordine, ma non si impegna pienamente nella cultura e cambiamento di gestione necessario per soddisfare queste cose. Vogliono i benefici di Scrum senza impegnarsi in Scrum.

— maple_shaft

4

Sono i puristi del processo di mischia come voi ragazzi che allontanano le persone da esso. Se non avesse riconosciuto di avere un problema, non avrebbe posto la domanda. Capire dove hai sbagliato e fare passi per fare meglio nelle iterazioni future è ciò che è agile. Individui e interazioni su processi e strumenti.

— Karl Bielefeldt,

7

Scrum o no, la correzione di bug è praticamente impossibile da prevedere. Il meglio che credo tu possa fare è:

Inizia subito i test, senza una stima iniziale, quando sarà fatto.
Quando scopri ogni errore, esegui un'analisi iniziale al punto da poterlo stimare.
Stimare il bug e decidere se deve essere corretto e se deve essere corretto per il relese iniziale.
Se deve essere corretto, aggiungilo all'iterazione.
Traccia un grafico bruciato. Ad un certo punto inizierà a diminuire, il che significa che non trovi più bug più velocemente di quanto riesci a risolverli. A quel punto sarai in grado di dare una stima approssimativa (e progressivamente più precisa) quando sarà possibile effettuare il rilascio.

Di quanto dovresti assicurarti la prossima volta che inizi a testare presto e correggi i bug man mano che procedi. Tutte le metodologie sensibili, agili o meno, richiedono la correzione di bug noti prima di procedere con nuove funzionalità. Inoltre, è necessario tenere conto di quanto tempo è stato dedicato alla correzione di bug per ciascuna funzionalità, in modo da poter migliorare la stima per l'implementazione della funzionalità allo stato di debug in futuro.

La stima e la correzione di bug sono ben coperte da Joel Spolsky in Evidence Based Scheduling e Hard Fixed Bug Fixin ' . Non è legato a Scrum, ma penso che sia abbastanza generale che si applichi in gran parte.

— Jan Hudec
fonte

5

Come rendere conto di una correzione dell'errore? Come pianifichi la tua iterazione per correggere i bug ancora da trovare?

Per quanto riguarda un "bug che ripara l'iterazione". I bug trovati non dovrebbero essere trattati in modo diverso dalle storie. Collaborare con il team per stimare lo sforzo (punti della trama) per correggere ogni errore e collaborare con il proprietario / cliente del prodotto per decidere se il bug deve passare alla successiva iterazione.

Per quanto riguarda "bug ancora da trovare". Preferibilmente, il team sta trovando e risolvendo i problemi ogni iterazione. In caso contrario, discuterne nella prossima retrospettiva. Se la qualità del prodotto è così bassa da rendere impossibile il rilascio, sposta immediatamente i tuoi migliori " cercatori di bug " alla ricerca di bug (non risolvendo). Se la qualità è abbastanza elevata da fornire una versione beta per selezionare gli utenti, fallo. Se non è possibile, fornire almeno dimostrazioni live degli utenti che parlano di aree deboli che si consiglia di migliorare.

— GuyR
fonte

+1. Quando sei nella fase di qualità beta, potresti anche prendere in considerazione l'idea di fare sessioni di test tra pari.

— louisgab,

2

Non pianifichiamo "iterazioni di correzione di bug", ma pianifichiamo iterazioni di test di sistema prima di ogni versione. Il test di sistema è test di integrazione, regressione e realese su tutte le parti del prodotto. I tester testano il prodotto (un sistema legacy abbastanza grande) e gli sviluppatori risolvono tutti i bug rilevati. Se non vengono rilevati bug, iniziamo a studiare le pianificazioni delle funzionalità per il prossimo progetto o lavoriamo sui miglioramenti interni.

Attualmente, prevediamo sei settimane di test di sistema dopo il blocco del codice (per un progetto di cinque mesi, test di sistema incluso), per assicurarci che tutto funzioni. Questo è in cima a tutti i test eseguiti durante le iterazioni di implementazione.

— Paula
fonte

1

È necessario definire un insieme di criteri di "rilascio". Questi potrebbero includere:

Tempo medio tra fallimento
Numero di difetti trovati al giorno
Gravità dei difetti riscontrati al giorno
Numero di difetti in sospeso

eccetera.

Quindi alla fine di ogni iterazione in cui hai alcune persone che testano (manualmente o scrivendo test automatizzati) e altri riparano il controllo per vedere se hai soddisfatto i tuoi criteri. Se hai quindi rilasciato, in caso contrario, scegli un'altra iterazione.

Dovrebbe esserci la possibilità di una sostituzione su questo, così come spesso i numeri grezzi non presentano un'immagine realistica dell'applicazione. Potresti avere un paio di difetti davvero gravi, ma si manifestano solo in rare condizioni con cui puoi convivere a breve termine.

— ChrisF
fonte

1

Un modo per farlo è scrivere storie per i tuoi test di integrazione, durante i quali scrivi nuove storie per tutti i bug che trovi, quindi correggi le storie dei bug nella prossima iterazione.

Un altro modo per farlo è semplicemente creare una storia che dice "Correzione di bug rilevati 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, in modo da poter assegnare i punti della storia in base a tale conoscenza. Potresti forse dividerlo in componenti se ciò lo rende più gestibile. C'è sempre inevitabile incertezza in questo. Aggiungi alcuni punti storia extra per spiegarlo.

Probabilmente ti sei reso conto in ritardo che il modo migliore è quello di incorporare un piccolo test di integrazione in ogni iterazione, se possibile. Congratulazioni per averlo riconosciuto e migliorato un po 'il processo per la tua prossima versione.

— Karl Bielefeldt
fonte