Sviluppo agile con Scrum

Che caos!
Rileggendo il mio post precedente sul confronto tra l’approccio a cascata e le metodologie di sviluppo agile, mi è sembrato che possa dare una percezione caotica di queste ultime. In realtà, e lo dico per esperienza personale, ci vuole un po’ per comprendere e abbracciare una filosofia che vede il cambiamento non solo come positivo, ma addirittura come fulcro per la creazione di valore. Dopotutto, storicamente, i cambiamenti alle specifiche di un progetto, se possibile, sono stati sempre evitati. Non è vero?

Gestire il cambiamento
E’ possibile imbrigliare il cambiamento in una serie di processi concettualmente semplici e, utilizzando un approccio ciclico, produrre valore ed informazioni utili al continuo miglioramento dei processi stessi. La parola magica per ottenere tutto questo è Scrum, un modello iterativo ed incrementale per lo sviluppo di progetti, prodotti o applicazioni.
Le richieste provenienti dai clienti, dagli utilizzatori, dal team di sviluppo e, in generale, da tutti gli stakeholder, vengono raccolte e viene redatta una lista ordinata per priorità di caratteristiche per il prodotto (Product Backlog).

La produzione è strutturata in cicli di sviluppo chiamati Sprint di durata costante (tipicamente tra una e quattro settimane) che si susseguono senza soluzione di continuità. Il prodotto dello Sprint è una porzione completa del prodotto finale, una porzione potenzialmente rilasciabile.
All’inizio di ogni Sprint (attraverso lo Sprint Planning Meeting) il team seleziona i task dal Product Backlog e si impegna a completarli all’interno del tempo concesso. Non è possibile allungare lo Sprint per permettere il completamento di un task e a Sprint avviato i task non possono essere più modificati. Se i task dovessero essere completati in anticipo (mostrando un errore di pianificazione), se ne possono selezionare degli altri per occupare il tempo altrimenti inutilizzato.
Durante lo Sprint, ogni mattina il team si incontra (Daily Scrum Meeting) per verificare come procedono i lavori e se ci sono impedimenti. Si tratta di un incontro informale, in piedi, magari accanto alla macchina del caffè, della durata massima di 15 minuti.

Al completamento dello Sprint c’è un incontro (Sprint Review) che coinvolge tutte le figure interessate allo sviluppo del progetto (può partecipare anche il cliente) e mette in atto l’idea chiave in Scrum: “inspect and adapt“. Viene mostrato il lavoro eseguito, che viene approvato secondo criteri condivisi, e discussa l’esecuzione dello Sprint. Tutti sono liberi di porre domande e dare dei suggerimenti innescando un colloquio che permette di trarre benefici dall’esperienza appena conclusa.
Successivamente alla Sprint Review viene avviata la Sprint Retrospective che estende l’applicazione della filosofia di ispezione e adattamento dal prodotto all’intero processo e coinvolge un gruppo più ristretto di persone. E’ una riunione di importanza strategica, che permette di capire cosa sta andando come previsto o cosa necessita di adattamento, nell’intero processo di produzione governato dalla metodologia Scrum. Con quest’ultima riunione lo Sprint è definitivamente concluso e il ciclo si ripete fino al completamento del prodotto.

I ruoli previsti
Scrum prevede tre ruoli:

Il Product Owner
Il Product Owner è responsabile della massimizzazione del ROI del progetto attraverso la gestione del Product Backlog, la lista di feature per il prodotto ordinata secondo una priorità dettata dal valore. Il concetto di valore è preso in senso lato, può essere dettato dalla necessità di soddisfare un cliente importante, realizzare degli obiettivi strategici o mettere in atto dei miglioramenti.
Le metodologie agili incentivano lo scambio diretto di informazioni, riducendo il numero di intermediari. E’ provato, infatti, che al crescere del numero di “handoff” il livello di qualità delle informazioni scambiate si abbassa. Questa è una delle motivazioni per cui i ruoli sono così pochi. Si ha così che, nel caso di un prodotto commerciale, il ruolo del Product Owner assomiglia a quello del classico Product Marketing Manager, con la differenza che esso interagisce direttamente con il Team, proponendo gli obiettivi. Il Team avrà così una percezione precisa, “di prima mano” dei risultati da perseguire. Il Product Owner, infine, ha la possibilità di accettare o rifiutare il risultato del lavoro del Team, sulla base di una “Definition of done” condivisa da tutti.

Il Team
Il Team, formato da 5-7 persone, è multi-funzionale (nel senso che contiene in se tutte le competenze necessarie per completare il lavoro) e in grado di autogestirsi. Sceglie i task da completare in uno Sprint insieme al Product Owner e decide in autonomia come procedere per rispettare l’impegno in modo puntuale e preciso. Il Team, oltre a occuparsi dello sviluppo, fornisce dei suggerimenti al Product Owner su come rendere il prodotto migliore alimentando il Product Backlog.

Lo ScrumMaster
Lo ScrumMaster aiuta il gruppo ad applicare Scrum, realizzare valore e garantire il successo. Scrum è in grado di evidenziare i pericoli e gli impedimenti e lo ScrumMaster si prodiga alla risoluzione delle problematiche che possono interferire con la capacità lavorativa e la produttività del team. Incentiva la cooperazione tra tutti i ruoli e le funzioni coinvolte, rimuovendo impedimenti e proteggendo il team da interferenze esterne. Si assicura, infine, che il processo sia seguito secondo la metodologia, invitando ai meeting.

Perchè mi piace Scrum?
Lascia il Team libero di poter esprimere le sue potenzialità
Lasciare il team libero di gestire il progetto, di prendere iniziative, di proporre soluzioni, anche al di fuori del contesto puramente tecnico, è un modo per lasciare esprimere al meglio le potenzialità dei talenti. Lo sperimento ogni giorno. Scrum permette tutto questo, ponendo allo stesso tempo degli obiettivi precisi, che coincidono con tutte le richieste che producono valore, e richiedendo dei risultati verificabili che migliorano la qualità del prodotto.

E’ efficace
Avere un breve percorso lineare che parte dalle specifiche e arriva a dei prodotti parziali potenzialmente rilasciabili permette di garantire una costante progressione, che si parli di un prodotto commerciale o di una soluzione ad-hoc. Il modello dello Sprint obbliga a creare la qualità nel corso della produzione del prodotto, imponendo test continui.

E’ mosso dalla logica “inspect and adapt”
Scrum permette di evidenziare e risolvere problemi e migliorare, non solo il prodotto, ma anche l’intero processo di produzione. Il risultato è che dopo una fase iniziale di resistenza e una di “caos”, in cui i processi usuali si riorganizzano per adattarsi alla metodologia, si ha un incremento continuo della produttività e della qualità.

Incentiva i feedback
Tutti sono coinvolti. Sono previste occasioni di incontro e di discussione che incentivano i feedback da parte di tutti gli stakeholder, permettendo di contribuire alla realizzazione di un prodotto migliore e al successo dell’organizzazione.

Scrum sta diventando un po la “buzz word” nell’ambito della gestione dei progetti software e sta riscuotendo molto successo. E’ un approccio agile efficace e ridotto all’essenziale e, quindi, è il più semplice da implementare. Se questo post ha suscitato la vostra curiosità, vi invito a fare il passo successivo, approfondendo la conoscenza di questa metodologia. Sono certo che resterete affascinati come me dalla semplicità concettuale e dalle potenzialità.

Questa voce è stata pubblicata in Project management e contrassegnata con , , , , , , , , . Contrassegna il permalink.

Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...