La metodologia Scrum accelera il processo di sviluppo software, grazie a un approccio iterativo e incrementale, che vede la stretta collaborazione tra sviluppatori e stakeholders.
Il business digitalizzato richiede all’IT una capacità di risposta senza precedenti in termini di velocità ed efficacia. L’adozione di metodologie Agile come Scrum permette di accelerare le attività di progettazione applicativa, migliorando contestualmente la qualità del software. Ma di che cosa si tratta esattamente e quali benefici porta alle aziende?
Secondo la concezione degli ideatori Ken Schwaber e Jeff Sutherland, il modello Scrum è un framework che permette di gestire il ciclo di sviluppo del software in modo iterativo e incrementale, sfruttando un insieme di tecniche e processi.
Il metodo è stato ufficialmente presentato al pubblico nel 1995, ma trae origine dall’approccio cosiddetto “olistico” o “rugby”, già sperimentato nell’industria automobilistica e dai produttori di stampanti per la realizzazione di manufatti commerciali. L’intero processo viene eseguito da un gruppo interdisciplinare di risorse, che lavorano in più fasi a un progetto collettivo, passandosi continuamente la palla e agendo come un’unica entità. Il termine “Scrum”, infatti, è mutuato dal rugby e indica la “mischia” come metafora della squadra di developers che avanza sinergicamente verso la meta, trascinando gli altri attori coinvolti.
Le figure coinvolte all’interno di un progetto Scrum sono diverse, dividendosi tra membri del team e ruoli esterni che a vario titolo vengono coinvolti.
Nella squadra di lavoro vera e proprio, che opera in modo totalmente autonomo all’interno del contesto aziendale, rientrano: il Product Owner (depositario degli interessi del cliente, con la responsabilità di definire i requisiti di prodotto e controllare l’allineamento agli obiettivi); il team di sviluppo (composto tipicamente da 3-9 persone con skill interdisciplinari, che si occupano dell’esecuzione del progetto); lo ScrumMaster (una sorta di facilitatore, che si preoccupa di rimuovere barriere e criticità che impediscono il conseguimento dei risultati).
Attorno al nucleo, ruotano soggetti con funzioni ausiliarie (ovvero che svolgono attività necessarie al progetto, senza avere tuttavia un ruolo formale all’interno del team) e gli stakeholders (i destinatari del prodotto, che viene realizzato proprio per soddisfare i loro interessi).
Come anticipato, il framework Scrum prescrive un approccio allo sviluppo iterativo e incrementale, ovvero: il risultato viene raggiunto attraverso la ripetizione continua di una sequenza di operazioni, che permettono di avvicinarsi all’obiettivo passo dopo passo. In sostanza, si procede per gradi e attraverso una serie di controlli empirici (basati sulla certezza derivante dall’esperienza pratica). Ogni modifica al software viene quindi testata prima di salire allo step successivo, così da individuare subito eventuali failure e cambiare rotta rapidamente in caso di errore.
I PRINCIPI DELLA METODOLOGIA SCRUM:
TRASPARENZA → il progetto deve essere verificabile, quindi avere terminologie e metriche di valutazioni condivise
Sintetizzando, il framework suggerisce di dividere il processo di sviluppo applicativo in sprint, ovvero blocchi di attività molto brevi (da una a quattro settimane) e additivi (solo al termine di un ciclo si passa al successivo), intervallati da incontri frequenti tra i membri del team.
I meeting sono organizzati allo scopo di svolgere le dovute ispezioni e discutere eventuali adattamenti; si rivelano fondamentali per ricevere feedback a seguito delle prove empiriche, così da avere sempre evidenza del gap tra risultati ottenuti e attesi.
Quando si implementano progetti secondo la metodologia Scrum, oltre agli attori coinvolti, bisogna fare riferimento a tre tipologie di artefatti, che permettono di stimare la qualità del lavoro svolto e il valore raggiunto grazie alle attività di sviluppo, rispetto agli obiettivi predefiniti.
Il primo degli artefatti è il Product Backlog ovvero la lista dei requisiti relativi a un prodotto, che contiene i desiderata funzionali e gli interventi da apportare, ordinati in base alla priorità, ai rischi e al valore di business.
Tipicamente, il Product Backlog evolve insieme al progetto, sulla spinta dei feedback raccolti dagli utenti. Dal punto di vista pratico, la lista dei requirements viene stilata in base alle user story, ovvero ragionando dal punto di vista di chi utilizza il prodotto, in risposta ad esigenze specifiche.
Ad esempio, si possono ipotizzare riflessioni di questo tipo: “Come venditore (tipologia di utente), vorrei accedere al catalogo prodotti da remoto (necessità) per promuovere le nostre offerte ai clienti in maniera più efficace (obiettivo)”. Da qui è possibile derivare le necessità per altre tipologie di utenti come gli admin tecnici: “Come amministratore IT, desidererei potenziare il sistema di gestione delle identità per consentire ai venditori da remoto di accedere agevolmente ai cataloghi prodotto”. Così si procede gradualmente alla raccolta delle migliorie di prodotto da apportare, con un livello di granularità sempre maggiore.
Tra gli artefatti, la metodologia Scrum contempla anche lo Sprint Backlog, ovvero una selezione tra i requisiti del Product Backlog, che deve essere lavorata e completata in un determinato sprint.
Infine, l’ultimo artefatto è definito incremento e indica l’insieme di tutti i risultati raggiunti nello sprint appena terminato e nei precedenti.
Ma concretamente, come viene eseguito un progetto Scrum?
Scendendo nel dettaglio, bisogna considerare la struttura di ogni singolo sprint, che si articola in 4 eventi fondamentali:
- Lo Sprint Planning ovvero la riunione iniziale che permette al team di definire gli obiettivi e gli interventi da realizzare durante lo sprint;
- Il Daily Scrum cioè un breve incontro quotidiano per puntualizzare i risultati raggiunti il giorno precedente e fissare le attività odierne;
- La Sprint Review ovvero il meeting conclusivo tra lo Scrum Team e gli stakeholder per confrontarsi sulle attività completate e impostare il blocco successivo;
- la Sprint Retrospective ovvero una riflessione interna allo Scrum Team per valutare risultati e processi dello sprint appena concluso e intercettare possibili miglioramenti per il successivo.
Concluse le 4 settimane (ovvero la durata tipica di uno sprint), al termine della retrospettiva, si inizia con la pianificazione di un nuovo sprint, fino al raggiungimento del risultato finale.
Chiarite le modalità per attivare correttamente un progetto secondo la metodologia Scrum, bisognerebbe sottolineare perché adottare tale metodo e quali sono le opportunità.
Certamente occorre partire da una basilare considerazione di scenario. Nel contesto imprenditoriale odierno, estremamente dinamico e competitivo, la velocità di risposta alle richieste del business e del mercato rappresenta un fattore critico di successo.
La metodologia Scrum permette quindi di accelerare il time-to-market applicativo grazie alla suddivisione del processo in sprint e alla chiarezza di obiettivi sul breve periodo. Un team altamente focalizzato su un traguardo condiviso e raggiungibile in poco tempo è certamente più motivato e produttivo. I metodi di sviluppo tradizionali a cascata, che prevedono un’unica sequenza per passare dall’ideazione allo sviluppo al collaudo alla maintenance, portano a tempi di realizzazione molto lunghi, con un rischio di errore decisamente troppo alto. Basti pensare ai danni economici derivanti da progetti che, dopo mesi di intenso lavoro e grandi investimenti, si sono rivelati infine del tutto fallimentari. Con il metodo Scrum, invece, la possibilità di verifiche periodiche riduce l’eventualità di perseguire nell’errore e ottenere un prodotto allineato ai requisiti prefissati.
La collaborazione tra i team di sviluppo e gli stakeholders è un altro fattore che limita il pericolo di fallimento: poiché ogni progresso del software viene direttamente testato, è possibile raccogliere i feedback dagli utenti interessati, identificando subito eventuali falle.
La metodologia Scrum, infine, si presta per tutte le moderne tecniche di sviluppo applicativo basate su microservizi, che rappresentano la tendenza più rilevante per il futuro. Con le nuove architetture, infatti, le applicazioni vengono concepite come un insieme modulare di unità funzionali indipendenti: agendo su una funzionalità, non si rischia di influenzare il comportamento dell’intera soluzione. Pertanto, è possibile agire proprio per piccoli interventi incrementali, che toccano solo alcuni aspetti del software, in base alle richieste e ai feedback degli utilizzatori. Ovviamente questo presuppone ancora una volta la stretta e sinergica cooperazione tra sviluppatori e utenti aziendali, come prescrive appunto l’approccio Scrum.