Come fanno i report dei bug a partecipare a uno sprint?

8

Recentemente ho letto su Scrum. Dalla mia comprensione, si tiene un incontro prima dell'inizio dello sprint, per decidere cosa viene spostato dal backlog del prodotto allo sprint in arrivo. Una volta che una funzionalità è completata nello sprint corrente, entrerà nel bucket "Ready to QA", ed è a questo punto che mi sto confondendo. Le segnalazioni di bug tornano nel backlog del prodotto? Presumo che non possano tornare nello sprint backlog dato che abbiamo già deciso quale lavoro verrà svolto per questo ciclo? Cosa succede quando QA trova un bug? Dove va?

    
posta Mark Ingram 06.12.2012 - 14:37
fonte

6 risposte

10

Per come la vedo ci sono due soluzioni principali:

  1. Non assegnare il 100% del tuo tempo allo sprint corrente. Consenti il 10-15% del tuo tempo per la risoluzione dei bug e altre attività di supporto che farà durante lo sprint. Quindi se viene rilevato un errore blocking hai il tempo di risolverlo nello sprint corrente.

    Se compare un bug non bloccante, puoi aggiustarlo alla fine dello sprint attuale se hai tempo da perdere o va nel "piatto" per lo sprint successivo.

  2. Avere uno "bug fixing" sprint ogni tanto. Probabilmente poco prima della prossima major release. Puoi usare questo comando per "rimuovere" tutti i bug che puoi / vuoi correggere per la prossima versione.

Nessuna di queste soluzioni è probabilmente vera per Scrum "pura", ma funziona nel mondo reale.

Durante uno sprint "normale" puoi ancora includere attività per correggere specifici bug, trattandoli come se fossero una nuova funzionalità.

    
risposta data 06.12.2012 - 14:44
fonte
5

In un mondo di mischia ideale, non esiste un bucket "Pronto per il QA" (almeno non visibile all'esterno del team), poiché una funzionalità non viene completata fino a quando le attività di controllo qualità sono terminate e gli errori risolti. Ciò significa che nel team devono esserci persone che possono svolgere le attività di controllo qualità.

Nel mondo reale, potresti avere un team QA / test separato che funziona in parallelo con il team di scrum (sviluppo). In tal caso, il seguente approccio potrebbe funzionare bene:

  1. Poco prima che una funzionalità venga inserita nel bucket "Pronto per il QA", lo sviluppatore (principale) di tale funzione e il rappresentante del QA che (probabilmente) prenderanno il controllo sedersi insieme e percorrere la funzionalità. Eventuali problemi rilevati in quel momento vengono risolti prima che la funzione venga inserita nel bucket "Pronto per il QA". Nota che questa è non una delle prime parti di una demo sprint. È pensato per far sì che il problema della bassa sospensione dei problemi risolva il prima possibile.

  2. Tutti i problemi riscontrati dopo il passaggio di consegne al controllo qualità devono essere inseriti nel backlog del prodotto come storie, da prendere in considerazione nella prossima riunione di pianificazione.

  3. Per i bug di show-stopper, riservi una quantità di tempo fissa per ogni sprint. Se, vicino alla fine dello sprint, è rimasto del tempo in questo buffer, potrebbe essere riempito con problemi di priorità inferiore.

risposta data 06.12.2012 - 20:26
fonte
2

In base a come descrivi il tuo flusso di lavoro da una storia, con un backlog di prodotto, uno sprint backlog e altri bucket (presumo che assomiglino a qualcosa come "in corso / in sviluppo", "pronto per il controllo qualità" , "finito"), sembra che tu stia aggiungendo alcuni elementi di Kanban a Scrum - una combinazione non rara chiamata a volte Scrumban . La nozione di Kanban aggiunge limiti alle dimensioni di ciascun bucket per impedire ai tuoi sviluppatori di avere troppe storie in corso o ai tuoi tester di testare troppo. È simile alla velocità per lo spostamento degli elementi dal backlog del prodotto nel backlog dello sprint, ma all'interno di uno sprint.

Affronterei il problema facendo in modo che i tuoi compiti fossero le storie degli utenti, con le storie degli utenti che passano dal backlog del prodotto allo sprint backlog al bucket in progress fino al bucket QA pronto per il bucket finito. Dopo che lo sviluppatore ha terminato la storia (in base alla tua definizione di finito), l'avrebbe spostato nel secchio "pronto per il QA", in cui la persona successiva lo avrebbe estratto e lavorato su di esso. In caso di problemi, nel sistema di tracciamento verrà inserito un difetto e il racconto dell'utente verrà spostato nel bucket finito poiché è stato implementato e testato. Se non ci sono problemi, passa direttamente al bucket finito.

Quando il difetto arriva dallo sprint, non c'è problema nel rimetterlo nello sprint backlog (o forse in una sorta di bucket "in progress"). Una storia con difetti noti viene solitamente considerata incompleta. Se è determinato che non c'è abbastanza tempo per terminare la storia o che i difetti sono attribuiti a non comprendere la storia, un'opzione potrebbe essere quella di descriverlo dallo sprint fino a quando non potrai capire meglio la necessità - in questo caso, ti consiglio di non inclusa l'implementazione difettosa nel prodotto rilasciato.

Se, a causa del tuo difetto, la storia non finisce nello sprint, questo verrà fuori nei tuoi calcoli di velocità per gli sprint futuri. Le storie non finite (storie difettose) non ti procurano punti storia, quindi pianifichi degli sprint più piccoli. Meno storie complesse porteranno a più tempo nei test e incoraggeranno a spendere di più per trovare i difetti in anticipo - prevenire i difetti non è solo più economico, ma richiede meno tempo della somma del tempo speso per identificare l'esistenza di un problema, trovare il problema nella progettazione o implementazione, risolvere il problema e ripetere il test per garantire che il problema sia stato risolto senza altri impatti negativi sul sistema. Poiché il timebox è la chiave, la capacità di prevenire i difetti porta a sprint più produttivi in futuro.

Indipendentemente da ciò che fai, dovresti coinvolgere il Product Owner (che si spera sia un cliente / utente rappresentante) quando si tratta di decidere come dare la priorità ai difetti. Alcuni difetti potrebbero essere accettabili per essere messi in un rilascio se ci sono soluzioni alternative o sono rari, il che significa che il difetto si presenterebbe come una storia in uno sprint futuro. Altri difetti potrebbero essere urgenti e "showstoppers": questi devono essere risolti immediatamente e un prodotto non può essere utilizzato se esiste.

    
risposta data 06.12.2012 - 15:17
fonte
2

Se il tempo speso per il difetto è abbastanza consistente da una molla all'altra, allora non hai davvero bisogno di gestirlo - la velocità del tuo team lo rifletterà.

Altrimenti, se è possibile pianificare la correzione dei difetti (ad esempio, puoi rimandare il fixing per la durata di uno sprint), quindi fallo.

Altrimenti, Scrum non ha una buona risposta - i difetti saranno un cambiamento di sprint non pianificato nel mezzo di uno sprint, il che significa che dovrai rinegoziare i tuoi impegni.

    
risposta data 07.12.2012 - 02:04
fonte
2

Uno sprint dovrebbe essere autonomo. Ciò significa che tutte le attività, incluso il QA, la risoluzione dei bug e la documentazione, dovrebbero essere completate prima della fine dello sprint. Le attività di pre-distribuzione dovrebbero anche aver luogo prima dello sprint.

Il problema con il non finire è che ti distrai nel prossimo sprint.

Se, nello sprint B, devi riportare la tua attenzione sul codice dallo sprint A in modo da poter correggere i bug, quindi la tua capacità di concentrarti sulle attività nello sprint B esce dalla finestra. Così fa la tua velocità in avanti.

    
risposta data 08.12.2012 - 01:11
fonte
0

Nel mio ultimo lavoro, gli sprint sono stati programmati in base al concetto di "ore ideali"; di un giorno di sviluppo di 8 ore, 5 ore erano a testa in giù TDDing nuove funzionalità che non sono mai esistite prima. Gli altri tre stavano facendo tutto il resto; e-mail, riunioni, compilazione / commit / aggiornamento del codice, refactoring, e sì, correzioni di bug.

Abbiamo preso in considerazione un lavoro che è stato fatto, ma i bug erano ancora validi per la velocità della squadra; tuttavia, i bug erano debito tecnico che doveva essere ripagato quando si accumulava, e quindi ovviamente da evitare. Non abbiamo mai avuto un vero problema con le persone che fanno lavori sciatti; nessuno voleva tornare indietro.

Ogni tanto, avremmo anche degli sprint che risolvono i bug. Avevamo la dubbia fortuna di avere un cliente che non poteva soddisfare i requisiti al ritmo che potevamo consumarli, quindi per fare in modo che l'arretrato aumentasse un po ', spesso programmavamo due settimane in cui l'oggetto doveva "uccidere quanti più difetti e pagare quanto più debito tecnico possibile ". Tecnicamente, la velocità per uno sprint di questo tipo è zero, ma questo è un lavoro che deve essere fatto e che rende il cliente felice, quindi ne vale la pena.

    
risposta data 07.12.2012 - 01:16
fonte

Leggi altre domande sui tag