Marco Papacchini

La Nuova Metodologia

Martin Fowler
Chief Scientist, ThoughtWorks

Traduzione italiana: Marco Papacchini, Giugno 2003
Testo originale: The New Methodology


Negli ultimi anni si è assistito ad un crescente interesse per le Metodologie Agili (conosciute anche come Metodologie Leggere). Indicate alternativamente come un antidoto all'approccio burocratico o come una concessione all'hacking, hanno suscitato interesse in tutto il panorama del software. In questo saggio esamino le motivazioni per i metodi agili, non concentrandomi troppo sul loro "peso" quanto piuttosto sulla loro natura adattiva e sulla loro attenzione primaria per l'individuo. Fornisco inoltre un elenco e dei riferimenti per i processi appartenenti a questa scuola e considero i fattori che dovrebbero influenzare la decisione di scegliere di percorrere questo sentiero da poco tracciato.

Dal Niente, al Monumentale, all'Agile

Gran parte dello sviluppo del software è un'attività caotica, spesso indicata con l'espressione "code and fix". Il software viene scritto senza troppo riferirsi ad un progetto di fondo e il design del sistema è messo insieme per mezzo di molte decisioni a breve termine. Questo risulta funzionare abbastanza bene finché il sistema è piccolo, ma non appena assume dimensioni maggiori diviene sempre più difficile aggiungere nuove funzionalità al sistema. Inoltre i malfunzionamenti aumentano sempre più e risultano sempre più difficili da correggere. Un tipico sintomo di tali sistemi risulta essere la presenza di una lunga fase di test, successiva al completamento di tutte le funzionalità del sistema. Una tale lunga fase di test distrugge qualsiasi programma di lavoro, dal momento che non è possibile inserire il testing e il debugging in un tale programma.

Abbiamo convissuto con questo stile di sviluppo per un lungo periodo, ma per un lungo periodo abbiamo anche avuto un'alternativa: la metodologia. Le metodologie impongono sullo sviluppo del software un processo disciplinato, con lo scopo di rendere lo sviluppo del software più prevedibile e più efficiente. Realizzano ciò sviluppando un processo dettagliato che dà grande enfasi alla pianificazione, prendendo spunto da altre discipline ingegneristiche -- e questo spiega perché sono solito riferirmi ad esse con il termine di metodologie ingegneristiche.

Le metodologie ingegneristiche sono state presenti per molto tempo. Non si sono distinte per aver portato a risultati molto soddisfacenti. Non si sono neanche distinte per la loro popolarità. La critica più frequente che viene fatta loro è che sono burocratiche. Ci sono talmente tante cose da fare per seguire la metodologia che il ritmo complessivo dello sviluppo del software rallenta.

In reazione a queste metodologie, negli ultimi anni è comparso un nuovo gruppo di metodologie. Per un breve periodo sono state conosciute come metodologie leggere, ma adesso il termine affermato è metodologie agili. Per molti l'attrattiva verso di esse risiede nella loro reazione alla burocrazia propria delle metodologie monumentali. Questi nuovi metodi ricercano un utile compromesso tra il non avere nessun processo e averne troppo, fornendone quanto basta al fine di ottenere un ragionevole beneficio.

Come conseguenza di tutto ciò, i metodi agili presentano alcuni cambiamenti significativi di enfasi rispetto ai metodi ingegneristici. La differenza più immediata è che sono meno orientati alla documentazione, poiché generalmente considerano una minore quantità di documentazione per un determinato compito. Sotto diversi aspetti sono abbastanza orientati al codice, poiché adottano il punto di vista secondo il quale l'elemento chiave della documentazione è il codice sorgente.

Comunque non ritengo che questo costituisca il punto fondamentale dei metodi agili. La carenza di documentazione è il sintomo di due differenze più profonde:

Nelle sezioni seguenti esaminerò queste differenze in maggior dettaglio, cosicché si potrà comprendere cosa sia un processo adattivo e orientato all'individuo, i suoi benefici e svantaggi, e se è il caso che lo adottiate, in qualità di sviluppatore o di cliente del software.


Predittivo contro Adattivo

La Separazione del Design e della Realizzazione

Le discipline ingegneristiche, quali l'ingegneria civile o quella meccanica, costituiscono l'usuale fonte di ispirazione per le metodologie. Questo genere di discipline presta grande attenzione alla pianificazione prima della costruzione. I loro ingegneri lavorano su una serie di diagrammi che indicano precisamente quali parti debbano essere realizzate e come queste debbano essere assemblate. Molte decisioni di progettazione, quali ad esempio la modalità di distribuzione del carico su un ponte, sono prese durante la realizzazione dei diagrammi. I diagrammi sono quindi assegnati ad un diverso gruppo di persone, spesso appartenenti ad una diversa compagnia, che si occupano della loro realizzazione. Si presume che il processo di costruzione seguirà le indicazioni dei diagrammi. In pratica i costruttori incontreranno alcune difficoltà, ma queste sono generalmente di scarsa entità.

Dal momento che i diagrammi forniscono una specifica delle parti e di come queste debbano essere assemblate, essi costituiscono il fondamento per un dettagliato piano di costruzione. Tale piano è in grado di determinare i compiti che devono essere svolti e le dipendenze che esistono tra essi. Questo consente di effettuare una previsione ragionevole sul programma di lavoro e sul budget per la costruzione. Il piano inoltre descrive in dettaglio come il personale addetto alla costruzione dovrebbe svolgere il proprio lavoro. Ciò rende la costruzione meno impegnativa dal punto di vista intellettuale, sebbene spesso richieda una grande abilità manuale.

Ci troviamo così in presenza di due attività fondamentalmente differenti. Il design, sul quale è molto difficile effettuare previsioni e che richiede personale costoso e dotato di creatività, e la costruzione, che è più facilmente prevedibile. Non appena possediamo un progetto possiamo pianificare la costruzione. Non appena abbiamo una pianificazione per la costruzione possiamo affrontare la costruzione in termini più predittivi. Nell'ingegneria civile la fase di costruzione è molto più grande di quella di design e di pianificazione, sia in termini di costi che di tempo.

Questo suggerisce il seguente approccio alle metodologie dell'ingegneria del software: si vuole un programma di lavoro prevedibile che consenta di utilizzare personale non altamente specializzato. A tal fine si deve separare il design dalla realizzazione. Si deve quindi determinare in che modo effettuare il design affinché la realizzazione possa essere facilmente eseguita non appena si dispone della pianificazione.

Di che tipo deve allora essere una tale pianificazione? Secondo molti qui subentra il ruolo delle notazioni di design, quale l' UML. Se è possibile esprimere tutte le decisioni significative di progettazione in termini dell'UML, è possibile elaborare un piano di realizzazione e poi passare i progetti ai programmatori per l'attività di realizzazione.

Ma qui sta l'aspetto cruciale. E' possibile ottenere un progetto capace di rendere la programmazione un'attività di realizzazione prevedibile? E in tal caso, il costo di un tale procedimento è sufficientemente basso da rendere questo approccio conveniente?

Tutto ciò fa nascere alcuni interrogativi. Il primo riguarda la difficoltà di rendere un design espresso in notazione UML in condizioni tali da poter essere passato ai programmatori. La difficoltà con il design espresso in notazione UML è che può apparire ottimo sulla carta, ma presentare seri problemi quando si deve di fatto trasformarlo in codice. I modelli utilizzati dagli ingegneri civili sono frutto di molti anni di un'esperienza che è riportata nei codici di ingegneria. Inoltre gli aspetti fondamentali, quali ad esempio la modalità di azione delle forze nel progetto, sono suscettibili di un'analisi matematica. L'unico controllo che è possibile effettuare sui diagrammi espressi in notazione UML è il peer review. Sebbene risulti essere utile, spesso non consente di individuare alcuni errori nel progetto, che vengono rilevati soltanto durante la programmazione o il testing. Persino progettisti esperti, quale io reputo di essere, rimangono spesso sorpresi quando un tale progetto viene trasformato in software.

Un altro aspetto riguarda la comparazione delle durate di queste due attività. Quando si deve edificare un ponte il costo della progettazione ammonta a circa il 10% del lavoro totale, il resto essendo relativo alla costruzione. Nel contesto del software la quantità di tempo dedicata alla programmazione è decisamente molto inferiore. McConnell indica che per un progetto di grandi dimensioni soltanto il 15% del tempo riguarda programmazione e unit test, una situazione perfettamente rovesciata rispetto a quanto accade nel caso del ponte. Anche se si raggruppa l'intero testing all'interno della fase di costruzione, il design rimane ancora il 50% del lavoro. Questo porge l'importante questione della natura del design nel contesto dello sviluppo del software, in relazione al ruolo che esso assume in altri rami dell'ingegneria.

Questo tipo di interrogativi ha condotto Jack Reeves a suggerire che il codice sorgente sia di fatto un documento di design e che la fase di costruzione sia in realtà costituita dall'utilizzo del compilatore e del linker. Difatti qualsiasi cosa possa essere considerata come costruzione può e dovrebbe essere automatizzata.

Queste considerazioni portano ad alcune importanti conclusioni:

L'Imprevedibilità dei Requisiti

C'è una frase che ho sempre sentito in ogni progetto complicato che ho incontrato. Gli sviluppatori vengono da me e dicono: "Il problema con questo progetto è che i requisiti cambiano continuamente". La cosa che trovo sorprendente in questa situazione è che qualcuno rimanga sorpreso da tale fatto. Nella realizzazione di software aziendale i cambiamenti nei requisiti costituiscono la norma, la questione è piuttosto come si intenda affrontare tale fatto.

Un atteggiamento è quello di considerare la modifica dei requisiti come la conseguenza di un'ingegneria dei requisiti di scarso valore. L'idea alla base dell'ingegneria dei requisiti è quella di ottenere un quadro completamente chiaro di essi prima di iniziare la realizzazione del software, di fare accettare tali requisiti al cliente, e poi di avviare delle procedure che limitino le modifiche ai requisiti dopo che questi sono stati accettati.

Un problema con questo approccio è che risulta già difficile cercare di comprendere le opzioni per i requisiti. Risulta ancora più difficile dal momento che la società di sviluppo generalmente non fornisce informazioni sui costi relativi ai requisiti. Alla fine si è in una situazione simile a chi desidera un tettuccio apribile sulla propria macchina, ma il concessionario non è in grado di dire se questo comporterà una spesa aggiuntiva al costo della macchina di 10 $ oppure di 10.000 $. Senza una chiara idea del costo, com'è possibile valutare se si desidera affrontare la spesa per quel tettuccio apribile?

Le stime sono difficili per varie ragioni. In parte ciò è dovuto al fatto che lo sviluppo del software è un'attività di progettazione, e quindi è difficile da pianificare e valutare nei costi. In parte al fatto che i materiali di base continuano a cambiare rapidamente. In parte al fatto che molto dipende dalle singole persone che sono coinvolte nello sviluppo, ed è difficile fare predizioni e quantificazioni sulle persone.

Entra in gioco inoltre la natura intangibile del software. E' molto difficile valutare il valore di una funzionalità del software sino a quando non la si usa direttamente. Soltanto quando si comincia ad utilizzare una versione preliminare di un qualche software ci si rende realmente conto quali siano le funzionalità utili e quali le parti che non lo sono.

Questo conduce ironicamente al punto di ritenere che i requisiti dovrebbero essere modificabili. Dopo tutto si suppone che il software sia soft. Quindi non solo i requisiti sono modificabili, ma dovrebbero esserlo. Richiede un notevole sforzo fare in modo che i clienti fissino i requisiti. E' anche peggio nel caso in cui essi stessi si siano sempre occupati di sviluppo di software, perché in tal caso sono "consapevoli" del fatto che è semplice modificare il software.

Ma anche se fosse possibile sistemare tutto ciò e poter realmente ottenere un insieme accurato e stabile di requisiti, probabilmente si sarebbe ancora in difficoltà. Nell'economia moderna le forze fondamentali del commercio cambiano il valore delle funzionalità del software troppo rapidamente. Ciò che potrebbe essere adesso un buon insieme di requisiti, non lo sarà più tra sei mesi. Anche se il cliente è in grado di fissare i requisiti, il mondo del lavoro non si fermerà per essi. E molti cambiamenti in esso sono completamente imprevedibili: chiunque affermi il contrario sta mentendo oppure ha già realizzato un miliardo di dollari nel mercato azionario.

Nello sviluppo del software qualsiasi cosa dipende dai requisiti. Se non si è in grado di avere dei requisiti stabili non è possibile ottenere una pianificazione prevedibile.

E' Impossibile la Prevedibilità?

In generale no. Ci sono alcuni casi di sviluppo del software nei quali la prevedibilità è possibile. Organizzazioni quali il gruppo di sviluppo del software per lo Space Shuttle della NASA sono un eccellente esempio di contesto in cui lo sviluppo del software può essere considerato prevedibile. Richiede una gran quantità di formalità, moltissimo tempo, un team numeroso e requisiti stabili. Si possono trovare progetti che sono analoghi a quello dello Space Shuttle. Comunque non ritengo che ci sia molto software aziendale che ricada in questa categoria. Per esso è richiesto un tipo di processo differente.

Uno fra i pericoli più grandi è quello di ritenere che sia possibile seguire un processo predittivo quando in realtà non lo è. Gli studiosi delle metodologie non sono molto abili nell'identificare le condizioni al contorno: le circostanze che fanno passare una metodologia dall'essere appropriata ad essere inappropriata. La maggior parte dei metodologisti pretende che la propria metodologia sia utilizzabile da tutti, così non comprende né pubblicizza le proprie condizioni al contorno. Questo porta le persone ad utilizzare una metodologia in circostanze sbagliate, ad esempio ad utilizzarne una predittiva in una situazione imprevedibile.

C'è una grande tentazione a fare questo. La predittività è una proprietà molto desiderabile. Però se si ritiene di poter essere predittivi quando invece non è possibile, si giunge a situazioni in cui si realizza un piano in anticipo e poi non si riesce a gestire adeguatamente la situazione quando il piano fallisce. Si osserva il piano e la realtà lentamente discostarsi. Per un lungo periodo si può pretendere che il piano sia ancora valido. Ma a un certo punto il distacco diviene troppo considerevole e il piano fallisce. Generalmente il fallimento è doloroso.

Quindi se ci si trova in situazioni che non sono prevedibili non è possibile utilizzare una metodologia predittiva. Questo è un duro colpo. Significa che molti dei modelli utilizzati per controllare i progetti, molti dei modelli per l'interazione completa con il cliente, non sono più validi. I benefici della predittività sono tanto grandi, è difficile rinunciarvi. Come accade in molti problemi, l'aspetto più difficile è semplicemente rendersi conto che vi è un problema.

Ad ogni modo rinunciare alla predittività non significa ricadere in un caos incontrollabile. Quello che serve è invece un processo che consenta un controllo sull'imprevedibilità. Questo è esattamente il significato dell'adattività.

Il Controllo di un Processo Non Predittivo - Le Iterazioni

In che modo quindi ci si controlla in un mondo non prevedibile? L'aspetto più importante, e tuttavia più difficile, è sapere esattamente dove ci si trova. Si ha bisogno di un meccanismo attendibile di feedback che possa accuratamente descrivere la situazione a intervalli frequenti.

Il modo per ottenere un tale feedback è rappresentato dallo sviluppo iterativo. Non si tratta di un'idea nuova. Lo sviluppo iterativo è stato presente per un certo periodo sotto diversi nomi: incrementale, evolutivo, staged, a spirale... una gran quantità di nomi. L'aspetto chiave dello sviluppo iterativo è quello di realizzare frequentemente versioni funzionanti del sistema finale che possiedano un sottoinsieme delle funzionalità richieste. Questi sistemi non hanno tutte le funzionalità, ma per il resto dovrebbero rispettare le richieste per il sistema finale. Dovrebbero essere completamente integrati e tanto attentamente testati quanto una versione finale.

Il punto è che non c'è niente di meglio che un sistema testato e integrato per rendere notevolmente più realistico un qualsiasi progetto. I documenti possono celare qualsiasi tipo di errore. Il codice non testato può nascondere una gran quantità di errori. E' solo quando ci si siede davanti ad un sistema e si lavora con esso che gli errori cominciano realmente ad emergere, sia in termini di malfunzionamenti che in termini di una cattiva comprensione dei requisiti.

Lo sviluppo iterativo ha senso anche nel contesto dei processi predittivi. Ma è essenziale in quelli adattivi, perché un processo adattivo deve essere in grado di affrontare le modifiche nelle funzionalità richieste. Questo porta ad un tipo di pianificazione con piani a lungo termine molto fluidi, mentre i piani stabili sono soltanto quelli a breve termine che sono relativi ad una singola iterazione. Lo sviluppo iterativo fornisce ad ogni iterazione un solido fondamento sul quale è possibile basare le successive pianificazioni.

A tale riguardo, un aspetto fondamentale concerne la durata di ogni iterazione. Si hanno diverse posizioni. La XP suggerisce di avere iterazioni comprese tra una e tre settimane. La metodologia SCRUM suggerisce la durata di un mese. Nella famiglia di metodologie Crystal si ha un ulteriore dilatazione dei tempi. La tendenza è comunque quella di rendere la durata di ciascuna iterazione la più piccola possibile. Questo consente di avere feedback più frequenti, così da valutare più spesso la situazione.

Il Cliente Adattivo

I processi adattivi richiedono una differente modalità di interazione con il cliente rispetto a quelli utilizzati più di frequente, in particolare nel caso in cui lo sviluppo venga effettuato da una diversa società. Quando si affida lo sviluppo del software ad un'altra società, la maggioranza dei clienti preferirebbe un contratto a prezzo fisso. Si forniscano agli sviluppatori le informazioni che vogliono, si richiedano i prezzi, se ne accetti uno e poi il resto è responsabilità della società che si occupa dello sviluppo del software.

Un contratto a prezzo fisso richiede requisiti stabili e quindi un processo predittivo. I processi adattivi e i requisiti instabili implicano che non sia possibile lavorare utilizzando l'usuale concetto di prezzo fisso. Cercare di adattare un modello a prezzo fisso ad un processo adattivo finisce per generare conseguenze molto dolorose. L'aspetto peggiore di queste conseguenze è che si ripercuotono sul cliente tanto quanto sulla società di sviluppo del software. Dopo tutto il cliente non vorrebbe del software se la sua attività non lo richiedesse. Se non gli viene consegnato la sua attività ne risente. Così anche se non deve pagare ulteriormente la compagnia di sviluppo, subisce ugualmente una perdita. Di fatto perde più di quanto pagherebbe per il software (perché altrimenti il cliente acquisterebbe del software se il valore che questo assume nella sua attività fosse minore della spesa?).

Così ci sono pericoli per entrambe le parti nel firmare un contratto a prezzo fisso in quei casi in cui un processo predittivo non può essere utilizzato. Questo vuol dire che il cliente deve operare diversamente.

Ciò non vuol dire che non sia possibile determinare a priori un budget per il software. Quello che significa è che non è possibile fissare il tempo, il prezzo e la quantità di lavoro da svolgere. L'approccio agile tradizionale consiste nel fissare il tempo e il prezzo, e di lasciare che la quantità di lavoro vari in modo controllato.

In un processo adattivo il cliente assume un controllo maggiormente dettagliato sul processo di sviluppo del software. Ad ogni iterazione ha la possibilità sia di controllare il progresso dello sviluppo del software che di alterarne la direzione. Questo crea una più stretta relazione con gli sviluppatori del software, una vera partnership. Un tale livello di interazione non si adatta ad ogni tipologia di cliente, e nemmeno ad ogni sviluppatore di software; ma è essenziale per fare funzionare adeguatamente un processo adattivo.

Tutto questo offre un certo numero di vantaggi per il cliente. Tanto per cominciare egli usufruisce di uno sviluppo del software molto più reattivo. Inoltre è possibile mandare molto presto in produzione un sistema utilizzabile, anche se minimale. Il cliente ne può quindi cambiare le capacità sulla base dei cambiamenti che avvengono nel contesto commerciale in cui opera, e anche sulla base dell'esperienza derivante dall'utilizzo diretto del sistema.

Della stessa importanza di ciò è la più accurata visione che si ottiene del reale stato del progetto. Il problema con i processi predittivi è che la qualità del progetto è misurata dalla conformità con la pianificazione. Questo rende difficile segnalare quando ci si scosta dalla pianificazione. Ciò che si ottiene comunemente è la constatazione di un grande errore nel programma di lavoro in uno stadio avanzato del progetto. In un progetto agile ad ogni iterazione si effettua una rielaborazione costante della pianificazione. Se vi sono dei problemi questi vengono rilevati in anticipo, quando c'è ancora tempo per fare qualcosa. Difatti questo controllo del rischio è un vantaggio fondamentale dello sviluppo iterativo. I metodi agili vanno oltre utilizzando iterazioni di piccola durata, ma anche considerando queste modifiche come delle opportunità.

Questo ha un'importante relazione con quello che costituisce un progetto di successo. Un progetto predittivo è spesso misurato attraverso la sua conformità con la pianificazione. Un progetto che rispetta tempi e costi è considerato un successo. Questo genere di misura è privo di senso in un contesto agile. Per chi segue l'approccio agile la questione fondamentale è relativa al valore assunto nei confronti dell'attività del cliente - il cliente ha ottenuto del software che ha per lui più valore di quanto ha speso per averlo? Un buon progetto predittivo procederà in accordo con la pianificazione, un buon progetto adattivo realizzerà qualcosa di differente e di migliore rispetto a quanto previsto dalla pianificazione originale.


Mettere l'Individuo in Primo Piano

Non è semplice eseguire un processo adattivo. In particolare è necessario un team di sviluppatori molto efficace. Il team deve essere efficace sia dal punto di vista delle qualità individuali, che del modo con cui i suoi membri riescono ad amalgamarsi. C'è anche un'interessante sinergia: non solo l'adattività richiede un team capace, ma anche gran parte degli sviluppatori preferisce un processo adattivo.

Unità di Programmazione Intercambiabili

Uno degli obbiettivi delle metodologie tradizionali è quello di sviluppare un processo in cui le persone che vi partecipano siano parti sostituibili. In un tale processo si possono considerare le persone come risorse che sono disponibili in varie tipologie. Si ha un analista, alcuni programmatori, alcuni addetti ai test, un manager. I singoli individui non sono molto importanti, solo i ruoli lo sono. Così se si pianifica un progetto non importa quale analista o quali addetti ai test si utilizzano, basta conoscere quanti se ne hanno per sapere in che modo il numero delle risorse influisce sulla pianificazione.

Ma questo fa nascere un interrogativo fondamentale: le persone coinvolte nello sviluppo del software sono veramente parti sostituibili? Una delle caratteristiche fondamentali dei metodi agili è il rifiuto di questa assunzione.

Probabilmente il rifiuto più esplicito all'idea delle persone come risorse è quello espresso da Alistair Cockburn. Nel suo articolo Characterizing People as Non-Linear, First-Order Components in Software Development avanza l'idea che i processi predittivi richiedono componenti che si comportino in modo prevedibile. Però le persone non rappresentano componenti prevedibili. Inoltre i suoi studi sui progetti software lo hanno condotto a concludere che le persone costituiscono il fattore più importante dello sviluppo del software.

«Nel titolo [-- del suo articolo], mi riferisco alle persone come "componenti". Questo è come le persone sono considerate nella letteratura relativa alla progettazione di processi/metodologie. L'errore di un tale approccio sta nel fatto che le "persone" sono in realtà altamente incostanti e non lineari, con modalità uniche di successo e fallimento. Quelle caratteristiche sono di primaria importanza, non trascurabili. L'incapacità dei progettisti di processi e metodologie di tenerne conto contribuisce al tipo di andamento di quei progetti non pianificati a cui così frequentemente assistiamo» -- [ Cockburn

Ci si può domandare se qui non sia la natura stessa dello sviluppo del software ad essere di ostacolo. Quando si programma un computer si controlla un dispositivo inerentemente prevedibile. Dal momento che operiamo in questo settore perché siamo in grado di farlo bene, siamo idealmente predisposti a fare confusione quando si tratta di avere a che fare con gli esseri umani.

Sebbene Cockburn sia il più esplicito, con la sua concezione di centralità dell'individuo nello sviluppo del software, il concetto di "individuo in primo piano" è un tema comune a molti studiosi nel settore del software. Il problema, troppo spesso, è che la metodologia si è opposta alla concezione degli individui come il fattore di primo ordine per il successo di un progetto.

Questo genera un forte feedback. Se ci si aspetta che tutti gli sviluppatori siano unità di programmazione intercambiabili, non si cerca di trattarli come individui. Questo influisce negativamente sul morale (e sulla produttività). Le persone competenti cercheranno un posto migliore dove andare e si finirà per restare con ciò che si desidera: unità di programmazione intercambiabili.

Stabilire che gli individui sono di primaria importanza è una grande decisione, una di quelle che per essere presa richiede una buona dose di determinazione. La concezione delle persone come risorse è profondamente radicata nel pensiero aziendale, poiché le sue radici risalgono all'impatto che ebbe l'approccio di Frederick Taylor all'organizzazione scientifica del lavoro. Nella direzione industriale questo approccio taylorista può avere un senso. Ma per un lavoro altamente creativo e professionale, quale ritengo sia lo sviluppo del software, questo non vale più (e infatti la produzione moderna si sta allontanando dal modello taylorista).

I Programmatori sono Professionisti Responsabili

Un aspetto fondamentale della concezione taylorista è che le persone che svolgono un lavoro non sono quelle che possono al meglio determinare come tale lavoro debba al meglio essere svolto. In un industria questo può risultare vero per varie ragioni. In parte perché i lavoratori di molte industrie non sono le persone più intelligenti e creative, in parte perché vi è una certa tensione fra il management e i lavoratori dovuta al fatto che il management realizza guadagni superiori nel caso in cui i lavoratori ne realizzano meno.

La storia recente ci dimostra sempre più quanto questo risulti essere falso per lo sviluppo del software. Persone sempre più brillanti e capaci sono attratte dallo sviluppo del software, attratte sia dalla sua ribalta che da guadagni potenzialmente grandi (entrambe queste cose hanno attratto anche me dal settore dell'ingegneria elettronica). Sistemi quali le stock options allineano sempre più gli interessi dei programmatori a quelli della compagnia.

(Ci può anche essere un effetto generazionale in tutto questo. Quanto viene riportato da alcuni aneddoti mi spinge a domandarmi se non sia più o meno negli ultimi dieci anni che siano approdate nel settore dell'ingegneria del software le persone più brillanti. Se così, questo spiegherebbe come mai ci sia un tale culto della gioventù nel settore dei computer; come accade con la maggior parte dei culti, ci deve essere in esso un briciolo di verità).

Quando si vuole assumere e trattenere persone capaci, si deve riconoscere che sono professionisti responsabili. In quanto tali essi sono le persone migliori per decidere le modalità di svolgimento del proprio lavoro. La concezione taylorista di un dipartimento separato per la pianificazione, che decide come debba essere svolto il lavoro, funziona soltanto nel caso in cui i pianificatori comprendono come il lavoro debba essere eseguito meglio di quelli che di fatto lo svolgono. Se si hanno lavoratori brillanti e motivati questo non è più valido.

La Direzione di un Processo Orientato all'Individuo

L'orientamento all'individuo si manifesta in molti modi differenti nei processi agili e produce diversi effetti, non tutti consistenti.

Un elemento fondamentale è quello di accettare un processo piuttosto che imporlo. Spesso i processi software sono imposti dalla dirigenza. In quanto tali provocano spesso resistenze, in particolare quando i dirigenti sono assenti dallo sviluppo attivo del software da molto tempo. L'accettazione di un processo rappresenta un impegno, e come tale necessita del coinvolgimento attivo di tutto il team.

Ciò conduce all'interessante conseguenza che soltanto gli sviluppatori possono scegliere di seguire un processo adattivo. Questo risulta essere particolarmente vero nel caso della XP, la cui adozione richiede una notevole dose di disciplina. E questo è il caso in cui Crystal [NdT: la famiglia di metodologie denominata Crystal] risulta essere un complemento decisamente effettivo, dal momento che si propone di essere minimamente disciplinata.

Un altro aspetto riguarda il fatto che gli sviluppatori devono essere in grado di prendere tutte le decisioni tecniche. La XP accentua notevolmente questo fatto stabilendo nel suo processo di pianificazione che soltanto gli sviluppatori possono fare previsioni sul tempo richiesto per svolgere un determinato compito.

La presenza di una tale leadership tecnica rappresenta un grande cambiamento per molte persone che rivestono cariche dirigenziali. Un simile approccio richiede una condivisione di responsabilità, dal momento che gli sviluppatori e la dirigenza assumono un uguale peso nella guida del progetto. Si noti che ho detto uguale. La dirigenza svolge ancora un ruolo, ma riconosce la competenza degli sviluppatori.

Una motivazione importante per tutto ciò è il ritmo di cambiamento della tecnologia nella nostra industria. Dopo pochi anni le conoscenze tecniche diventano obsolete. Questa vita media delle competenze tecniche non ha uguale in nessun altro tipo di industria. Persino i tecnici riconoscono che il passaggio alla dirigenza comporta un rapido deperimento delle loro conoscenze tecniche. Gli ex sviluppatori devono riconoscere che le proprie competenze tecniche scompariranno rapidamente e che devono confidare e affidarsi agli sviluppatori di adesso.

La Difficoltà di Effettuare Misure

Se si ha un processo in cui le persone che stabiliscono le modalità di lavoro sono differenti da quelle che di fatto lo svolgono, i capi necessitano di un qualche sistema per misurare l'efficienza dei lavoratori. Nell'organizzazione scientifica del lavoro c'era una forte spinta a sviluppare approcci oggettivi per misurare il rendimento delle persone.

Tenere presente questo è particolarmente importante quando ci si riferisce al software, data la difficoltà di effettuare misure sul software. A dispetto dei nostri sforzi migliori, non siamo in grado di misurare neanche gli aspetti più semplici riguardanti il software, quali la produttività. Senza delle misure accurate per questi aspetti, ogni tipo di controllo esterno è destinato a fallire.

L'introduzione di una gestione basata sulle misure senza disporre di buone misure presenta i propri problemi. Robert Austin ha discusso questo aspetto in modo eccellente. Egli sottolinea che quando si misurano le prestazioni si devono sottoporre a misura tutti i fattori rilevanti. Se si omette una qualsiasi cosa si ottiene come inevitabile conseguenza che i lavoratori altereranno la propria modalità di lavoro pur di far rilevare le misure migliori, anche se così facendo riducono la reale efficacia del proprio lavoro. Questa alterazione delle misure rappresenta il tallone di Achille della gestione basata sulle misure.

La conclusione di Austin è che si debba scegliere tra una gestione basata sulle misure ed una basata sulla delega (secondo la quale i lavoratori decidono come svolgere il proprio lavoro). La gestione basata sulle misure è più adatta ai lavori semplici e ripetitivi, con un bassi requisiti di conoscenza e con risultati misurabili - esattamente l'opposto di come risulta essere lo sviluppo del software.

L'aspetto fondamentale messo in rilievo da tutto ciò è che i metodi tradizionali hanno operato sotto l'ipotesi che la modalità più efficiente di gestione sia quella basata sulle misure. La comunità agile riconosce che lo sviluppo del software possiede delle caratteristiche tali che una gestione basata sulle misure porta a livelli molto alti di alterazione delle misure stesse. E' di fatto più efficiente utilizzare uno stile di gestione basato sulla delega, che è proprio il tipo di approccio che è al centro del punto di vista agile.

Il Ruolo della Leadership Aziendale

Il personale tecnico non può però svolgere l'intero processo da solo. Ha bisogno di consulenza sulle necessità aziendali. Questo conduce ad un altro importante aspetto dei processi adattivi: necessitano di uno stretto contatto con gli esperti aziendali.

Questo va al di là del coinvolgimento del ruolo dell'azienda che si ha nella maggior parte dei progetti. I team agili non possono esistere sulla base di una comunicazione occasionale. Necessitano di interagire continuamente con gli esperti aziendali. Inoltre una tale interazione non è qualcosa che si attua ad un livello dirigenziale, è invece qualcosa che è presente per ogni sviluppatore. Poiché gli sviluppatori sono dei professionisti capaci all'interno della propria disciplina, devono poter lavorare alla pari con gli altri professionisti in altre discipline.

Naturalmente gran parte di ciò è richiesto dalla natura adattiva dello sviluppo. Poiché la premessa fondamentale dello sviluppo adattivo è che le cose cambiano velocemente, si ha bisogno di continui contatti per informare tutti dei cambiamenti.

Non c'è niente di più frustrante per uno sviluppatore che vedere sprecato il proprio duro lavoro. E' quindi importante garantire che gli sviluppatori possano avere la disponibilità di esperti aziendali che siano di qualità sufficientemente buona da risultare affidabili.


Il Processo Autoadattivo

Finora ho parlato di adattività relativamente ad un progetto che adatta frequentemente il proprio software al fine di soddisfare i requisiti mutevoli del proprio cliente. Vi è comunque un altro aspetto dell'adattività: quello del processo che cambia nel tempo. Un progetto che comincia seguendo un processo adattivo non necessiterà del medesimo processo dopo un anno. Col passare del tempo il team scoprirà ciò che per lui risulta funzionare e modificherà il processo di conseguenza.

La prima parte dell'autoadattività consiste in regolari revisioni del processo. Generalmente queste vengono effettuale ad ogni iterazione. Al termine di ogni iterazione si organizzi una breve riunione e ci si pongano le seguenti domande (estratte dal lavoro di Norm Kerth):

Tali domande apporteranno idee utili per modificare il processo per l'iterazione successiva. In questo modo un processo che comincia con dei problemi può migliorare di pari passo all'avanzamento del progetto, adattandosi meglio al team che lo utilizza.

Se l'autoadattività si manifesta all'interno di un progetto, è ancora più evidente all'interno di un'organizzazione. Per accentuare il processo di autoadattività io suggerisco ai team di effettuare una revisione più formale e le principali tappe del progetto seguendo le sessioni retrospettive del progetto descritte da Norm Kerth. Queste retrospettive prevedono una riunione esterna di 2-3 giorni e un facilitator esperto. Esse non solo rappresentano un momento di formazione per il team, ma forniscono anche insegnamenti all'intera organizzazione.

Una conseguenza dell'autoadattività è che non ci si dovrebbe mai aspettare di trovare un'unica metodologia aziendale. Invece ciascun team dovrebbe non solo scegliere il proprio processo, ma dovrebbe anche attivamente adattarlo durante l'avanzamento del progetto. Mentre sia i processi pubblicati che l'esperienza acquisita con altri progetti possono agire come ispirazione e fondamento, la responsabilità professionale degli sviluppatori è quella di adattare il processo al compito del momento.

L'autoadattività è maggiormente evidente nell'ASD e in Crystal. Le rigide regole della XP sembrano non consentirla, ma è soltanto un'impressione superficiale poiché la XP incoraggia ad adattare il processo. La principale differenza con la XP consiste nel fatto che i suoi sostenitori suggeriscono di seguirne la formulazione tradizionale per parecchie iterazioni prima di adattarla. Inoltre le revisioni non sono né enfatizzate né parte del processo, sebbene alcuni suggeriscono che le revisioni dovrebbero entrare a far parte delle pratiche della XP.


Le Metodologie

Sono molte le metodologie che si possono comprendere sotto la bandiera dello sviluppo agile. Nonostante tutte condividano molte caratteristiche, vi sono anche alcune differenze significative. Non posso evidenziare tutti i punti in questo breve resoconto, ma posso almeno indicare alcune referenze. Non posso neanche parlare con significativa esperienza della maggior parte di esse. Ho lavorato molto soprattutto sulla base della XP e ho visto il RUP sotto diverse forme, ma la mia conoscenza di gran parte delle rimanenti metodologie si riferisce soltanto a ciò che ho potuto leggere.

XP (Extreme Programming)

Di tutte le metodologie agili, questa è quella che ha ottenuto la maggiore attenzione. Ciò è in parte dovuto al ragguardevole carisma dei suoi leader, in particolare di Kent Beck. Ma è anche dovuto all'abilità di Kent Beck di attirare le persone verso questo approccio e di assumere al suo interno un ruolo di primo piano. In un certo senso, comunque, la popolarità della XP è divenuta un problema, dal momento che ha offuscato le altre metodologie e le loro valide idee.

Le radici della XP giacciono all'interno della comunità dello Smalltalk, e in particolare nella stretta collaborazione tra Kent Beck e Ward Cunningham alla fine degli anni '80. Entrambi raffinarono le proprie pratiche su numerosi progetti nei primi anni '90, estendendo le proprie idee di un approccio allo sviluppo del software adattivo e orientato all'individuo.

Il passo cruciale da una pratica informale a una metodologia fu compiuto nella primavera del 1996. A Kent fu chiesto di esaminare l'andamento del progetto della Crysler denominato C3. Il progetto veniva realizzato in Smalltalk da una compagnia contraente, e stava incontrando dei problemi. A causa della scarsa qualità del codice, Kent raccomandò di eliminare tutto il codice e di ricominciare da capo. Il progetto allora ricominciò sotto la sua guida e da quel momento divenne il primo esempio autorevole e il primo ambiente di formazione per la XP.

La prima fase del progetto C3 ebbe molto successo e prese vita all'inizio del 1997. Il progetto poi continuò e successivamente incontrò dei problemi, che ne portarono all'interruzione nel 1999 (il che, se non altro, prova che la XP non è garanzia di successo).

Al cuore della XP ci sono quattro valori: la Comunicazione, il Feedback, la Semplicità e il Coraggio. Sono poi introdotte una dozzina di pratiche che i progetti XP dovrebbero seguire. Molte di queste pratiche sono tecniche di vecchia data, sperimentate e collaudate, sebbene spesso dimenticate da molti, compresa la maggior parte dei processi utilizzati di solito. Oltre a farle risorgere, la XP le imbastisce in un complesso sinergico, nel quale ciascuna di esse viene rinforzata dalle altre.

Una delle più straordinarie, quanto per me inizialmente affascinante, è la forte enfasi sul testing. Sebbene tutti i processi menzionino il testing, la maggior parte di essi lo fa con una scarsa enfasi. Invece la XP pone il testing come fondamento dello sviluppo, con ciascun programmatore che scrive i test parallelamente al codice richiesto per la produzione. I test sono integrati in un processo di integrazione continua e di costruzione, il che porta ad ottenere una piattaforma altamente stabile per lo sviluppo futuro.

Su questa piattaforma la XP realizza un processo di design evolutivo, che ad ogni iterazione si fonda sul refactoring di un semplice sistema di base. Tutto il design è focalizzato attorno all'iterazione corrente, senza che nessun tipo di design venga anticipato per future necessità. Il risultato è un processo di design che è disciplinato, ma sensazionale, che combina disciplina con adattività in un modo che rende la XP la metodologia adattiva meglio sviluppata.

Vi sono numerose autorità in materia di XP, molte delle quali provenienti dal progetto C3. Di conseguenza vi è una gran quantità di fonti di ulteriori informazioni. Kent Beck ha scritto Extreme Programming Explained, il manifesto fondamentale della XP, che spiega le ragioni alla base della metodologia, della quale fornisce un quadro sufficiente per comprendere se si è interessati a seguirla ulteriormente. Negli ultimi due anni si è assistito ad una grande diffusione di libri brillantemente colorati sulla XP, la maggior parte dei quali sono piuttosto simili tra loro in quanto descrivono l'intero processo dal punto di vista di alcuni dei suoi primi utilizzatori.

Oltre ai libri, c'è anche una discreta quantità di risorse sul web. Per trovare un approccio più strutturato alla XP è meglio cominciare dai siti di due alunni del progetto C3: xProgramming.com, di Ron Jeffries, ed extremeProgramming.org, di Don Wells. Gran parte dell'iniziale promozione e sviluppo delle idee della XP è avvenuta nell'ambiente di scrittura collaborativa sul web wiki di Ward Cunningham. Il wiki rimane un posto affascinante da scoprire, sebbene si rischi di essere inghiottiti dalla sua natura dispersiva. Vi è anche un attivo,e spesso interessante, gruppo di discussione sulla XP. Uno dei più interessanti punti di vista "esterni" sulla XP è quello di Mark Paulk, uno dei leader della comunità CMM - il suo articolo esamina la XP dalla prospettiva del CMM.

Crystal -- La Famiglia di Metodologie di Cockburn

Alistair Cockburn lavora sulle metodologie da quando fu incaricato, nei primi anni '90, di ideare e documentare la metodologia dell'IBM. Il suo approccio è però differente da quello di gran parte degli altri studiosi di metodologie. Invece di basarsi soltanto sulla propria esperienza personale per costruire una teoria su come le cose dovrebbero essere fatte, integra la propria esperienza diretta cercando attivamente di esaminare i progetti per rendersi conto della qualità del loro funzionamento. Egli inoltre non teme di dover cambiare i propri punti di vista sulla base delle proprie scoperte: tutto ciò lo rende il mio studioso di metodologie preferito.

Il suo libro, Surviving Object-Oriented Projects, rappresenta la sua prima indicazione sulla direzione dei progetti, e rimane il mio libro numero uno di istruzioni per la direzione dei progetti iterativi. Più di recente Alistair ha scritto un libro che descrive lo sviluppo agile del software e che esamina i principi di base di questo genere di metodologie.

Dopo quel libro ha esplorato ulteriormente i metodi agili, proponendo la famiglia di metodologie denominata Crystal. E' una famiglia perché lui ritiene che differenti tipologie di progetti richiedano differenti tipologie di metodologie. Egli considera questa variazione secondo due assi: il numero di persone coinvolte nel progetto e il tipo di conseguenze che possono avere gli errori. Ciascuna metodologia ricade in una differente parte di tale diagramma; così un progetto con 40 persone per il quale un errore può causare la perdita di una quantità discrezionale di denaro richiederà una metodologia differente rispetto ad uno con 6 persone e per il quale un errore può essere pagato in termini di vite umane.

Le metodologie della famiglia Crystal condividono con la XP l'orientamento all'individuo, ma un tale atteggiamento si manifesta in termini differenti. Alistair ritiene che per le persone risulti difficile seguire un processo disciplinato, così, invece di seguire la grande disciplina della XP, Alistair esamina le metodologie meno disciplinate che possono però ancora funzionare, coscientemente rinunciando alla produttività in favore della facilità di esecuzione. Egli così ritiene che sebbene le metodologie della famiglia Crystal siano meno produttive della XP, un maggior numero di persone sarà in grado di seguirle.

Alistair inoltre dà grande importanza alle revisioni alla fine di ciascuna iterazione, incoraggiando così il processo ad automigliorarsi. Egli afferma che lo sviluppo iterativo ha lo scopo di far rilevare prima i problemi e di consentire quindi di correggerli. Questo pone una maggiore enfasi sul monitoraggio del processo e sul suo adattamento durante lo sviluppo.

Open Source

Si può rimanere sorpresi da questa intestazione. Dopo tutto l'open source è una tipologia di software, non proprio un processo. Comunque vi è una determinata modalità di lavoro all'interno della comunità open source, e gran parte di questo approccio è applicabile ai progetti tradizionali quanto lo è a quelli open source. Un tale processo è in particolare strettamente collegato a team che sono fisicamente distribuiti, aspetto importante da rilevare perché la maggior parte dei processi adattivi pone l'accento su team concentrati in un unico luogo.

La maggior parte dei progetti open source possiede uno o più responsabili della propria manutenzione. Il responsabile è l'unica persona alla quale è consentito effettuare materialmente una modifica al codice sorgente ufficiale. Comunque altre persone, oltre a lui, possono effettuare modifiche al codice. La differenza fondamentale consiste nel fatto che esse devono inviare le proprie modifiche al responsabile, il quale le esamina e le apporta al codice. Generalmente tali modifiche vengono fatte nella forma di patch file, il che rende questo procedimento più facile. Il responsabile ha così il compito di coordinare tali file e di mantenere la coesione nel design del software.

Progetti differenti concepiscono il ruolo del responsabile della manutenzione in modo differente. Alcuni hanno un unico responsabile per l'intero progetto, altri sono divisi in moduli e possiedono un responsabile per ogni modulo, altri alternano responsabili differenti, altri possiedono vari responsabili per lo stesso codice, altri risultano essere una combinazione di tutto ciò. Gran parte dei partecipanti ad un progetto open source sono part time, quindi sorge la questione di quanto sia possibile coordinare bene un tale team in un progetto a tempo pieno.

Una caratteristica particolare dello sviluppo open source è che il debugging risulta essere altamente parallelizzabile. Molte persone possono essere coinvolte in una tale attività. Quando incontrano un bug possono inviare la correzione al responsabile. Questo è un buon ruolo per chi non è un responsabile della manutenzione, dal momento che gran parte del tempo viene trascorso a cercare i bug. E' inoltre buono per chi non possiede una spiccata competenza di progettazione.

Il processo caratteristico dell'open source non è stato sino ad ora adeguatamente documentato. L'articolo più famoso è quello di Eric Raymond, The Cathedral and the Bazar, che sebbene sia un'eccellente descrizione risulta essere piuttosto breve. Il libro di Karl Fogel relativo al codice del CVS [N.d.T.: Concurrent Versions System] contiene anche alcuni validi capitoli riguardanti il processo dell'open source, che potrebbero essere interessanti anche per coloro che non hanno alcuna intenzione di effettuare aggiornamenti tramite il CVS.

Adaptive Software Development di Highsmith

Jim Highsmith ha trascorso molti anni lavorando con le metodologie predittive. Le ha sviluppate, installate, insegnate ed è arrivato alla conclusione che sono profondamente problematiche, in particolare per le aziende moderne.

Il suo recente libro si concentra sulla natura adattiva delle nuove metodologie, dando particolare enfasi all'applicazione delle idee originate nel contesto dei sistemi complessi adattivi (generalmente indicato col termine di Teoria del Caos). Non fornisce il tipo di pratiche dettagliate offerte dalla XP, ma fornisce la base fondamentale per comprendere la ragione dell'importanza dello sviluppo adattivo e le sue conseguenze ai più profondi livelli organizzativi e dirigenziali.

Al cuore dell'ASD vi sono tre fasi non lineari e che si intersecano: la speculazione, la collaborazione e l'apprendimento.

Highsmith considera la pianificazione in un ambiente adattivo come un paradosso, dal momento che gli sviluppi sono naturalmente imprevedibili. Nella pianificazione tradizionale le deviazioni dai piani sono considerate degli errori che dovrebbero essere corretti. In un ambiente adattivo, invece, le deviazioni ci guidano verso la soluzione corretta.

In questo ambiente imprevedibile le persone devono collaborare in modo completo per poter affrontare l'imprevedibilità. La preoccupazione della dirigenza è meno rivolta a dire alle persone cosa fare ed è più attenta a favorire la comunicazione, così che le persone possono pervenire da sole a soluzioni creative.

In un ambiente predittivo l'apprendimento è spesso scoraggiato. Si prendono decisioni in anticipo e quindi si segue quel progetto.

«In un ambiente adattivo l'apprendimento coinvolge tutte le parti in causa - gli sviluppatori e i loro clienti - al fine di valutare le loro assunzioni e di utilizzare i risultati di ogni ciclo di sviluppo per adattare il successivo» -- [Highsmith]

In quanto tale, l'apprendimento è una caratteristica continua e importante, che assume che i piani e i progetti debbano cambiare con il procedere dello sviluppo.

«Il beneficio più importante, potente, inseparabile, predominante del Ciclo di Vita dello Sviluppo Adattivo sta nel fatto che ci costringe ad affrontare i modelli che sono alla base delle nostre illusioni. Ci costringe a valutare in modo più realistico le nostre capacità» -- [Highsmith]

Con tale enfasi, il lavoro di Highsmith si concentra direttamente sulle parti difficili dello sviluppo adattivo, in particolare su come favorire la collaborazione e l'apprendimento all'interno del progetto. In tal modo il suo libro aiuta a fornire idee per far sviluppare questi "deboli" aspetti, il che costituisce un buon complemento agli approcci basati su pratiche consolidate, quali la XP, il FDD e Crystal.

Scrum

Scrum è stato presente per qualche tempo nei circoli interessati all'Orientamento agli Oggetti, sebbene debba confessare che non sono molto al corrente della sua storia o sviluppo. Anch'esso si concentra sul fatto che processi definiti e ripetibili funzionano soltanto per affrontare problemi definiti e ripetibili, con persone definite e ripetibili, in ambienti definiti e ripetibili.

Scrum divide un progetto in iterazioni (che vengono chiamate sprint) di 30 giorni ciascuna. Prima di iniziare uno sprint si determina la funzionalità da assegnare ad esso e poi si lascia al team il compito di realizzarla. Il punto è quello di stabilizzare i requisiti durante la durata dello sprint.

La dirigenza però non viene estromessa durante lo svolgimento di uno sprint. Ogni giorno il team tiene una breve riunione (di circa 15 minuti), denominata scrum, in cui viene presentato ciò che sarà eseguito il giorno successivo. In particolare vengono messi in rilievo alla dirigenza gli ostacoli: impedimenti che si stanno incontrando e che la dirigenza deve risolvere. Inoltre viene riferito cosa si sta facendo, di modo che la dirigenza può avere un quadro aggiornato quotidianamente sullo stato del progetto.

La letteratura su Scrum si concentra principalmente sul processo iterativo di pianificazione e di tracking. E' molto vicina alle altre metodologie agili e dovrebbe funzionare bene con le pratiche di programmazione della XP.

Dopo la mancanza per un lungo periodo di tempo di un testo di riferimento, alla fine Ken Schwaber e Mike Beedle hanno scritto il primo libro su Scrum. Ken Schwaber ha anche realizzato ControlChaos.com che probabilmente costituisce la migliore descrizione di Scrum. Jeff Sutherland ha un attivo sito web relativo alla tecnologia ad oggetti che include anche una sezione su Scrum. Una buona descrizione delle pratiche di Scrum può anche essere trovata nel libro PLoPD 4. Scrum possiede un gruppo di discussione su Yahoo.

Feature Driven Development

Il Feature Driven Development (FDD) è stato sviluppato da Jeff De Luca e da un guru di vecchia data dell'OO, Peter Coad. Al pari delle altre metodologie adattive, si concentra su brevi iterazioni che realizzano una funzionalità evidente. Nel caso del FDD le iterazioni hanno durata di due settimane.

Il FDD possiede cinque processi. I primi tre vengono eseguiti all'inizio del progetto:

Gli ultimi due sono eseguiti all'interno di ciascuna iterazione:

Ciascun processo è suddiviso in compiti e gli vengono attribuiti dei criteri di verifica.

Gli sviluppatori appartengono a due categorie: i responsabili delle classi e i capi programmatore. Questi ultimi rappresentano gli sviluppatori con maggiore esperienza. A loro vengono assegnate le funzionalità da realizzare. Comunque non le realizzano da soli. Invece il capo programmatore determina quali classi sono coinvolte nell'implementazione della funzionalità in esame e ne riunisce i rispettivi responsabili per formare un team di sviluppo ad essa relativo. Il capo programmatore agisce come coordinatore, capo progetto e consulente, mentre i responsabili delle classi scrivono gran parte del codice relativo alla funzionalità in esame.

Sino a poco tempo fa la documentazione sul FDD era molto scarsa. Alla fine è stato pubblicato un intero libro su questa metodologia. Jeff De Luca, l'ideatore principale di essa, adesso ha un portale sul FDD contenente articoli, blog e forum di discussione. La descrizione originale della metodologia compare nel libro di Peter Coad et al. UML in Color. La sua compagnia, TogetherSoft, esegue anche consulenza e formazione sul FDD.

DSDM (Dynamic System Development Method)

Il DSDM nacque in Gran Bretagna nel 1994 come un consorzio di compagnie britanniche che desideravano realizzare software sulla base del RAD e dello sviluppo iterativo. Partito con 17 fondatori, adesso vanta più di un migliaio di membri e si è diffuso al di fuori delle proprie radici britanniche. Essendo stato sviluppato da un consorzio, possiede caratteristiche diverse dagli altri metodi agili. Possiede un'organizzazione a tempo pieno che lo supporta per mezzo di manuali, corsi di formazione, programmi di certificazione e così via. Risulta anche avere un certo prezzo, la qual cosa ha limitato la mia indagine sulla metodologia. Jennifer Stapleton ha comunque scritto un libro che ne fornisce una descrizione.

L'utilizzo del metodo inizia attraverso uno studio di fattibilità e uno studio commerciale. Lo studio di fattibilità valuta se il DSDM è appropriato per il progetto in esame. Lo studio commerciale consiste di una serie di seminari volti a comprendere il settore commerciale dove lo sviluppo viene effettuato. Si perviene inoltre ad un'architettura sommaria del sistema e ad un piano per il progetto.

Il resto del processo è costituito da tre cicli intrecciati: il ciclo del modello funzionale produce la documentazione di analisi e i prototipi, il ciclo di design e realizzazione ingegnerizza il sistema per l'utilizzo operativo, e il ciclo di implementazione tratta il deployment per l'utilizzo operativo.

Il DSDM possiede dei principi di base che includono l'interazione attiva del cliente, frequenti consegne, team autonomi, testing durante tutto il ciclo. Al pari degli altri metodi agili, si effettuano cicli di breve durata, compresi tra le due e le sei settimane. Viene data enfasi all'elevata qualità e all'adattività nei riguardi del cambiamento dei requisiti.

Non possiedo grande evidenza del suo utilizzo al di fuori del Regno Unito, ma il DSDM è degno di nota per possedere gran parte dell'infrastruttura propria delle metodologie tradizionali più mature, pur seguendo nel contempo i principi dell'approccio proprio dei metodi agili. Sembra lecito porsi l'interrogativo se le sue varie componenti incoraggino un approccio più orientato al processo e più formalità di quanto io non gradisca.

Il Manifesto per lo Sviluppo Agile del Software

Con così tante somiglianze tra questi metodi, c'era un ragionevole interesse verso una qualche forma di collaborazione. Così rappresentanti di ciascuna di queste metodologie furono invitati ad un convegno di due giorni a Snowbird, nello Utah, nel Febbraio 2001. Vi partecipai, senza avere molte aspettative. Dopo tutto quando si raccolgono in una stanza degli studiosi di metodologie, il meglio che si possa sperare di ottenere è generalmente una certa dose di buone maniere.

Rimasi sorpreso dai risultati. Ciascuno era consapevole del fatto che vi erano una gran quantità di aspetti comuni, e queste similitudini erano molto più grandi delle differenze tra i processi. Così, al pari di alcune utili prese di contatto tra i leader dei vari processi, emerse anche l'idea di emettere una dichiarazione congiunta - una sorta di chiamata alle armi in favore di processi software maggiormente agili (si concordò inoltre sull'utilizzo del termine "agile" per indicare le nostre idee comuni).

Ciò che è risultato è il Manifesto dello Sviluppo Agile del Software, una dichiarazione sui valori e sui principi comuni ai processi agili. Vi è anche il desiderio di collaborare ancora in futuro, per incoraggiare ulteriormente sia i tecnici che i responsabili aziendali ad utilizzare e richiedere approcci agili allo sviluppo del software. Vi è un articolo sul Software Development Magazine che spiega e commenta il manifesto.

Il manifesto era proprio questo, una pubblicazione che voleva chiamare a raccolta coloro che condividevano queste idee di base. Uno dei frutti di una tale azione è stata la creazione di un'entità più longeva, l'Alleanza Agile. L'Alleanza Agile è un'organizzazione no-profit che si propone di promuovere la conoscenza e la discussione su tutti i metodi agili. Molti dei leader dei metodi agili che ho qui menzionato sono membri e leader dell'Alleanza Agile.

Context Driven Testing

Sin dall'inizio sono stati gli sviluppatori del software a guidare la comunità agile. Comunque molte altre persone sono coinvolte nello sviluppo del software e sono interessate da questo nuovo movimento. Una di queste categorie è ovviamente quella degli addetti ai test, che spesso vivono in un mondo fortemente costretto da un modo di pensare rivolto verso l'approccio a cascata. Con l'attitudine comune di considerare il ruolo del testing come quello di garantire la conformità del software a delle specifiche scritte a priori, il ruolo degli addetti ai test è tutt'altro che chiaro in un contesto agile.

Da quello che risulta, molti fra quelli che si occupano di testing hanno criticato per un certo periodo buona parte dell'approccio tradizionale al testing. Questo ha condotto ad un movimento conosciuto come Context Driven Testing. La sua migliore descrizione è rappresentata dal libro Lessons Learned in Software Testing. Questa comunità è anche molto attiva sul web; si dia uno sguardo ai siti di Brian Marick (uno degli autori del Manifesto Agile), Brett Pettichord, James Bach e Cem Kaner.

RUP: un Metodo Agile?

Ogni volta che si comincia a discutere di metodologie nella comunità OO, inevitabilmente si giunge al ruolo del Rational Unified Process. Il Processo Unificato fu sviluppato da Philippe Kruchten, Ivar Jacobson e da altri alla Rational, come il complemento sul lato del processo all'UML. Il RUP è un framework per processi e in quanto tale può comprendere una grande varietà di processi. Questa è appunto la mia principale critica al RUP - dal momento che può essere tutto finisce per non essere niente. Preferisco un processo che stabilisca cosa fare piuttosto che fornire una lista infinita di opzioni.

In conseguenza a questa sua natura di framework di processi, il RUP può essere utilizzato secondo il tradizionale approccio a cascata oppure secondo una modalità agile. Quindi dal RUP si può ottenere un processo agile oppure un processo pesante - tutto dipende da come lo si configura per il contesto in cui ci si trova.

Craig Larman è un deciso sostenitore dell'utilizzo del RUP in modo agile. Il suo eccellente libro di introduzione allo sviluppo OO contiene un processo che è considerevolmente influenzato dalla sua concezione agile del RUP. Egli ritiene che la recente spinta verso i metodi agili altro non è che l'accettazione del metodo di sviluppo OO predominante, che è stato poi sintetizzato come RUP. Una delle cose che fa Craig è quella di trascorrere assieme all'intero team i primi due o tre giorni di un'iterazione della durata di un mese, utilizzando l'UML per delineare il design relativo al lavoro che deve essere svolto durante quella iterazione. Questo non costituisce un progetto dal quale non ci si possa discostare, ma è piuttosto un abbozzo che fornisce una prospettiva su come le cose debbano essere svolte nel corso dell'iterazione.

Un'altra preferenza per il RUP agile è rappresentata dal processo dX di Robert Martin. Il processo dX è una versione del RUP ad esso completamente conforme, che risulta proprio coincidere con la XP (si osservi fra l'altro cosa si ottiene capovolgendo la scritta dX...). dX è progettato per chi deve utilizzare il RUP, ma desidera seguire la XP. In quanto tale è sia XP che RUP, e quindi un buon esempio dell'utilizzo agile del RUP.

A mio giudizio, una delle cose fondamentali che devono accadere riguardo al RUP è che i suoi leader operanti nell'industria enfatizzino il proprio approccio allo sviluppo del software. Più di una volta mi è capitato di incontrare persone che utilizzano il RUP e che lavorano secondo un approccio a cascata. Grazie ai miei contatti nel mondo dell'industria, so che Philippe Kruchten e il suo team sono convinti sostenitori dello sviluppo iterativo. Chiarificare questi principi e incoraggiare l'utilizzo di istanze agili del RUP, quali sono i lavori di Craig e di Robert, avrà un importante impatto.

Ulteriori Riferimenti

Recentemente sono usciti due buoni libri che si occupano del vasto argomento dei metodi agili: quello di Alistair Cockburn e quello di Jim Highsmith.

C'è un certo numero di altri articoli e discussioni sul tema dei metodi agili. Sebbene alcuni di essi possono non essere delle metodologie complete, offrono comunque degli approfondimenti su questo crescente filone.

La serie di conferenze Patterns Language of Programming ha spesso ospitato materiale che riguarda questo argomento, se non altro perché molte delle persone interessate ai pattern sono anche interessate ai metodi più adattivi e più rivolti all'individuo. Un primo autorevole articolo è stato quello di Jim Coplien, pubblicato in PLoP1. Il linguaggio di pattern Episodes di Ward Cunningham è contenuto in PLoP2. Jim Coplien attualmente gestisce il sito OrgPatterns, un wiki che raccoglie pattern organizzativi.

Dirk Riehle inviò un articolo alla conferenza XP2000, che presenta una comparazione tra il sistema dei valori della XP e quello dell'Adaptive Software Development. L'edizione di Febbraio 2002 della Coad Letter compara la XP al FDD. L'edizione di Luglio di IEEE Software comprende vari articoli sulla "Diversità tra i processi", che accenna a queste metodologie.

Mary Poppendieck ha scritto un articolo affascinante che compara le metodologie agili alla Produzione Snella [N.d.T.: in inglese "lean manufacturing"].


L'Approccio Agile fa per Te?

L'utilizzo di un metodo agile non è per tutti. Ci sono diverse cose da tenere a mente se si decide di seguire questo approccio. Comunque ritengo certamente che queste nuove metodologie siano ampliamente applicabili e dovrebbero essere utilizzate da più persone di quelle che attualmente le considerano.

Nel contesto attuale, la metodologia più comunemente adottata è il "code and fix". L'utilizzo di un metodo più disciplinato sarà quasi certamente di aiuto, e l'approccio agile ha il vantaggio di essere più facilmente realizzabile di un metodo pesante. Difatti buona parte del vantaggio dei metodi agili consiste nella loro leggerezza. E' più facile seguire un processo semplice quando si è abituati a non seguire proprio alcun processo.

Una delle limitazioni più grandi di queste nuove metodologie riguarda la gestione dei team più numerosi. Come molti nuovi approcci, esse tendono ad essere utilizzate dapprima su una piccola scala. Inoltre sono state spesso create proprio con un'enfasi verso i piccoli team. La Extreme Programming afferma esplicitamente che è stata progettata per team aventi al massimo circa venti persone. E' meglio ricordare che molti team per lo sviluppo del software potrebbero essere diminuiti di numero senza ridurre la produttività complessiva.

Altri approcci agili sono specificatamente pensati per team più numerosi. Il FDD fu originariamente progettato per un progetto di circa cinquanta persone. ThoughtWorks ha utilizzato progetti ispirati alla XP con un team di circa cento persone in tre continenti. Anche Scrum è stata utilizzata per coordinare dei team di produzione altrettanto numerosi.

Un messaggio che spero risulti chiaro in questo articolo è che i processi adattivi risultano essere indicati nel caso di requisiti incerti e mutevoli. Se non si dispone di requisiti stabili, non si è allora nella condizione di avere un design stabile e di seguire un processo pianificato. In tali situazioni un processo adattivo può essere meno confortevole, ma risulterà molto più effettivo. Spesso il più grande ostacolo è qui rappresentato dal cliente. Ritengo che sia importante per il cliente comprendere che, quando i requisiti cambiano, seguire un processo predittivo risulta per lui essere tanto rischioso quanto lo è per lo sviluppo.

Se si decide di seguire l'approccio adattivo, si deve confidare negli sviluppatori e coinvolgerli nelle decisioni. I processi adattivi si aspettano che ci si fidi dei propri sviluppatori, così se si ritiene che essi siano di scarsa qualità e motivazione si dovrebbe seguire un approccio predittivo.

Riassumendo. I seguenti fattori suggeriscono di utilizzare un processo adattivo:

Questi fattori suggeriscono un processo predittivo:


Ringraziamenti

Per la stesura di questo articolo ho preso molte idee da più persone di quante ne possa mai elencare qui. Per i suggerimenti concreti vorrei ringraziare Marc Balcer, Kent Beck, Alistair Cockburn, Ward Cunningham, Bill Kimmel e Frank Westphal.

Si tenga presente che questo è un articolo su web in continua evoluzione e soggetto a cambiamenti ogni volta che lo riterrò opportuno. Aggiungerò una nota con i cambiamenti significativi, ma le modifiche minori saranno apportate senza alcun commento.


Cronologia degli aggiornamenti

© Copyright Martin Fowler, all rights reserved

© Copyright Marco Papacchini