Nell'ingegneria del software, per metodologia agile (o leggera) o metodo agile si intende un particolare metodo di sviluppo software che coinvolge quanto più possibile il committente,
ottenendo in tal modo una elevata reattività alle sue richieste.
Esistono un certo numero di tali metodologie, tra le quali vanno citate
quelle della Agile alliance, una organizzazione no-profit creata allo scopo di diffonderle.
Introduzione
La gran parte dei metodi agili tentano di ridurre il rischio
di fallimento sviluppando il software in finestre di tempo limitate
chiamate iterazioni che, in genere, durano qualche settimana. Ogni
iterazione è un piccolo progetto a sé stante e deve contenere tutto ciò
che è necessario per rilasciare un piccolo incremento nelle
funzionalità del software: pianificazione (planning), analisi dei requisiti, analisi, implementazione, test e documentazione.
Anche se il risultato di ogni singola iterazione non ha sufficienti
funzionalità da essere considerato completo deve essere rilasciato e,
nel susseguirsi delle iterazioni, deve avvicinarsi sempre di più alle
richieste del cliente. Alla fine di ogni iterazione il team deve
rivalutare le priorità di progetto.
I metodi agili preferiscono la comunicazione in tempo reale,
preferibilmente faccia a faccia, a quella scritta (documentazione). Il
team agile è composto da tutte le persone necessarie per terminare il
progetto software. Come minimo il team deve includere i programmatori
ed i loro clienti. (con clienti si intendono le persone che definiscono
come il prodotto dovrà essere fatto. Possono essere dei product manager, dei business analysts, o veramente dei clienti).
Suddivisione
Il nome deriva da una differenziazione all'interno dell'ingegneria del software per quanto riguarda i metodi e i modelli di sviluppo. Infatti si parla di:
Il manifesto
La formalizzazione dei principi su cui si basano le metodologie
leggere è stata oggetto del lavoro di un gruppo di progettisti software
e guru dell'informatica che si sono spontaneamente riuniti nell'Agile Alliance.
Il documento finale di questo lavoro è stato poi sottoscritto da un
nutrito gruppo di questi professionisti, molti dei quali hanno anche
sviluppato alcune delle metodologie leggere più famose.
I firmatari dell'Agile Manifesto sono (in ordine alfabetico): Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham (inventore di Wiki), Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas.
Obiettivi
L'obiettivo è la piena soddisfazione del cliente e non solo
l'adempimento di un contratto. L'uso di queste metodologie, inoltre,
serve ad abbattere i costi di sviluppo del software.
Essa è esplosa proprio in concomitanza con la crisi successiva al
boom di Internet prendendo spunto dai metodi applicati in piccole software house.
Principi
I principi su cui si basa una metodologia leggera che segua i punti indicati dall'Agile Manifesto, sono solo quattro:
- le persone e le interazioni sono più importanti dei processi e
degli strumenti (ossia le relazioni e la comunicazione tra gli attori
di un progetto software sono la miglior risorsa del progetto);
- è più importante avere software funzionante che documentazione
(bisogna rilasciare nuove versioni del software ad intervalli
frequenti, e bisogna mantenere il codice semplice e avanzato
tecnicamente, riducendo la documentazione al minimo indispensabile);
- bisogna collaborare con i clienti al di là del contratto (la
collaborazione diretta offre risultati migliori dei rapporti
contrattuali);
- bisogna essere pronti a rispondere ai cambiamenti più che aderire
al progetto (quindi il team di sviluppo dovrebbe essere autorizzato a
suggerire modifiche al progetto in ogni momento).
Pratiche
Le singole pratiche applicabili all'interno di una metodologia
leggera sono decine e dipendono essenzialmente dalle necessità
dell'azienda e dall'approccio del project manager. Nella scelta però
bisogna tenere conto delle caratteristiche di ogni pratica per i
benefici che apporta e le conseguenze che comporta. Ad esempio, in
Extreme Programming, si supplisce alla mancanza assoluta di qualsiasi
forma di progettazione e documentazione con lo strettissimo
coinvolgimento del cliente nello sviluppo e con la progettazione in
coppia.
Le pratiche più diffuse tra cui scegliere sono simili fra di loro e possono essere raggruppate in categorie:
- Automation - Se l'obiettivo delle metodologie leggere è
concentrarsi sulla programmazione senza dedicarsi alle attività
collaterali, allora possono essere eliminate o automatizzate; la
seconda soluzione è migliore perché si può, ad esempio, eliminare la
documentazione aumentando il testing, ma non si possono eliminare
entrambe; quindi si sceglie che strada si vuole percorrere e si fa in
modo da utilizzare strumenti per automatizzare il maggior numero di
attività;
- Close Communication - Secondo Alistar Cockburn,
probabilmente il primo teorico delle metodologie leggere, questo è
l'unico vero aspetto nodale che renda leggera una metodologia.
Per comunicazione diretta si intende la comunicazione interpersonale,
fra tutti gli attori del progetto, cliente compreso. Ciò serve ad avere
una buona analisi dei requisiti ed una proficua collaborazione fra
programmatori anche in un ambito di quasi totale assenza di
documentazione;
- Customer Involvement - Il coinvolgimento del cliente è qui
indicato singolarmente perché ci sono differenti gradi di
coinvolgimento possibili; ad esempio in Extreme Programming il
coinvolgimento è totale, il cliente partecipa persino alle riunioni
settimanali dei programmatori; in altri casi, il cliente è coinvolto in
una prima fase di progettazione e poi non più; in altri ancora il
cliente partecipa indirettamente e viene usato come test della versione
rilasciata;
- Design & Documentation - Pensare che le metodologie leggere eliminino
la progettazione e la documentazione è un errore, in effetti non è
così, le metodologie leggere introducono un'iterazione nel ciclo di
vita del progetto; quanta progettazione fare e quanta documentazione
produrre, escludendo i casi estremi, è una scelta lasciata a chi
gestisce il progetto e spesso i teorici dell'Agile Alliance avvisano
che è un errore trascurare o addirittura omettere queste due fasi;
- Frequent Delivery - Effettuare rilasci frequenti di versioni
intermedie del software permette di ottenere più risultati
contemporaneamente: si ricomincia l'iterazione avendo già a
disposizione un blocco di codice funzionante in tutti i suoi aspetti,
si offre al cliente 'qualcosa con cui lavorare' e lo si distrae così da
eventuali ritardi nella consegna del progetto completo, si usa il
cliente come se fosse un test visto che utilizzerà il software e
riscontrerà eventuali anomalie, si ottengono dal cliente informazioni
più precise sui requisiti che probabilmente non sarebbe riuscito ad
esprimere senza avere a disposizione utilità e carenze del progetto;
- Hierarchy - La scelta di creare una struttura gerarchica
all'interno del team di sviluppo dipende molto dall'approccio del
project manager, in ogni caso si ha una conseguenza non secondaria
facendo questa scelta; se si decide per una struttura gerarchica ad
albero e frammentata si ottiene la possibilità di gestire un numero
molto alto di programmatori e di lavorare a diversi aspetti del
progetto parallelamente; se si decide per una totale assenza di
gerarchia si avrà un team di sviluppo molto compatto e motivato, ma
necessariamente piccolo in termini di numero di programmatori;
- Pair Programming - Programmare in coppia, ossia: due
programmatori, due sedie, una scrivania, un computer, una tastiera ed
un mouse; uno dei due scrive, l'altro verifica, entrambi scelgono la
soluzione costruttiva migliore; è stato dimostrato che i costi di
questa scelta sono inferiori ai benefici che apporta, ma ci sono esempi
pratici che indicano come questa pratica possa essere insopportabile
per alcuni programmatori e quindi controproducente;
- Refactoring - Ossia la riscrittura completa di parti di
codice mantenendone invariato l'aspetto esterno, nel caso di una
funzione ciò significa riscriverne completamente il core mantenendone
invariato header ed ovviamente sintassi, trattandola cioè come una
black box; è una delle pratiche più diffuse e suggerite, ma anche
questa, come il Pair Programming, ha differenti studi che ne attestano
l'inutilità ed in alcuni casi la dannosità;
- Reflective Improvement - Nata con l'avvento della
programmazione Object-Oriented, non è altro che la presa di coscienza
della produzione di conoscenza che si fa un un'azienda man mano che si
produce codice; questa conoscenza prodotta non deve andare perduta ed è
per far ciò che si sfruttano spesso le altre pratiche, come la
comunicazione stretta o la condivisione della proprietà del codice;
- Reverse Engineering - Ossia ottenere, spesso in maniera
automatica, la documentazione a partire dal codice già prodotto; è una
delle pratiche più diffuse e più controverse, diffusa perché permette
un guadagno enorme in termini di tempo, ma controversa perché spesso la
documentazione prodotta è inutilizzabile oppure è prodotta solo per una
richiesta burocratica del cliente e non verrà mai realmente utilizzata;
- Simplicity - Uno dei punti chiave delle metodologie leggere,
direttamente mutuato dalla programmazione Object-Oriented, è la
semplicità; semplicità nel codice, semplicità nella documentazione,
semplicità nella progettazione, semplicità nella modellazione; i
risultati così ottenuti sono una migliore leggibilità dell'interno
progetto ed una conseguente facilitazione nelle fasi di correzione e
modifica;
- Team forming & Code property - La formazione del team di
sviluppo è condizionata dalla scelta sulla gerarchia interna, ma segue
regole precise che permettono di ottenere un team produttivo
nell'ambito della metodologia scelta; la scelta dei membri del team è
condizionata anche alla scelta della proprietà del codice, che può
essere individuale o collettiva; nel primo caso la responsabilità sullo
sviluppo è individuale, nel secondo dipende da tutto il team e quindi
dal project manager;
- Testing - Pratica diffusissima anche prima della nascita
delle metodologie leggere, ha prodotto una letteratura vastissima ed
una serie di approcci differenti come il Rapid Testing o il Pair Testing; nell'ambito delle metodologie leggere vengono spesso utilizzati insieme tre tipi di test differenti: i test funzionali, utilizzati per verificare che il software faccia effettivamente ciò che è previsto debba fare, i test unitari, utilizzati per verificare che ogni pezzo di codice funzioni correttamente, e i test indiretti effettuati inconsciamente dal cliente ogni volta che gli si consegna una versione;
- Version Control - Una delle conseguenze dirette
dell'iterazione nella produzione è la necessità di introdurre un
modello, un metodo, uno strumento, per il controllo delle versioni del
software prodotto e rilasciato; uno degli strumenti più diffusi e
maggiormente suggeriti per ottemperare automaticamente a questa pratica
è CVS.
Insieme di metodologie
In senso lato questo termine 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 e Lean Software Development. Tali metodologie si chiamano appunto agili
perché consentono di rivedere di continuo le specifiche e di cambiarle
durante lo sviluppo mediante un forte scambio di informazioni e di
pareri con il committente.