È ormai difficile trovare un'azienda che non dichiari di usare, in qualche modo, metodologie per lo sviluppo agile. L'Agile Development ha ampiamente dimostrato i suoi vantaggi rispetto agli approcci tradizionali. Ed è anche particolarmente adatto ai nuovi ambienti applicativi legati al cloud e ai microservizi. È anche un approccio che possiamo considerare consolidato. In una recente indagine di Digital.ai, solo un terzo del campione ha dichiarato di usarlo da meno di due anni. Il resto è già più "avanti".

Questo non vuol dire che le aziende abbiano già raggiunto una piena maturità nell'adozione dello sviluppo agile. Nella stessa indagine citata prima, solo il 16% delle aziende ha dichiarato di sentirsi ben solido da questo punto di vista. Il 54% usa metodi Agile ma si considera ancora in via di maturazione. E comunque solo il 18% del campione dichiara di avere esteso questi approcci a tutti i team di lavoro. Lo spazio per migliorare, insomma, c'è.

Questo accade anche perché l'approccio Agile, per lo sviluppo software ma non solo, non entra in azienda con una lista precisa di passi da seguire e di cose da fare. I concetti chiave sembrano facilmente comprensibili. Ma quando si tratta di metterli in pratica è facile perdersi. Serve una guida, che di solito si trova nell'adozione di una specifica metodologia Agile. Che nella maggioranza dei casi (il 58% nell'indagine Digital.ai) è Scrum. Vediamo di che si tratta, in estrema sintesi.

La definizione astratta di Scrum

In astratto e tecnicamente, Scrum è un "framework di processo". Cosa che in sé dice pochino ai non iniziati. Però è un passo in avanti rispetto al concetto di Agile. Questo in estrema sintesi indica che una certa attività (ad esempio lo sviluppo software) si può fare con procedure e team elastici e adattabili, conseguendo notevoli vantaggi. Un framework di processo aggiunge che l'attività in causa si può svolgere utilizzando certi elementi precisi, passando per tappe specifiche, con figure ben identificate. Metaforicamente, non indica - né vuole farlo - il percorso preciso da A a B. Ma in parte lo delimita nello spazio e nel tempo.

Perché Scrum non è una procedura precisa

Perché se lo fosse imporrebbe quella rigidità dei processi di sviluppo che il modello Agile vuole superare. Inoltre, qualsiasi strutturazione rigida dello sviluppo diventerebbe immediatamente obsoleta non appena qualcosa cambiasse rispetto alle premesse iniziali. Ad esempio le funzioni più importanti da implementare in un nuovo modulo software. Inoltre, un processo rigido non può nemmeno adattarsi facilmente ai cambiamenti che possono verificarsi nel team di sviluppo. O alla volontà di adottare in corsa una nuova tecnologia.

La struttura base dello sviluppo in Scrum

Scrum è basato su un approccio particolarmente empirico. Le attività di sviluppo quindi partono dall'obiettivo: un elenco di funzioni o migliorie che si vogliono aggiungere ad un dato componente software, già esistente o da creare da zero. Queste attività di sviluppo sono portate avanti da un team specifico di persone e si devono concludere in un certo lasso di tempo. È importante notare che questo lasso di tempo non è estendibile e l'elenco delle funzioni da implementare nemmeno. Per evitare il rischio di progetti troppo ambiziosi in partenza e indefiniti nel loro svolgimento.

Il punto di partenza: il Product Backlog

In Scrum si suppone che un prodotto - diciamo una applicazione - sia un oggetto "vivo", nel senso che i suoi requisiti e le sue necessità e caratteristiche cambiano nel tempo. Ad esempio, in base ai feedback del mercato si può decidere che è opportuno aggiungere una data funzione. Oppure sono gli sviluppatori stessi, o il marketing, a stabilire che determinate migliorie sono necessarie. La lista delle "cose da fare" relative a un prodotto è detta Product Backlog ed è uno dei principali "artefatti" di Scrum.

Il Product Backlog è un elenco ordinato per importanza di caratteristiche, funzioni, requisiti, migliorie, correzioni da apportare a un prodotto. È un elenco mai finito perché cambia lungo tutto il ciclo di vita del prodotto stesso. E nessun team di sviluppo può assumerlo in toto come obiettivo. Ma a un certo tempo un sottoinsieme di questo elenco viene assegnato ad un team di sviluppo, per il suo completamento. Inizia così un "ciclo" di sviluppo software. Nella terminologia di Scrum: inizia uno Sprint.

L'attività di sviluppo: lo Sprint

La terminologia di Scrum dà l'idea di cosa sia una attività di sviluppo mirata. Una specie di corsa - appunto Sprint - che ha un traguardo preciso: concretizzare il sottoinsieme del Product Backlog assegnato. Che prende il nome di Sprint Backlog. In nome della concretezza, uno Sprint non può durare più di un mese. Se lo facesse, i requisiti e gli obiettivi di partenza potrebbero cambiare troppo. E comunque una fase di sviluppo così lunga è rischiosa e costosa.

La descrizione di Scrum che diamo qui è ovviamente solo un accenno alla metodologia. Molte più informazioni si possono trovare sul sito ufficiale. Comprese quelle sulle certificazioni e sui corsi per ottenerle.

Se lo Sprint Backlog è l'insieme delle cose da fare in uno Sprint, bisogna definire come farle. Lo si fa durante il cosiddetto Sprint Planning, un evento di pianificazione che non deve durare più di otto ore. Alla fine del quale il lavoro da compiere dovrebbe essere suddiviso in vari blocchi. Che il team di sviluppo auto-gestisce man mano nel tempo.

Il team di lavoro: lo Scrum Team

Il gruppo di lavoro più importante in una attività di sviluppo è ovviamente costituito dagli sviluppatori stessi. In Scrum si tratta del Team di Sviluppo, costituito da un insieme di figure multi-disciplinari che portano tutte le competenze necessarie al progetto. Per essere agili, è un team numericamente limitato: da tre a nove persone. Con meno di tre elementi c'è troppa rigidità e il rischio di avere poche competenze. Più di nove persone incontrano difficoltà ad auto-gestirsi e coordinarsi.

Il Team di Sviluppo è infatti un team "piatto" che si auto-coordina, senza "comandanti" e sotto-team. Le uniche due figure che si possono considerare vagamente apicali, ma che non fanno parte del Team di Sviluppo, sono il Product Owner e lo Scrum Master. Il Product Owner è una persona che ottimizza (ma non organizza) il lavoro degli sviluppatori in funzione dello Sprint Backlog, ed è responsabile del suo completamento. Lo Scrum Master è un facilitatore: aiuta il team ad applicare i principi Scrum, diffondendoli (e difendendoli se necessario) anche nell'organizzazione in generale. Team di Sviluppo, Product Owner e Scrum Master costituiscono lo Scrum Team.

Il confronto continuo in Scrum

L'approccio empirico che è alla base di Scrum si concretizza in una serie di momenti di confronto che servono ad essere tutti allineati su cosa è stato fatto. Ma anche a trarre una sorta di "morale" dalle varie esperienze di sviluppo in uno Sprint. L'appuntamento più frequente riguarda il Team di Sviluppo, che ogni giorno dedica massimo 15 minuti al Daily Scrum. Qui gli sviluppatori fanno il punto su cosa è stato fatto e, soprattutto, pianificano insieme e autonomamente il lavoro delle prossime 24 ore.

Alla fine di uno Sprint si tiene invece la Sprint Review. Un appuntamento di massimo quattro ore che coinvolge lo Scrum Team ma anche persone esterne che sono in vario modo stakeholder del lavoro fatto durante lo Sprint. Qui si illustra quello che è stato completato, cosa non si è riusciti a fare, le difficoltà incontrate. Ma si guarda anche ai futuri sviluppi del prodotto, esaminando come il Product Backlog è cambiato dopo il lavoro completato nello Sprint.

Alla fine di uno Sprint c'è anche un confronto interno per lo Scrum Team. Si tratta della Sprint Retrospective, un meeting di massimo tre ore in cui si esamina cosa è andato bene nell'organizzazione del lavoro e cosa no. La retrospettiva riguarda quindi le persone, le relazioni e i processi. Non i risultati pratici dello Sprint, se non indirettamente. Dalla Sprint Retrospective dovrebbe uscire uno Scrum Team più in grado di lavorare meglio nel prossimo Sprint.