Scrum framework per sviluppo agile: è la soluzione migliore?

Scrum è il framework più utilizzato nello sviluppo Agile del software perché è davvero straordinario. Ma cosa lo rende tale? In una parola, la semplicità.

Il manifesto Agile (qui trovi in breve la differenza tra la metodologia Agile e gli altri metodi di sviluppo software) non fornisce degli step concreti per la realizzazione di prodotti, ma dà soltanto dei princìpi da seguire. Per questo motivo, sono nati alcuni framework che tentano di riassumere in una strategia vincente i passi chiave che ci permetterebbero di organizzare il nostro lavoro coerentemente al suddetto manifesto (tra essi troviamo Scrum ma anche Extreme Programming, Feature Driven Development, Crystal e altri).

La maggior parte degli sviluppatori Agile (compresi noi a DevInterface) utilizzano Scrum: alcune persone pensano addirittura che Scrum e Agile siano termini intercambiabili. Questo perché, rispetto agli altri, Scrum ha una forza di fondo, che lo differenzia dai framework concorrenti: il processo di produzione dell’applicativo viene diviso in tanti piccoli mattoncini chiamati sprint (come avevo già spiegato qui). Ciò permette di stimare la durata di ogni micro-processo, dando la possibilità allo sviluppatore di organizzare ottimamente i suoi tempi. Inoltre fornisce al programmatore degli incentivi sorprendenti sotto il profilo psicologico: esso ora riesce a vedere “la fine del lavoro”, il che gli dà in un certo senso più coraggio, poiché conosce bene come e quando raggiungere i suoi obiettivi; ha fondamentalmente più controllo. Successivamente, il fatto stesso di consegnare un pezzettino di software che funzioni, dà allo sviluppatore l’idea tangibile del raggiungimento di un obiettivo, che si traduce in sana positività e autostima.

Ma andiamo a vedere il processo un po’ più in dettaglio.

Lo sprint

Lo sprint è uno dei pezzi in cui viene scomposto il processo di sviluppo del software. La sua durata, al termine della quale viene rilasciata una parte di programma funzionante, viene decisa all’inizio del progetto e può andare da 1 a 6 settimane; rimane fissa fino alla fine del lavoro.

Esso è preceduto dalla fase di pianificazione, dove il team di sviluppo, lo Scrum master e il committente (poi vedremo più in dettaglio queste figure) si incontrano per stabilire gli obiettivi da raggiungere all’interno dello sprint nei minimi dettagli, stimandone i relativi tempi.

Quando lo sprint ha inizio, abbiamo lo stand-up meeting giornaliero, un breve incontro che si svolge tra gli sviluppatori i quali si informano sui compiti completati il giorno prima, su ciò che faranno il giorno stesso e sugli eventuali problemi che impediscono l’avanzamento del lavoro.

Se lo sprint ha un’ampia durata (3 settimane o più), solitamente si fanno anche delle revisioni periodiche, incontri dalla cadenza regolare della durata di un’ora circa, dove i membri del team condividono tutti gli obiettivi che hanno raggiunto con i compagni: serve per fare il classico punto della situazione.

Un’altra sezione dello sprint è la retrospettiva: essa ha cadenza regolare ed è fondamentale per la buona riuscita del lavoro, nonché per l’aumento della sinergia all’interno del team. Si tratta del controllo sulle operazioni effettuate, che permette di capire quali siano quelle più o meno efficaci. Le retrospettive sono quindi utilissimi momenti di confronto costruttivo per migliorarsi sempre di più.

Infine c’è il rilascio, che avviene al termine del periodo di tempo concordato all’inizio, nel quale il team consegna al committente una porzione di software funzionante.

Ogni sprint si pone di raggiungere, al suo termine, determinati obiettivi: essi sono estrapolati dal cosiddetto product backlog, documento che contiene tutti i procedimenti necessari a sviluppare l’applicazione completa, fornito inizialmente dal committente e revisionato insieme al team di sviluppo. Possiamo dire quindi che il product backlog rappresenta il processo completo di sviluppo del prodotto, mentre gli sprint sono un insieme, più o meno esteso, di punti estrapolati dal product backlog.

I ruoli nello Scrum

Come detto in precedenza, i protagonisti dello sprint sono il committente, lo Scrum master e il team di sviluppo.

Il committente è la persona che commissiona l’applicazione: deve sapere bene quali funzioni dovrà implementare il software ed avere la capacità di spiegarlo, nei minimi dettagli, al team di sviluppo tramite il product backlog. Scrum, in riferimento a questa figura, prevede qualcosa di rivoluzionario se confrontato con altri framework: il committente può, anzi deve, essere presente durante tutte le fasi dello sprint, o comunque essere messo al corrente di tutte le informazioni che vengono scambiate durante tali fasi.

Lo Scrum master è il leader del team, lo sviluppatore più esperto. È in grado di coordinare il lavoro e quindi di assegnare agli altri le diverse mansioni in modo da creare una sinergia di gruppo che porti al soddisfacimento degli obiettivi prefissati nel modo più efficiente possibile. Egli ha anche il compito di capire i problemi all’interno del gruppo di programmatori e di risolverli, di intuire la causa di eventuali rallentamenti del lavoro e fornirne la soluzione.

Per ottenere la qualifica di Scrum master esistono degli enti certificanti: uno dei più importanti è Scrumstudy, presso il quale il nostro co-founder Stefano otterrà presto l’attestato di Scrum master.

Il team di sviluppo è composto da un numero che va dalle 4 alle 7 persone. Ogni programmatore ha delle skill differenti e ognuno le insegna ai compagni lavorando in un clima di completo scambio di competenze, in modo da evitare il più possibile rallentamenti nel processo.

Nei prossimi articoli esamineremo singolarmente e più in profondità tutti i concetti brevemente trattati oggi.

Seguici su Facebook e Twitter per rimanere sempre aggiornato su tutti i nostri articoli.

Contattaci se desideri avere maggiori informazioni su DevInterface o se vuoi sviluppare un’app con noi.