Stabilizzazione agile e gestione del rilascio

Non dovresti avere sprint di stabilizzazione. Il tuo software dovrebbe essere rilasciabile ogni sprint. Ciò significa che se hai bisogno di stabilizzazione, ciò deve avvenire all'interno di ogni sprint e non solo prima di un rilascio. Una volta raggiunto questo obiettivo, la pianificazione del rilascio diventa una preoccupazione per il proprietario del prodotto ("Quali caratteristiche sono necessarie per il rilascio?") E la stabilizzazione di un problema di gruppo (definizione di fatto).

Lo stesso vale per i bachi e il debito tecnico: sono cose che sono sempre fissate, se necessario e non richiedono storie - di fatto, è normalmente parte di ogni storia: non può essere "fatto" a meno che non sia stabile e correttamente refactored.

Mi rendo conto che questo non risponde direttamente alla tua domanda, ma la stabilizzazione non è affatto un concetto agile , quindi non ha senso chiedere come farlo con Scrum.

Modificato per commentare l'indirizzo:

Secondo Scrum, i bug hanno rilevato che le pre-release devono essere gestite all'interno dell'iterazione. Una storia non è normalmente considerata "fatta" se ha dei bug. Se non puoi spedirlo, non ha valore. Inoltre, secondo i principi base di Agile, le squadre dovrebbero lavorare a un ritmo sostenibile. Se è necessario interrompere lo sviluppo in modo sostanziale per affrontare il debito o gli errori, allora non si sta lavorando a un ritmo sostenibile. Diminuisci la tua velocità, spedisci meno funzioni, ma senza bug.

Di solito la stabilizzazione avviene in team con un team di controllo qualità separato che controlla le funzioni post hoc . Questo non si adatta al modello Agile o Scrum. Le squadre dovrebbero essere funzionali e in grado di spedire una funzione in modo indipendente.

Nel complesso, molte aziende affermano di fare Scrum o Agile senza comprendere i profondi cambiamenti che ciò comporta nel modo in cui il software viene creato. Se non sei preparato a creare software in base a queste metodologie, non utilizzarlo come "aggiunta di gestione" su pratiche diverse.

Se gli dai il nome di "stabilizzazione" o semplicemente "Sprint 12" non importa, a un certo punto la tua squadra avrà interrotto lo sviluppo iniziale di storie e farà sprint di debito tecnico o chiuderà storie che non hanno È stato fatto perché sono stati trovati problemi e non è stato possibile chiuderli. Questi sono solo normali sprint agili, suppongo che la tua squadra sia come la nostra e sa che avremo bisogno di quel calendario per affrontare il problema "Non ho pensato a quello".

Nel nostro negozio, se inizialmente prevediamo un backlog di rilascio di 400 punti e inizialmente pensiamo di poter fare una velocità di 100 punti basata sulla cronologia, ciò dovrebbe teoricamente significare che possiamo farlo in 4 sprint. Tuttavia, abbiamo anche abbastanza esperienza sui progetti per sapere che le nostre stime di velocità e arretrato totale non sono sempre corrette. Potrebbe essere necessaria una nuova funzionalità per MVP, un ritardo imprevisto potrebbe impedirci di completare qualcosa, quindi pianifichiamo un simile "sprint" per affrontarlo. Quindi potremmo inserire 5 o 6 sprint nel nostro piano di calendario per tenere conto del livello di sconosciuto.

Ora, la quantità di tempo che stai pronosticando per la "stabilizzazione" indica un problema organizzativo con la consegna se hai bisogno di quasi tanto tempo per stabilizzare quanto inizialmente costruire. Come altri hanno già accennato, è probabile che sia necessario integrare i test in precedenza nella fase in modo da ottenere il feedback in precedenza. Usando tecniche di test continuo, la tua squadra ripulirà le storie man mano che andrai. In questo modo, quando la tua squadra è effettivamente "completata", la versione è pronta.

ASSUMI CHE FATE QUESTA REGOLAZIONE: Ora arriviamo alla parte di gestione del rilascio della nostra domanda: come affronti il tentativo di terminare il rilascio mentre inizi anche una nuova versione in parallelo? In genere, l'ultimo sprint o due potrebbero non avere abbastanza lavoro per la tua versione iniziale per mantenere occupato tutto il team. Questo è quando puoi iniziare a introdurre le tue prossime storie di rilascio per mantenere la squadra al massimo delle capacità. Dal punto di vista della gestione del codice, l'utilizzo della strategia di diramazione preferita aiuta a mantenere isolate le codebase e il team può passare da un ramo all'altro in base all'attività su cui sta lavorando. Dal punto di vista della gestione delle attività, devi essere in grado di delineare chiaramente la squadra che rilascia una funzionalità, in modo che sappiano dove metterla.

Dovresti dividere il team? Personalmente, ho trovato utile questo per mantenere i membri del team concentrati, ma funziona davvero solo se la tua squadra può davvero lavorare su quasi tutto. Se si dispone di specialisti, avranno le capacità di cui tutti hanno bisogno e avranno bisogno della flessibilità per saltare tra una release e l'altra. Se puoi definire un gruppo principale per gestire entrambe le versioni e poi altri membri del team che possono farlo fluttuare, ciò può consentire un attacco più bilanciato.

COSA SE NON SEI PROVA CONTINUA? Se stai costruendo un sacco di codice, buttandolo su un altro team e poi passando alla nuova versione e aspettando il feedback, lo farai è necessario gestire la tua squadra in modo diverso. Si tratta di una modalità di consegna più "a cascata" e significa che il team di rilascio iniziale non può prevedere quando arriverà il feedback o quanto ci sarà. Ciò rende la pianificazione degli sprint più difficile per la prossima versione poiché non si è sicuri di quanto lavoro ci sarà nella versione iniziale. In questo scenario, potrebbe essere necessario pianificare i nuovi sprint di rilascio per avere un "buffer" in grado di tenere conto del feedback del team di test. Probabilmente userai l'intero team per la nuova versione all'inizio e, una volta che avrai un debito tecnico da risolvere, potrai iniziare a formare un gruppo per affrontarlo e cancellarlo.

Mi scuso perché questo può sembrare un po 'militante e duro, ma se vuoi giocare al gioco agile di alto livello, è meglio essere preparati a mettere in campo i grandi cannoni, lavorare come un matto e mai scendere a compromessi.

Vorrei prendere in considerazione la possibilità di mettere in cortocircuito i tuoi sprint e fare della qualità e testare una priorità assoluta. Ho lavorato con team agili rilasciando settimanalmente e ogni due settimane e trovando qualcosa di diverso da quello che può essere problematico. Una buona suite di test solida (copertura al 100% insieme ai test automatici del browser) e revisioni obbligatorie di tutto il codice faranno molto per ridurre i bug. Il vantaggio del ciclo di rilascio settimanale è che i bug vengono corretti quasi immediatamente e gli sprint di stabilità diventano un problema. Questo tipo di sviluppo richiede una grande quantità di disciplina e deve essere guidato militante dal proprietario. Se la tua azienda non è disposta a portare avanti questo livello di impegno, diventerai un altro aspirante agile e mediocre, quindi non perdere tempo.

Per commentare le tue domande:

1. Hai solo bisogno di una squadra. Le persone sistemano i propri bug poiché hanno la maggior conoscenza di loro e con un programma di rilascio settimanale le cose dovrebbero essere fresche.

2. Le dimensioni e i dibattiti sono inutili. Gli sviluppatori hanno compiti e sono responsabili per le stime e la programmazione. La gestione può sovrascrivere questo, ovviamente, ma i bug dovrebbero sempre essere affrontati per primi a meno che non ci siano ragioni di business critiche per non farlo. Tratta il debito tecnico come bug. Non dovrebbe esserci alcunché, a meno che un motivo commerciale critico non lo crei. Idealmente il debito tecnico non dovrebbe superare la revisione del codice. Se lo fa, come un bug risolverlo nella prossima versione.

3. Bug e nuove funzionalità sono uguali. Non c'è motivo di differenziarsi poiché è la loro priorità che conta.

Infine, automatizza, automatizza, automatizza e poi trova un modo per automatizzare ancora. Non c'è modo di realizzare questo livello di sforzo senza automazione.

Stabilità della vestibilità in agile bene. Semplicemente non è una caratteristica.

Questo è un debito tecnico. Dove questo si adatta in modo agile è la quantità di funzionalità che si accetta la responsabilità di consegnare. Agile dice che non prometti al proprietario del prodotto che questo sprint "stabilizzerà" qualsiasi cosa. Questo non significa niente per loro. Dici: "Prevediamo che la nostra velocità diminuirà perché abbiamo realizzato il bisogno di ripulire e ci impegneremo solo in queste 3 cose". Fai in modo che quelle 3 cose siano abbastanza piccole da lasciare il tempo di ripulire.

Certo, dovresti essere stabile e pulire ogni sprint. Ma a volte il codice ha bisogno di un grande refactoring. Agile non dice che non puoi farlo. Dice che non hai credito per questo.

Solo perché sei pagato per abbattere l'albero non significa che non devi affilare la tua ascia. Non aspettarti di essere pagato per affinare la tua ascia. La tua ascia è sotto la tua responsabilità.