In questo primo dei tre articoli sulle metodologie agili, cominciamo con la presentazione dei principi alla base delle metodologie agili, guardando brevemente alla storia dei processi di sviluppo del software e al modo in cui certe esigenze sono emerse e si sono strutturate in metodologie. Agile può essere in certi casi solo una parola di moda, ma si tratta in realtà di un complesso di principi che guidano lo sviluppo software consentendone l’ottimizzazione in termini di tempi, costi e qualità.

I temi principali

Che cosa si intende per Agile? Quali sono i più importanti processi di sviluppo software agili? Come può lo sviluppo agile aiutare a migliorare un’organizzazione? Come possono i suoi valori e principi migliorare l’attuale Project Management, anche in progetti e discipline diversi dall’informatica? Quali sono i principali modelli di “ciclo di vita”? Queste sono alcune domande cui intende rispondere questa introduzione alla scuola di sviluppo del pensiero Agile.

Nell’ultimo decennio le Metodologie Agili (precedentemente note anche come Metodologie Leggere) sono passate dall’essere una nuova corrente di pensiero a rappresentare le metodologie maggiormente utilizzate (cosddette mainstream) La figura 1 mostra un’indagine effettuata nel 2009 da Forrester Research in cui si evidenzia come le metodologie agili e iterative rappresentino il 56% contro il 13% di quelle tradizionali.

Le metodologie agili hanno suscitato interesse in tutto il panorama del software e sono state indicate alternativamente come un antidoto all’approccio burocratico o come una concessione all’hacking (hacking significa “tagliare a pezzi” , “sminuzzare” e quindi analizzare un problema difficile per risolverlo; hacker è quindi anzitutto l’esperto informatico, prima di assumere il significato dispregiativo che si è in seguito erroneamente diffuso).

Benche’ ciascuno dei metodi agili sia unico nel suo approccio specifico, tutti condividono una visione comune e una serie di valori di base come chiaramente esposto nel Manifesto Agile [1]. Tutte le metodologie incorporano infatti il concetto di iterazione e il feedback continuo che tale concetto fornisce allo scopo di rilasciare e successivamente raffinare un sistema software. Tutte le metodologie coinvolgono le attività di planning, testing e integrazione continua assieme ad altre forme di evoluzione, allo scopo di perfezionare qualsiasi aspetto relativo sia al progetto, sia al software. Tutte le metodologie sono dette lightweight (specialmente se comparate con il tradizionale processo waterfall) e sono inerentemente adattabili. Ugualmente importante è il fatto che tutti i metodi si focalizzano sul fornire una importante spinta alle persone a collaborare e prendere decisioni assieme velocemente e in modo efficace.

In questa serie, nel primo articolo verranno mostrati i limiti dell’approccio classico ed esaminate le motivazioni alla base dei metodi agili, non concentrandomi troppo sul loro “peso” quanto piuttosto sulla loro natura adattiva e sulla loro attenzione primaria per l’individuo. Nel secondo articolo, si fornirà un elenco ragionato con le caratteristiche fondamentali dei processi appartenenti a questa scuola. Infine, nel terzo articolo, si concluderà la panoramica dei processi di sviluppo agile, concentrandosi su Scrum e Lean Software Development, e si faranno alcune riflessioni finali, prendendo in considerazione alcuni fattori che dovrebbero influenzare la decisione di scegliere e di percorrere questo sentiero ormai tracciato con determinazione.

Limiti dell’approccio tradizionale a cascata

L’essenza del processo di sviluppo software waterfall (“a cascata” in italiano) consiste nel ritenere che sistemi software complessi possano essere realizzati in maniera sequenziale, per fasi. In tale processo lineare, inizialmente vengono raccolti e analizzati tutti i requisiti; il completamento della progettazione costituisce il passo successivo. Infine, il risultato definitivo di tale progettazione viene implementato come software di produzione, passando per una lunga fase di integrazione e test.

Questo approccio sostiene che i sistemi complessi possono essere costruiti in un unico passaggio, senza rivisitare i requisiti o le idee di progettazione, alla luce di possibili mutamenti delle condizioni di business o tecnologiche. La nozione del processo a cascata è stata introdotta per la prima volta in un articolo scritto da Winston Royce nel 1970 e destinato prevalentemente ad essere utilizzato in grandi progetti governativi [5].

Concettualmente il processo waterfall equivale a un nastro trasportatore in una linea di produzione. Gli analisti dei requisiti compilano le specifiche di sistema fino a quando non passano il documento di specifica dei requisiti completato ai progettisti software, i quali pianificano il sistema software e creano tutti i diagrammi necessari a documentare come il codice dovrà essere scritto. Gli schemi di progettazione sono poi passati agli sviluppatori, che implementano il codice a partire dai disegni di progetto (figura 2).

Anche se questo approccio sembra concettualmente valido, nella realtà dei fatti ha portato a risultati decisamente negativi, se non catastrofici. Nel famoso studio dello Standish Group si riporta un successo dei progetti software pari a solo il 16%. La causa di questi fallimenti è quasi sempre indicata nell’utilizzo delle metodologie tradizionali.

Benche’ questi metodi sembrino funzionare in teoria, in pratica essi portano al caos e a scarse prestazioni nel progetto. Analizzando difatti il processo waterfall più in dettaglio, possiamo meglio comprendere le sue gravi lacune. In effetti, è inevitabile che i tentativi di una specifica dei requisiti up-front tralascerà alcuni dettagli molto importanti, semplicemente perche’ le parti in causa non sono in grado di dire agli sviluppatori tutto ciò che serve sul sistema gia all’inizio del progetto. Molti dei requisiti emergeranno infatti in modo chiaro solo successivamente.

Evoluzione dello sviluppo agile

Possiamo affermare che i processi di sviluppo software tradizionale non sono in grado di affrontare in modo efficace le due questioni principali relative a costi e tempo. Da circa una decina di anni è, tuttavia, emersa una filosofia di sviluppo che è alla base di una vasta raccolta di nuovi processi nota come Agile Software Development. Tali nuovi processi si concentrano maggiormente sulle interazioni tra le persone e un rapido sviluppo di codice piuttosto che sulla documentazione e sulla pianificazione.

Il significato letterale della parola agile è “caratterizzato da rapidità, leggerezza e facilità di movimento”. Questo significa quindi che il processo di sviluppo agile consiste in una consegna rapida di software caratterizzata da una maggiore facilità e flessibilità di sviluppo. Utilizzando una definizione più classica, potremmo dire che: “L’Agile è un processo di sviluppo che enfatizza la soddisfazione del cliente attraverso la fornitura continua di software funzionante”.

In senso lato, la denominazione Metodologie agili indica tutte quelle metodologie di sviluppo che rivoluzionano i vecchi sistemi di ingegneria del software (modello a cascata, modello a spirale, etc.), basati su una raccolta delle specifiche e su una strutturazione sequenziale dello sviluppo software. In questo modo, sotto questo nome, si raggruppano metodologie innovative come eXtreme Programming, Scrum, Feature Driven Development, DSDM, Crystal o Lean Software Development. Tali metodologie, che analizzeremo singolarmente nei prossimi articoli, si chiamano appunto agili perche’ consentono di rivedere di continuo le specifiche e di cambiarle durante lo sviluppo mediante un forte scambio di informazioni e pareri con il committente.

Le proprietà dei processi agili

Potremmo dire che, indipendentemente dalla specifica metodologia seguita, il processo di sviluppo software agile è caratterizzato nel complesso dalle proprietà che andiamo a elencare.

Iterativo e incrementale

L’intera applicazione viene realizzata in unità incrementali dette iterazioni. Il tempo di sviluppo di ciascuna iterazione è piccolo (due settimane in media), fisso e rigorosamente rispettato. Ogni iterazione rappresenta quindi un mini incremento delle funzionalità del sistema che viene rilasciato sopra al risultato dell’iterazione precedente.

Coinvolgimento attivo del cliente

Si ha un forte coinvolgimento del committente mediante collaborazione faccia-a-faccia. Il risultato di ogni iterazione viene testato e approvato dal cliente stesso. Il riscontro ottenuto è implementato in iterazioni successive, riducendo così i rischi e garantendo una maggiore soddisfazione del cliente.

Guidato dalle funzionalità

Viene posta una maggiore enfasi nel fornire le funzionalità richieste nell’applicazione. Il principio Pareto dell’80/20 viene applicato per selezionare il 20% di funzionalità che verranno effettivamente utilizzate per l’80% del tempo.

Tempo fisso

Ogni iterazione ha una durata limitata di tempo, in cui un nuovo incremento delle funzionalità viene realizzato e consegnato.

Consegna basata su priorità

Alle funzionalità viene assegnata una priorità in base a esigenze del cliente, rischi di sviluppo, opportunità di business. Dapprima vengono sviluppate le funzionalità con priorità maggiore, quindi al termine di ogni iterazione, le priorità del progetto vengono rivalutate.

Adattiva

La metodologia in generale è molto adattabile e flessibile, in modo tale che l’applicazione realizzata possa soddisfare l’afflusso di nuovi requisiti durante lo sviluppo. L’obiettivo non è quello di rimuovere l’incertezza all’inizio, ma piuttosto quello di adattarsi a necessità mutevoli. Il progetto e il codice sono impostati per privilegiare l’adattabilità alle modifiche, piuttosto che per soddisfare pienamente ed in modo pianificato tutte le specifiche. Ma avendo fin dal principio tutte le specifiche in modo completo si potrebbe progettare da subito tutto il sistema? L’interrogativo si basa su un errore di fondo: non è possibile, o è estremamente difficile, ottenere a priori tutte le specifiche in modo completo.

Responsabilizzare il team

I team di progetto sono in genere piccoli e caratterizzati da un alto grado di interazione e comunicazione. Dal momento che l’intero team è attivamente coinvolto, esso stesso ha il potere di prendere decisioni. Non esiste un team separato che abbia il compito di gestire il progetto.

Centrato sulle persone

Viene posta una maggiore enfasi su come le persone più qualificate ad effettuare lo sviluppo lavorino assieme, che non sul seguire i processi. La documentazione e le altre attività non propriamente di sviluppo e test sono ridotte al minimo.

Sviluppo rapido

In genere lo sviluppo viene effettuato velocemente, utilizzando moderne tecnologie di sviluppo leggere. Questo ha il vantaggio di consentire cicli di feedback ridotti.

Rilasci frequenti

Grazie al procedimento composto da piccoli passi, il team di sviluppo è in grado di produrre versioni del software in tempi più ridotti; i rilasci risultano quindi più frequenti.

Testing

Uno dei concetti cardine delle discipline agili è il testing, la verifica automatica del corretto funzionamento del sistema. Questo si applica sia al codice, che ai dati, e agli altri prodotti a cui le diverse discipline sono orientate (come i modelli o la documentazione). Dove non è possibile un test automatico, viene proposta una verifica manuale da parte di colleghi di pari esperienza.

Più disciplina

Volendo essere veloci, tutto deve essere consegnato correttamente già la prima, volta. Il processo implica molto gioco di squadra e autodisciplina. Quindi, ai membri del team si richiede di essere altamente qualificati e organizzati.

Semplicità

L’accento è posto sul mantenere ogni cosa il più semplice possibile ed essere aperti al cambiamento. È importante sottolineare che quest’ultimo aspetto è sempre presente nell’insieme dei valori di tutte le metodologie agili.

La “filosofia” delle metodologie agili

Possiamo riassumere dicendo che l’obiettivo di queste metodologie è la piena soddisfazione del cliente e non solo l’adempimento di un contratto. L’uso delle metodologie agili, inoltre, serve ad abbattere i costi di sviluppo del software. Esse sono esplose proprio in concomitanza con la crisi successiva al boom di Internet, prendendo spunto dai metodi applicati in piccole software house.

La filosofia agile ritiene che il modo migliore per soddisfare le esigenze del cliente si ottenga attraverso la collaborazione di un gruppo di persone impegnate, che si concentrano sul raggiungimento dei risultati in modo rapido, con il minor overhead di processo possibile. Un elemento chiave di questa filosofia è che si abbia più fiducia nella gente e nella loro capacità di collaborare, che non in un particolare processo di sviluppo. Questo principio deriva dal fatto che la gente può avere successo senza un processo formale, ma un processo non può avere alcun successo senza il contributo della gente. Per questo motivo, è necessario pensare e progettare un processo agile enfatizzando le capacità dei membri del team, sottolineando la collaborazione, piuttosto che fare affidamento sulla struttura di un processo per garantirne il successo.

Molti dei principi e delle pratiche individuali promosse dallo sviluppo agile sono state già impiegate da anni, se non da decenni, nel mondo dell’Information Technology. Comunque, piuttosto che implementare queste best practice in modo atomico e non coordinato, le metodologie agili hanno riunito in un corpus strutturato una serie di principi e di pratiche relativi a clienti, management e, in alcuni casi, all’ingegneria del software stessa, in modo da fornire una valida guida ai team di sviluppo attraverso al processo di pianificazione e rilascio rapido di software funzionante e testato. Possiamo affermare che ciascuna metodologia agile combina idee, sia nuove che meno recenti, in un  processo di raffinamento che è certamente superiore alla somma delle proprie parti.

Il Manifesto Agile

La formalizzazione dei principi e dei valori su cui si basano le metodologie agili è stata oggetto del lavoro di un gruppo di 17 progettisti software e guru dell’informatica che si sono spontaneamente riuniti nell’Agile Alliance. Il documento finale risultante da questo lavoro è stato poi sottoscritto nel 2001 da un nutrito gruppo di professionisti, molti dei quali hanno anche sviluppato alcune delle metodologie agili più famose. Il copyright del Manifesto Agile, del 2001, indica che tali dichiarazioni possono essere copiate liberamente in qualsiasi forma, purche’ sia inclusa la nota di copyright. Gli autori coinvolti e il testo completo, peraltro molto breve, dell’Agile Manifesto sono riportati nel sito ufficiale dell’iniziativa [1]. Riassumendo, in breve, il Manifesto afferma sostanzialmente quanto già detto, ossia che gli autori considerano di maggiore importanza:

• gli individui e le interazioni piuttosto che i processi e gli strumenti;
• il software funzionante più che la documentazione esaustiva;
• la collaborazione con il cliente più che la negoziazione dei contratti;
• rispondere al cambiamento più che seguire un piano prefissato.

Il Manifesto Agile non specifica alcuna particolare pratica che debba essere seguita da un team di sviluppo. Sono invece gli specifici framework agili di processo, come ad esempio Scrum o eXtreme Programming (XP), che definiscono l’insieme delle pratiche che dovranno essere seguite.

Il ciclo di vita dello sviluppo agile

Ognuna delle metodologie agili ha la sua peculiarità sia in termini di pratiche che di processi di sviluppo. Da un punto di vista concettuale possiamo rappresentare il ciclo di vita (figura 3) iterativo e incrementale, comune a tutte le diverse metodologie agili, nel modo seguente:

1. una prima fase (denominata Iteration 0 o Cycle 0);
2. una seconda fase caratterizzata da una serie di iterazioni di sviluppo in cui si realizza il sistema in maniera incrementale;
3. una terza fase costituita da una o più iterazioni di rilascio (o fine partita) relative alla Release N, al termine della quale si può procedere allo sviluppo della Release N+1;
4. una fase finale di produzione.

Iterazione 0

L’iterazione iniziale convenzionalmente denominata Iteration 0 (o Cycle 0), ha lo scopo di lanciare il progetto, focalizzandosi sui seguenti obiettivi:

• garantire una partecipazione attiva degli stakeholder;
• ottenere fondi e supporto necessari;
• iniziare a costituire il team;
• creare un modello iniziale dei requisiti;
• realizzare un modello iniziale dell’architettura;
• effettuare il setup degli ambienti.

Iterazioni di sviluppo

Nel corso delle successive iterazioni di sviluppo incrementale, gli “agilisti” realizzano e forniscono software funzionante di alta qualità che soddisfa le esigenze spesso cangianti dei propri stakeholder. Possiamo individuare i principali fattori di successo di tale prassi nei seguenti punti:

• Collaborazione stretta con gli stakeholder e gli altri membri del team. Questo garantisce una riduzione dei rischi, grazie all’impiego di cicli di feedback molto stretti e a un miglioramento della comunicazione mediante la collaborazione continua. Implementando le funzionalità in base alla loro priorità viene consentito agli stakeholder di avere pieno controllo su ambito di applicazione, bilancio, e calendario.
• Analisi e progettazione emergente: i singoli requisiti vengono dapprima analizzati utilizzando la tecnica del model storming, basata su un criterio di “just-in-time” (JIT), per alcuni minuti, quindi vengono realizzati mediante attività della durata di alcune ore o qualche giorno. La progettazione e l’architettura del sistema stesso è “emergente”. Guidati dai modelli di architettura, spesso diagrammi abbozzati a mano su lavagne, si procede con un approccio di sviluppo altamente collaborativo, detto “test-driven design” (TDD) in cui iterativamente si scrive dapprima un test e poi solo il codice di produzione sufficiente a soddisfare le esigenze di tale test.
• Assicurare continuamente una qualità senza compromessi: gli agilisti sono estremamenteconvinti dell’importanza di seguire linee guida, come convenzioni sul codice o linee guida dello stile di modellazione. Inoltre, l’utilizzo continuo delle tecniche di refactoring sul codice applicativo e/o sugli schemi del database è necessario per assicurare che si abbia sempre il miglior design possibile.
• Rilascio continuo e regolare di software funzionante: al termine di ogni ciclo di sviluppo/iterazione, si dovrebbe sempre avere un sistema parziale funzionante che sia possibile mostrare a cliente e stakeholder. Meglio ancora, si dovrebbe essere in grado di distribuire questo software in un ambiente di test pre-produzione/QA sandbox allo scopo di effettuare i test d’integrazione del sistema. Tanto più frequentemente vengono fatte queste verifiche, tanto migliore sarà il sistema finale.
• Test, test e… test: l’intero processo di sviluppo agile è caratterizzato da una notevole quantità di test (vedere ad esempio le pratiche di TDD) realizzati durante tutto lo sviluppo del sistema. Durante la fase di deployment vengono quindi eseguiti dei test di conferma che sono un misto tra test automatici e test di accettazione.

Rilascio (fine partita)

Al termine delle iterazioni di sviluppo, durante l’iterazione di Release (End Game), che può essere singola oppure costituita da un numero limitato di iterazioni, si procede a effettuare la transizione del sistema in produzione. Non è detto che per tutti i sistemi complessi la fine della partita debba richiedere più iterazioni, in quanto, se sono stati realizzati regolarmente i test di sistema e utente durante il ciclo di sviluppo, probabilmente non sarà necessario svolgere l’end game su più iterazioni.

I principali aspetti da considerare per questa attività sono:

• Test finale del sistema: i test finali di sistema e di accettazione devono essere effettuati a questo punto, anche se, come ho sottolineato in precedenza, la maggior parte dei test dovrebbe essere stata compiuta durante le iterazioni di sviluppo.
• Rework: ovviamente non ha senso effettuare delle verifiche finali se non si alloca una certa quantità di tempo a correggere le anomalie riscontrate.
• Training: deve essere fatta formazione e corsi a utenti, sistemisti e operatori di supporto, allo scopo di consentirgli il miglior utilizzo del sistema.
• Deploy del sistema: questo aspetto riguarda l’insieme di tutte le attività di messa in produzione del sistema stesso.

A questo punto, l’intero ciclo di sviluppo può ripetersi per i successivi rilasci previsti dal progetto, passando dalla Release N alla N+1.

Produzione

L’obiettivo della fase di produzione è quello di mantenere i sistemi utili e produttivi dopo che sono stati distribuiti alla comunità degli utenti. Questa fase termina quando l’uscita di un sistema è stato previsto per “pensionamento” o quando il supporto per quella determinata versione è terminato; in pratica il sistema viene dismesso.

Il triangolo di ferro

Le metodologie agili precisano quattro diverse variabili che entrano in gioco nei progetti software: costo, tempo, qualità e portata. L’elemento nuovo di Agile è il fatto che solo tre di queste variabili sono definite a priori, mentre la quarta è il grado di libertà che sarà stabilita dal gruppo di lavoro in base al valore delle altre. Ad esempio, a parità di tempo e qualità, al crescere della portata, il gruppo di lavoro potrebbe determinare che il costo aumenta proporzionalmente; oppure a parità di costo e portata, se il management richiede un’alta qualità, il tempo potrebbe crescere di conseguenza. Il management solitamente, tende invece a fissare a priori il valore di tutte e quattro le variabili, mettendo in difficoltà il team.

Conclusioni

Con questo articolo sono stati presentati i principi basilari del mondo delle metodologie agili: esse non possono essere certo considerate delle “novità”, visto che è oramai un decennio che si parla di tali metodiche e che in esse sono confluite anche delle buone pratiche che esistono da ancora più anni. Ma se è vero che molte delle pratiche associate con lo sviluppo agile esistono da un discreto lasso di tempo, va anche riscontrato come la media dei team di sviluppo software, specie in Italia, deve ancora abbracciare molti di tali principi e pratiche.

Nel prossimo articolo, cominceremo a vedere le più note metodiche agili.