In quest’ultima parte parliamo dello SPRINT, come viene pianificato, eseguito, dimostrato e rivisto.

La prima azione relativa allo SPRINT è la pianificazione delle attività che verranno eseguite. Come possiamo aspettarci qualsiasi attività prima di essere eseguita viene pianificata.

Uno degli errori più comuni infatti è pensare che AGILE manchi di pianificazione: non è vero.

La pianificazione avviene già all’inizio, ad esempio con il Release Planning, dove si presenta il rilascio delle caratteristiche del prodotto nel tempo. E’ chiaro che è un documento che viene aggiornato ed è chiaro che non si arriva ai task che verranno eseguiti negli SPRINT, la granularità di maggior dettaglio è la User Story.

Una domanda tipica dell’esame di certificazione PMI-ACP® (che nel tempo di pubblicazione di questi articoli ho conseguito, a conferma della validità dei corsi di BE Formazione) è, ad esempio, qual è l’elemento minimo considerato nel Release Planning. Non può essere il task, perché quello verrà deciso dal gruppo all’ultimo momento responsabile, cioè prima dello SPRINT, ma è la User Story. I task vengono decisi nello Sprint Planning.

Lo Sprint Planning

Questo evento è molto particolare. Siamo abituati a vedere un leader (technical leader) che assegna i task da eseguire ai colleghi del gruppo.

Non è così in AGILE.

Se rivedete i precedenti articoli più volte si è affermato che il gruppo è auto organizzato. Ed è proprio così.

Supponiamo, per semplicità, che si debba costruire la pagina di login. Una persona del gruppo lo ha già fatto in un altro progetto e magari ci impiegherà poco tempo a svilupparla, allora potrà dire: la login la sviluppo io. Un altro programmatore è esperto in tematiche di eCommerce e potrà dire, questa parte la sviluppo io. In modo autonomo il gruppo si assegna i task e si coordina per il rilascio a fine SPRINT: quando le User Story sono state sviluppate e raggiungono lo stato di “Done”.

E’ questo il coordinamento che avviene nello Sprint Planning, in modo del tutto autonomo da parte del Team.

Abbiamo già visto nella seconda parte dell’articolo che lo Sprint Planning crea un Backlog delle User Story da implementare.

Sono le User Story presenti nel Product Backlog, che è gestito dal Product Owner. Quest’ultimo ha dato priorità alle User Story, in modo da consegnare subito del Valore al Cliente. Quindi le User Story scelte per essere inserite nello Sprint Baklog saranno quelle con priorità più alta.

Ma la scelta dovrà tenere conto anche del fatto che tutte le User Story scelte dovranno essere implementate nello SPRINT. Non viene considerata la possibilità che una User Story sia parzialmente implementata. Alla fine se una User Story non ha raggiunto lo stato di Done è come se non fosse stata neanche iniziata.

Per questo motivo occorre considerare la velocità.

Quanti story point il gruppo può sviluppare in uno SPRINT. 30 Story Point ? Allora la somma del valore dei story point assegnate alle User Story deve essere inferiore o uguale a 30.

Lo Sprint

Durante lo SPRINT possono succedere tante cose. Ad esempio può succedere che viene rilevato un problema tecnico. Cosa fare dipende dalla gravità del problema. Solitamente la soluzione viene rimandata ad uno spike, se non ha impatti immediati sul progetto.

Uno spike risolve infatti un technical debt. Dopo aver accumulato una serie di “debiti tecnici” il team decide di risolvere dei problemi ad esempio architetturali, che aveva messo da parte sempre con la logica dell’ultimo momento responsabile. Lo spike, che ha una durata inferiore allo Sprint e non impegna tutte le persone del gruppo, porterà ad una soluzione, oppure ad una maggiore conoscenza per poter poi trovare la soluzione in un secondo momento.

Se il problema è grave ed è bloccante per il progetto, anche se lo Sprint è un’unità minima che non potrebbe essere interrotta, si può decidere di trovare una soluzione anche interrompendo i task in corso.

Ancora durante lo Sprint potrebbe succedere che il Product Owner, che ha di continuo comunicazioni face to face con il Team, come è nello spirito AGILE, affermi che alcune User Story non hanno più senso e non danno valore al progetto.

Quindi dovranno essere assegnate altre User Story, in modo da poter continuare a consegnare valore al Cliente.

Quindi lo Sprint è un evento complesso e per niente scontato, e le best practice e gli approcci dei vari framework ci aiutano a prendere le decisioni giuste.

La durata dello Sprint varia a seconda dei framework: in Scrum un mese o meno. In XP due settimane. Lo Sprint planning dura 2 ore per la durata dello Sprint. Mentre il meeting giornaliero dura sempre sui 15 minuti. Il Retrospective dura 3 ore per uno Sprint di due settimane o meno in proporzione.

Il Daily Stand Up meeting

Cosa abbiamo fatto ieri? Quali ostacoli abbiamo trovato? Cosa vogliamo fare oggi?

Sono queste le domande che guidano il Daily, che dura 15 minuti, è un meeting quotidiano. Le cose che si dicono sono in continuità con quelle dette ieri.

Un errore da evitare è cercare di risolvere un problema od un ostacolo presentato durante il meeting. La cosa migliore è, se la gravità del problema lo richiede, di finire il Daily, dando l’opportunità a tutti di parlare e affrontare il problema appena dopo il meeting, con le persone che possono dare un contributo.

Anche questo è un concetto che viene stressato durante l’esame di certificazione.

Lo Sprint Review

Come si ottiene l’approvazione del Cliente su quanto è stato sviluppato? Come facciamo ad avere subito i correttivi nel caso la strada che stiamo seguendo non fosse quella che si aspettava il Cliente ? Con lo Sprint Review. In questo evento avviene una dimostrazione di quanto è stato sviluppato nello Sprint: del Done delle User Story.

La dimostrazione del Review ha l’obiettivo di mettere tutti d’accordo, non solo il Cliente. Tutti sono allineati sulla consegna che viene effettuata, tutti hanno condiviso il Done precedentemente ed adesso lo verificano. Nel caso ci fossero delle incomprensioni, meglio che vengano fuori adesso dopo il primo Sprint, che alla fine. Con evidente risparmio di tempo e di costi.

Lo Sprint Retrospective

In questo evento avviene il più volte enunciato Continuos Improvement di AGILE.

Le domande che guidano questo evento sono :

Cosa ha funzionato ?

Cosa non ha funzionato ?

Cosa può essere migliorato e come ?

Durante il retrospective hanno luogo una serie di giochi che aiutano ad avere i feedback.

Triple Nickel

Ad esempio una tecnica utile nel Retrospective, ma che viene utilizzata anche in altri eventi, per decidere come andare avanti nel progetto è quella denominata Triple Nickel.

Consente di generare idee su punti posti all’attenzione ed importanti per il progetto.

Si svolge in questo modo: ogni partecipante ha 5 minuti per scrivere su un foglio le proprie idee sull’argomento. Successivamente passa il foglio al collega a fianco. Si continua fino a quando il foglio ritorna al primo partecipante.

Questa tecnica può essere utile per avere il contributo di persone che solitamente partecipano meno degli altri nelle discussioni.

Color Dots, Mad Sad Glad, ROTI

Altre tecniche vengono considerate per avere un feedback emotivo da parte dei team member quali il Color Code Dots oppure il Mad, Sad, Glad.

Durante tale attività ognuno esprime come si è sentito durante l’iterazione. Il feedback può essere espresso anche con la tecnica ROTI (Return On Time Invested), per valutare l’efficienza della sessione di Retrospective appena conclusa dal punto di vista del Team Member.
Per facilitare i membri del Team a scambiarsi opinioni su quanto siano soddisfatti rispetto a particolari aree del progetto, possono essere implementati i «Satisfaction Histogram» .

L’Istogramma viene utilizzato anche per misurare l’interesse del partecipante rispetto alla riunione che si sta per tenere o in corso. Ad esempio ad ognuno viene chiesto il proprio livello di interesse, classificandolo in:

ESVP

E= Explorer. Vogliono apprendere tutto quello che viene detto in Riunione. Sono ansiosi di scoprire nuove idee

S= Shopper. Vogliono esaminare quello che viene detto ed è lieto di tornare dalla riunione con nuove idee

V=Vacationer. Non sono interessati alla riunione ma sono lieti di non svolgere il loro lavoro quotidiano

P= Prisoners. Sono costretti a partecipare alla riunione ma vorrebbero fare altro.

Ci siamo dilungati sul Retrospective perché è qui che si realizza il miglioramento continuo ed è importante avere il contributo di tutti. In realtà l’uso dei giochi è molto diffuso in AGILE, perché consentono di ottenere ottime valutazioni con il coinvolgimento del Team. La più famosa è la tecnica del Planning Poker.

Il Planning Poker

Questa tecnica in realtà si basa sull’osservazione principale attribuita a WideBand Delphi.

Il dimensionamento che è espressione del gruppo ha più valore del dimensionamento individuale.

Significa che occorre evitare il groupthink, che accade quando personalità forti influenzano le stime. Se le personalità forti influenzano le stime allora si avrà un dimensionamento individuale.

Ma il principio enunciato stabilisce che il dimensionamento di gruppo ha più valore. Quindi, come succede nel poker, le stime non vengono mostrate subito. Ma alla fine ognuno mostra quanti punti assegna alla User Story, utilizzando un mazzo di carte che raffigura i punti da assegnare.

Prima di mostrare i punti, illustra il suo punto di vista con un time box di due minuti, potrà se vuole ripetere la discussione dopo. Due minuti perché non bisogna perdere troppo tempo nello spiegare il proprio punto di vista. Alla fine si chiede a chi ha dato il punteggio minore, e a chi ha dato il punteggio maggiore alla storia, di spiegare le motivazioni.

La discussione si ripete perché probabilmente alcune complessità tecniche possono essere state poco chiare e necessitano di dettagli. Alla fine si arriva ad un comune accordo. Durante la discussione è possibile anche far riferimento ad una storia che è stata già dimensionata, considerando quindi un dimensionamento relativo.

Solitamente i modi di dimensionare una User Story è relativo ad una storia di media difficoltà oppure viene scelta una User Story di complessità minima e si assegna «1 story point».

La tecnica del Planning Poker combina tecniche come «consulenza degli esperti», analogia, scomposizione in un modo giocoso. E’ generalmente riconosciuta essere la migliore tecnica per stimare le User Story.

Leggi l’articolo completo dedicato al Planning Poker qui.

Conclusioni

In queste serie di articoli abbiamo visto le basi AGILE e le tecniche di gestione più diffuse.

Nel corso di preparazione all’esame di certificazione PMI-ACP® di BE Formazione sono presentate molte di queste tecniche (lo stesso vale per il corso di preparazione all’esame di certificazione PMP®), con esempi ed esercitazioni in modo che sia (PM)Facile comprendere ed applicarle …. se le riteniamo utili.

Alla fine la metodologia ed il framework vanno “cucite” addosso al nostro Progetto, applicando il tailoring.

Ma di questo parlerò in un altro articolo.

Alla prossima!