Extreme Programming

Corrado Aaron Visaggio, ricercatore presso il Research Centre on Software Technology (RCOST), Università del Sannio, Benevento Italy.

E' autore di diverse pubblicazioni scientifiche su libri, riviste e conferenze internazionali. I suoi temi di ricerca sono: agile methodologies, knowledge management applicata all'Ingegneria del Software e qualità del processo software.

A lui abbiamo posto alcune domande su questo nuovo metodo di sviluppo del software.

Che cos’è l’eXtreme Programming, anche nota come XP ?

L’eXtreme programming (XP) è una nuova disciplina di sviluppo del software, è una metodologia agile. Consta di dodici pratiche (pair programming, continuous integration, etc.) utilizzate per organizzare il processo di sviluppo del software con l’esplicito obiettivo di evitare la produzione di semilavorati diversi da quelli strettamente necessari alla realizzazione dell’applicazione. Dettagliate specifiche formali, approfondite analisi e puntigliosa documentazione sono considerate attività troppo costose rispetto ai benefici apportati, in quanto limitano la flessibilità del processo che deve poter modificare i propri obiettivi in ogni momento.  

La produzione di un’applicazione, non è un’attività che può essere analizzata e precisamente pianificata a priori. Invece, esattamente come quando si guida l’automobile, la condotta complessiva è il risultato di un gran numero di minimi cambiamenti di rotta che il pilota decide in base alla sua istantanea percezione di curve ed ostacoli. 

Quali sono le differenze rispetto ad una metodologia classica di sviluppo del software? 

Tipicamente, laddove i requisiti del sistema sono estremamente instabili o emergenti, i processi ‘monumentali’, rigorosamente sequenziali diventano estremamente costosi o, addirittura, falliscono completamente.  Questo è dovuto al fatto che le metodologie classiche della produzione del software funzionano molto bene in due situazioni:

• quando i requisiti possono essere definiti correttamente e completamente prima di avviare lo sviluppo; in tal caso si può adottare il noto processo di sviluppo ‘waterfall’, in cui è possibile definire i requisiti, poi progettare  l’architettura del sistema e i test da eseguire, quindi scrivere il codice e solo successivamente eseguire i test;
•  quando, pur non possedendo una chiara definizione dei requisiti all’inizio del progetto, sono presenti le competenze e le risorse per condurre un processo ‘a spirale’, nel quale i requisiti vengono raffinati durante il processo stesso; in questo caso si segue un processo che è un ibrido tra il rigoroso ‘waterfall’ ed il processo incrementale.
• XP si propone come soluzione ottimale da adottare in un terzo scenario: quando i requisiti non sono noti a priori e non sono presenti le risorse per avviare un processo a spirale. Implementare l’XP significa integrare le 12 pratiche di cui si compone, o un suo sottoinsieme, nel processo di sviluppo aziendale.

 Tra le caratteristiche più interessanti dell’XP, ritengo utile annoverare le seguenti:

Ø       in ogni momento la squadra di sviluppo dispone di un software funzionante anche se non completo di tutte le sue funzionalità;

Ø       la squadra di sviluppo collabora attivamente con il committente, al fine di rilevare i feedback sul prodotto già durante il processo di sviluppo e non quando il prodotto è ultimato;

Ø       è il collaudo a guidare lo sviluppo e non il contrario: in tal modo si ha una costante consapevolezza di cosa funziona correttamente e cosa no.

 Qual è stata la prima esperienza di software realizzato con questa tecnica?  

XP è nato nel 1996, quando Kent Beck, consulente di sviluppo software, fu contattato da un’azienda costruttrice di automobili, la Chrysler, per risollevare le sorti di un progetto che stava decisamente naufragando.  Il progetto prendeva il nome di Chrysler Comprehensive Compensation (C3), e doveva gestire la compensation dei dipendenti dell’azienda. Kent Beck, coraggiosamente, decise di mettere in pratica alcune idee che aveva formulato, ma mai attuato, durante la sua carriera. Il progetto ha avuto un enorme successo; C3 attualmente gestisce il sistema retributivo di oltre 86.000 dipendenti. 

Quali sono i  risultati più importanti raggiunti? 

 Le voglio riportare i dati pubblicati d’alcune esperienze industriali che parlano da soli.  La Thoughtworks, inc., una società di consulenza statunitense, ha utilizzato XP per il reengineering di  un sistema legacy in uso nella società leader nel settore dell’energia nel North America, ovvero la TransCanada Pipelines Limited; il progetto è finito nel tempo previsto e rimanendo nel budget pianificato. FST s.r.l. ha introdotto XP in due progetti: il primo era finalizzato alla produzione di componenti di crittografia, il secondo riguardava la realizzazione di un portale di e-procurement. Ancora una volta i progetti hanno avuto risultati così incoraggianti da convincere l’azienda ad istituzionalizzare la pratica.  La IONA Technology ha condotto con successo progetti di manutenzione ‘extreme’, riportando risultati più che incoraggianti.  Questi, naturalmente sono solo alcune delle esperienze riportate. 

Il successo a quali fattori critici è dovuto? 

 Mettere in piedi un team agile che raggiunga con successo gli obiettivi, necessita di competenza e metodo. Nei processi plan-driven è più semplice ‘nascondere’ le carenze di conoscenza e abilità dietro la struttura monumentale del processo, nei processi agili necessitano persone che abbiano un forte rigore metodologico ed esperienza di alta qualità. Il secondo fattore è la capacità di fare squadra, i  processi agili si basano proprio sulla capacità di affrontare i problemi insieme, con lo stesso approccio, con una forte capacità di collaborazione e comunicazione.

 Quali sono le resistenze e quali i problemi maggiori incontrati dalle aziende nelle tappe di avvicinamento a XP? 

 I problemi che s’incontrano, tipicamente, riguardano la ‘specializzazione’ di XP. XP non è un processo, con una formale definizione da applicare ‘as-is’, XP è un metodo da personalizzare in base alle esigenze di business dell’azienda, ai suoi processi organizzativi e alle sue competenze.  E’ questo lo scoglio più arduo da superare. 

Ritiene che XP abbia realmente le carte in regola per una grossa diffusione? In particolare, nel nostro paese? 

Nel nostro paese, c’è un livello di cultura sufficientemente elevato per poter affrontare i progetti XP, la questione decisiva del metodo è prepararsi a sostenere XP. Come, tipicamente accade con le altre tecnologie, XP non è la panacea per tutti i mali. XP può essere applicata solo in precisi ambiti ed in precise circostanze. Se si ignora questo, il fallimento, doloroso, è proprio dietro l’angolo.  Se XP, viene eseguita nella maniera corretta, produce notevoli vantaggi per chi produce software: ottenere, fin dalle prime fasi del processo di sviluppo, un software funzionante, ridurre la densità dei difetti nel codice, maggiore coinvolgimento del committente nello sviluppo, dominare il cambiamento riducendo il rischio, e in ultimo, fattore importante ma difficilmente misurabile, aumentare la soddisfazione degli sviluppatori nel loro lavoro. 

Quali consigli è possibile dare a chi si avvicina per la prima volta a questo nuovo metodo? 

Studiare criticamente le sue pratiche,studiare il testing, il refactoring, l’integrazione continua , ma  soprattutto, imparare a lavorare in una squadra.

Dal suo punto di vista privilegiato quale pensa possa essere il futuro scenario IT?  

C’è molto interesse verso  Xp da parte delle aziende e da parte del mondo della  ricerca.  E’ tanto sbagliato sostenerla incondizionatamente così come è sbagliato rigettarla, dal momento che esistono applicazioni di successo il cui numero sta crescendo.  Confido che XP e i suoi derivati si affermeranno in molti ambienti industriali, soprattutto in quelli ove ci sono forti competenze e che soffrono molto l’instabilità dell’ambiente operativo: requisiti non definiti, risorse umane, immateriali e materiali che possono mutare in modo impredicibile nel bel mezzo del progetto.  Ritengo, inoltre, che l’industria ora inizia a riconoscere un valore concreto alla conoscenza ed al metodo ingegneristico, e questo sicuramente traccia un canale che convoglierà le metodologie ‘forti’ escludendo le metodologie ‘deboli’.