La questione della gestione degli errori nella produzione è stata una grande funzione nella mia mente negli ultimi tempi. Gli Sprint non sono pensati per avere elementi aggiunti a loro, ma per i bug critici , questo è semplicemente inevitabile.
Come si fa a gestire questa pausa nello sprint? Concedi semplicemente uno sprint a una percentuale di "tempo", quindi riempire solo l'80% del programma con gli sprint "nel caso in cui"?
Se questo è critico , devi gestirlo.
Per misurare il suo impatto sullo sprint, devi loggarlo.
Guarda questo radiatore di informazioni:
C'èunapartechiamata" Elementi non pianificati ". Metti il tuo bug critico lì. Come puoi vedere, esiste l'inversa con la parte " Avanti " in cui inserisci più storie utente rispetto a quelle pianificate nel caso in cui completi lo scatto più velocemente.
Ne parleremo nella recensione sprint e / o nella retrospettiva . L'obiettivo è trovare come limitarli e anche regolare di conseguenza la velocità di conseguenza .
Se si utilizza la velocità come indicatore di "tolleranza" in base al meteo di ieri, si regolerà automaticamente per una quantità media di tagli di lavoro extra negli sprint.
Se il problema di produzione è causato da bug creati in precedenti sprint, è OK che il lavoro di riparazione sia ridotto alla velocità dello sprint corrente. In questo modo la velocità della squadra viene "compensata" per i punti che non avrebbero dovuto guadagnare in precedenza.
A volte non fai tutti i tuoi obiettivi di sprint, superalo ;-) Velocity raggiungerà la media di un numero inferiore se succede molto.
Qualsiasi altro elemento non critico può essere incluso nel backlog per l'inclusione normale in uno sprint. Preferisco dare la massima priorità ai bug e non farli contare sulla velocità.
Tutto il tempo necessario per risolvere e risolvere i problemi di produzione viene automaticamente incluso nella velocità del team. Ci vuole solo del tempo per passare alla media, non ha davvero bisogno di un assegno separato.
Lavoro in un team che svolge prevalentemente attività di sviluppo, ma è anche responsabile di sistemi complessi esistenti. Abbiamo avuto anche questo problema.
Fondamentalmente, stimiamo i nostri punti in base all'ultimo sprint (s) e quindi riserviamo un numero di punti per il lavoro di manutenzione previsto. Se si verifica un'attività di manutenzione che supera in modo significativo questo aspetto, ad esempio un'interruzione maggiore, la aggiungiamo come storia utente e ne rimuoviamo quella esistente che non è ancora stata avviata, per mantenere lo sprint della stessa dimensione. Se si verifica un problema grave meno urgente, lo spostiamo nel prossimo sprint.
Sì, tecnicamente non sta seguendo la mischia. Ma la flessibilità ha funzionato bene per noi.
Abbiamo perfezionato questo tempo riservato chiedendo al team in ogni riunione di pianificazione se vedono un motivo per deviare dalla prenotazione standard. L'abbiamo presentato dopo aver fatto una mossa per l'ufficio che ci ha portato via molto più tempo di quanto avevamo previsto, portando a molte storie non finite.
Tuttavia, non limitarti a come la mia squadra o qualsiasi altra squadra lo fa. Scegli qualcosa, e fallo e basta. Non c'è modo di garantire che funzioni bene per la tua squadra. Prova e valuta nella retrospettiva. Se la squadra è infelice, prova qualcosa di diverso e valuta di nuovo. Tutti i team sono diversi e anche i loro bisogni e limiti sono diversi.
Se si tratta di un problema di produzione critico, dovresti essere in grado di gestirlo direttamente, la metodologia di sviluppo scelta è irrilevante. Una correzione non è correlata a un ciclo di rilascio regolare (spints o altro).
Suggerirei di risolverlo in un branche 'fix', basato sul codice attualmente in produzione.