Nell’articolo successivo a questo ci occuperemo di Scrum e Lean Software Development, due tra le metodologie più conosciute e diffuse. Ma intanto, in questa seconda parte della serie vogliamo dare una panoramica su alcune metodologie meno diffuse o più controverse (con il ruolo fondamentale di XP, per esempio) che è bene conoscere: l’analisi dei diversi approcci e delle loro caratteristiche ci aiuterà ad avere un quadro ragionato del panorama agile.

Una filosofia comune per molte metodologie

Le varie metodologie agili condividono una comune filosofia, così come molte pratiche e caratteristiche, come sarà evidente nei paragrafi seguenti. Però, da un punto di vista implementativo, ciascuna ha un suo peculiare insieme di principi, pratiche, terminologia e tattica. Nelle prossime sezioni verranno affrontate più nel dettaglio alcune di queste metodologie e considerati i loro fattori di somiglianza e differenza, così come eventuali possibilità di mutua interazione tra i diversi metodi. Vediamone intanto un breve quadro riassuntivo.

Il movimento agile ha trovato una forte promozione nella metodologia XP, (eXtreme Programming), nata probabilmente durante un progetto sviluppato da Kent Beck, per Daimler Chrysler, anche coadiuvata dalla ricerca fatta negli anni precedenti congiuntamente a Ward Cunningham. Kent Beck, per chi non lo sapesse, è un esperto informatico piuttosto “creativo”: è stato uno dei pionieri, oltre che di XP, anche dell’uso dei template nel software, ha ideato i file CRC (le schede Class – Responsibility – Collaboration), il framework per editor grafici HotDraw e quello per il testing xUnit… insomma, non poco. In eXtreme Programming si inseriscono alcune pratiche, tra cui il refactoring del codice, formalizzato nel noto testo di Martin Fowler, “Refactoring: Improving the Design of Existing Code” [7]. Sulla base dei concetti di XP è nata Scrum, un metodologia agile per gestire i progetti software, dove si ribadisce che il ciclo di sviluppo è composto da molte iterazioni di breve durata, in particolare con brevi meeting di dieci minuti ogni giorno e sprint produttivi di un mese.

Tra XP e Scrum si posizionano una serie di metodologie, come l’Agile Modeling, che si pone l’obiettivo di modellare e documentare i sistemi software puntando direttamente all’obiettivo, oppure l’Agile Data, che porta i concetti agili nello sviluppo dei database, anche proponendo un catalogo di refactoring per i dati. Entrambe queste ultime discipline sono state sviluppate da Scott Ambler, già noto in passato per “The Object Primer” [8] e “The Elements of Java Style” [9].

Degno di nota anche il Feature Driven Programming, una metodologia creata da Peter Coad e Jeff De Luca e pubblicata per la prima volta nel loro libro “Java Modeling in Color with UML” [2], che pone l’attenzione sulle funzionalità richieste dal cliente.

Altre metodologie meno note, ma che hanno contribuito significativamente al movimento delle discipline agili, sono DSDM, ASD e Crystal.

Agile Modeling

Agile Modeling (AM) è una metodologia basata su una serie di pratiche per la modellazione e la documentazione dei sistemi software. Ad alto livello, AM consiste in una collezione di best practice, rappresentate nella mappa concettuale basata sul linguaggio dei pattern e mostrata in figura 1.

Figura 1 – Agile Modeling best practice.

Ad un livello maggiore di dettaglio AM, è costituita da un insieme di valori, principi, e pratiche per la modellazione del software che possono essere applicati a un progetto di sviluppo software in modo più flessibile ed efficace rispetto ai tradizionali e pesanti metodi di modellazione. Nello schema di figura 2 viene mostrato il ciclo di sviluppo previsto da AM.

Figura 2 – Agile Modeling.

Va inoltre detto che questa metodologia può essere considerata come un valido supplemento ad altre metodologie standard quali

• Agile Unified Process
• Feature Driven Design
• eXtreme Programming
• Scrum

nelle quali AM viene utilizzata per sostituire in maniera più snella lo UML o altri strumenti di progettazione standard.

Agile Unified Process (AUP)

AUP è una versione semplificata, sviluppata da Scott Ambler, dell’IBM Rational Unified Process (RUP). Essa descrive un approccio allo sviluppo di applicazioni software, semplice, facile da comprendere e che utilizza tecniche e concetti agili pur rimanendo fedele al processo RUP. Scott Ambler ha cercato di mantenere Agile Unified Process il più semplice possibile, sia nell’approccio che nella sua descrizione.

AUP applica le tecniche di sviluppo agile tra cui test-driven development (TDD), Agile Modeling, gestione agile del cambiamento e refactoring di codice e database per migliorare in modo continuo la produttività e la qualità del prodotto realizzato.

Pratiche

Diversamente da RUP, l’Agile UP ha soltanto 7 discipline o pratiche che vengono utilizzate in modo incrementale e iterativo:

• Modellazione: comprendere il business dell’organizzazione, il dominio del problema affrontato dal progetto, e individuare una soluzione praticabile per affrontare il dominio del problema.
• Implementazione: trasformare i modelli in codice eseguibile ed effettuare un livello base di test, in particolare test unitari.
• Test: eseguire una valutazione oggettiva dell’intero sistema per garantire la qualità. Questo include trovare difetti, avere la convalida che il sistema abbia funzionato come previsto e verificare che i requisiti siano stati soddisfatti.
• Deployment: pianificare la consegna del sistema ed eseguire tale piano per rendere il sistema disponibile agli utenti finali.
• Gestione della configurazione: gestire tutti gli artefatti di progetto. Questo include non solo il tener traccia delle versioni degli artefatti nel tempo, ma anche controllarne e gestirne le modifiche.
• Project Management: dirigere le attività che si svolgono nell’ambito del progetto. Questocomprende la gestione dei rischi e delle persone (assegnazione di compiti, monitoraggio dei progressi, …), e il coordinamento con persone e sistemi esterni al progetto stesso, per essere sicuri che sia consegnato nei limiti di tempo e budget previsti.
• Ambienti: sostenere il resto del progetto, garantendo che, in base alle esigenze, siano disponibili per il team un processo corretto, i dovuti orientamenti (standard e linee guida) e gli adeguati strumenti (hardware, software, etc).

Principi

La metodologia Agile UP è basata sui seguenti principi “filosofici”:

• Il vostro personale sa cosa sta facendo. Alle persone non è richiesto di leggere la documentazione dettagliata di processo, ma verranno date alcune linee guida di alto livello e/o della formazione all’occorrenza. AUP fornisce collegamenti a molti dettagli, se siete interessati, ma non vi obbliga a seguirli.
• Semplicità. Tutto viene descritto in modo conciso con una manciata di pagine, non migliaia.
• Agilità. Agile UP è conforme ai valori e principi dell’Agile Software Development e dell’Agile Alliance.
• Concentrarsi su attività ad alto valore. L’attenzione deve concentrarsi sulle attività che contano realmente, e non su qualsiasi cosa possa accadere durante un progetto.
• Indipendenza dagli strumenti. È possibile utilizzare qualsiasi set di strumenti si desideri. La raccomandazione è di utilizzare gli strumenti che sono più adatti per un determinato lavoro, che spesso sono gli strumenti più semplici.
• Personalizzazione. È possibile personalizzare AUP per adattarlo ancor più alle proprie esigenze.

Rilasci

L’Agile Unified Process fa distinzione tra due tipi di iterazioni: quelle di rilascio in sviluppo e quelle di rilascio in produzione. Un’iterazione di rilascio in sviluppo risulta nel deployment del sistema in ambiente di Quality Assurance e/o nell’area demo. Invece un’iterazione di rilascio in produzione risulta in un deployment nell’area di produzione (figura 3). Si tratta di un significativo perfezionamento rispetto al Rational Unified Process.

Figura 3 – Tipologie d’iterazione in Agile UP.

Adaptive Software Development (ASD) e Agile Project Management (APD)

È una metodologia agile ideata da Jim Highsmith, direttore del Cutter Consortium’s Agile Project Management Advisory Service. Questa metodologia è composta da un insieme di regole di sviluppo software inserite in un sistema complessivo detto Agile Project Management i cui concetti base sono 3:

• Leadership-Collaboration Management: uno stile di gestione misto fra modello gerarchico e collaborativo.
• From Processes to Pattern: questo concetto rappresenta il passaggio dall’idea di processo definito e misurabile a quella di processo non perfettamente definito, quasi un processo fuzzy.
• Peering into the Future: osservazione del futuro per capire come l’idea che produrrà un affare o prodotto di successo debba essere legata al momento in cui diventerà una forma di business.

Jim Highsmith e Ken Orr affermano che la metodologia Adaptive Software Development può funzionare solo ed esclusivamente se l’intero team è consapevole dell’importanza del lavoro di gruppo e spiegano come si discosti, ad esempio, da eXtreme Programming su punti essenziali (cliente presente, Pair Programming, test automatizzati) concentrandosi sulla strategia della Leadership-Collaboration Management e sull’adattamento totale al progetto in lavorazione.

Di sicuro, esistono tre situazioni esemplari che suggeriscono di utilizzare l’Agile Project Management:

• progetti ad alto valore esplorativo (nel senso di sperimentazione);
• progetti in cui il feedback del cliente è di capitale importanza;
• organizzazioni che apportino innovazioni estreme.

La formalizzazione di un sistema complessivo costruito intorno ad Adaptive Software Development porta a considerare Agile Project Management (APM) come un nuovo framework metodologico.

Ciclo di vita di APM: 5 fasi

Le cinque fasi del ciclo di vita di APM sono generalizzate per consentirne un utilizzo con qualunque metodologia agile:

• prevedere: innanzi tutto definire una vision del prodotto finale, decidere chi farà cosa, scegliere come il gruppo di lavoro lavorerà insieme;
• ipotizzare: sviluppare una versione basata solo sulle funzionalità selezionate, decidere delle milestone e un interation plan;
• esaminare: cioè consegnare spesso versioni con nuove funzionalità testate, e che il cliente potrà testare ancor meglio con l’utilizzo;
• adattare: verificare i risultati delle versioni consegnate, ricontrollare l’ambiente reale di utilizzo, testare così le prestazioni del gruppo di lavoro; adattare e riadattare se necessario;
• chiudere: concludere il progetto, affrontare gli ultimi dettagli in sospeso… e festeggiare.

Principi fondamentali di ASD

I principi fondamentali connessi con questa metodologia possono essere riassunti nei seguenti punti:

• sviluppare qualcosa di utile;
• coltivare la fiducia degli stakeholders;
• utilizzare Leadership-Collaboration Management come stile gestionale;
• costituire gruppi di lavoro competenti e collaborativi;
• far sì che il team abbia la possibilità e sia in grado di prendere decisioni;
• consegnare spesso nuove versioni caratterizzate dall’aggiunta di nuove funzionalità;
• incoraggiare l’adattabilità;
• cercare di ottenere l’eccellenza tecnica;
• quando possibile, aumentare il volume di dati immessi.

Crystal Clear e altre metodologie Crystal

La famiglia di metodologie Crystal, ideata da Alistair Cockburn, è orientata prevalentemente alle persone e si concentra sul rafforzamento e miglioramento del lavoro delle persone coinvolte. La logica è quella di iniziare le attività realizzando piccoli task, che successivamente vengono assemblati in task più grandi. Le attività di overhead sono ridotte al minimo e gli sforzi vengono concentrati sul lavoro effettivo di costruzione. In pratica si tratta di un processo collaborativo che coinvolge il monitoraggio e le iterazioni continue.

Crystal Clear

Crystal Clear, che la più semplice metodologia di questa famiglia, può essere applicata a gruppi di massimo 6 o 8 sviluppatori che si trovino nella stessa stanza e che lavorino su sistemi non life-critical. Questa metodologia richiede che siano rispettate le seguenti proprietà:

• rilascio frequente di codice utilizzabile agli utenti;
• miglioramenti riflessivi;
• comunicazione osmotica, preferibilmente essendo il team collocato nello stessoambiente.

Crystal Clear può includere anche queste caratteristiche opzionali:

• sicurezza personale;
• focalizzazione;
• facilità ad accedere agli esperti;
• test automatici;
• gestione della configurazione e integrazione frequente.

Dynamic Systems Development Methods (DSDM)

La metodologia DSDM [6], distribuita gratuitamente dal consorzio DSDM ai propri membri, è fornita assieme ad un framework e può essere utilizzata per progetti che abbiano tempi e budget ristretti. Tale consorzio è nato per definire e distribuire uno standard industriale per il processo di sviluppo RAD (Rapid Application Development). È importante sottolineare il fatto che DSDM è una metodologia che si integra facilmente con altre metodologie agili (esistono risorse già pronte per farlo con eXtreme Programming, Prince2, RUP, …). Il metodo DSDM, che il consorzio definisce framework perche‘ prevede di integrarlo al framework RAD, si basa su quattro principi:

• lo sviluppo avviene mediante un lavoro di gruppo;
• l’alta qualità si ottiene grazie a velocità e robustezza;
• lo sviluppo può essere incrementale;
• bisogna impiegare il tempo dedicato allo sviluppo concentrandosi prima sulle funzionalità che rendono di più in termini di business.

Nell’ambito disegnato da questi principi si inseriscono le regole di base, che come ben possiamo vedere sposano appieno i principi di tutto il movimento agile:

• coinvolgimento attivo degli utenti;
• potere decisionale al team;
• rilasci frequenti del prodotto;
• rilasciare le versioni dando priorità allo sviluppo delle funzionalità finalizzate al business;
• sviluppo iterativo e incrementale;
• tutti i cambiamenti effettuati durante lo sviluppo devono essere reversibili;
• i requisiti e le specifiche sono definite solo ad alto livello;
• la fase di test è integrata nel ciclo di vita del prodotto;
• la collaborazione e la cooperazione fra gli attori coinvolti nel progetto sono d’obbligo.

L’assunto da cui si parte per ottenere un buon prodotto con una tempistica migliore è che, anche se le prime versioni non saranno perfette, in generale è meglio rilasciarle subito perche‘ l’80% del prodotto richiesto può essere sviluppato nel 20% del tempo necessario a sviluppare il prodotto intero. Poi, nel resto del tempo, si potrà terminare il lavoro e correggere gli errori che gli utenti segnaleranno.

Feature Driven Development (FDD)

Lo scopo principale della metodologia Feature Driven Development (FDD), concepita da Peter Coad e Jeff De Luca (Coad, 1999) e indicata nel Manifesto Agile, è quello di fornire in modo tangibile del software funzionale ripetutamente e in modo tempestivo. Essa miscela, in un insieme coerente, una serie di best practice di settore riconosciute a livello internazionale. Queste pratiche sono tutte guidate da una prospettiva dettata da funzionalità (feature) che abbiano valore per il committente.

Dato che FDD propone una robusta fase di analisi e progettazione integrata con un modello di sviluppo agile, può essere probabilmente ritenuta come il miglior compromesso e la miglior soluzione agile possibile, anche se molto meno nota di eXtreme Programming. Khramtchenko [3] fa un confronto diretto dal quale emerge sorprendentemente che Feature Driven Development è addirittura più flessibile di XP anche se la prima ha una fase di progettazione classica che la seconda elimina proprio per guadagnarne in flessibilità.

Fasi di sviluppo

FDD è un processo di sviluppo iterativo e incrementale guidato da modelli, caratterizzato da brevi iterazioni, che suddivide il progetto in 5 fasi, dette processi. Durante le prime tre fasi sequenziali viene stabilita una forma per il modello complessivo, mentre le due fasi finali vengono iterate per ciascuna funzionalità (figura 4).

• Sviluppare un modello generale: il progetto inizia con un’esplorazione ad alto livello del campo di applicazione del sistema e del suo contesto. Successivamente, vengono effettuate delle analisi dettagliate di dominio per ogni area di modellazione.
• Definire una lista di funzionalità: le conoscenze che sono state acquisite durante la modellazione iniziale vengono utilizzate per identificare vari elenchi di funzionalità. Questo viene realizzato decomponendo funzionalmente il dominio in aree tematiche. A ciascun insieme di funzionalità (feature set) viene assegnato uno specifico team. Tale squadra, denominata feature set team, deve quindi definire ogni elemento, presente nella lista delle funzionalità, in termini di azione – risultato – oggetto.
• Pianificare per funzionalità: una volta che la lista di funzionalità è completa, il passo successivo è quello di produrre un piano di sviluppo. L’assegnazione delle classi viene fatta ordinando e assegnando le funzionalità (o liste di funzionalità) in forma di classi (secondo il paradigma object oriented) ai diversi programmatori capo di ogni feature set team.
• Progettare per funzionalità: in quest’attività iterativa, per ciascuna funzionalità viene prodotto un pacchetto di progettazione. Un capo-programmatore seleziona quindi un piccolo gruppo di funzionalità che devono essere realizzate in un’iterazione di due settimane. Insieme con i corrispondenti proprietari delle classi, il programmatore capo elabora i diagrammi di sequenza dettagliati per ogni elemento e raffina il modello complessivo. Successivamente, vengono scritte le classi e gli header dei metodi e, infine, viene svolto un riesame della progettazione.
• Sviluppare per funzionalità: dopo che è stata effettuata un’ispezione della progettazione con esito positivo, viene iniziata l’attività di produzione di una singola funzionalità completa che abbia valore per il cliente. Ciascun proprietario di classe sviluppa il codice effettivo per le classi di sua competenza. Dopo avere eseguito i test unitari e un’ispezione del codice, il capo-programmatore decide, assieme al team delle funzionalità, quali classi possono essere considerate promuovibili come utili alla costruzione del progetto in riguardo alle funzionalità richieste.

Figura 4 – Fasi di sviluppo del processo FDD.

Milestone

Dal momento che le funzionalità sono di piccole dimensioni, il completamento di una singola feature è un compito relativamente breve. Allo scopo di ottenere un accurato reporting, e di poter tenere traccia dello stato di sviluppo software del progetto, è comunque importante poter segnare i progressi compiuti per ogni funzione. A tale scopo FDD definisce un insieme di 6 tappe fondamentali che devono essere completate in sequenza per ciascuna funzionalità.

A conclusione delle informazioni sul Feature Driven Development, va detto che la nozione di Domain Object Modeling sta conquistando un sempre maggiore interesse anche al di fuori della comunità FDD, specialmente grazie al successo del libro di Eric Evans “Domain-Driven Design” [10].

eXtreme Programming

Passiamo ora a descrivere brevemente una delle più note e forse controverse metodologie agili. eXtreme Programming (espressione inglese per programmazione estrema, spesso abbreviata in XP) è un approccio all’ingegneria del software formulato da Kent Beck, Ward Cunningham e Ron Jeffries. Essa implementa un ambiente semplice ma efficace che consente ai team di diventare altamente produttivi. Il gruppo si auto-organizza intorno al problema da risolvere nel modo più efficiente possibile.

4 valori e 12 pratiche

XP è caratterizzata da insieme di 4 valori e 12 pratiche. I 4 valori su cui si fonda questa metodologia sono: semplicità, comunicazione, testing e coraggio, mentre le 12 “prassi consolidate” possono essere raggruppate in quattro aree fondamentali. Vediamo di seguito le 12 “core practices” di XP raggruppate nelle 4 aree definite feedback a scala fine, processo continuo, comprensione condivisa, benessere dei programmatori.

Feedback a scala fine

• Pair programming: significa che tutto il codice viene prodotto da due persone che programmano assieme su una sola workstation.
• Planning Game: è una riunione di pianificazione che avviene una volta per iterazione, tipicamente una volta a settimana.
• Test-Driven Development: i test unitari vengono scritti prima di scrivere il codice.
• Whole Team: in XP, il “cliente” non è colui che paga il conto, ma la persona che realmente utilizza il sistema.

Processo continuo

• Continuous integration: eviterà ritardi più avanti nel ciclo del progetto, causati da problemi d’integrazione. L’integrazione delle modifiche nel sistema viene fatta frequentemente, in modo da limitare i conflitti che il nuovo codice (e il codice di test) dovesse dare. Inoltre, questa procedura avviene in modo strettamente sequenziale: solo uno sviluppatore alla volta integra le sue modifiche con il sistema, testa e rilascia il codice. Questo, assieme alla programmazione collettiva, consente di risolvere in modo semplice le tipiche problematiche di integrazione su una stessa base di codice del lavoro di diverse persone.
• Refactoring o design improvement: refactoring del codice cambiando l’architettura, in modo da renderlo più semplice e generico.
• Small releases: consegna del software avviene tramite frequenti rilasci di funzionalità che creano del valore concreto.

Comprensione condivisa

• Coding standards: è un insieme di regole concordate, che l’intero team di sviluppo accetta di rispettare nel corso del progetto.
• Collective code ownership: significa che ognuno è responsabile di tutto il codice.
• Simple design: i programmatori dovrebbero utilizzare un approccio “semplice è meglio” alla progettazione software.
• System metaphor: è una “storia” che ognuno (clienti, programmatori e manager), può raccontare circa il funzionamento del sistema.

Benessere dei programmatori

• Sustainable pace: il concetto è che i programmatori o gli sviluppatori software non dovrebbero lavorare più di 40 ore a settimana.

Una supposizione interessante delle metodologie agili, ed in particolare di XP, in contrasto con la maggior parte dei metodi conosciuti, è quella secondo cui, con il progredire del tempo, il costo del cambiamento non cresce, ma al contrario si stabilizza ad un valore modesto.

Conclusioni

Lungi dal voler essere esaustivi (esistono decine di corposi volumi sull’argomento), in questo articolo abbiamo voluto presentare una panoramica breve, ma ci auguriamo chiara, di molte metodologie agili che ricoprono un ruolo importante nel panorama: questa importanza è dovuta, più che alla vasta adozione, all’introduzione alcuni concetti importanti oppure al fatto che alcune pratiche si sono integrate con altre metodologie a più ampia adozione.

Nel prossimo articolo, che concluderà questa serie, parleremo invece di Lean Software Development e Scrum, metodologie di vasta diffusione e per questo più conosciute.

Riferimenti

[1] Manifesto for Agile Software Development, 2001
http://agilemanifesto.org

[2] P. Coad – J. De Luca – E. Lefebvre, “Java Modeling In Color With UML: Enterprise Components and Process”, Prentice Hall, 1999

[3] S. Khramtchenko, “Comparing eXtreme Programming and Feature Driven Development in academic and regulated environments”, Harvard University, CSCIE-275: Software Architecture and Engineering, 2004

[4] M.P. Poppendieck, “Lean Software Development: An Agile Toolkit”,. Addison-Wesley Professional, 2003

[5] W.Royce, “Managing the Development of Large Software Systems”. Proc. Westcon, IEEE CS Press, 1970, pp. 328-339

[6] J. Stapleton, “DSDM Dynamic Systems Development Method: The Method in Practice”, Addison Wesley, 1997

[7] M. Fowler – K. Beck – J. Brant – W. Opdyke – D. Roberts, “Refactoring: Improving the Design of Existing Code”, Addison-Wesley Professional, 1999

[8] S.W. Ambler, “The object primer: the application developer’s guide to object-orientation”, SIGS Books, 1995

[9] A. Vermeulen – S.W. Ambler – G. Bumgardner – E. Metz – T. Misfeldt – J. Shur, “The Elements of Java Style”, SIGS Reference Library, 2000

[10] E. Evans, “Domain-Driven Design: Tackling Complexity in the Heart of Software”, Addison-Wesley Professional, 2003