Extreme pro­gram­ming: un approccio estremo allo sviluppo di software

Esistono svariate evo­lu­zio­ni dello sviluppo agile di software. Accanto a Scrum e Kanban, si parla sempre e si utilizza l'extreme pro­gram­ming. Ma cos'ha di tanto estremo questo tipo di sviluppo?

L'extreme pro­gram­ming (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 pro­gram­ma­zio­ne tra­di­zio­na­le. L'extreme pro­gram­ming, pertanto, si distingue anche con­cre­ta­men­te dal modello a cascata, cosa che, secondo gli inventori dell'XP, porta con sé numerosi problemi. A metà degli anni 90, gli svi­lup­pa­to­ri Kent Beck, Ward Cun­nin­gham e Ron Jeffries hanno deciso di rinnovare di sana pianta l'ap­proc­cio classico di lavoro e di sondare nuove pos­si­bi­li­tà.

In linea generale l'extreme pro­gram­ming è 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 dif­fi­col­tà iniziano so­prat­tut­to quando questi desideri cambiano re­go­lar­men­te. L'XP cerca di stimolare la crea­ti­vi­tà degli svi­lup­pa­to­ri 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 dal­l'i­ni­zio alla fine e investire diversi mesi solo per ac­cor­ger­si alla fine che il risultato non va bene: con l'XP non succede più, perché si controlla, si discute e si pubblica co­stan­te­men­te, con cicli brevi. Ciò consente di in­di­vi­dua­re e risolvere tem­pe­sti­va­men­te gli errori.

Per sod­di­sfa­re i requisiti richiesti, è stato svi­lup­pa­to un framework estre­ma­men­te 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 mo­di­fi­ca­re l'ap­proc­cio di base del lavoro di pro­gram­ma­zio­ne. Il team deve essere unito nel seguire una de­ter­mi­na­ta mentalità, così da poter col­la­bo­ra­re al meglio e dare vita a un prodotto di prima qualità.

Nell'XP, la co­mu­ni­ca­zio­ne è im­por­tan­te sia tra i membri del team che tra svi­lup­pa­to­ri e clienti. Uno scambio continuo deve per­met­te­re di af­fron­ta­re di­ret­ta­men­te i problemi. Solo quando tutti i soggetti coinvolti si con­fron­ta­no con­ti­nua­men­te è possibile scoprire tem­pe­sti­va­men­te le criticità. Inoltre, la co­mu­ni­ca­zio­ne fa sì che tutti lavorino con lo stesso grado di co­no­scen­ze e si sentano impegnati nel progetto. Una buona con­ver­sa­zio­ne 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 que­st'ot­ti­ca rientra anche lo sviluppo solo delle fun­zio­na­li­tà ne­ces­sa­rie 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 suc­ces­si­ve di sviluppo che nella ma­nu­ten­zio­ne. Infine, un codice di pro­gram­ma­zio­ne quanto più semplice possibile consente di com­pren­de­re anche l'im­por­tan­za della co­mu­ni­ca­zio­ne: se tutto il team è in grado di capire il codice sorgente, diventa più facile con­fron­tar­si su di esso.

Anche questo valore è stret­ta­men­te legato alla grande im­por­tan­za della co­mu­ni­ca­zio­ne diretta. Il cliente deve poter esprimere le sue critiche il più spesso possibile. Nel­l'ex­tre­me pro­gram­ming, 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, è im­por­tan­te procedere gra­dual­men­te: il team lavora con cicli brevi, testa con­ti­nua­men­te il codice e sottopone anche al cliente i progressi dello sviluppo a in­ter­val­li brevi. Ciò consente di apportare tem­pe­sti­va­men­te modifiche e di risolvere gli errori.

Nel­l'ex­tre­me pro­gram­ming, per coraggio si intende la di­spo­ni­bi­li­tà a dire la verità, anche quando è spia­ce­vo­le. Se ci sono errori nel prodotto, devono essere co­mu­ni­ca­ti, anche quando se ne ha la re­spon­sa­bi­li­tà. In un team che lavora in base ai valori dell'XP, non c'è spazio per le scuse. Nessun com­po­nen­te del team dovrebbe cercare di mi­ni­miz­za­re il proprio coin­vol­gi­men­to in un errore, in quanto è un at­teg­gia­men­to non co­strut­ti­vo per il rag­giun­gi­men­to degli obiettivi. Inoltre, in questo contesto il coraggio è anche quello di mo­di­fi­ca­re le strutture del­l'or­ga­niz­za­zio­ne, di mettere in di­scus­sio­ne il proprio modo di lavorare, di accettare le critiche e magari anche di ri­scri­ve­re di sana pianta il codice.

Affinché il team lavori in armonia e possa giungere a pre­sta­zio­ni ec­cel­len­ti, è im­por­tan­te il rispetto reciproco. Un valore che implica anche, ad esempio, che il lavoro di un com­po­nen­te del team non deve essere sabotato dalle modifiche apportate da un altro svi­lup­pa­to­re. La stima è im­por­tan­te in tutti gli attori coinvolti, dal team al cliente. Solo quando si prendono a cuore gli interessi del­l'al­tro si può reagire in modo ap­pro­pria­to. Infine, anche la direzione deve mostrare rispetto al team di sviluppo e fornire ai col­la­bo­ra­to­ri le com­pe­ten­ze e le risorse ne­ces­sa­rie.

Nel­l'ex­tre­me pro­gram­ming, i principi si trovano tra i valori e la prassi, e sono pertanto l'anello di con­giun­zio­ne 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 pro­ve­nien­ti dal sistema stesso (durante il test del codice) devono essere im­ple­men­ta­ti nel giro di secondi o minuti, invece di rac­co­glie­re prima il feedback, ad esempio. Il feedback dei clienti, invece, deve essere ottenuto e preso in con­si­de­ra­zio­ne nel giro di giorni o settimane.

Il principio della sem­pli­ci­tà cor­ri­spon­de fon­da­men­tal­men­te al­l'o­mo­ni­mo valore, ma implica in­di­ca­zio­ni di im­ple­men­ta­zio­ne più concrete. I metodi uti­liz­za­ti in tal senso sono due:

• You ain’t gonna need it (YAGNI): per non fare lavoro inutile, fintanto che una fun­zio­na­li­tà non viene richiesta con­cre­ta­men­te, non va im­ple­men­ta­ta.
• Don’t repeat yourself (DRY): si deve evitare di fare doppio lavoro e anche il codice deve essere strut­tu­ra­to in modo tale da non dover apportare una modifica in più punti, ma sempre solo una volta.

Nel­l'ex­tre­me pro­gram­ming, le modifiche vengono sempre eseguite gra­dual­men­te. Invece di attuare grandi ag­gior­na­men­ti per eliminare diverse fonti di errore in una sola volta, si affronta un problema dopo l'altro. In questo modo il team reagisce più ra­pi­da­men­te e le modifiche possono essere seguite meglio. Il principio non si riferisce però solo al codice di pro­gram­ma­zio­ne. Anche le modifiche nella pro­get­ta­zio­ne o ad­di­rit­tu­ra nella struttura del team devono essere svolte in piccoli passaggi in­cre­men­ta­li.

Poiché l'extreme pro­gram­ming mette al centro il cliente, at­tri­bui­sce un grande valore anche alle sue richieste di modifiche. Pertanto tutto il team deve vedere po­si­ti­va­men­te tali modifiche, invece di osta­co­lar­le. 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 im­por­tan­te per il fun­zio­na­men­to del­l'ex­tre­me pro­gram­ming: il team deve fornire un lavoro di alta qualità. Cosa si intende per alta qualità, lo sta­bi­li­sce 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 sod­di­sfat­to della pre­sta­zio­ne fornita, le ri­per­cus­sio­ni sul morale sono positive.

Le pratiche dell'XP sono in­di­ca­zio­ni concrete sui metodi di lavoro. Mentre i valori e i principi il­lu­stra­ti si applicano anche agli altri metodi di lavoro agili, le tecniche concrete del­l'ex­tre­me pro­gram­ming sono una pe­cu­lia­ri­tà di questo metodo. Anch'esse sono leg­ger­men­te cambiate nel tempo e variano da una fonte all'altra. In generale, le tecniche vengono suddivise in quattro ambiti.

Nel­l'ex­tre­me pro­gram­ming, i team di svi­lup­pa­to­ri lavorano in cicli estre­ma­men­te brevi. Ciò consente di testare con­ti­nua­men­te il codice scritto. Il Test-Driven De­ve­lo­p­ment va ancora oltre: gli svi­lup­pa­to­ri, infatti, scrivono un ambiente di test prima ancora di creare il codice sorgente effettivo. Il codice che non supera questo test non può essere pro­se­gui­to. In tal caso il feedback arriva di­ret­ta­men­te dal sistema.

Il co­sid­det­to Planning Game è una riunione che si effettua al­l'i­ni­zio di ogni fase di pro­gram­ma­zio­ne. Il team e il cliente si in­con­tra­no 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 rap­pre­sen­tan­te del cliente deve essere un membro fisso del team, in modo da ri­spon­de­re tem­pe­sti­va­men­te alle domande o il­lu­stra­re idee o priorità.

Il pair pro­gram­ming, infine, assicura il principio del doppio controllo: due persone lavorano sempre con­tem­po­ra­nea­men­te allo stesso codice. Mentre un collega scrive il codice, l'altro controlla il codice sorgente, propone mi­glio­ra­men­ti e indica eventuali errori. Si tratta di un metodo però molto costoso in quanto richiede l'impiego di due col­la­bo­ra­to­ri per un unico compito; d'altro canto, il codice ri­sul­tan­te è de­ci­sa­men­te migliore e si traduce in meno ri­fi­ni­tu­re suc­ces­si­ve.

I team dell'XP rivedono con­ti­nua­men­te il loro codice. Questo re­fac­to­ring serve a mi­glio­ra­re il testo sorgente e a rimuovere ri­pe­ti­zio­ni ed elementi superflui. Un codice così ot­ti­miz­za­to è com­pren­si­bi­le, anche a lettori esterni, e meno soggetto a errori.

Con la con­ti­nuous in­te­gra­tion, nell' extreme pro­gram­ming e in altri metodi di lavoro agili, i team ef­fet­tua­no l'in­te­gra­zio­ne continua di nuovo codice nel progetto com­ples­si­vo. Uno svi­lup­pa­to­re inserisce più volte al giorno il suo lavoro nel progetto. Così i singoli con­tri­bu­ti vengono con­trol­la­ti con­ti­nua­men­te e tutti i soggetti coinvolti lavorano con materiale ag­gior­na­to.

L'XP prevede che programmi e ag­gior­na­men­ti fun­zio­nan­ti vengano ri­la­scia­ti il prima possibile. Le small releases aumentano anche la frequenza dei feedback. Così gli errori possono essere in­di­vi­dua­ti molto più ra­pi­da­men­te ed eliminati con l'ag­gior­na­men­to suc­ces­si­vo. Il cliente ha sempre la pos­si­bi­li­tà di provare la versione più ag­gior­na­ta dello sviluppo e di esporre critiche e proposte.

Con una pro­get­ta­zio­ne semplice (Simple Design), il codice risulta com­pren­si­bi­le a tutti i soggetti coinvolti. Tutto ciò che rende inu­til­men­te complesso il codice sorgente deve essere eliminato. Gli svi­lup­pa­to­ri che lavorano secondo l'extreme pro­gram­ming devono eliminare tutti i duplicati. In più, il codice sorgente deve rendere chiaro l'o­biet­ti­vo della pro­gram­ma­zio­ne.

Per con­sen­ti­re a tutto il team di lavorare di pari passo, fon­da­men­tal­men­te vengono stabiliti dei "Coding Standards". Queste direttive si ri­fe­ri­sco­no al­l'ap­proc­cio e al formato. I colleghi devono potersi orientare anche nel codice degli altri; in più deve essere sempre possibile stabilire chia­ra­men­te chi ha apportato de­ter­mi­na­te modifiche.

La Col­lec­ti­ve Code Ownership rafforza la pos­si­bi­li­tà di lavorare insieme sul codice: invece di far notare chi è re­spon­sa­bi­le di un de­ter­mi­na­to pezzo (e quindi degli errori contenuti), il codice è con­si­de­ra­to un prodotto globale. Pertanto tutto il team è re­spon­sa­bi­le tanto degli errori quanto dei successi. Questa tecnica invita inoltre a rivedere il codice degli altri e a esprimere le proprie idee.

Per aumentare ul­te­rior­men­te la com­pren­sio­ne del codice sorgente, nel­l'ex­tre­me pro­gram­ming si utilizza la tecnica del System Metaphor. Questa pratica consiste nel de­scri­ve­re il progetto con la massima sem­pli­ci­tà, uti­liz­zan­do anche metafore. Un approccio che implica anche delle con­ven­zio­ni nella de­no­mi­na­zio­ne di elementi, classi o funzioni nel codice, che siano pos­si­bil­men­te intuitivi. I nuovi col­la­bo­ra­to­ri che su­ben­tra­no nel progetto devono così poter capire ra­pi­da­men­te questi aspetti. Così anche chi non è pro­gram­ma­to­re può farsi un'idea del codice sorgente.

Il benessere del team è fon­da­men­ta­le per il successo del progetto: solo dei col­la­bo­ra­to­ri riposati e motivati possono dare risultati di alta qualità. Per ga­ran­tir­lo, l'extreme pro­gram­ming prevede la settimana di 40 ore (40-Hour Week). Le ore di straor­di­na­rio devono essere evitate a tutti i costi e sono con­sen­ti­te solo se nella settimana non se ne ac­cu­mu­la­no altre.

Nel­l'ex­tre­me pro­gram­ming, i ruoli servono a sud­di­vi­de­re i compiti e le com­pe­ten­ze tra tutti i soggetti coinvolti, svi­lup­pa­to­ri e clienti che siano.

L'extreme pro­gram­ming è molto orientato al cliente, al punto da essere con­si­de­ra­to un elemento del team e da ri­chie­de­re la presenza di almeno un suo rap­pre­sen­tan­te sul posto (On-Site Customer). Il cliente pone i requisiti per il prodotto, ma si esprime solo li­mi­ta­ta­men­te su come rag­giun­ge­re gli obiettivi. Nella sua sfera di com­pe­ten­za rientra solo l'as­se­gna­zio­ne 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 rap­pre­sen­tan­ti del cliente. Nella prassi, spesso sono i product manager o anche gli addetti del­l'uf­fi­cio marketing ad assumersi questo compito (sempre nel rispetto del­l'o­biet­ti­vo del progetto).

Il team di svi­lup­pa­to­ri non ha ulteriori sud­di­vi­sio­ni. Ciò significa che tutti coloro che creano at­ti­va­men­te il prodotto assolvono il ruolo di svi­lup­pa­to­ri. Tra questi rientrano non solo i pro­gram­ma­to­ri, ma anche altre persone coinvolte nella creazione, in base alle esigenze poste dal progetto. Oltre al lavoro di sviluppo vero e proprio, compito degli svi­lup­pa­to­ri è anche ri­spon­de­re alle esigenze del cliente: stimare le spese, redigere una tabella di marcia, pro­gram­ma­re l'im­ple­men­ta­zio­ne.

Tra i diritti degli svi­lup­pa­to­ri rientra quello di cercare gli aiuti necessari, e quindi ad esempio ri­chie­de­re altre risorse alla direzione. Inoltre, secondo le tecniche dell'XP, per gli svi­lup­pa­to­ri vale la settimana di 40 ore. Per il bene del progetto, gli svi­lup­pa­to­ri non devono lavorare troppo. Pertanto, il team di svi­lup­pa­to­ri sta­bi­li­sce au­to­no­ma­men­te la sua tabella di marcia.

Il manager ha il ruolo di anello di con­giun­zio­ne tra svi­lup­pa­to­ri e clienti. Le persone ap­par­te­nen­ti a questa categoria portano gli altri due a uno stesso tavolo e moderano ad esempio la pia­ni­fi­ca­zio­ne. Il manager si preoccupa per prima cosa che vengano ri­spet­ta­te le regole stabilite pre­ce­den­te­men­te e le con­ven­zio­ni generali di una di­scus­sio­ne co­strut­ti­va. 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 im­por­tan­ti (ad esempio il tempo speso da ogni col­la­bo­ra­to­re per il progetto).

Tutto il team (incluso il cliente) deve conoscere l'extreme pro­gram­ming e applicare coe­ren­te­men­te 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 con­su­len­te esterno, proprio come uno Scrum Master. Nei colloqui pre­li­mi­na­ri con il coach, si possono ana­liz­za­re le regole e le pratiche. Nella migliore delle ipotesi, il coach ac­com­pa­gna il team lungo l'intero percorso di sviluppo e in­ter­vie­ne in caso di domande o di dubbi.

Spesso tale ruolo è rivestito da un fornitore esterno. Il coach può anche però essere un soggetto interno al­l'a­zien­da, magari di un altro ufficio. Vanno evitati i doppi ruoli (ad esempio uno svi­lup­pa­to­re che svolge anche il ruolo di coach).

L'extreme pro­gram­ming ha dato impulsi im­por­tan­ti alla modalità di sviluppo di software, ma non è indicato per tutte le si­tua­zio­ni e per tutti i team. L'XP parte dal pre­sup­po­sto che, al­l'i­ni­zio del progetto, il cliente non abbia ancora un'idea precisa del prodotto finito. In tal caso, il software può essere pro­get­ta­to in modo agile, con una pro­get­ta­zio­ne in continua evo­lu­zio­ne.

Così facendo, da un lato si soddisfa il cliente, in quanto si cerca di trovare insieme a lui la soluzione giusta, coin­vol­gen­do­lo in ogni fase. Dal­l'al­tro, gli svi­lup­pa­to­ri possono im­ple­men­ta­re i progetti in base alle loro va­lu­ta­zio­ni, invece di dover fare sempre dei com­pro­mes­si. Se invece il cliente arriva con una de­scri­zio­ne già pronta del prodotto e una lista di funzioni da con­se­gna­re al team di svi­lup­pa­to­ri, è molto difficile uti­liz­za­re l'XP.

Già il pair pro­gram­ming può mettere i piccoli team davanti a dei problemi se le risorse ne­ces­sa­rie non sono di­spo­ni­bi­li. Anche gli incontri periodici con il cliente ri­chie­do­no tempo, sottratto al lavoro effettivo di pro­gram­ma­zio­ne. In una si­tua­zio­ne ideale ciò non conta: il risultato sarà ine­qui­vo­ca­bil­men­te migliore se il team può con­ce­der­si il tempo ne­ces­sa­rio e le risorse richieste.

Nella pratica, però, gli svi­lup­pa­to­ri sono sotto pressione per via del budget limitato e delle scadenze stabilite. In più, il cliente potrebbe non avere interesse o le pos­si­bi­li­tà di im­pe­gnar­si nel progetto nella misura richiesta dall'XP.

Se invece le cir­co­stan­ze con­sen­to­no di procedere in base al­l'ex­tre­me pro­gram­ming, con questo metodo un team può fornire risultati ec­cel­len­ti. I test continui si traducono in sistemi stabili, e la procedura iterativa, insieme al­l'ap­proc­cio mi­ni­ma­li­sti­co, fa sì che vengano create davvero solo le funzioni ne­ces­sa­rie per il progetto.