Come gestire "ticket" durante la pianificazione dello sprint

Question

Lavoro in una squadra agile.

Abbiamo un prodotto rilasciato e stiamo ancora lavorando per una versione futura.

Ogni sprint viene consegnato ovunque da 0 a 5 ticket per correggere i bug nel prodotto rilasciato.

Il nostro team è composto da ingegneri del software (per gestire i nuovi sviluppatori) e ingegneri del software di manutenzione (per gestire i biglietti).

La mia domanda è come si tiene conto delle ore di manutenzione durante la pianificazione dello sprint.

Attualmente abbiamo una storia chiamata buffer di manutenzione in cui dedichiamo alcune ore per risolvere i ticket. E lo usiamo come un buffer, quindi negli sprint in cui non riceviamo ticket utilizziamo le ore nel buffer per il lavoro di sviluppo.

Ritengo che questo non sia un buon modo agile per fare le cose, qualche suggerimento?

Answer 1

L'approccio che hai citato è anche coperto da Mike Cohn in Should Story Points Be Assigned to the Agile Defect Story?, dove scrive:

A volte le squadre scrivere una storia utente per questa attività come ad esempio: “Come utente , voglio almeno 15 bug corretti "o," Come utente, voglio spendere circa 50 ore nello per correggere gli errori in modo che l'applicazione diventi gradualmente più di alta qualità. "Anche una squadra che non scrive scrive esplicitamente una tale user story di solito include una riga sulla sua taskboard per rendere visibili i difetti agili e il bug fixing, e per monitoralo.

Al momento è un buffer di manutenzione storia chiamata dove allocare alcune ore per risolvere i biglietti, che è qualcosa di simile a quanto indicato nell'articolo di Mike Cohn dove si raccomanda di assegnare punti ai bug che fissa i difetti agili.

Ci potrebbero essere anche altre opzioni, come

• Impostazione del tempo per bug-fixing in ogni sprint. Potrebbe essere un orario fisso del giorno/settimana in cui ogni membro del team si occupa di bug.
• Includendo ciascun bug nello stesso backlog di sprint considerandoli come una funzionalità parzialmente implementata. Questo è discusso da Mark Summer nel Managing Bugs in Scrum.

Cosa fare in caso di emergenze/hotfix?

È necessario valutare la criticità e lo sforzo richiesto per correggere l'errore urgente. Spetta al Product Owner decidere se il team lascia cadere tutto e inizia a lavorare sull'aggiornamento rapido. Il motivo è che il cliente viene sempre al primo posto e se il prodotto consegnato non fornisce il valore previsto,, non è più possibile aggiungere ulteriori funzionalità a un prodotto incompleto. Nessun framework/metodologia ti impedisce di gestire casi eccezionali o impone di ignorare i problemi critici. Quindi lo sprint attuale può essere cancellato o se l'hotfix può essere gestito da uno (o alcuni) membri del team, quindi una funzionalità o un bug, dallo sprint corrente, può essere scambiato con la correzione rapida.

In parole di Geoff Watts da Production Support and Scrum:

Se il problema è una vera emergenza, il Product Owner deve avere l'autorità di giocare la “carta d'emergenza,” finché egli è consapevole della costi per farlo - non completando gli articoli che avevamo pianificato e, potenzialmente, mettendo a repentaglio l'obiettivo dello sprint.

Il Product Owner può esercitare una qualsiasi delle 3 opzioni:

• Aggiungere il difetto urgente al backlog perché lui/lei ha deciso che l'obiettivo sprint corrente ha priorità maggiore
• Aggiungere la urgente difetto allo sprint corrente perché è abbastanza critico che potrebbe persino mettere a repentaglio l'obiettivo di sprint
• Annullare lo sprint corrente, fare l'aggiornamento rapido e quindi avviare un nuovo sprint dopo quello

Answer 2

In breve, vorrei sollevare bug (s) come Product Backlog Item (PBI) e dare la priorità ad altri PBI nel Product Backlog. In questo modo, puoi sempre essere sicuro che le cose più importanti siano fatte prima.

Parte del contratto non scritto di Scrum è che l'azienda si impegna a non interrompere il team di sviluppo. Questo è in parte il modo in cui possono migliorare le prestazioni.

Se si riceve un ticket caldo/urgente che NON PU wait attendere la durata di uno Sprint, è necessario convincere il Product Owner a negoziare con il team di sviluppo per il modo migliore di introdurre l'elemento hot.

Tuttavia, questa dovrebbe essere un'eccezione, piuttosto che la regola. Se, come sottintende, ottieni molti bug da correggere, sarei tentato di eseguire il fix di manutenzione/difetto con un team separato usando KanBan, piuttosto che Scrum.

Answer 3

Sono d'accordo con te che questo non è un buon modo agile per fare le cose! La domanda da porsi è: il tuo vero obiettivo è pianificare gli orari di manutenzione o garantire che il tuo team venga utilizzato in modo ottimale lavorando su storie e difetti degli utenti mentre si esegue il codice di qualità su base continua, comprese correzioni di errori?

Vorrei fare un passo in più rispetto a ciò che Derek ha suggerito - e usare Kanban AND Scrum insieme - Scrumban sta sempre più prendendo piede! Dal momento che hai detto che potresti avere da 0 a 5 difetti in uno sprint, chiaramente la tua "richiesta di guasti" è variabile, così come la necessità della tua capacità di "manutentori di manutenzione". Cosa fanno quando ci sono 0 o 1 o 2 difetti? Presumo che contribuiscano anche alla "domanda di valore" - nuove storie di utenti.

Qui è dove risplende il Kanban. Mentre il design attuale della tua scheda Kanban dovrà essere analizzato dal tuo team, puoi potenzialmente iniziare con una semplice scheda a due corsie che rispecchia il tuo attuale processo per svolgere il tuo lavoro. Un semplice esempio è mostrato sotto -

Qui, avete tutti i vostri ingegneri disponibili per lavorare in entrambe le corsie. Mentre scorre il lavoro, a seconda di chi è libero di prenderlo in mano - e può riprenderlo - tirano dentro il lavoro e ci lavorano. Continui a mettere in ordine le cose per lo sprint in fase di staging e distribuisci il batch in una sola volta.

In alternativa, si potrebbe avere corsie completamente separate per user story e difetti -

Anche in questo caso, tutti i vostri ingegneri lavorano su articoli in entrambe le corsie. Tuttavia, si ha la flessibilità di implementare correzioni di errori non appena vengono riparate e accettate dal cliente (se applicabile). Con la vostra richiesta di valore, continuate a seguire lo stesso processo che state facendo ora e distribuite quando ogni sprint è fatto.

I vantaggi di uno di questi approcci sono -

1. si ottiene una piscina più grande di persone di lavorare su entrambe le situazioni.
2. È possibile ottenere tempi di risposta più rapidi, prestazioni SLA migliori, su difetti.
3. Hai una squadra più felice dove tutti possono lavorare su nuove cose. La maggior parte degli ingegneri non vuole essere "di manutenzione" ragazzi :-)

Naturalmente, questo è basato solo sull'analisi di base. Se non hai familiarità con Kanban o Scrumban, dovresti leggere libri di David Anderson (Kanban) e articoli di Corey Ladas (Scrumban) e molti altri come Yuval Yeret, Jim Benson, Masa Maeda e prepararti meglio. Puoi anche connetterti con noi su www.swiftkanban.com e possiamo anche aiutarti.

Spero che questo aiuti!