Come implementare lo Sprint con Scrum: #step6!

Ok, siamo con oggi allo #step6 della nostra Guida a Scrum: come implementarlo in 10 semplici passi.

Qui le tappe precedenti del nostro percorso:
Step #1: Tieni in ordine il tuo backlog di progetto
Step #2: Come fare la stima del tuo backlog di progetto
Step #3: Come pianificare lo Sprint – I requisiti
Step #4: Come pianificare lo Sprint – I task
Step #5: Come creare un ambiente di lavoro collaborativo

Oggi entriamo nel vivo dello Sprint, parlando di come implementare lo Sprint con Scrum.
——-

La prima nota necessaria è che Scrum non descrive precisamente in quale modo devi arrivare a consegnare i task del tuo Sprint. Scrum è infatti una pratica di management agile e non si addentra nello specifico dell’agile engineering, ambito che solitamente viene coperto invece da XP (Extreme Programming).
Forse è proprio questo il bello di Scrum: qualunque buona practice d’ingegnerizzazione tu stia usando, da RAD a RUP, da XP a DIY, Scrum si può adattare ad ogni contesto. Ecco perché è così semplice: è un approccio alternativo al management, ed è estremamente versatile. Si adatta ai progetti come al BAU (Business As Usual), e funziona. Proprio perché non è un approccio allo sviluppo, funziona anche fuori dal mero contesto di sviluppo.
Dicevamo: Sprint non fornisce alcuna descrizione specifica su come i team dovrebbero chiudere lo Sprint task dopo task, ma è pur vero che esistono alcuni principi-chiave dello sviluppo software agile e sono questi che è buona cosa tenere presenti quando si è faccia a faccia con lo Sprint.

I team agili devono avere il controllo

Il servant leader

Un team Scrum prende le proprie decisioni durante lo sprint, è in carico di queste decisioni e ne ha il pieno controllo.
Ogni volta che un manager s’intromette e prende una decisione per il team, in quel momento toglie responsabilità al team stesso e se continua a farlo rieptutamente -pezzo dopo pezzo- solleva il team dal controllo sul progetto.

Il ruolo del manager in un team Scrum è quello di guidare, offrire supporto, assistenza, ma mai dare istruzioni e soverchiare nel controllo.
Il team deve essere aiutato a prendere le decisioni al proprio interno ed in autonomia, non sollevato dall’assumerle. La capacità di facilitare è un requisito fondamentale dello Scrum manager: usare la propria esperienza e responsabilità per aiutare il team a svolgere il proprio lavoro, non per dirgli come farlo. La tipica servant leadership, insomma: un leader che sappia mettersi al servizio del team, supportarlo, ispirarlo.

Il tempo non aspetta nessuno

Se aggiungi, sottrai.

La durata dello Sprint è stata fissata.
Puoi eventualmente aggiungere obiettivi o task in corsa, ma solo nel caso in cui siano assolutamente necessari ed in ogni caso ogni eventuale aggiunta dovrebbe idealmente essere sempre equilibrata da una corrispondente sottrazione.
Es: si aggiunge un task ma se ne toglie un altro.

Nell’ottimistico caso in cui finiste un task in anticipo, si procede con quello immediatamente successivo sulla lista del backlog.
Se invece pensate di essere in ritardo non vi rimane che eliminare uno o più interevnti previsti per evitare di mancare la deadline di consegna.

È finito quando è (veramente) finito

Chiudi qualcosa al 100%, non tutto all’80.

Per evitare di perdere il filo del backlog stabilito, è assolutamente imperativo assicurarsi che un task sia effettivamente, definitivamente e completamente chiuso prima di procedere con quello successivo.

Quello che devi cercare di evitare come la peste è di arrivare in prossimità della chiusura di Sprint col 90% di tutto il lavoro fatto.

Sì, hai letto bene: il 90% di tutto il lavoro fatto non serve, perché ti permette di consegnare nè di chiudere lo sprint.
Il 100% di qualcosa sì.
C’è una sottile ma significativa differenza, ed è fondamentale coglierla.

…Fase di testing inclusa.

Includi i test nel ciclo del task

Rispetto a quanto sopra è importante specificare che un task è finito al 100% quando include anche il test di tutte le sue feature, quando cioè il testing è incluso nel ciclo di vita del task e quando restituisce i desiderata attesi, naturalmente.
Siamo sempre al consueto discorso: nello sviluppo agile smettiamo di pensare alle fase design-sviluppo-test come macro fasi dell’intero progetto nel suo complesso e cominciare a considerarle invece come fasi ricorrenti di ogni singolo ciclo di vita di una task.
Il testing parte con l’inizio dello Sprint, non alla sua fine.
Comincia nella pianificazione, perché lo integriamo direttamente nello Sprint e non al suo esterno in un generico ( e pericolosissimo) “dopo”. Questo implica -chiaramente- che chi si occupa della fase di testing deve essere presente e dare il suo contributo nella definizione delle specifiche e dei requirements di progetto. Se scrivi le procedure di testing prima che la feature venga sviluppata otterrai sviluppatori più attenti e inclini a scrivere un codice pronto già ottimizzato per passare il test.

Nessuna interferenza, se possibile

Potere allo Scrum team

Una volta che lo Scrum team ha preso uno Sprint in carico, dovrebbe essere lasciato libero di auto-organizzarsi e concentrarsi su quanto, per l’appunto, hanno preso in carico.
Continue modifiche alle priorità impediscono al team di essere pienamente produttivo e li conduce al rischio di non riuscire a tagliare il traguardo della consegna.
Se qualcosa nelle priorità deve necessariamente essere aggiunto a Sprint avviato, che si alloa eqamente equilibrato da una qualche altra priorità che viene tolta a compensazione.

In ogni caso, è comunque una pratica che consigliamo di evitare nella maggior parte dei casi: questo perché quel piccolo pezzo di aggiunta non è mai così piccolo come sembra, dal momento che non è stato discusso né pianificato, oltre al fatto che si va ad aggiungere allo sforzo stesso di prevederlo in corsa e mettere in opera l’occorrente per realizzarlo.
Con i task dell’ultimo minuto consigliamo quindi sempre un approccio “largo”: per ogni 3 h di sviluppo aggiunto, dovreste toglierne non 3, ma 6.

Eliminare uno Sprint

Pensaci due(mila) volte.

L’eventuale eliminazione di un intero sprint è una decisione estremamente forte, ergo da valutare con cautela e solo in circostanze davvero eccezionali.
Nella prassi significa eliminarlo completamente e ritornare alla pianificazione per rivederla nelle sue parti, riscrivere le priorità e pianificare gli sprint da capo.
Può rendersi necessario qualora l’obiettivo dello Sprint non sia più per qualche motivo ragionevolmente raggiungibile. Oppure che sia intervenuta una circostanza tale da modificare completamente il focus del team sul progetto.
Anche in questi casi comunque, attenzione: eliminare uno sprint è un atto irreversibile e che comporta una rilavorazione notevole. Non prendetelo mai alla leggera.

Step #1: Tieni in ordine il tuo Backlog di progetto
Step #2: Come fare la stima del tuo backlog di progetto
Step #3: Come pianificare lo Sprint – I requisiti
Step #4: Come pianificare lo Sprint – I task
Step #5: Come creare un ambiente di lavoro collaborativo

Step #7: Standup e… fai sentire la tua voce!
Step #8: Traccia i progressi con un diagramma quotidiano
Step #9: Consegna in tempo!
Step #10: Rivedi, rifletti, ripeti.