Metodologie Agili
La nascita delle metodologie agili si può inquadrare nel periodo del boom "Internet" degli ultimi anni 90 dove la produzione di software ha visto riduzioni drastiche dei tempi di sviluppo e di rilascio dei prodotto software passando dall'ordine degli anni all'ordine di mesi.
Le metodologie agili (MA) vengono anche dette "leggere" (lightweight) e si contrappongono alle metodologie pesanti (heavyweight) come quella waterfall o a certe 'istanziazioni' RUP che prevedono un consistente "formalismo".
L'idea alla base delle metodologie agili è che non sono predittive, cioè non cercano di prevedere come evolverà il sistema software, bensì sono adattive, cioè cercano di capire le pratiche migliori per meglio adattarsi all'evouzione dei requisiti dell'utente piu' che del sistema software (vedere [MFNM]).
Lo scopo delle metodologie agili è quindi quello di gestire progetti dove i requisiti utente non sono conosciuti a priori o sono "volatili" e quindi il processo non è completamente prevedibile a priori e di conseguenza un approccio predittivo potrebbe risultare poco efficace.
Le metodologie agili quindi si concentrano sul facilitare il piu' possibile le modifiche al sistema basandosi su un processo iterativo composto da fasi di progettazione, sviluppo e test molto brevi al fine di agevolare l'adattamento in corso di sviluppo orientandosi fortemente ai risultati.
Le caratteristiche comuni di una metodologia di sviluppo agile sono:

• La capacità di gestire i requisiti "instabili": nei progetti in cui si è costretti a "rincorrere" l'evoluzione dei requisiti utente quasi in tempo reale l'adozione di discipline agili è particolarmente indicato
• Adattabilità: adattare piuttosto che pianificare
• Iteratività e incrementalità: fasi ridotte per concentrarsi su piccoli obiettivi in modo ciclico
• Rilasci frequenti: grazie al ciclo di sviluppo concentrato, i rilasci sono piu' frequenti
• Test: il codice deve essere testato in modo automatico e continuo
• Orientamento alle persone: privilegiare le persone rispetto ai processi
• Collaborazione con il cliente piuttosto che negoziazione del contratto

Agile Alliance
Attorno ai valori e ai concetti di base di tutte le discipline agili, è nata un'alleanza di persone, l'Agile Alliance (vedere[AA]) che ha pubblicato i principi su cui si basa in un "manifesto" disponibile su Internet (vedere [AAM]).
Sono nate diverse metodologie agili come ad esempio XP, Agile Modeling, Agile Data, Scrum, FDD, DSDM, Crystal, …
Vediamo quindi una descrizione saliente delle principali metodologie agili come XP, Scrum e FDD.

XP
XP è un processo di sviluppo del software, di recente formulazione e in continua evoluzione, incentrato sulla fase di codifica e portato alla ribalta da Kent Beck.
Per progetti in cui i cicli di consegna sono molto compressi e con fattori di rischio tecnologico molto elevati piuttosto che seguire un processo di sviluppo "canonico" si segue un processo più "leggero", "intuitivo" e quindi molto operativo.
Se RUP si può dire che è "document-centric", sicuramente si può affermare che XP è "code-centric": tutte le fasi del ciclo di vita del software vengono compresse a favore dell'attività di codifica.
L'XP si basa su dodici pratiche fondamentali (più altre introdotte successivamente) nessuna delle quali è un'invenzione del metodo. XP infatti propone pratiche già usate e consolidate e consiglia di applicarle tutte al massimo delle loro potenzialità: da qui il termine "estrema".
Le principali pratiche indicate da XP sono:

• Pair programming: ad ogni postazione di lavoro sono presenti due sviluppatori che si alternano nella fase di codifica. In questo modo si ha una costante revisione del codice ("code review") cercando di tenerlo il più semplice e "pulito" possibile.
• Testing: prima di scrivere il codice dell'applicazione, deve essere scritto quello di test (Test First Design -Test Driven Development) utilizzando i frameworks di test già disponibili come ad esempio JUnit. I test devono riguardare sia le classi sviluppate (test d'unità) che garantire il soddisfacimento dei requisiti del cliente (test funzionali). In caso di errore si devono scrivere prima i test unitari capaci di rilevare l'errore e solo dopo procedere alla risoluzione del bug.
• Refactoring: il sistema è soggetto a continua riscrittura al fine di produrre codice che implementi le funzionalità richieste nella maniera più semplice possibile. L'intervento continuo sul codice può avvenire "con coraggio" perché si hanno i test unitari e funzionali che garantiscono la non regressione dell'intervento.
• Integrazione continua: l'integrazione delle modifiche nel sistema viene fatta frequentemente ("Continuous integration"), in modo da limitare e circoscrivere eventuali problemi dovuti al nuovo codice integrato.
• Standard e proprietà collettiva: il codice deve seguire precisi standard al fine di permettere a chiunque di sentirsi a proprio agio con il codice scritto da altri membri del gruppo visto che in XP si ha una proprietà collettiva del codice (Collective Code Ownership). E' evidente che la pair programming fornisce una grossa spinta in questo senso.

Il ciclo di vita prevede un'iniziale fase di "esplorazione" (Exploration Phase) dove si iniziano a raccogliere le user story, una versione "leggera" (e informale) degli Use Case previste da RUP.
Successivamente segue la fase di pianificazione (Planning Phase) dove il cliente scrive le "storie" su delle schede assegnando la relativa priorità e definisce i relativi test di accettazione.
Le user story devono essere capite dal programmatore che deve stimarle e classificarle in base alla difficoltà (rischio) di realizzazione. Questo evidenzia come XP si spinga nella direzione della responsabilizzazione dei programmatori e della loro capacità di fare tesoro dell'esperienza delle passate iterazioni ed esperienza.
Una volta prodotte le user story il cliente sceglie le storie da implementare compatibilmente con tempo e stime per la specifica iterazione.
Il metodo suggerito dall'XP per passare dalle storie (descrizione funzionale) alla struttura ad oggetti del sistema è l'analisi con le schede CRC (Classe, Responsabilità, Collaborazione: una tecnica di OOA introdotta da Beck e Cunningham nel 1989).
Le schede CRC hanno lo scopo di individuare in modo informale le caratteristiche fondamentali delle classi candidate esplicitandone il nome, la gerarchia e la relativa responsabilità (vedere [CRC]).
Per user story particolarmente complesse o potenzialmente rischiose è consigliato lo sviluppo di un Architectural Spike. Un' Architectural Spike è un programma scritto per sperimentare una soluzione, una sorta di prototipo, quasi sempre "usa e getta" per permettere una stima più accurata di una particolare user story.

Definite le User Story d'interesse si passa alla pianificazione dello sviluppo ossia alla assegnazione delle user story da implementare alle varie coppie di sviluppatori (Iterations to Release Pahse).
Mentre le iterazioni sono della durata fissa di una settimana, la durata di un rilascio varia a secondo che sia deciso per data (generalmente 2/3 mesi di durata) o per funzionalità (quante user story devono essere realizzate per lo specifico rilascio). L'importante è che ogni rilascio produca un sistema funzionante che permetta di ottenere feedback dal cliente.
Gli sviluppatori devono sviluppare in modo semplice e concentrandosi sullo stretto richiesto ("il miglior modo per avere meno errori è avere meno codice!"). L'applicazione diventa quindi "il minimo insieme di codice che soddisfa i requisiti emersi" ("keep it simple").
Una riunione al giorno (in piedi!) permette di fare il punto della situazione e evidenziare eventuali problemi. Se l'iterazione è in ritardo, il cliente sceglie che storie differire alla successiva. La possibilità di tracciare il ritardo/anticipo permette di stimare la velocità di sviluppo del gruppo ed eventualmente rivedere la pianificazione del progetto.
Terminata la codifica si inizia la fase di test di accettazione mediante sia test automatici al fine di certificare sia la qualità del codice prodotto sia per decidere l'eventuale rilascio (Productionizing Phase).

Figura 1 : ciclo di vita XP

Come si può notare in questo ciclo di sviluppo appena descritto non è prevista esplicitamente né la fase di analisi né la fase di design. Queste fasi nei processi come RUP (in questo contesto sono chiamate discipline) producono documentazione per il team stesso e per le fasi successive del progetto. In questo processo di sviluppo le fasi di analisi, design e sviluppo sono concentrate in un'unica fase e sulle medesime persone e questo fa sì che non vi sia una necessità immediata di produrre documentazione; in Xp il progetto evolve insieme al codice.

La documentazione del sistema in Xp è descritta mediante una System Methapor, una metafora del sistema che per Kent Beck è uno dei punti chiave dell'Xp. La metafora è una visione del sistema coerente e comprensibile sia dal cliente che dai programmatori.
In molti casi la metafora può rispecchiare le entità nel mondo reale gestite dal sistema stesso e serve anche a dare nomi coerenti a classi, variabili e metodi del sistema, in modo che siano comprensibili a tutti i membri del gruppo di sviluppo.
Le variabili in gioco in XP sono quattro: costo, tempo, qualità e portata.
Generalmente tutte e quattro queste variabili sono fissate dal Management o dal client stesso.
Xp dice che solo tre di queste variabili sono fissate a priori, mentre la quarta è il grado di libertà che sarà stabilita dal gruppo di lavoro in base al valore delle altre. In questo modo ad esempio a parità di costo e portata, se il management richiede una maggiore qualità, il tempo viene definito dal gruppo di sviluppo…committente permettendo.
Tirando un po' le somme, Xp si focalizza su gruppi di sviluppo piccoli (sull'ordine della dozzina di persone) per progetti di piccole medie dimensioni dove la stesura/modifica dei requisito sono all'ordine del giorno(vedi [TECXP]).
Il processo è semplice, snello e poco burocratrico ma deve essere comunque seguito con molta disciplina.
E' bene sottolineare che per applicare Xp il cliente ha un ruolo molto importante perché deve partecipare sia al progetto che alla sua evoluzione.
Il Customer Xp è in ruolo chiave (e quindi anche critico) deve essere un esperto di dominio e quindi conoscere bene il business del cliente. Deve stabilire le priorità delle user story da implementare e specificare i relativi test di accettazione fino a tendere (idealmente !?) a condividere il successo/insuccesso del progetto.
La critica più forte che viene mossa dagli oppositori di XP è che la disciplina funziona solo per buoni programmatori e che è inadatta a contesti progettuali in cui sia richiesta una tracciatura sistematica dei requisiti.
Da un punto di vista organizzativo Xp prevede oltre alla figura di programmatore (stima le storie, definisce i task dalle storie, scrive il codice ed i relativi test), il Tester (esegue i test di accettazione e avverte il gruppo di sviluppo in caso di regressioni), il Tracker (tiene traccia della metrica e della storia del processo) ed il Coach; quest'ultimo piu' che un Project Manager deve essere il Project Leader che segue/traccia il processo di sviluppo del progetto e aiuta in modo traversale nei casi di bisogno).

Scrum
Scrum è un approccio allo sviluppo del software che prevede la suddivisione del progetto in iterazioni del progetto dette Sprints.
Ad inizio progetto vengono definite le funzionalità che si dovranno implementare chiamate Backlog con le relative priorità. Tali priorità vengono assegnate da un'unica persona, il Product Manager, responsabile del prodotto e della sua visione; senza la sua autorizzazione non è possibile modificare la priorità del Product Backlog.
Prima dell'inizio di ogni sprint, il gruppo di lavoro si riunisce con il responsabile del prodotto e insieme concordano gli elementi prioritari del Backlog che si dovranno implementare durante lo sprint. Ogni sprint ha una durata predefinita di 30 giorni ed una volta decisi gli obiettivi, questi non possono essere cambiati (se non dagli sviluppatori stessi) sino alla fine dello Sprint stesso.
Al termine di ogni Sprint deve esserci il rilascio del software prodotto che deve essere un qualcosa di tangibile e utilizzabile dal cliente.

Figura 2: SCRUM

Durante lo sprint ogni giorno il team tiene un breve incontro di una quindicina di minuti chiamato Daily Scrum (Scrum è un termine che deriva dal Rugby e indica il "pacchetto di mischia") dove il capo progetto (Scrum Master) annota i backlog completati e quelli che rimangono ed ogni sviluppatore racconta cosa ha fatto quel giorno e cosa dovrà fare il successivo.
In generale gli Scrum Meeting si tengono generalmente sempre allo stesso posto e alla stessa ora per dare un ben preciso "ritmo" al progetto.
Con lo Scrum si ha un ciclo di controllo molto fine che permette capire lo stato quotidiano di avanzamento dei lavori e di scoprire quanto prima eventuali problemi progetto.
Da un punto di vista organizzativo Scrum prevede un Product Owner (analogo al Customer in XP) che come committente del lavoro definisce le cose da fare (Product Backlog) e le relative priorità con scadenza mensile. Lo Scrum Master (analogo al Coach di Xp) è invece responsabile di gestire gli allineamenti giornalieri e mensili tenendo quindi traccia dello stato di avanzamento dei lavori e della situazione dei Backlog. Ogni mese (Sprint Review) definisce il lavoro per il mese successivo (Sprint Planning) in base alla priorità evidenziate dal Product Owner e sulle stime di impegno da parte del gruppo di sviluppo.
Il gruppo di sviluppo (Scrum Team) crea un elenco (Sprint Backlog) di task (sotto attività del Backlog) da effettuare per raggiungere gli obiettivi del mese, segnala eventuali criticità allo Scrum Master negli allineamenti giornalieri e mensilmente presenta i risultati ottenuti durante lo Sprint.
E' bene precisare, prima di concludere questa breve descrizione, che SCRUM è una metodologia che definisce pratiche per pianificare e gestire i progetti, cioè di Project Management, ma non indirizza la modalità di sviluppo del prodotto (raccolta requisiti, analisi, disegno, sviluppo, test, …) e che quindi occorre integrarlo con altri approcci (RUP, XP, FDD, …) per indirizzare il processo di sviluppo.
Per maggiori informazioni su Scrum vedere [SCRUM, ITSCRUM].

Feauture Driven Development
Il Feature Driven Development (FDD) è stato ideato da Jeff De Luca e Peter Coad.
E' una metodologia agile esplicitamente citata nell'Agile Manifesto e prevede un processo di sviluppo iterativo-incrementale.
Come suggerisce il nome, FDD è "feature-centrica" e cioè si focalizza sullo sviluppo di funzionalità "tangibili" per il cliente. Di fatto la Feature è una funzionalità che deve avere un valore per il committente e che "guida" il ciclo di sviluppo della durata di due settimane.
FDD sta suscitando interesse per il fatto di essere sia "pesante" che "agile". I più tradizionalisti apprezzano l'analisi del modello preliminare e la prescrizione di diagrammi di progetto aggiornati, mentre lo sviluppo avviene secondo iterazioni brevi e rilasci frequenti, in piena sintonia con i principi delle MA.
FDD prevede inizialmente una fase di Up-front Design, cioè di analisi e progettazione prescrittive del sistema, attraverso diagrammi UML.
Tale fase (atipica per le metodologie agili) viene seguita da una fase di progettazione dettagliate e di stesura del codice che vengono eseguite attraverso iterazioni brevi (tipicamente due settimane) in piena sintonia con i principi delle MA.
In ciascuna iterazione vengono implementate delle determinate funzionalità permettendo al Project Manager di controllare continuamente lo stato di avanzamento del progetto.
FDD è caratterizzata da cinque fasi, di cui le prime tre vengono affrontate a inizio progetto mentre le altre due sono eseguite ad ogni iterazione e "guidate" dalla lista di feature da implementare.

Figura 3 : FDD

La prima fase riguarda lo sviluppo di un modello del dominio del problema. Partendo dalla raccolta dei requisiti e dalla relativa formalizzazione, si sviluppa un modello ad oggetti per il dominio del problema. Il risultato è un insieme di diagrammi UML (sia di classe che sequenziali) che rappresentano le principali caratteristiche statiche e dinamiche del Sistema. Dopo di ciò, viene compilata una prima lista informale di funzionalità che poi verrà completata nella fase successiva.
Nella seconda fase si specificano nel dettaglio i requisiti del cliente aggiornando la lista delle Feature.
Le funzionalità vengono individuate attraverso un processo di scomposizione del modello del dominio che permette di individuare l'insieme principale di funzionalità (Major Feautuere Set) per poi scendere nel dettaglio (Feature Set) fino alle singole funzionalità (Feature).
Ad ogni funzionalità viene associata la sua priorità (A-essenziale, B-utile, C-desiderabile, D -futura) in base alle esigenze del cliente; in base a tale priorità si procede con la pianificazione delle attività.
Se una funzionalità richiede più di due settimane di sviluppo, deve essere suddivisa.
La terza fase è quella di pianificazione (Plan by Feature): si stabiliscono quali funzionalità verranno realizzate nelle varie iterazioni.
La pianificazione delle attività viene effettuata da un apposito Team noto come Planning Team coadiuvato dal Project Manager. Ad ogni classe viene assegnato un proprietario (Class Owner) così come ad ogni funzionalità (Chief Programmer), quest'ultimi sono di solito le persone del team con maggiore esperienza.

La quarta fase è quella di Progettazione (Design by Feature): il capo programmatore
individua le classi coinvolte nello sviluppo di una funzionalità e contatta i relativi proprietari. Si forma così il Feature Team, incaricato di creare la funzionalità. Tale gruppo deve analizzare, progettare e documentare le classi coinvolte nella realizzazione della specifica Feature aggiornando i digrammi UML del modello di Sistema.

La quinta e ultima fase è quella di Sviluppo (Build by Feature): basandosi sui diagrammi di classe e sequenziali aggiornati della fase precedente, i proprietari delle classi implementano le classi delle quali sono responsabili.
Nella fase di implementazione il codice viene testato con i test di unità ma anche revisionato dai capi programmatore che di fatto agiscono anche da "Mentor".
Quando il codice passa queste due verifiche, viene rilasciato e inserito nel repository del codice di progetto condiviso da tutti gli sviluppatori.
Il Capo Programmatore è responsabile dello sviluppo, dell'integrazione e del Test delle classi che compongono la funzionalità sviluppata.
Per maggiori informazioni vedere [FDDO],[FDDP], [ITFDD].

DX
RUP, come già detto, è un framework di processo e come tale può modellare (se opportunamente personalizzato/specializzato) una varietà di processi; tale flessibilità è il punto di forza principe di RUP e al contempo il principale motivo di critiche, in quanto RUP "as-is" è poco fruibile.
Può essere RUP usato in modo agile?
La risposta è sì: RUP, se opportunamente specializzato, è una metodogia agile e un esempio pratico è costituito dal processo DX ideato da Robert Martin.
dx è un processo (minimale) di RUP che cerca di ottenere il meglio sia da RUP che da XP, prendendo dal primo l'impostazione e dal secondo l'agilità. Questo si evince anche dal gioco di parole che deriva dal nome stesso; dX sarebbe XP scritto al contrario :-).
dx condivide con RUP le quattro fasi di Inception, Elaboration, Contructon, Transition mediandole però con la filosofia XP.
Di fatto il template di RUP viene "estremizzato" prevedendo delle fasi "ristrette" ed uno sviluppo suppotato dalle principali pratiche XP quali Pair Programming, Test, Refactoring, Continuous Integration, …
Laddove DX risulti essere troppo dinamico e non si sposi bene con il progetto da affrontare, lo stesso autore consiglia di aggiungere pratiche e elaborati indirizzati da RUP a fine di arricchire il processo stesso.
Per maggiori dettagli vedere [DX].

Code & fix
Code & fix, ovvero: "one year of slamming code, one year of debugging". L'immagine sotto riportata comunica piuttosto bene il concetto (vedere [CEF]). Questo metodo può funzionare finché il sistema è piccolo, ma non appena assume dimensioni maggiori diviene sempre più difficile gestirlo, aggiungere nuove funzionalità e correggere i malfunzionamenti del sistema (vedere [MFNM]). Un approccio del genere porta sicuramente ad un dispendio di energia ed è altamente pericoloso nella maggior parte dei progetti perchè non permette un tracciamento dello stato e dello sviluppo del processo.

Figura 4 : CodeAndFix

Conclusioni
In questo articolo si è effettuata una veloce "carrellata" su alcune delle principali metodologie agili di sviluppo.
Nel prossimo articolo verranno messe a confronto le metodologie predittive e adattive fino ad adesso presentate.

Bibliografia e risorse
[MOKAMET_1] S. Rossini: Processi e metodologie di sviluppo(I)-Mokabyte 83 Marzo 2004
[PXP] Kent Beck, Martin Fowler: Planning Extreme Programming - Addison Wesley 2000
[MFNM] M. Fowler: The New Methodology
http://www.martinfowler.com/articles/newMethodology.html
[UMLD] M. Fowler, Kendall Scott: UML Distilled (Addison Wesley)
[MKUML] Luca Vetti Tagliati: UML e ingegneria del software-Dalla teoria alla pratica
(HOPS)
[RUP]The Rational Unified Process - http://www.rational.com
[MASD] Manifesto for Agile Software Development - http://www.agilemanifesto.org
[AA] Agile Alliance - http://agilealliance.org
[AMD] Agile Modeling - http://www.agilemodeling.com
[AMF] Manifesto meotodologia agile - http://agilemanifesto.org
[XP] Estreme Programming: A gentle introduction - http://www.extremeprogramming.org
[XPA] http://www.adaptionsoft.com/xp.html
[CXP] http://www.c2.com/cgi/wiki?ExtremeProgrammingRoadmap
[TCXP] C.F.Acebal, J.M.C. Lovelle: Un nuovo metodo di Sviluppo Software: eXtreme Programming (XP) - http://upgrade.tecnoteca.it
[CRC] K. Beck - W. Cunningham: A Laboratory For Teaching Object-Oriented Thinking
http://c2.com/doc/oopsla89/paper.html
[SCRUM] http://www.controlchaos.com
[ITSCRUM] Lo Sprint di partenza- http://www.itware.com
[PRCSW] Processo di sviluppo SW
http://www.analisi-disegno.com/processo/processosvilupposw.htm
[XPMB]Extreme Programming e Metodologie Agili di Sviluppo software, M. Bigatti,
http://www.bigatti.it
[AGRUP]Agility with the RUP:
http://www.therationaledge.com/content/jan_02/f_agilityWIthRUP_pk.html
[dX] Robert C. Martin: A description of XP as a minimal instance of RUP
http://www.objectmentor.com/resources/listArticles?key=topic&topic=RUP
[AM] http://www.agilemodeling.com/
[CEF] http://en.wikipedia.org/wiki/Code_and_fix
[FDDO] FDD Overview: http://www.nebulon.com/articles/fdd/fddoverpres.html
[ITFDD] S.Pinna, N.Serra, M.Marchesi: La più industriale delle Metodologie Agili: FDD - http://www.itware.com
[PFDD]Portale FDD: http://www.featuredrivendevelopment.com