Un’introduzione a Extreme Programming (XP): cos’è e come funziona

Questo articolo inaugura la serie di Nicola Moretto, developer, Agile coach e founder di QMates, sulle pratiche dell’Extreme Programming, ospitata dal blog di UNGUESS.

Nel panorama in continua evoluzione dello sviluppo software, l'eXtreme Programming (XP) si distingue come un faro di innovazione e agilità. Dal suo concepimento alla sua attuale rilevanza nel contesto moderno, l'XP ha ridefinito la prospettiva dello sviluppo software, offrendo una serie di pratiche fondamentali che consentono un processo fluido, flessibile e di alta qualità. Guidati da un approccio che combina rigore nel rispetto delle sue pratiche e interazione umana tra gli sviluppatori, i fondamenti dell'XP abbracciano un'idea radicale: l'andare in produzione con fiducia e regolarità, senza compromettere la qualità o la flessibilità.

eXtreme Programming è una metodologia agile formalizzata da Kent Beck alla fine degli anni '90. Da un punto di vista storico, è una delle persone che ha innovato di più il mondo dello sviluppo del software tentando di dargli una forma. Le radici dell'eXtreme Programming provengono da una community legata a un linguaggio chiamato Smalltalk, che già negli anni '80 discuteva di continuous integration e test automatici. Concetti che per molti sviluppatori sono ancora molto lontani dalla realtà quotidiana, anche nel 2023.

Nascita

Il metodo eXtreme Programming, come dicevamo, nasce come una serie di pratiche sparse ideate all'interno della community Smalltalk. Sono proprio Kent Beck e Ward Cunningham a provarle per primi in un contesto reale, unendole ai concetti derivanti dal Lean. La sperimentazione sul campo permette a Kent Beck di scrivere il libro "Extreme Programming Explained" libro che ha formalizzato le pratiche funzionanti sul campo mettendole a servizio della community. Nel 2001 Beck e Cunningham partecipano alla stesura del manifesto Agile per lo sviluppo software insieme agli inventori di Scrum, Crystal, Software Adaptive Development e altre metodologie allora affini con i concetti di flessibilità. Dall'eXtreme Programming derivano gran parte dei principi del manifesto legati all'eccellenza tecnica, e non solo. Gran parte dei metodi agili più noti si concentrano principalmente sul processo di gestione dello sviluppo, eXtreme Programming fa un passo oltre, focalizzandosi sì su di esso, ma anche e soprattutto sulle pratiche tecniche che lo fanno emergere valorizzando il fatto che una buona gestione emerge da un software sano (quindi manutenibile) che a sua volta nasce da delle buone pratiche tecniche.

Successivamente la community ha prodotto una collana di libri che hanno approfondito sempre più gli aspetti di dettaglio dell'eXtreme Programming facendo nascere titoli come "Planning Extreme Programming", "Extreme Programming Installed", "Extreme Programming Applied", "Questioning Extreme Programming", "Extreme Programming Examined" ed altri. A differenza di quanto accaduto con Scrum, per volontà dei creatori di eXtreme Programming non sono nate delle certificazioni inerenti a questa metodologia, ma i concetti espressi sono rimasti di proprietà della community stessa, senza quindi scopo di lucro alcuno.

eXtreme Programming è, quindi, rimasto una collana di libri tramite cui si sono evoluti i concetti che hanno dato fondamento al metodo. L'esempio più significativo è il modo in cui si creano i test automatici: nella prima edizione di eXtreme Programming, non c'era il "test first" ma si parlava semplicemente di test automation; poi è stato introdotto il test-driven development, una delle pratiche fondanti di eXtreme Programming che analizzeremo in dettaglio nella prossima puntata della rubrica.

Ad oggi, molte di queste pratiche sono poco conosciute dagli sviluppatori, tanto che spesso si sa poco più del nome. Le pratiche dell'XP richiedono molto allenamento: eXtreme Programming, infatti, porta all'estremo concetti che funzionano in piccolo ma che, per essere applicati su larga scala e con costanza, richiedono impegno, disciplina e costanza da parte di tutti i membri del team.  

Portare all'estremo le pratiche del software

Si dice che l'eXtreme Programming è come avere a disposizione una serie di manopole che ci aiutano a spingere sempre di più all'estremo delle pratiche note nello sviluppo software. L'importante è essere coscienti di quanto sia il livello attuale e quello a cui vogliamo tendere come team. Le pratiche, come sono descritte dall'XP, sono il livello 10 delle manopole dell'estremismo.

Per farvi capire il concetto vi riporto i due esempi più significativi.

Il primo esempio di pratica portata all'estremo riguarda i test automatici: nello sviluppo software tradizionale, si riconosce l'importanza di testarlo e del controllo di qualità, questo è un assunto base, ma spesso si fa troppo tardi; eXtreme Programming porta all'estremo l'importanza del testing e della qualità, richiedendo che vengano creati e concepiti addirittura prima della scrittura del codice. Concepire i test prima fa sì che essi risultino una parte integrante del processo di sviluppo delle funzionalità. La radice storica di questo concetto viene dal Lean Manufacturing in particolare il principio di "Build Quality In". Il creatore di XP ha notato che portare all'estremo degli assunti di base dello sviluppo software produce risultati migliori.

Altra pratica esempio per spiegare il concetto di eXtreme è il "pair programming". Si tratta di una pratica - che approfondiremo nella prossima puntata di questa rubrica - in cui due persone sviluppano il codice insieme, con un unico computer di fronte a loro. La collaborazione tra persone nella scrittura del software permette lo scambio di idee, la discussione e il feedback continuo. Due persone insieme possono scrivere un software di migliore qualità. In questo caso sappiamo che lo sviluppo software è un attività socio-collaborativa perché coinvolge il pensiero e le idee di più persone messe insieme; anche qui l'eXtreme Programming porta all'estremo questo assunto dello sviluppo software affermando: rendiamo collaborativo ogni singolo minuti, secondo della scrittura del software accorciando al minimo possibile lo scambio di feedback facendo attivamente collaborare due team member su un'unica funzionalità.

Diffusione delle Pratiche

È difficile parlare di queste pratiche come pratiche mainstream. Anche quando si sente parlare di queste pratiche all'interno delle organizzazioni, spesso la loro effettiva applicazione è molto lontana dall’ideale. Spesso si sente dire: "Facciamo pair programming": la realtà dei fatti è spesso che due persone si trovano davanti al computer e ciascuna di loro guarda il proprio schermo. Ad essere mainstream - almeno in parte - è forse il nome delle pratiche ma il vero concetto che sta dietro, in realtà, è ancora lontano dall'essere compreso come dovrebbe.

Inoltre, se queste pratiche fossero così diffuse, non ci troveremmo nella situazione attuale che vediamo nel mondo del software. Guardiamo al codice scritto dalle organizzazioni ad oggi: è pieno di debito tecnico, di bug, difficile da manutenere e gli sviluppatori spesso si trovano impotenti nel tentativo di apportare modifiche e migliorare la situazione. Questo perché, nella quasi totalità dei casi, non sono state adottate le pratiche che dovrebbero evitare questi problemi. Quindi, se queste pratiche fossero davvero diffuse, non ci troveremmo in questa situazione.

Ma quindi perché non sono così diffuse? Il problema principale è proprio il debito tecnico. Esso è un ostacolo alla comprensione e alla sperimentazione delle pratiche più tecniche dell'XP. In un codice con alto debito tecnico adottare Test Driven Development o Simple Design oppure collective ownership tende all'impossibile se non si hanno basi solide nell'utilizzo di queste pratiche. Il risultato è che nella testa degli sviluppatori più giovani nella sperimentazione dell'XP le pratiche dell'XP non funzionano. Si esce da questo loop studiandole, provandole su contesti sicuri e greenfield, oppure studiando in prima battuta le tecniche di refactoring legacy code.

Come mi sono avvicinato a eXtreme Programming

Mi sono avvicinato all'eXtreme Programming da molto giovane; ho iniziato a studiare e sperimentare le prime pratiche dell'XP negli ultimi anni delle scuole superiori grazie a un professore illuminato che me le ha fatte conoscere. Anche se non mi ha insegnato direttamente l'eXtreme Programming, mi ha introdotto alle tecniche di collaborazione e al significato di qualità nel software. In quel periodo, ero già un appassionato di codice, tanto che la mia prima riga di codice risale a quando avevo poco più di 12 anni.

Ricordo quando capii che il metodo sarebbe stato importante per la mia carriera; dopo aver ottenuto uno dei voti più bassi in una verifica sulle metodologie, dissi al professore che non mi importava molto di quelle tecniche e che le tecnicità dello sviluppo erano molto più importanti. Quel giorno ho ricevuto uno "schiaffo" metaforico: il prof. mi fece capire che non potevo definirmi un vero software engineer senza conoscere le metodologie e i processi in modo impeccabile.Così ho allargato la mia visione sulle metodologie e ho iniziato a studiarle e a metterle davanti alla pura tecnica.

Ci fu successivamente un altro evento che mi avvicinò ulteriormente all'XP. Durante l'università a Trento, partecipai a un evento chiamato "ICT Days", in cui le aziende si presentano agli studenti. In quell'occasione ho assistito a una presentazione di Pietro Di Bello, uno dei massimi esperti di eXtreme Programming in Italia. Pietro ha mostrato l'importanza dei test automatici, di metodi come “la tecnica del pomodoro” e dell'avere una test suite. La presentazione mi scioccò a tal punto da correre da lui per chiedergli cosa avrei dovuto studiare per impararle.

Fu lui a darmi il libro "Extreme Programming Explained". Era circa il 2010-2011, e da lì è iniziata la mia avventura. Dopo una serie di colloqui, sono stato assunto dall'azienda in cui Pietro lavorava che prendeva l'eXtreme Programming come parte della cultura; il nome dell'azienda era XPeppers. L'approccio era severo ma necessario, e ho iniziato a lavorare su progetti, in cui le pratiche dell'XP venivano applicate realmente.

Nel mondo reale

Ho lavorato su progetti notevoli, ma uno dei più significativi è stato lo sviluppo di un sistema di payment gateway per il leader nazionale dei pagamenti. Il nostro obiettivo era andare in produzione ogni mercoledì rilasciando valore costantemente e nel modo più flessibile possibile. Ciò significava che non potevamo permetterci nemmeno un bug o una svista, altrimenti l'azienda avrebbe perso molte transazioni e quindi molti soldi.

Come potevamo garantirlo: avevamo una suite di oltre 3.000 test automatici, che venivano eseguiti ad ogni singolo commit. Ogni commit andava su trunk e doveva essere atomico e completamente testato questo produceva una versione del software potenzialmente rilasciabile ad ogni commit. Questa esperienza mi ha insegnato che l'andare in produzione non è un evento speciale: ma deve diventare la normalità. Mi si sono aperti gli occhi sulla forza delle pratiche dell'eXtreme Programming, e da allora ho continuato a promuoverne l'adozione ovunque andassi.

Controllo di Qualità Continuo

Gran parte delle pratiche dell'eXtreme Programming sono state progettate per permettere di andare in produzione con il massimo della flessibilità, senza i disagi tipici di un ambiente di produzione software disfunzionale. Questo obiettivo è raggiunto grazie al controllo di qualità continuo. Il pairing, ossia il lavoro a due nello sviluppo, garantisce una costante revisione del codice e assicura la qualità poiché i due sviluppatori monitorano il lavoro a vicenda. Inoltre, nel contesto dell'eXtreme Programming, c'è una rotazione delle coppie. Questo significa che oggi potresti sviluppare con un collega e domani con un altro membro del team, e questa rotazione è fondamentale.

Le 13 Pratiche dell'eXtreme Programming e la loro classificazione

Uno dei valori fondanti dell'XP è il feedback; il motivo è che il software è intangibile e ciò rende il feedback ancor più importante e centrale. Le 12 pratiche dell'XP rispondono a sistemi di feedback via via più ampi. Possiamo, quindi, categorizzare le pratiche in tre gruppi in base alla rapidità dei feedback che offrono.

Il primo gruppo comprende il pair programming, il test-driven development, il refactoring e il simple design. Queste quattro pratiche sono raggruppate insieme perché offrono il ciclo di feedback più breve. Per esempio, il TDD offre un ciclo di feedback di pochi minuti, mentre il pair programming è immediato e il refactoring e il design - se applicate frequentemente - anch'esse offrono cicli di feedback veloci.

Espandendo il sistema, troviamo un secondo gruppo di pratiche con un ciclo di feedback leggermente più lungo. Questo gruppo include la collective ownership, il sustainable pace, la metafora, la continuous integration e il coding standard. Queste cinque pratiche offrono un ciclo di feedback più lento rispetto al primo gruppo perché coinvolgono il sistema team nella sua interezza.

Infine, le ultime quattro pratiche hanno cicli di feedback più ampio, coinvolgendo l'intera organizzazione. Queste pratiche sono il planning game, le small releases, il customer test e il whole team. Il planning game riguarda come l'organizzazione pianifica, le small releases identificano la creazione delle più piccole release per fornire valore al cliente, il customer test coinvolge il customer nel testing del prodotto e il concetto di whole team implica che il team debba essere composto dalla più ampia varietà di persone che possono portare un'idea dalla concezione alla produzione.

Questo sistema di raggruppamento delle pratiche può essere utile per comprenderne meglio la portata e la relazione tra di esse. Tutte le pratiche dell'eXtreme Programming sono connesse tra loro rinforzandosi a vicenda l'un l'altra contribuendo attivamente alla realizzazione di un sistema team in grado di deliverare valore nel modo più adattabile e flessibile possibile.

Nel prossimo articolo inizieremo a scoprire nel dettaglio le 13 pratiche di eXtreme Programming  a partire dal ciclo di feedback più ristretto.