Extreme programming: un approccio estremo allo sviluppo di software

Esistono svariate evoluzioni dello sviluppo agile di software. Accanto a Scrum e Kanban, si parla sempre e si utilizza l'extreme programming. Ma cos'ha di tanto estremo questo tipo di sviluppo?

L'extreme programming (XP) è la versione più radicale dello sviluppo agile di software e viene perciò detto estremo. In altre parole, non esiste forse un metodo più agile dell'XP, e non lo è neanche la programmazione tradizionale. L'extreme programming, pertanto, si distingue anche concretamente dal modello a cascata, cosa che, secondo gli inventori dell'XP, porta con sé numerosi problemi. A metà degli anni 90, gli sviluppatori Kent Beck, Ward Cunningham e Ron Jeffries hanno deciso di rinnovare di sana pianta l'approccio classico di lavoro e di sondare nuove possibilità.

In linea generale l'extreme programming è orientato alle esigenze del cliente. Potrebbe sembrare ovvio, invece lo sviluppo di software classico può andare incontro ai desideri del cliente solo fino a un certo punto; e le difficoltà iniziano soprattutto quando questi desideri cambiano regolarmente. L'XP cerca di stimolare la creatività degli sviluppatori e accetta gli errori come un fattore naturale durante il lavoro.

Inoltre, l'XP, come anche altri metodi agili, parte da processi iterativi. Seguire un grosso progetto dall'inizio alla fine e investire diversi mesi solo per accorgersi alla fine che il risultato non va bene: con l'XP non succede più, perché si controlla, si discute e si pubblica costantemente, con cicli brevi. Ciò consente di individuare e risolvere tempestivamente gli errori.

Per soddisfare i requisiti richiesti, è stato sviluppato un framework estremamente chiaro, composto da diversi valori, principi e tecniche. In più vengono assegnati dei ruoli concreti in modo da poter assegnare i compiti in modo chiaro.

Con cinque valori, l'XP tenta di modificare l'approccio di base del lavoro di programmazione. Il team deve essere unito nel seguire una determinata mentalità, così da poter collaborare al meglio e dare vita a un prodotto di prima qualità.

Nell'XP, la comunicazione è importante sia tra i membri del team che tra sviluppatori e clienti. Uno scambio continuo deve permettere di affrontare direttamente i problemi. Solo quando tutti i soggetti coinvolti si confrontano continuamente è possibile scoprire tempestivamente le criticità. Inoltre, la comunicazione fa sì che tutti lavorino con lo stesso grado di conoscenze e si sentano impegnati nel progetto. Una buona conversazione di persona è da preferire allo scambio di messaggi scritti.

Nell'XP si cerca sempre di trovare la soluzione più semplice, un approccio che implica molti vantaggi. Quando si ci concentra solo sui fattori necessari, non ci si sofferma su aspetti superflui. In quest'ottica rientra anche lo sviluppo solo delle funzionalità necessarie al momento, invece di iniziare già a lavorare per eventuali requisiti futuri. In questo modo il team accelera lo sviluppo. Inoltre, un prodotto agile è molto più semplice da gestire, sia nelle fasi successive di sviluppo che nella manutenzione. Infine, un codice di programmazione quanto più semplice possibile consente di comprendere anche l'importanza della comunicazione: se tutto il team è in grado di capire il codice sorgente, diventa più facile confrontarsi su di esso.

Anche questo valore è strettamente legato alla grande importanza della comunicazione diretta. Il cliente deve poter esprimere le sue critiche il più spesso possibile. Nell'extreme programming, anche i messaggi del sistema (log) vengono trattati come feedback. Per poter mettere in atto una cultura del feedback come la si intende nell'XP, è importante procedere gradualmente: il team lavora con cicli brevi, testa continuamente il codice e sottopone anche al cliente i progressi dello sviluppo a intervalli brevi. Ciò consente di apportare tempestivamente modifiche e di risolvere gli errori.

Nell'extreme programming, per coraggio si intende la disponibilità a dire la verità, anche quando è spiacevole. Se ci sono errori nel prodotto, devono essere comunicati, anche quando se ne ha la responsabilità. In un team che lavora in base ai valori dell'XP, non c'è spazio per le scuse. Nessun componente del team dovrebbe cercare di minimizzare il proprio coinvolgimento in un errore, in quanto è un atteggiamento non costruttivo per il raggiungimento degli obiettivi. Inoltre, in questo contesto il coraggio è anche quello di modificare le strutture dell'organizzazione, di mettere in discussione il proprio modo di lavorare, di accettare le critiche e magari anche di riscrivere di sana pianta il codice.

Affinché il team lavori in armonia e possa giungere a prestazioni eccellenti, è importante il rispetto reciproco. Un valore che implica anche, ad esempio, che il lavoro di un componente del team non deve essere sabotato dalle modifiche apportate da un altro sviluppatore. La stima è importante in tutti gli attori coinvolti, dal team al cliente. Solo quando si prendono a cuore gli interessi dell'altro si può reagire in modo appropriato. Infine, anche la direzione deve mostrare rispetto al team di sviluppo e fornire ai collaboratori le competenze e le risorse necessarie.

Nell'extreme programming, i principi si trovano tra i valori e la prassi, e sono pertanto l'anello di congiunzione tra gli aspetti astratti e quelli concreti. I principi derivano più o meno dai valori appena definiti.

Il feedback deve essere ottenuto il prima possibile e messo in pratica con la stessa rapidità. I riscontri provenienti dal sistema stesso (durante il test del codice) devono essere implementati nel giro di secondi o minuti, invece di raccogliere prima il feedback, ad esempio. Il feedback dei clienti, invece, deve essere ottenuto e preso in considerazione nel giro di giorni o settimane.

Il principio della semplicità corrisponde fondamentalmente all'omonimo valore, ma implica indicazioni di implementazione più concrete. I metodi utilizzati in tal senso sono due:

• You ain’t gonna need it (YAGNI): per non fare lavoro inutile, fintanto che una funzionalità non viene richiesta concretamente, non va implementata.
• Don’t repeat yourself (DRY): si deve evitare di fare doppio lavoro e anche il codice deve essere strutturato in modo tale da non dover apportare una modifica in più punti, ma sempre solo una volta.

Nell'extreme programming, le modifiche vengono sempre eseguite gradualmente. Invece di attuare grandi aggiornamenti per eliminare diverse fonti di errore in una sola volta, si affronta un problema dopo l'altro. In questo modo il team reagisce più rapidamente e le modifiche possono essere seguite meglio. Il principio non si riferisce però solo al codice di programmazione. Anche le modifiche nella progettazione o addirittura nella struttura del team devono essere svolte in piccoli passaggi incrementali.

Poiché l'extreme programming mette al centro il cliente, attribuisce un grande valore anche alle sue richieste di modifiche. Pertanto tutto il team deve vedere positivamente tali modifiche, invece di ostacolarle. Il cliente, anzi, dovrebbe essere invitato a esprimere richieste di modifiche, invece di essere dissuaso dal farlo.

Può sembrare banale, ma, se ci si pensa, è molto importante per il funzionamento dell'extreme programming: il team deve fornire un lavoro di alta qualità. Cosa si intende per alta qualità, lo stabilisce il cliente. Per ottenere un lavoro di qualità, tuttavia, ci vuole una gestione. Se i fattori sono quelli giusti e il team può quindi essere soddisfatto della prestazione fornita, le ripercussioni sul morale sono positive.

Le pratiche dell'XP sono indicazioni concrete sui metodi di lavoro. Mentre i valori e i principi illustrati si applicano anche agli altri metodi di lavoro agili, le tecniche concrete dell'extreme programming sono una peculiarità di questo metodo. Anch'esse sono leggermente cambiate nel tempo e variano da una fonte all'altra. In generale, le tecniche vengono suddivise in quattro ambiti.

Nell'extreme programming, i team di sviluppatori lavorano in cicli estremamente brevi. Ciò consente di testare continuamente il codice scritto. Il Test-Driven Development va ancora oltre: gli sviluppatori, infatti, scrivono un ambiente di test prima ancora di creare il codice sorgente effettivo. Il codice che non supera questo test non può essere proseguito. In tal caso il feedback arriva direttamente dal sistema.

Il cosiddetto Planning Game è una riunione che si effettua all'inizio di ogni fase di programmazione. Il team e il cliente si incontrano per discutere del lavoro svolto fino a quel momento, per dare un feedback e per discutere delle funzioni future. In più vengono assegnati dei compiti.

Anche l'idea di un On-Site Customer consente di avere un feedback regolare. Nella migliore delle ipotesi, almeno un rappresentante del cliente deve essere un membro fisso del team, in modo da rispondere tempestivamente alle domande o illustrare idee o priorità.

Il pair programming, infine, assicura il principio del doppio controllo: due persone lavorano sempre contemporaneamente allo stesso codice. Mentre un collega scrive il codice, l'altro controlla il codice sorgente, propone miglioramenti e indica eventuali errori. Si tratta di un metodo però molto costoso in quanto richiede l'impiego di due collaboratori per un unico compito; d'altro canto, il codice risultante è decisamente migliore e si traduce in meno rifiniture successive.

I team dell'XP rivedono continuamente il loro codice. Questo refactoring serve a migliorare il testo sorgente e a rimuovere ripetizioni ed elementi superflui. Un codice così ottimizzato è comprensibile, anche a lettori esterni, e meno soggetto a errori.

Con la continuous integration, nell' extreme programming e in altri metodi di lavoro agili, i team effettuano l'integrazione continua di nuovo codice nel progetto complessivo. Uno sviluppatore inserisce più volte al giorno il suo lavoro nel progetto. Così i singoli contributi vengono controllati continuamente e tutti i soggetti coinvolti lavorano con materiale aggiornato.

L'XP prevede che programmi e aggiornamenti funzionanti vengano rilasciati il prima possibile. Le small releases aumentano anche la frequenza dei feedback. Così gli errori possono essere individuati molto più rapidamente ed eliminati con l'aggiornamento successivo. Il cliente ha sempre la possibilità di provare la versione più aggiornata dello sviluppo e di esporre critiche e proposte.

Con una progettazione semplice (Simple Design), il codice risulta comprensibile a tutti i soggetti coinvolti. Tutto ciò che rende inutilmente complesso il codice sorgente deve essere eliminato. Gli sviluppatori che lavorano secondo l'extreme programming devono eliminare tutti i duplicati. In più, il codice sorgente deve rendere chiaro l'obiettivo della programmazione.

Per consentire a tutto il team di lavorare di pari passo, fondamentalmente vengono stabiliti dei "Coding Standards". Queste direttive si riferiscono all'approccio e al formato. I colleghi devono potersi orientare anche nel codice degli altri; in più deve essere sempre possibile stabilire chiaramente chi ha apportato determinate modifiche.

La Collective Code Ownership rafforza la possibilità di lavorare insieme sul codice: invece di far notare chi è responsabile di un determinato pezzo (e quindi degli errori contenuti), il codice è considerato un prodotto globale. Pertanto tutto il team è responsabile tanto degli errori quanto dei successi. Questa tecnica invita inoltre a rivedere il codice degli altri e a esprimere le proprie idee.

Per aumentare ulteriormente la comprensione del codice sorgente, nell'extreme programming si utilizza la tecnica del System Metaphor. Questa pratica consiste nel descrivere il progetto con la massima semplicità, utilizzando anche metafore. Un approccio che implica anche delle convenzioni nella denominazione di elementi, classi o funzioni nel codice, che siano possibilmente intuitivi. I nuovi collaboratori che subentrano nel progetto devono così poter capire rapidamente questi aspetti. Così anche chi non è programmatore può farsi un'idea del codice sorgente.

Il benessere del team è fondamentale per il successo del progetto: solo dei collaboratori riposati e motivati possono dare risultati di alta qualità. Per garantirlo, l'extreme programming prevede la settimana di 40 ore (40-Hour Week). Le ore di straordinario devono essere evitate a tutti i costi e sono consentite solo se nella settimana non se ne accumulano altre.

Nell'extreme programming, i ruoli servono a suddividere i compiti e le competenze tra tutti i soggetti coinvolti, sviluppatori e clienti che siano.

L'extreme programming è molto orientato al cliente, al punto da essere considerato un elemento del team e da richiedere la presenza di almeno un suo rappresentante sul posto (On-Site Customer). Il cliente pone i requisiti per il prodotto, ma si esprime solo limitatamente su come raggiungere gli obiettivi. Nella sua sfera di competenza rientra solo l'assegnazione delle priorità alle varie sottoaree. Inoltre, deve rendere chiare le sue esigenze.

Il ruolo del cliente può essere svolto da una persona o da un team composto da diversi rappresentanti del cliente. Nella prassi, spesso sono i product manager o anche gli addetti dell'ufficio marketing ad assumersi questo compito (sempre nel rispetto dell'obiettivo del progetto).

Il team di sviluppatori non ha ulteriori suddivisioni. Ciò significa che tutti coloro che creano attivamente il prodotto assolvono il ruolo di sviluppatori. Tra questi rientrano non solo i programmatori, ma anche altre persone coinvolte nella creazione, in base alle esigenze poste dal progetto. Oltre al lavoro di sviluppo vero e proprio, compito degli sviluppatori è anche rispondere alle esigenze del cliente: stimare le spese, redigere una tabella di marcia, programmare l'implementazione.

Tra i diritti degli sviluppatori rientra quello di cercare gli aiuti necessari, e quindi ad esempio richiedere altre risorse alla direzione. Inoltre, secondo le tecniche dell'XP, per gli sviluppatori vale la settimana di 40 ore. Per il bene del progetto, gli sviluppatori non devono lavorare troppo. Pertanto, il team di sviluppatori stabilisce autonomamente la sua tabella di marcia.

Il manager ha il ruolo di anello di congiunzione tra sviluppatori e clienti. Le persone appartenenti a questa categoria portano gli altri due a uno stesso tavolo e moderano ad esempio la pianificazione. Il manager si preoccupa per prima cosa che vengano rispettate le regole stabilite precedentemente e le convenzioni generali di una discussione costruttiva. Qualora ce ne fosse bisogno, il manager svolge anche il ruolo di mediatore.

Il suo ruolo è talvolta detto anche tracker, in quanto uno dei compiti del manager è quello di prendere nota di indici importanti (ad esempio il tempo speso da ogni collaboratore per il progetto).

Tutto il team (incluso il cliente) deve conoscere l'extreme programming e applicare coerentemente questo metodo di lavoro. Affinché tutti abbiano la stessa idea delle procedure, può essere utile la presenza di un coach, che non ha niente a che fare con lo sviluppo effettivo del prodotto, ma è presente solo come consulente esterno, proprio come uno Scrum Master. Nei colloqui preliminari con il coach, si possono analizzare le regole e le pratiche. Nella migliore delle ipotesi, il coach accompagna il team lungo l'intero percorso di sviluppo e interviene in caso di domande o di dubbi.

Spesso tale ruolo è rivestito da un fornitore esterno. Il coach può anche però essere un soggetto interno all'azienda, magari di un altro ufficio. Vanno evitati i doppi ruoli (ad esempio uno sviluppatore che svolge anche il ruolo di coach).

L'extreme programming ha dato impulsi importanti alla modalità di sviluppo di software, ma non è indicato per tutte le situazioni e per tutti i team. L'XP parte dal presupposto che, all'inizio del progetto, il cliente non abbia ancora un'idea precisa del prodotto finito. In tal caso, il software può essere progettato in modo agile, con una progettazione in continua evoluzione.

Così facendo, da un lato si soddisfa il cliente, in quanto si cerca di trovare insieme a lui la soluzione giusta, coinvolgendolo in ogni fase. Dall'altro, gli sviluppatori possono implementare i progetti in base alle loro valutazioni, invece di dover fare sempre dei compromessi. Se invece il cliente arriva con una descrizione già pronta del prodotto e una lista di funzioni da consegnare al team di sviluppatori, è molto difficile utilizzare l'XP.

Già il pair programming può mettere i piccoli team davanti a dei problemi se le risorse necessarie non sono disponibili. Anche gli incontri periodici con il cliente richiedono tempo, sottratto al lavoro effettivo di programmazione. In una situazione ideale ciò non conta: il risultato sarà inequivocabilmente migliore se il team può concedersi il tempo necessario e le risorse richieste.

Nella pratica, però, gli sviluppatori sono sotto pressione per via del budget limitato e delle scadenze stabilite. In più, il cliente potrebbe non avere interesse o le possibilità di impegnarsi nel progetto nella misura richiesta dall'XP.

Se invece le circostanze consentono di procedere in base all'extreme programming, con questo metodo un team può fornire risultati eccellenti. I test continui si traducono in sistemi stabili, e la procedura iterativa, insieme all'approccio minimalistico, fa sì che vengano create davvero solo le funzioni necessarie per il progetto.