Scrum - Gestire gli hotfix

Uno dei principi fondamentali di Agile è che è più importante capire cosa funziona per la squadra che seguire ciecamente le regole. Sì, la "regola" è che non lavori mai a metà dello sprint.

La realtà è a volte più confusa. Se arriva un difetto critico, e forse un difetto ti sta costando denaro, o l'apertura della tua azienda a responsabilità, o l'apertura di un hacker o la disattivazione di una funzionalità fondamentale, è dannatamente corretto ora, le regole vanno maledette.

In tutti questi casi, però, dovresti sempre considerare "rollback" come opzione preferita. Questo non è solo a causa del processo Agile. È anche perché gli aggiornamenti rapidi affrettati sono un modo comune per creare un difetto ancora più disastroso. (Potrei raccontare storie ...)

Ci sono quindi due cose importanti da considerare.

1) Devi assicurarti che ciò avvenga solo per difetti critici, non "il VP senior non ama il colore dello sfondo". Questo naturalmente diventa un po 'più difficile se si ha l'abitudine di correggere problemi critici. Quindi, ovviamente, la soluzione è non entrare mai in questa situazione in primo luogo. Questo è il motivo per cui Agile pone una strong enfasi sui test automatici. Se disponi di un CI e di una infrastruttura di testing davvero affidabili, dovresti vedere queste situazioni di hotfix solo una volta in una luna blu.

2) Come si spiega il lavoro? È più facile Hai lavorato, quindi hai una storia. Tu punti la storia. È incluso nella velocità. Ma ovviamente come detto sopra, questo dovrebbe essere raro.

Quando viene rilevato un problema, devi innanzitutto eseguire una valutazione del problema per determinare se si tratta di un problema di "correzione immediata" davvero critico o se può essere sospeso e pianificato insieme all'altro lavoro.

Se il problema deve essere risolto immediatamente, devi inserirlo nello sprint corrente come lavoro non pianificato e tenere traccia del tempo trascorso dal team su di esso.
Alla fine dello sprint, probabilmente scoprirai che non hai potuto completare tutto il lavoro che avevi inizialmente programmato. Gran parte di questo "residuo" del lavoro sarà dovuto al lavoro non pianificato che doveva essere fatto. Durante la revisione sprint, è anche utile menzionare quanto tempo il team ha "perso" sul lavoro non pianificato, perché può essere un'indicazione per problemi all'interno dell'organizzazione (o del team) se una parte significativa dello sprint viene persa in caso di mancato utilizzo lavoro.

Se si inizia a ripararlo immediatamente o si esegue il rollback dell'aggiornamento, non si dovrebbe basare sullo stato di nessuno sprint. Questo articolo dovrebbe andare sul backlog e potrebbe essere necessario fare una sorta di mini sprint per alcuni giorni o semplicemente estendere lo sprint precedente. Risolvi il problema e non preoccuparti troppo per Scrum.

L'intero punto deve essere agile e non arbitrariamente attenersi a blocchi di pianificazione di 2 settimane. Sono utilizzati come guida per avere una certa coerenza per semplificare la pianificazione (quindi, in genere, cosa facciamo in genere?). Alcune volte potresti iniziare uno sprint e buttare via tutto e ricominciare da capo per qualche problema imprevisto. La chiave è far sapere ai responsabili che le interruzioni sono sempre dolorose. Non c'è modo di aggirare le battute d'arresto che creano in tutti i progetti. Questa correzione non avverrà senza che qualcun altro non venga eseguito, quindi assicurati che tutti sappiano che non dovresti nemmeno provarlo.

Lascia che il problema si risolva / si interrompa nello sprint corrente

Questo di solito non è un'opinione popolare, ma: risolvi il problema. Hai lasciato cadere la palla lo sprint scorso. Lascia che passi alla tua velocità per questo sprint. Ciò creerà un incentivo a non far cadere di nuovo la palla e renderà la tua velocità più realistica a causa dell'inclusione dei problemi che si verificano.

Tuttavia, se è possibile posticipare la correzione al prossimo sprint, perché non è critico o un rollback non rappresenta un problema. Includere la correzione come una storia di bug senza assegnare punti storia. Di solito vado su questa rotta se si tratta di un problema in sospeso, non rilevato, non necessariamente creato dallo sprint precedente.

Dopo lo sprint, la tua versione deve rimanere chiusa, quindi è impossibile aggiungere o rimuovere storie, ma puoi comunque modificarle.

1. Trova la storia che ha originato questo bug e riaprilo. Assegna un nome a qualcosa come "Rifiutato" o "Test fallito", o qualsiasi altra cosa pensi sia ragionevole.
2. Assegna di nuovo il lavoro a questa storia, io la chiamo "Compiti", durante il tuo attuale sprint. Ogni sprint dovrebbe avere un tempo extra pianificato per quel tipo di problemi. È facile essere preparati per questo dopo le riunioni di revisione e consegna.
3. Fallo, testalo, segnalalo e consegnalo come "hotfix".
4. Chiudi di nuovo la storia.

Se la merda è troppo grande per entrare nel tuo calendario, crea una nuova storia nel backlog del tuo prodotto, assemblala con priorità alta e risolvila il più velocemente possibile. Mantieni la tua vecchia storia aperta e contrassegnata per non dimenticartene, puoi anche fare una relazione come "questa storia è bloccata da questa un'altra". Il fatto è, basta chiuderlo dopo aver fatto anche la nuova storia.

Ripristina la distribuzione precedente e accoda il lavoro nel backlog.

Se si ottengono bug "critici" come questo, si punta a un errore nei test, affrettare le modifiche fa solo peggiorare le cose. Spingi indietro la prossima versione, che a sua volta si sposta velocemente, il che porta a più bug, che spinge indietro la prossima versione .. ecc.

Rilascia la versione, prenditi del tempo per capire perché il bug è stato perso, assicurati di mettere in atto i processi per evitare che ciò accada di nuovo.

Supponendo che non possa aspettare e che un rollback non sia necessario, impossibile o indesiderabile, ti sei suddiviso in due sprint paralleli. Ovviamente hai bisogno di dividere le tue risorse per farlo, ma spero che sia solo un dev e un po 'di QA.

Uno sprint prende il ramo di produzione attuale e si sviluppa, test & distribuisce la hot-fix e solo la hot-fix. A causa del ramo, non sono inclusi lavori "in corso" e puoi pubblicare annunci in modo indipendente non appena la correzione è pronta.

L'altro sprint continua con il resto del team e il backlog corrente sapendo che saranno a corto di risorse. Esegui ciò che ha senso per il proprietario del prodotto (completa utilizzando un po 'più di tempo o premi la data, ma non riesci a trovare alcuni elementi) e distribuisci.

Hai portato uno o più membri del team fuori dallo sprint principale. Gli effetti sulla velocità e quant'altro possono essere valutati e giustificati / riconciliati come è logico. La cosa fondamentale è che puoi riuscire a eseguire il rollback, correggere, arare approfonditamente o pianificare come desideri. Non hai un processo che non ti dà queste scelte.