Arrivare a XP (eXtreme Programming) - Intervista a Francesco Cirillo

In collaborazione con

Il Dott. Francesco Cirillo è uno dei maggiori rappresentanti dell' eXtreme Programming in Italia. Ha fondato e dirige XPLabs, società nata per applicare e promuovere il metodo della programmazione estrema, è coach del team XP Bees e mentor di diversi team XP. In un'intervista realizzata via e-mail approfondiremo con lui la vera essenza di XP.

• • •

Facciamo una breve panoramica sulla Sua esperienza XP: come è venuto a conoscenza di questo nuovo metodo e da chi e come è stato avvicinato ad esso? Può farci una descrizione anche degli eventi principali, ovvero come ha iniziato, di cosa si occupava prima e di cosa si occupa ora e quando ha deciso di impegnarsi seriamente nell'XP?

Nel 1999 iniziai a leggere sulle principali liste americane le prime e-mail sull'eXtreme Programming.

A quei tempi collaboravo principalmente con Sun Microsystems come consulente, mentor, docente e technical writer per le tematiche di ingegneria del software - in particolare process improvement, architetture e metodi di sviluppo object-oriented. Come mentor lavoravo a Milano con un team di una importante banca italiana. Con quel team, parallelamente ad un'attività di formazione sulle tematiche di ingegneria del software tradizionale, stavamo lavorando sulla definizione di un processo di sviluppo strict iterative and incremental che gli consentisse di rispondere efficacemente alle richieste dei trader (quel team si sarebbe poi chiamato Klondike).

Allo stesso tempo lavoravo come consulente indipendente con un'azienda di Firenze per il miglioramento del processo di sviluppo di uno dei loro team. L'obiettivo consisteva nel mettere in grado quel team di raggiungere il livello III e successivamente IV del CMM.

Per anni la mia attività era stata quella di studiare e sperimentare un gran numero di metodi per lo sviluppo del software con lo scopo di verificarne efficacia e applicabilità. La mia esperienza professionale maturata lavorando insieme a sviluppatori che falliscono progetti e imparano lezioni, mi ha da sempre fatto privilegiare la continua ricerca di qualcosa, qualsiasi cosa per consegnare software di qualità, nei tempi e nei limiti del budget definito, sempre e comunque col rispetto delle dinamiche umane e con l'obiettivo di soddisfare le necessità del cliente.

Come dicevo, in quel periodo comparvero una serie di e-mail, soprattutto a firma Ron Jeffries, che scossero il mondo delle liste che si occupavano di analisi e progettazione object-oriented. I subject ricorrenti di quelle liste, "extends versus uses", "aggregazione o composizione?!", "come applicare il principio di sostituibilità al mio caso concreto?", etc., furono per un certo periodo di tempo sostituiti da quelli delle e-mail di uno strano signore, Ron, che proponeva cose strane su una cosa ancor più strana che chiamava ricorrentemente "eXtreme Programming" .

Per uno come me, i cui miti erano - e tuttora rimangono - Parnas, Jacobson, DeMarco e Meyer, qualcuno che parlasse di programmazione estrema senza aver fatto robustness analysis e chiusure strategiche, era quanto meno uno sprovveduto. Eppure qualcosa mi attraeva. Quella di Ron era comunque una esperienza di progetto e nella mia ottica, ogni esperienza di progetto può produrre indicazioni utili per il miglioramento.

Cominciai a documentarmi su XP dagli allora pochi siti su Internet e la cosa mi interessava sempre di più, anche se non riuscivo a capire come gli XPer avrebbero risolto nella programmazione le complesse questioni architetturali e di design senza anticipazione. Questa era una sfida molto attraente. Il resto mi sembrava un modo molto bene organizzato di lavorare che richiedeva disciplina e una profonda preparazione delle tematiche di ingegneria del software tradizionale. Già pensavo che alcune di quelle cose le avrei potute applicare al team di Milano di cui ero mentor. Ma prima avrei dovuto capirle bene.

Conoscevo la serietà di Robert Martin, così decisi di partecipare alla prima "XP Immersion" a Chicago nel dicembre 1999. Lì ero l'unico europeo continentale. Tra gli altri conobbi Kent Beck e lo "strano signore" ( :) ) che era dietro alla firma di quelle ancor più "strane" e-mail. Se da una parte quei giorni furono molto intensi, dall'altra io ero abbastanza confuso. Non riuscivo ancora a vedere come far crescere un sistema senza almeno "un minimo" di design anticipatorio. Chiesi allora a Kent cosa avrei potuto fare per riuscire e mi misi a sua disposizione. La risposta fu "continua a studiare e ad applicare XP". Fu quello che feci.

Una volta tornato in Italia contattai una persona con la quale Kent aveva lavorato sull'approccio evolutivo allo sviluppo e che, secondo lui, mi avrebbe aiutato a rispondere alle mie domande. La persona era Massimo Arnoldi, CEO di Lifeware. Egli, dopo avermi conosciuto, mi consentì di partecipare al loro progetto nel team di Zurigo.

Cominciai a lavorare a Zurigo: un periodo indimenticabile, indimenticabili le sessioni di pair con Massimo, come le cene nei ristoranti italiani di Zurigo. Di lì anche il mio ruolo - ormai ufficiale anche nella comunità XP - di "Chief Cooking Officer" di Lifeware, titolo meritato nelle cucine di Lifeware a Zurigo.

L'esperienza di Lifeware dovrebbe essere maggiormente posta in risalto come esempio di come con XP un cosiddetto small team possa in pochi anni realizzare una cosa complessa come l'intero software per la gestione di una compagnia di assicurazioni dal front al back-end.

Per vari motivi - soprattutto logistici - fui costretto a interrompere la mia attività a Zurigo, ma ormai qualcosa era irreversibilmente cambiato. Avevo finalmente sciolto i miei dubbi sulla questione dello sviluppo evolutivo ed ero pronto al prossimo passo.

Rientrato definitivamente in Italia nel settembre 2000 creai, stimolato da Kent, la lista italiana sull'eXtreme Programming (http://it.groups.yahoo.com/group/extremeprogramming-it/) e costituii XPLabs, la società della quale sono stato fino al dicembre 2002 direttore e dal gennaio 2003 sono CEO. Per la sede decidemmo di ristrutturare una villa in campagna (la ristrutturazione avvenne con planning game e user story, sfruttando tutti i vantaggi di XP). Curiosamente la società nasceva nel segno della comunicazione con cinque collaboratori di cinque paesi diversi appartenenti a quattro continenti diversi.

Tornato a collaborare con Sun per conto di XPLabs, avanzai l'idea di proporre un'attività di mentoring XP al team di Milano. Sun mostrò la sua apertura e il team di Milano accettò fiducioso. Il team assunse il nome di Klondike e il risultato di quell'attività fu il progetto Repo Margining (vedi http://www.communications.xplabs.com/lab2001-1.html).

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

Due momenti sono stati importanti per me:

• Liberarmi della paura di dover prevedere il cambiamento. L'obiettivo dell'ingegneria del software tradizionale è un'idea molto potente: per ogni nuovo requisito si vogliono scrivere nuove classi e non modificare quelle già realizzate e testate. Per sette anni ho lavorato con questi principi. Per chi lavora in questo modo, decidendo le primary abstraction, applicando il design anticipatorio, il "managing complexity with complexity", disegnando i pattern di design, il primo passo verso XP sta nel fermarsi a considerare i requisiti correnti dell'applicazione, nell'aprirsi all'idea di far crescere un piccolo sistema, in cui le astrazioni e le strutture di design emergono dal codice e in cui tutti i comportamenti sono in continuo cambiamento.
• Capire il ruolo dei principi e dei pattern di design in un'ottica evolutiva; imparare a far crescere il software. La conoscenza di principi e pattern di design è fondamentale in XP. A differenza della progettazione object-oriented tradizionale, tali conoscenze sono utilizzate per "riconoscere forme", invece che per "disegnare forme". La capacità che serve sviluppare in XP è quella di "ascoltare il codice", facendo emergere astrazioni e pattern di design attraverso l'eliminazione delle duplicazioni. Per far questo occorre essere in grado di poter riconoscere quelle strutture. L'unico modo per essere in grado di riconoscere i pattern di design è studiarli continuamente.

XP rappresenta una evoluzione o una rivoluzione? In cosa consiste l'innovazione di XP?

L'eXtreme Programming rappresenta una evoluzione dell'ingegneria del software tradizionale. Extreme deriva dal fatto di portare all'estremo una serie di buone, già note, pratiche di ingegneria del software tradizionale, Programming fa riferimento al fatto che il nostro obiettivo ultimo è consegnare cose che funzionano, che danno valore al committente, codice eseguibile e per far questo, occorre programmare.

Val la pena sottolineare che XP è un metodo con le radici ben salde nell'ingegneria del software tradizionale (vedi http://www.computer.org/software/dynabook/WhatIs.htm e http://www.computer.org/software/dynabook/RootsXPsdb.htm). La reale innovazione sta - a mio modo di vedere - nella particolare selezione di una ridotta serie di pratiche e nei caratteri people-centric e labour-intensive del metodo, soprattutto nella condivisione all'interno del team di una serie di valori: comunicazione, semplicità, feedback e coraggio. Solo la spontanea condivisione di tali valori può portare alla continua applicazione di sforzo necessaria per dare continuità alle pratiche.

XP non è un silver bullet, non è una panacea ai problemi dello sviluppo software. Senza refactoring continuo, o senza una continuità nella pratica del test-first incrementale, qualsiasi progetto XP fallisce. Ripeto, XP non è la soluzione a tutti i mali del software development. È solo un primo passo in quella direzione.

Quali sono i vantaggi che ha riscontrato nell'uso di XP?

• Soddisfazione da parte del cliente. Il cliente può aggiungere, cambiare, eliminare funzionalità a ogni planning game - da noi ogni settimana. Può anticipare la realizzazione dei ricavi attraverso la composizione di release più brevi.
• Efficacia nell'introdurre nel sistema nuove funzionalità. Per gli sviluppatori il cambiamento, dall'essere una paura diventa un'ottima opportunità per migliorare il design del proprio sistema. Acquisita la capacità di introdurre nuove funzionalità nel sistema minimizzando il relativo costo, diventa inefficace qualsiasi forma di anticipazione, il cui effetto si riduce ad un indesiderato aumento della complessità.
• Soddisfazione da parte dei programmatori. Il lavoro è collaborativo, creativo, intenso, focalizzato e motivante: continuamente i membri del team consegnano valore al committente sotto forma di user story completate. Non si fa overtime sistematico, non è efficace, l'uomo non funziona come una macchina.

Ma, da dove nascono questi vantaggi?

Steve McConnell ha proposto nel suo libro "Rapid Development" una serie di cause per cui i progetti falliscono: mancanza di input da parte dell'utente, pianificazione insufficiente, gold-plating, abbandono della pianificazione sotto pressione, feature creep, eroismo, personale non preparato, etc. Riclassificando questo elenco emergono due fattori principali: la incapacità a gestire la complessità e la velocità. Insieme, questi due fattori, generano un pericoloso circolo vizioso.

Mentre la complessità rappresenta il nemico numero uno degli sviluppatori, la velocità molte volte rappresenta un vero e proprio valore per gli sviluppatori. C'è un test molto semplice per verificare se nello sviluppo il proprio valore è quello della velocità. Se in ogni momento ci si domanda "sto andando abbastanza veloce?", il proprio valore è la velocità. Ovviamente si tratta di un pessimo valore per chi sviluppa software, tra l'altro in genere facilmente condiviso dal team. In realtà, se vediamo tale valore come motore dei comportamenti messi in atto all'interno del team, non abbiamo buone notizie, perché l'effetto ultimo di tale valore è far prendere allo sviluppatore scorciatoie nella qualità producendo una serie di conseguenze negative: funzionalità che non corrispondono a quelle richieste dal cliente, design rigido, fragile e immobile e un intensificarsi della attività di bug detection. Particolarmente subdolo quest'ultimo fenomeno, noto in ingegneria del software come devolution, un processo degenerativo evolutivo per il quale un'attività di bug fixing non supportata da un'adeguata ristrutturazione del design del sistema porta ad una maggiore rigidità del sistema stesso e ad uno scadimento delle relative performance. Ognuna delle suindicate conseguenze negative causate dalla velocità, genera un aumento indesiderato della complessità.

Cosa propone allora XP? XP propone di sostituire il motore della velocità con uno basato sui valori della comunicazione, del feedback, della semplicità e del coraggio. Se in ogni momento ci si domanda, "sto comunicando, sto dando feedback, sto lavorando in modo semplice, ho il coraggio, ad esempio, di chiedere aiuto quando ne ho bisogno?", allora si ha il motore XP e questo è il primo passo per fare XP. Su questi valori, su questo motore si basa una serie di dodici pratiche cui i valori danno continuità. Valori e pratiche di XP sono dirette a ridurre, spezzettare, da un lato la complessità del business, dell'area del problema, dall'altro la complessità della costruzione del software. Ovvero a combattere il nemico numero uno degli sviluppatori: la complessità. L'effetto ultimo è che questi valori, questo motore XP, portano alla velocità, all'aumentare cioè del ritmo di consegna, riducendo la complessità. Le pratiche richiedono di essere continuamente applicate e per questo devono vivere i valori.

In altri termini, il vantaggio nell'applicare XP è dato da un aumento di velocità nel ritmo di valore consegnato derivante da una continua regolazione della complessità, sia del business, sia tecnica, ottenuta attraverso la continua applicazione di semplici pratiche, resa possibile attraverso la spontanea condivisione di una serie di valori.

Ripeto, la complessità è il nemico numero uno degli sviluppatori. XP fornisce degli strumenti efficaci per combatterla puntando su una serie di valori nel segno della comunicazione, invece che aumentarla, come fanno molti altri metodi, attraverso la richiesta di formalità.

Qualsiasi tentativo di comprendere XP partendo dalle pratiche e trascurando i valori è destinato a fallire.

In quali progetti sono stati più evidenti i benefici di XP e in quali meno?

L'esperienza maturata, sia come mentor di team XP, sia come coach del team Bees di XPLabs, dimostra che più complesso è il progetto, più evidenti sono i benefici derivanti dall'applicazione di XP.

Qual è stato l'esito dei progetti XP cui ha partecipato? In particolare, riesce a quantificare la percentuale di successo a seguito dell'applicazione di XP per ognuno di essi?

Per i tre progetti XP finora avviati in XPLabs, il team Bees, di cui sono coach, riesce a consegnare le funzionalità richieste dal cliente, nei tempi e nel budget allocato, lavorando in modo piacevole e imparando ogni giorno qualcosa di nuovo. Questo ci fa dire che sono tre progetti di successo.

Quali consigli si sentirebbe di dare a chi si avvicina per la prima volta a questo nuovo metodo?

Gli stessi consigli che darei a chiunque sia sinceramente interessato a migliorare il suo processo di sviluppo:

• Umiltà. Consegnare valore al proprio cliente è sicuramente di maggiore soddisfazione che essere speculativamente efficaci consegnando "artefatti" complessi e ben disegnati, ma implica maggiori responsabilità. In situazioni realmente complesse e critiche, in cui nessun membro del team, da solo, può dominare completamente il problema, ma ognuno può solo disporre di conoscenze parziali del problema, attraverso una reale collaborazione i problemi si possono risolvere più efficacemente e con maggiore soddisfazione del cliente. Per far questo bisogna però essere umili, riuscire a comunicare con gli altri, a cercarne il feedback, a lavorare in modo semplice - magari accettando di partire dal codice - e ad avere il coraggio di ammettere di non essere in grado da soli di risolvere qualsiasi problema e di riconoscere di poter imparare, sul lavoro, da qualsiasi membro del team. Responsabilità e collaborazione sono le parole vincenti di XP. La presunzione di riuscire a dominare completamente un problema per risolverlo nella dinamica violenta del cambiamento risulta essere subottimale, devastante e perdente.
• Apertura mentale. Per poter cambiare occorre essere disposti ad accettare e provare nuove idee. "Process improvement is difficult because people are reluctant to try new things. Their current habits seem so natural they can't believe the change would help" (Watts S. Humphrey, "Introduction to the Personal Software Process").
• Osservazione e capacità critica. Per migliorare occorre misurare e valutare gli effetti del cambiamento.

A chi sconsiglierebbe l'uso di XP?

Innanzitutto vorrei consigliare a tutti coloro che lavorano nell'area dell'ingegneria del software di prodigarsi in uno sforzo sincero volto a comprendere cosa sia realmente XP e a praticarlo partendo dai valori e successivamente lavorando sulle pratiche.

Detto questo, sconsiglio XP a chi dopo averne compreso i fondamenti e provato le pratiche non ne condivida i valori. Come già detto, il primo passo per praticare XP è sostituire il motore dei valori. Sui valori si costruiscono le pratiche. I valori danno infatti la possibilità di dare continuità a quelle pratiche. Senza continuità, il castello delle pratiche cade rovinosamente. XP richiede una spontanea condivisione dei valori all'interno del team.

Esiste qualche aspetto di XP o su XP che non condivide o che ritiene non essere così importante?

Personalmente condivido pienamente i valori e le pratiche proposte da XP.

Cosa non condivido?! Non condivido il modo di attaccare XP senza sforzarsi di comprenderlo.

Dal Suo punto di vista e sulla base della Sua esperienza, pensa si possa far convivere una metodologia estrema con una tradizionale nello stesso progetto?

La mia domanda è: perché dovremmo far convivere XP con un metodo tradizionale?

Rick Kazzman, mio professore di architetture software alla Carnegie Mellon University usava ripetere: "Software Engineering = Cost Effectiveness". Io sono molto d'accordo su questa definizione. È certo che il nostro obiettivo di ingegneri del software è essere efficaci. Non esiste quindi un metodo di sviluppo migliore in teoria. Migliore o peggiore in questo contesto vuol dire più o meno efficace. Allora la domanda è: può essere XP più efficace facendolo convivere con un metodo tradizionale o innestandovi altre tecniche tradizionali? La mia risposta è negativa. Al momento XP non ha bisogno di alcun altro metodo o di altre tecniche tradizionali per essere più efficace.

L'unico motivo per cui oggi degli XPer possono usare altre tecniche è perché il cliente glielo chiede espressamente. Se il cliente richiede una documentazione con modelli in notazione UML, o una stima con function point o applicando COCOMO o altro, il team XP creerà una user story per quell'attività, ne stimerà il relativo sforzo e la sottometterà al cliente nel planning game. Se il cliente deciderà di investire in quelle carte, il team le realizzerà, ma quelle tecniche non rientrano nella funzione di produzione del team.

Ciò non vuol dire che in futuro XP non trarrà beneficio da nuovi metodi e tecniche. XP nasce per evolvere. Gli XPer sono alla continua ricerca di maggiore efficacia. La più importante delle pratiche di XP è quella per la quale le pratiche stesse possono cambiare. Questo comporta un continuo sforzo volto a comprendere e verificare l'efficacia di metodi e tecniche soprattutto se derivanti da significative esperienze di progetto. Imparare da chiunque e ovunque.

Relativamente al confronto dell'efficacia di XP con altri metodi c'è un'altra cosa che vorrei dire. Molti affermano che XP sia adatto a progetti medio piccoli confrontando il ridotto numero di mesi uomo di un progetto XP con quello di un progetto tradizionale. Vorrei segnalare al riguardo un errore metodologico. I due progetti si basano su due diversi metodi di sviluppo software, e quindi due diverse funzioni di produzione che implicano un diverso modo di affrontare e regolare la complessità.

Per confrontare l'efficacia di due diverse funzioni di produzione occorre innanzitutto lavorare a parità di condizioni. Posta pari la complessità delle funzionalità da risolvere e posta la medesima serie di vincoli, occorre quindi misurare quale delle due funzioni di produzione richiede meno sforzo per raggiungere gli obiettivi prefissati.

Assumendo che la complessità funzionale sia assimilabile ad una distanza, si tratterebbe di trovare l'automobile, che, ceteris paribus - a parità di distanza, tempi massimi richiesti, usura massima richiesta, etc. - consumi meno benzina. Se volessimo confrontare in un contesto reale l'efficacia di XP con quella di un altro metodo, quindi un'altra funzione di produzione, dovremmo domandarci, ceteris paribus, per sviluppare analogo sistema, con analoga capacità di rispondere nella costruzione del software alla dinamica di business, ritmo di consegna, velocità da sostenere per soddisfare il mio cliente, etc. quanto sforzo dovrò applicare con le varie funzioni di produzione? L'automobile che a parità di condizioni consumerà meno sarà la preferita.

Se è vero che un progetto con tanti mesi uomo, eventualmente dovuti a più team che interagiscono in modo distribuito, rappresenta maggiore complessità comunicativa/costruttiva è anche vero che quello può non essere il miglior modo per organizzare i fattori della produzione, ma soprattutto che quella complessità rimane limitata alla funzione di produzione del team di sviluppo.

L'ipotesi di comportamento razionale vuole che l'imprenditore minimizzi il costo di produzione - a parità di qualità - ottimizzando l'allocazione delle risorse. Il ridotto sforzo (mesi uomo) necessario per risolvere, in condizione di violento cambiamento, un problema, che richiede lo sviluppo di un sistema di migliaia di classi applicative, può significare che il processo seguito è molto efficace e quindi rilevante.

In Lifeware ad esempio, in pochi anni, un cosiddetto small team di programmatori con XP è stato in grado di supportare le necessità di un business estremamente dinamico e complesso, come quello relativo alle compagnie di assicurazioni, con consegne rapide e frequenti, garantendo la piena soddisfazione del cliente.

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

Uno dei fondamenti di XP è la netta separazione tra business e sviluppo. Da una parte esiste un committente che ha un problema ed è interessato a risolverlo o ha un'idea di business e intende svilupparla, dall'altra esistono degli sviluppatori che sono in grado di consegnare le funzionalità richieste ed effettuare i cambiamenti in modo rapido ed economico, incoraggiando nuove richieste da parte del committente. In XP, committente e sviluppatori interagiscono continuamente collaborando in un unico team.

Sulla situazione in Italia, distinguerei tra aziende grandi e medio-piccole.

Relativamente alle grandi aziende italiane, la sempre maggiore pressione competitiva, derivante dagli effetti della progressiva unificazione europea e del relativo allargamento a nuovi paesi, impone di trovare una soluzione efficace al problema del cambiamento. Nessun comportamento tecnocratico o di opposizione al cambiamento può essere più consentito. Il software è già da tempo diventato il modo di caratterizzare e individuare i servizi di business offerti dall'azienda. Le dinamiche di business e la costruzione del software sono legate come non mai. In questo contesto, i grandi investimenti su progetti software multimilionari con scadenze e ritorni finanziari ed economici lontani nel tempo, non sono più possibili.

Inevitabilmente i CEO di queste grandi aziende avvertono la necessità di dover adottare nuovi metodi per lo sviluppo del software , maggiormente efficaci, reattivi al cambiamento e in grado di supportarli nello sviluppo del loro business, anche dal punto di vista finanziario. La cura degli aspetti di definizione delle funzionalità del software da realizzare diviene un elemento vitale e strategico, in cui la componente creativa nella definizione del business appartiene unicamente all'azienda attraverso la visione del management. Tale processo di definizione del business, per essere efficace, richiede un continuo riscontro nella realtà. Indispensabile diventa la necessità di apportare cambiamenti in qualsiasi momento e direzione. Tutto questo risulta concretizzabile solo disponendo di un team di sviluppo in grado di realizzare il cambiamento in modo veloce ed economico. La sopra citata separazione tra responsabilità di business, di definizione delle funzionalità da realizzare, e responsabilità tecniche, di come cioè si realizzeranno quelle funzionalità, richiede una continua collaborazione tra le parti che si realizza nel lavoro in team.

XP risulta essere in questo momento l'alleato migliore per le grandi aziende italiane. Val la pena sottolineare che un team XP viene assunto per la sua capacità di minimizzare il costo del cambiamento, di adeguare continuamente il sistema alle richieste del committente, consentendogli la possibilità di testare le proprie idee, massimizzando in questo modo lo sviluppo del suo business. Nella mia esperienza, la citata partecipazione del committente al team di progetto è un aspetto di XP che, nelle grandi aziende, superate le iniziali difficoltà, soprattutto organizzative, incontra sempre maggior favore, grazie alla efficacia dei risultati.

Se tante sono le grandi aziende italiane che potrebbero trarre un vantaggio competitivo dall'applicazione di XP, molte di più sono le aziende medie e piccole che ne potrebbero usufruire in modo altrettanto vantaggioso. Tali aziende conoscono i loro problemi e sono realmente piene di idee e desiderose di realizzarle attraverso un software personalizzato sulle proprie esigenze. Per tanti anni vessate da software-house molto abili nel vendere un prodotto iniziale, quanto pronte a ritirarsi alla prima richiesta di cambiamento, queste aziende piccole e medie sono ideali per l'applicazione e diffusione di XP.

In quale misura crede che sarà adottato XP? Cosa ritiene occorra fare per favorire la diffusione di XP?

La risposta alla prima domanda dipende in qualche modo da quanto saremo efficaci nel rispondere alla seconda.

Cosa occorre fare allora per la diffusione di XP. Per punti:

• Occorre dimostrare una ripetibilità controllata dei risultati. Questo non alla ricerca di un'inutile dimostrazione induttivista della validità di XP (come afferma Popper: "Nessun numero di osservazioni di cigni bianchi riesce a stabilire che tutti i cigni sono bianchi, o che la probabilità di trovare un cigno che non sia bianco è piccola"), ma per consentirci di conoscere meglio XP. Secondo il fallibilismo epistemologico di Popper, il contenuto di una teoria scientifica consiste nelle sue conseguenze; per essere provata deve essere controllabile di principio, da essa deve cioè essere possibile estrarre conseguenze che possono essere confutate, cioè falsificate. In questo sperimentando una asimmetria logica tra verificabilità e falsificabilità di una teoria per cui miliardi e miliardi di conferme non rendono certa una teoria, mentre un solo fatto negativo la falsifica dal punto di vista logico. XP ha ancora tanto da insegnarci e l'unico modo per imparare è osservare, estraendo conseguenze misurabili e controllabili. In senso epistemologico lo sforzo di noi XPer dovrà essere volto a rendere controllabile e quindi, paradossalmente, falsificabile XP, per scoprire cioè come migliorarlo. Scrive Popper: "Da un sistema scientifico non esigerò che sia capace di essere scelto, in senso positivo, una volta per tutte; ma esigerò che la sua forma logica sia tale che possa essere messo in evidenza, per mezzo di controlli empirici, in senso negativo: un sistema empirico deve poter essere confutato dall'esperienza". Il principale obiettivo di XPLabs è da sempre quello di realizzare una serie di laboratori in settori molto diversi tra loro al fine di estrarre contenuto informativo. Tutti i nostri lab saranno pienamente tracciati e la relativa documentazione sarà resa pubblica, come nello spirito di XPLabs. Abbiamo bisogno di feedback per migliorare. Ogni indicazione sarà per noi preziosa.
• Occorre un sempre maggiore impegno per rendere evidente che XP non è solo un insieme di pratiche, ma è soprattutto un insieme di valori condivisi spontaneamente all'interno del team. Sempre con maggior frequenza negli incontri che faccio, noto che i miei interlocutori si focalizzano sulle pratiche sminuendo a volte maliziosamente l'importanza dei valori di XP (così come se includere quei valori fosse null'altro che una buona idea di marketing ). La spontanea condivisione dei valori proposti da XP è invece fondamentale per il successo del team ed esalta due aspetti realmente rilevanti nel lavoro di un team XP: la responsabilità e la collaborazione.
• Occorre un approccio sistematico allo studio dei metodi per lo sviluppo del software. Frequentemente ascolto un ormai vecchio e noto refrain: "d'altronde l'ingegneria del software ha pochi anni di vita, è ancora giovane...". Ogni tentativo di vedere lo studio dei metodi di sviluppo software come una materia "nuova" e in certo modo distinta dalle altre può portare solo a inutili limitazioni. Lo studio dei metodi di sviluppo software è figlio della filosofia logica, dell'antropologia, dell'architettura, della psicologia, della biologia, dell'economia, etc. ...e per questo non ha pochi anni di vita, ma offre secoli di esperienze. Con umiltà occorre imparare ad apprendere in modo efficace da tutte queste materie.
• Occorre maggiore "disponibilità" da parte degli accademici. C'è bisogno di chiarezza, semplicità, ma soprattutto di rispetto per chi offre una diversa visione, e rigore nell'applicazione del metodo scientifico. La filosofia della scienza insegna che non esistono teorie vere, ma teorie più o meno verosimili. Tutte le teorie sono falsificabili. Il progresso avviene falsificando teorie in modo scientifico. Riuscire a non far fallire un progetto e a supportare il nostro cliente nello sviluppo del business è già di per sé cosa sufficientemente complicata. È necessario che XPer e mondo accademico collaborino più attivamente per comprendere e risolvere, con metodo scientifico, i problemi dello sviluppo del software.

Informazioni sull'autore

MM,

È possibile consultare l'elenco degli articoli scritti da MM.

Altri articoli sul tema Metodologie / XP.

Risorse

1. XPLabs Communications: Arrivare a XP - Intervista a Francesco Cirillo
   http://www.communications.xplabs.com/experience2003-1.html