Scrum, c'è un percorso critico per la pianificazione del rilascio?

Il pensiero critico viene dal tentativo di prevedere il futuro e indovinare dove / come possono verificarsi i colli di bottiglia o dove i rischi possono verificarsi e causare problemi e quindi organizzare il resto delle attività di sviluppo attorno a quei colli di bottiglia / rischi in modo che l'importante le funzionalità possono essere "garantite" per la consegna.

Da un certo punto di vista questo è un aspetto del pensiero snello e cerca di ottimizzare il flusso attraverso il processo di sviluppo, purtroppo di solito non viene confermato in questo modo perché viene trattato come un esercizio in stile cascata frontale e mai rivisto man mano che lo sviluppo avanza . La realtà è che abbiamo colli di bottiglia e rischi dappertutto e tendono a cambiare nel tempo mentre il team lavora attraverso lo sviluppo. È come ci adattiamo a quelli che è importante.

In Scrum evitiamo l'inutile sforzo di predire il futuro facendo piccoli lotti di lavoro e poi ispezionando i nostri progressi e adattando le attività pianificate per il prossimo piccolo lotto in base ai risultati del nostro precedente lavoro, sui rischi che hanno effettivamente provocato e le funzionalità più preziose di cui abbiamo bisogno in seguito.

Ciò non significa che non possiamo fare alcune riflessioni iniziali sui rischi e sull'ordine di consegna delle funzionalità. In scrum facciamo questo lavorando con il proprietario del prodotto in modo che ordinino il backlog del prodotto con gli articoli ad alto rischio / alto valore che vengono prima. Inoltre gestiamo i colli di bottiglia monitorando la nostra velocità e assicurando che pensiamo a dove stiamo andando lenti e come migliorarlo durante ogni retrospettiva di primavera.

Quindi, mentre Scrum non ha alcun componente di pianificazione del percorso critico, il processo stesso incorpora questo pensiero direttamente in esso. Forniamo gli articoli "critici" nelle fasi iniziali e affrontiamo eventuali rischi che riteniamo possano verificarsi in modo da avere il tempo di apportare eventuali modifiche per i nostri piani futuri in base a quali eventi, assicurando al tempo stesso che il cliente ottenga ciò di cui hanno bisogno il più presto possibile possibile.

Non esiste più un percorso critico.

Alla fine di ogni sprint hai un prodotto consegnabile. Lo mostri al cliente nella demo di sprint. Se al cliente piace ciò che vede, puoi consegnare ciò che hai, se non lo fai fai un altro sprint.

Ripeti i processi. Ogni volta che il cliente sembra aver acquisito una notevole quantità di funzionalità (storie), può prendere in consegna la versione successiva.

Avere una scadenza fissa (ogni 3-6 mesi) e un set di funzionalità fisse è ciò che stai cercando di evitare. Come puoi pianificare qualcosa che è a 6 mesi di distanza con le poche conoscenze che hai e aspettarti di raggiungere entrambi gli obiettivi.

Puoi fornire stime ma ogni scatto devi rivalutare ciò che puoi ottenere.

• Se hai impostato una funzione fissa, il punto finale si sposterà alla fine di ogni sprint.
• Se hai un punto finale fisso, il set di funzionalità si sposterà alla fine di ogni sprint.
• La terza tappa è di qualità e in mischia questa è la gamba che non deve essere spostata. Devi ancora fornire test unitari e verifica di ogni sprint.

È meglio non averne e lasciare che il cliente accetti aggiornamenti incrementali man mano che le funzionalità diventano disponibili.

Se stai facendo Agile, non ci dovrebbero essere delle dipendenze perché puoi testare senza aver completato le parti su cui sei "dipendente". E la rara eccezione non dovrebbe essere sufficiente per fare un analisi critica del percorso utile.