Extreme programming

Pianificazione e cicli di feedback nella programmazione estrema

La programmazione estrema (in inglese extreme programming, abbreviata XP) è una metodologia agile di sviluppo software, caratterizzata da cicli di sviluppo brevi, frequenti riscontri da parte del cliente e un insieme coordinato di pratiche di ingegneria del software. Il metodo è concepito per favorire l'adattamento ai cambiamenti dei requisiti e il miglioramento della qualità del software, attraverso la collaborazione tra i membri del gruppo di sviluppo e il coinvolgimento del cliente.

L'extreme programming fu sviluppato negli anni novanta da Kent Beck, in particolare nell'ambito del progetto Chrysler Comprehensive Compensation (C3), finalizzato alla realizzazione di un sistema per la gestione delle retribuzioni della Chrysler. Il metodo venne descritto sistematicamente da Beck nel libro Extreme Programming Explained: Embrace Change, pubblicato nel 1999 e successivamente rielaborato in una seconda edizione, scritta con Cynthia Andres e pubblicata nel 2004.

Tra le pratiche caratteristiche del metodo figurano la programmazione in coppia (pair programming), lo sviluppo guidato dai test, il refactoring, l'integrazione continua e i rilasci frequenti di software funzionante. Tali pratiche si fondano su cinque valori: comunicazione, semplicità, feedback, coraggio e rispetto. La denominazione extreme programming deriva dall'idea di applicare con particolare intensità alcune pratiche considerate efficaci nell'ingegneria del software, portandole a un livello definito «estremo».

Storia

Origini e sviluppo

Le origini dell'extreme programming risalgono alla fine degli anni ottanta, nell'ambiente degli sviluppatori del linguaggio di programmazione Smalltalk. In questo contesto, Kent Beck e Ward Cunningham collaborarono allo sviluppo di pratiche di ingegneria del software orientate all'adattamento ai cambiamenti e alla collaborazione tra i membri dei gruppi di sviluppo. Durante i primi anni novanta, entrambi continuarono a sperimentare e perfezionare tali pratiche nell'ambito di diversi progetti software.

Il passaggio da un insieme di pratiche sperimentali a un metodo di sviluppo riconoscibile avvenne nel 1996, quando Beck assunse la guida tecnica del progetto Chrysler Comprehensive Compensation (C3), dedicato alla realizzazione di un sistema per la gestione delle retribuzioni della Chrysler. Il progetto rappresentò il principale contesto nel quale le pratiche che avrebbero costituito l'extreme programming furono integrate in un approccio unitario. Secondo Martin Fowler, che partecipò al progetto come consulente, Beck iniziò a utilizzare la denominazione extreme programming intorno al 1997.

Nella seconda metà degli anni novanta, il metodo iniziò a diffondersi attraverso gruppi di discussione su Internet e il wiki creato da Cunningham, dove Beck e Ron Jeffries, anch'egli coinvolto nel progetto C3, contribuirono alla descrizione e alla discussione delle pratiche XP. Un momento importante nella formalizzazione e nella diffusione del metodo fu la pubblicazione, nel 1999, del libro Extreme Programming Explained: Embrace Change, scritto da Beck ed edito da Addison-Wesley, nel quale vennero esposti sistematicamente i valori, i principi e le pratiche dell'approccio.

Il progetto Chrysler C3

Il progetto Chrysler Comprehensive Compensation (C3) aveva l'obiettivo di sostituire diversi sistemi preesistenti per la gestione delle retribuzioni dei dipendenti della Chrysler, basati principalmente sul linguaggio COBOL, con un'applicazione unificata. Lo sviluppo del nuovo sistema, realizzato in Smalltalk, iniziò nel 1995, ma incontrò difficoltà tecniche e organizzative che impedirono di raggiungere i risultati previsti.

Nel 1996 Kent Beck venne coinvolto nel progetto per esaminarne i problemi. In seguito alla sua valutazione, il codice esistente fu abbandonato e lo sviluppo riprese adottando un nuovo approccio. Beck assunse il ruolo di consulente e responsabile metodologico, mentre Ron Jeffries contribuì al coordinamento quotidiano del gruppo. Furono introdotte pratiche quali la programmazione in coppia, i test automatizzati, il refactoring, l'integrazione continua e la pianificazione attraverso brevi iterazioni. L'esperienza costituì il principale contesto di definizione e sperimentazione dell'extreme programming.

Nel maggio 1997 una prima versione del sistema entrò in produzione e venne utilizzata per elaborare le retribuzioni di circa 10 000 dipendenti. L'obiettivo successivo era estenderne l'utilizzo ad altre categorie di personale, fino a sostituire progressivamente i sistemi precedenti. Nonostante il proseguimento dello sviluppo, le ulteriori fasi di distribuzione non furono completate.

Secondo la ricostruzione di Martin Fowler, le attività di sviluppo di nuove funzionalità furono interrotte nel 1999. La conclusione formale del progetto è documentata al 1º febbraio 2000, senza che fosse stata completata la successiva fase di distribuzione. Nel resoconto di un intervento di Jeffries alla conferenza XP 2000, Fowler riportò tra le difficoltà emerse la divergenza di obiettivi tra il dipartimento responsabile delle retribuzioni e quello dei sistemi informativi, oltre al deterioramento della comunicazione tra il gruppo di sviluppo e i responsabili aziendali.

Il sistema inizialmente distribuito rimase operativo anche dopo l'interruzione dello sviluppo, prima di essere successivamente sostituito. L'esperienza di C3 ebbe un ruolo significativo nella diffusione iniziale dell'extreme programming, pur non avendo raggiunto l'obiettivo originario di sostituire integralmente i sistemi di gestione delle retribuzioni della Chrysler.

Evoluzione del metodo

La prima formulazione sistematica dell'extreme programming fu pubblicata da Kent Beck nel 1999, nel volume Extreme Programming Explained: Embrace Change. Il metodo era organizzato attorno a quattro valori fondamentali — comunicazione, semplicità, feedback e coraggio — e a dodici pratiche di sviluppo software, comprendenti, tra le altre, la programmazione in coppia, l'integrazione continua, il refactoring e la presenza di un rappresentante del cliente all'interno del gruppo di sviluppo. Questa formulazione era rivolta principalmente a gruppi di sviluppo di piccole dimensioni, impegnati in progetti caratterizzati da requisiti incerti o soggetti a frequenti cambiamenti.

Nel febbraio 2001, Beck partecipò a un incontro tenutosi a Snowbird, nello Utah, insieme ad altri sedici esperti di sviluppo software, tra cui Ward Cunningham, Martin Fowler e Ron Jeffries. L'incontro portò alla redazione del Manifesto per lo sviluppo agile del software (Manifesto for Agile Software Development), che individuò quattro valori comuni a diversi approcci di sviluppo già esistenti, tra i quali l'extreme programming. Il metodo XP precedette quindi la formulazione del manifesto e contribuì alla nascita del movimento dello sviluppo agile del software.

Nel 2004 Beck pubblicò, insieme a Cynthia Andres, una seconda edizione di Extreme Programming Explained, nella quale il metodo venne ampiamente rielaborato alla luce delle esperienze maturate negli anni precedenti. Ai quattro valori originari fu aggiunto il rispetto, mentre le dodici pratiche della prima edizione furono riorganizzate in tredici pratiche primarie e undici pratiche corollarie. Le prime venivano presentate come il punto di partenza per l'adozione del metodo, mentre le seconde riguardavano aspetti la cui applicazione poteva richiedere un maggiore consolidamento delle capacità del gruppo di sviluppo.

La revisione modificò anche la formulazione di alcune pratiche. Il principio della settimana lavorativa di quaranta ore (40-hour week) venne rielaborato nel concetto di lavoro sostenibile (energized work), mentre l'indicazione della presenza continuativa di un cliente presso il gruppo di sviluppo (on-site customer) lasciò spazio a una concezione più ampia della collaborazione, articolata nelle pratiche relative al gruppo di lavoro completo (whole team) e al coinvolgimento effettivo del cliente (real customer involvement).

Secondo Fowler, la seconda edizione rappresentò una riformulazione significativa dell'extreme programming, pur mantenendone l'impostazione generale. La distinzione tra le due edizioni è rilevante anche per l'interpretazione della letteratura sul metodo, poiché numerose descrizioni dell'XP continuano a fare riferimento alle pratiche originariamente presentate nel 1999.

Caratteristiche generali

Obiettivi e approccio iterativo

L'extreme programming adotta un approccio iterativo e incrementale allo sviluppo software, concepito per consentire l'adattamento a requisiti che possono modificarsi nel corso del progetto. Il lavoro viene organizzato in cicli di sviluppo brevi, denominati iterazioni, durante i quali vengono realizzate e verificate porzioni di funzionalità del sistema. L'obiettivo è disporre frequentemente di software funzionante, da sottoporre alla valutazione del cliente per ottenere indicazioni utili alle attività successive.

La pianificazione si basa su descrizioni sintetiche delle funzionalità richieste, generalmente espresse attraverso storie utente (user stories). Il gruppo di sviluppo ne valuta l'impegno necessario alla realizzazione, mentre il cliente o un suo rappresentante ne stabilisce le priorità in funzione delle esigenze del progetto. All'inizio di ogni iterazione vengono selezionate le funzionalità da sviluppare, tenendo conto delle priorità e delle capacità del gruppo. I risultati ottenuti possono determinare una revisione delle attività previste nelle iterazioni successive.

Nella formulazione presentata nella seconda edizione di Extreme Programming Explained, l'organizzazione del lavoro comprende un ciclo settimanale (weekly cycle), dedicato alla pianificazione e alla realizzazione delle funzionalità a breve termine, e un ciclo trimestrale (quarterly cycle), destinato a definire obiettivi e priorità su un orizzonte più ampio. Questi cicli permettono di coordinare le attività immediate con la pianificazione dei rilasci, mantenendo la possibilità di modificarne i contenuti sulla base delle informazioni acquisite durante lo sviluppo.

L'approccio iterativo non elimina le attività di analisi, progettazione e verifica, ma ne prevede lo svolgimento ricorrente durante l'evoluzione del sistema. La progettazione viene progressivamente adattata alle funzionalità da realizzare, mentre i test automatizzati e l'integrazione frequente delle modifiche contribuiscono a individuare tempestivamente eventuali problemi. Il metodo mira così a contenere il costo delle modifiche e a mantenere il software in condizioni tali da consentirne l'ulteriore sviluppo.

Rapporto con lo sviluppo agile

L'extreme programming è uno dei metodi di sviluppo software associati al movimento delle metodologie agili. La sua formulazione precede la pubblicazione del Manifesto per lo sviluppo agile del software del 2001, che individuò un insieme di valori condivisi da diversi approcci già esistenti. L'XP contribuì alla formazione di questo movimento attraverso l'esperienza dei suoi ideatori e la diffusione delle pratiche di sviluppo iterativo e collaborativo.

L'XP condivide con gli altri approcci agili l'attenzione alla collaborazione tra sviluppatori e clienti, alla disponibilità di software funzionante e alla capacità di rispondere ai cambiamenti dei requisiti. Questi aspetti corrispondono ad alcuni dei valori enunciati nel Manifesto Agile, che attribuisce maggiore importanza agli individui e alle interazioni rispetto ai processi e agli strumenti, al software funzionante rispetto alla documentazione esaustiva, alla collaborazione con il cliente rispetto alla negoziazione contrattuale e alla risposta al cambiamento rispetto alla rigida osservanza di un piano.

Rispetto ad altri approcci agili, l'extreme programming si caratterizza per l'attenzione specifica alle pratiche tecniche di sviluppo software. Il metodo comprende infatti indicazioni relative alla progettazione, alla scrittura e alla verifica del codice, attraverso pratiche quali la programmazione in coppia, lo sviluppo guidato dai test, il refactoring e l'integrazione continua. Queste pratiche costituiscono un insieme coordinato, concepito per sostenere la capacità del gruppo di apportare modifiche frequenti al sistema.

Una distinzione significativa può essere stabilita con Scrum, un altro approccio agile che si concentra principalmente sull'organizzazione del lavoro e sulla gestione iterativa dei prodotti. Scrum definisce responsabilità, eventi e artefatti, tra cui gli sprint e il product backlog, senza prescrivere specifiche tecniche di programmazione. L'XP, pur comprendendo anche pratiche di pianificazione e collaborazione, fornisce invece indicazioni dettagliate sulle attività di ingegneria del software.

La diversa impostazione rende possibile l'impiego di pratiche tecniche dell'XP all'interno di gruppi che utilizzano Scrum per organizzare il lavoro. I due approcci non sono tuttavia equivalenti: l'adozione di singole pratiche dell'extreme programming non implica necessariamente l'applicazione del metodo nel suo insieme.

Valori e principi

Valori fondamentali

L'extreme programming si fonda su un insieme di valori destinati a orientare le decisioni e le pratiche del gruppo di sviluppo. Nella prima edizione di Extreme Programming Explained, pubblicata nel 1999, Kent Beck individuò quattro valori fondamentali: comunicazione, semplicità, feedback e coraggio. Nella seconda edizione del 2004, scritta insieme a Cynthia Andres, venne aggiunto il rispetto, portando a cinque il numero dei valori esplicitamente riconosciuti dal metodo.

I cinque valori sono definiti nel modo seguente:

• Comunicazione (communication): riguarda lo scambio continuo di informazioni tra i membri del gruppo di sviluppo e le altre persone coinvolte nel progetto. Il metodo attribuisce particolare importanza alla comunicazione diretta, alla condivisione delle conoscenze e alla collaborazione, allo scopo di ridurre le incomprensioni sui requisiti e sulle attività da svolgere. Pratiche come la programmazione in coppia e il coinvolgimento del cliente sono concepite anche per favorire tale comunicazione.

• Semplicità (simplicity): consiste nel privilegiare le soluzioni più semplici in grado di soddisfare i requisiti effettivamente conosciuti. Il metodo scoraggia l'introduzione anticipata di funzionalità e strutture non necessarie, favorendo invece una progettazione che possa essere modificata progressivamente. La semplicità non implica l'assenza di progettazione, ma la ricerca di soluzioni adeguate alle esigenze presenti.

• Feedback: indica l'acquisizione e l'utilizzo frequente di informazioni sui risultati del lavoro svolto. Il feedback proviene, tra l'altro, dai test automatizzati, dalla collaborazione tra sviluppatori e dalle valutazioni del cliente sulle funzionalità realizzate. Queste informazioni permettono di individuare errori, verificare le ipotesi di sviluppo e modificare le decisioni progettuali nelle iterazioni successive.

• Coraggio (courage): rappresenta la disponibilità ad affrontare problemi tecnici e organizzativi, riconoscere gli errori e modificare decisioni precedenti quando le informazioni disponibili lo rendono necessario. Comprende la capacità di comunicare difficoltà e rischi, accettare le osservazioni degli altri e intervenire su soluzioni esistenti. Nel metodo, il coraggio è associato alla responsabilità delle decisioni e non all'assunzione indiscriminata di rischi.

• Rispetto (respect): riguarda il riconoscimento del contributo e delle responsabilità delle persone coinvolte nel progetto. Si manifesta nella considerazione reciproca tra i membri del gruppo, nell'ascolto delle diverse competenze e nella collaborazione con il cliente e gli altri soggetti interessati. Il rispetto è considerato una condizione necessaria per sostenere la comunicazione, la condivisione delle conoscenze e l'accettazione del feedback.

I cinque valori non costituiscono procedure operative autonome, ma rappresentano il riferimento concettuale dal quale derivano i principi e le pratiche dell'extreme programming. Secondo l'impostazione di Beck e Andres, i valori forniscono criteri generali di orientamento, i principi ne precisano le implicazioni per lo sviluppo software e le pratiche individuano comportamenti concreti attraverso i quali applicarli.

Principi

Nell'extreme programming, i principi costituiscono il collegamento tra i valori generali del metodo e le pratiche adottate durante lo sviluppo software. Essi forniscono criteri per orientare le decisioni del gruppo di sviluppo e adattare le pratiche alle caratteristiche dei singoli progetti.

Nella prima edizione di Extreme Programming Explained del 1999, Kent Beck individuò cinque principi fondamentali: feedback rapido (rapid feedback), presupposizione della semplicità (assume simplicity), cambiamento incrementale (incremental change), accettazione del cambiamento (embracing change) e lavoro di qualità (quality work). Questi erano affiancati da dieci ulteriori principi, riguardanti, tra gli altri aspetti, l'apprendimento, la sperimentazione, la comunicazione, l'assunzione di responsabilità e l'adattamento del metodo al contesto.

Nella seconda edizione del 2004, Beck e Cynthia Andres riorganizzarono il quadro teorico in quattordici principi, presentati come criteri generali per l'applicazione dei valori e delle pratiche dell'extreme programming.

I quattordici principi sono:

• Umanità (humanity): considera lo sviluppo software un'attività svolta da persone, le cui esigenze individuali e relazionali influiscono sull'organizzazione e sui risultati del lavoro. Il principio attribuisce importanza alle condizioni di lavoro, alla collaborazione e alla possibilità di conciliare le esigenze delle persone con quelle del progetto.

• Economia (economics): richiede di considerare le conseguenze economiche delle decisioni di sviluppo, valutando costi, benefici e tempi di realizzazione. La scelta delle attività e delle funzionalità deve tenere conto del valore che esse possono produrre per il cliente.

• Beneficio reciproco (mutual benefit): privilegia le attività che producono vantaggi per più soggetti coinvolti nel progetto, sia nell'immediato sia nel lungo periodo. La realizzazione di test automatizzati, per esempio, può sostenere il lavoro degli sviluppatori e facilitare la successiva manutenzione del software.

• Autosimilarità (self-similarity): consiste nel riconoscere e riutilizzare modalità di soluzione efficaci a differenti livelli di organizzazione del lavoro. Schemi di comportamento applicati a un'attività circoscritta possono quindi orientare anche la gestione di processi più ampi, quando le circostanze sono analoghe.

• Miglioramento (improvement): considera il perfezionamento del prodotto e del processo di sviluppo un'attività continua. Le soluzioni adottate vengono progressivamente riviste sulla base dell'esperienza e delle nuove informazioni disponibili.

• Diversità (diversity): riconosce il contributo di competenze, esperienze e prospettive differenti all'interno del gruppo di sviluppo. La presenza di punti di vista diversi può favorire l'individuazione di problemi e alternative progettuali, purché sia accompagnata da un'efficace collaborazione.

• Riflessione (reflection): prevede che il gruppo esamini periodicamente le proprie attività, i risultati raggiunti e le difficoltà incontrate. Le osservazioni emerse vengono utilizzate per modificare e migliorare il modo di lavorare.

• Flusso (flow): favorisce la continuità delle attività di sviluppo e la realizzazione di piccoli incrementi di software, riducendo le interruzioni e i tempi di attesa tra le diverse operazioni. Questo principio è associato alla frequente integrazione e verifica delle modifiche.

• Opportunità (opportunity): considera le difficoltà e i cambiamenti come possibili occasioni di apprendimento e miglioramento. Gli imprevisti possono fornire informazioni utili per rivedere le soluzioni tecniche e organizzative.

• Ridondanza (redundancy): prevede l'impiego di più meccanismi di controllo o prevenzione per affrontare problemi particolarmente importanti. Nell'extreme programming, pratiche differenti possono contribuire congiuntamente all'individuazione degli errori e alla riduzione dei rischi.

• Fallimento (failure): riconosce che gli esiti negativi di esperimenti e tentativi di soluzione possono contribuire all'apprendimento. Quando non è possibile stabilire anticipatamente quale soluzione sia più adeguata, il metodo favorisce esperimenti circoscritti dai quali ricavare informazioni.

• Qualità (quality): considera la qualità del software un elemento da preservare durante lo sviluppo, anziché una variabile da ridurre per accelerare il lavoro. Il principio è collegato all'impiego sistematico di pratiche di verifica e miglioramento del codice.

• Piccoli passi (baby steps): privilegia cambiamenti limitati e progressivi rispetto a interventi estesi realizzati in un'unica soluzione. La ridotta dimensione delle modifiche facilita la verifica dei risultati e la possibilità di correggere eventuali errori.

• Assunzione della responsabilità (accepted responsibility): stabilisce che le responsabilità operative debbano essere assunte consapevolmente dalle persone incaricate delle attività. Il principio collega l'impegno a svolgere un lavoro alla partecipazione alle decisioni e alla valutazione delle attività necessarie per completarlo.

Nel loro insieme, questi principi definiscono il quadro concettuale attraverso il quale vengono interpretate e adattate le pratiche del metodo. Beck e Andres non li presentano come procedure da eseguire in una sequenza prestabilita, ma come criteri per valutare le scelte tecniche e organizzative durante lo sviluppo del software.

Pratiche

Le dodici pratiche originarie

Nella prima edizione di Extreme Programming Explained: Embrace Change, pubblicata nel 1999, Kent Beck descrisse dodici pratiche fondamentali dell'extreme programming. Esse riguardano la pianificazione, la progettazione, la programmazione, la verifica del software e l'organizzazione del lavoro. Le pratiche sono concepite come elementi interdipendenti, il cui impiego congiunto dovrebbe sostenere la capacità del gruppo di sviluppo di rispondere ai cambiamenti dei requisiti mantenendo la qualità del codice.

Le dodici pratiche originarie sono:

1. Gioco della pianificazione (planning game): consiste nella definizione e nell'aggiornamento delle attività da realizzare, attraverso la collaborazione tra il cliente e gli sviluppatori. Il cliente stabilisce il valore e la priorità delle funzionalità richieste, mentre gli sviluppatori ne valutano la fattibilità e lo sforzo necessario. Le decisioni relative al contenuto dei rilasci e delle iterazioni vengono assunte combinando le priorità di business con le stime tecniche. La pianificazione viene rivista quando emergono nuove informazioni o cambiano le esigenze del progetto.
2. Piccoli rilasci (small releases): prevede la distribuzione frequente di versioni funzionanti del software, ciascuna contenente un insieme limitato di funzionalità. Il rilascio anticipato di una prima versione utilizzabile permette di ottenere riscontri sull'effettivo comportamento del sistema e sulle esigenze degli utilizzatori. Le versioni successive vengono realizzate in cicli brevi, riducendo l'intervallo tra lo sviluppo di una funzionalità e il suo impiego.
3. Metafora del sistema (system metaphor): consiste nell'adottare una descrizione condivisa del funzionamento generale del sistema, comprensibile ai membri del gruppo di sviluppo e agli altri soggetti coinvolti. La metafora fornisce un modello concettuale comune, che può orientare la scelta dei nomi, l'organizzazione dei componenti e la comunicazione relativa all'architettura del software. Non richiede necessariamente l'utilizzo di un'analogia figurata, ma la disponibilità di una rappresentazione coerente e condivisa.
4. Progettazione semplice (simple design): privilegia la soluzione progettuale più semplice in grado di soddisfare i requisiti conosciuti e i test previsti. Il metodo scoraggia l'introduzione anticipata di funzionalità o strutture motivate esclusivamente da esigenze future ipotetiche. La progettazione viene modificata progressivamente, mediante interventi successivi, quando nuove funzionalità o informazioni rendono necessarie soluzioni differenti.
5. Verifica mediante test (testing): prevede l'impiego sistematico di test automatizzati durante lo sviluppo. I programmatori scrivono ed eseguono test unitari per verificare il comportamento del codice, secondo un approccio che comprende la scrittura dei test prima dell'implementazione delle funzionalità. Il cliente contribuisce inoltre alla definizione dei test di accettazione, destinati a verificare che il sistema soddisfi i requisiti richiesti. I test vengono eseguiti ripetutamente per individuare eventuali regressioni causate dalle modifiche.
6. Refactoring (refactoring): consiste nella modifica della struttura interna del codice senza alterarne il comportamento osservabile. Gli interventi possono riguardare l'eliminazione delle duplicazioni, il miglioramento della leggibilità e la semplificazione delle dipendenze tra componenti. L'esecuzione frequente dei test permette di verificare che le modifiche non abbiano introdotto comportamenti indesiderati. Il refactoring viene considerato un'attività ricorrente, integrata nel processo di sviluppo.
7. Programmazione in coppia (pair programming): prevede che due programmatori lavorino congiuntamente alla scrittura del codice, utilizzando una stessa postazione di lavoro. Durante l'attività, uno dei due si occupa direttamente della scrittura, mentre l'altro osserva, esamina le scelte effettuate e contribuisce alla soluzione dei problemi. I ruoli possono essere scambiati e le coppie possono cambiare nel corso del progetto. La pratica integra una forma continua di revisione del codice e favorisce la condivisione delle conoscenze.
8. Proprietà collettiva del codice (collective code ownership): stabilisce che il codice sorgente non sia di competenza esclusiva dei singoli programmatori che lo hanno scritto. Ogni membro del gruppo può intervenire sulle diverse parti del sistema per correggere errori, introdurre miglioramenti o realizzare funzionalità. La possibilità di modificare il codice condiviso è accompagnata dalla responsabilità di preservarne il funzionamento, anche attraverso l'esecuzione dei test.
9. Integrazione continua (continuous integration): consiste nell'integrare frequentemente le modifiche apportate dai programmatori in una versione condivisa del sistema. Nella formulazione originaria dell'XP, l'integrazione viene eseguita più volte al giorno, generalmente al completamento di singole attività. Ogni integrazione è accompagnata dalla compilazione, ove necessaria, e dall'esecuzione dei test, in modo da individuare rapidamente eventuali incompatibilità o errori introdotti dalle modifiche.
10. Settimana lavorativa di quaranta ore (40-hour week): prevede un'organizzazione del lavoro che eviti il ricorso sistematico agli straordinari. Nella formulazione del 1999, Beck proponeva una settimana lavorativa normalmente limitata a quaranta ore, escludendo in particolare il ricorso agli straordinari per due settimane consecutive. La pratica si fonda sull'importanza attribuita alla continuità delle prestazioni e alla prevenzione dell'affaticamento dei programmatori. Nella seconda edizione del metodo questo concetto venne riformulato in termini di lavoro sostenibile.
11. Cliente presente sul posto (on-site customer): prevede la partecipazione continuativa di un rappresentante del cliente alle attività del gruppo di sviluppo. Questa figura deve essere disponibile per chiarire i requisiti, stabilire le priorità e fornire risposte alle domande dei programmatori. Il rappresentante non coincide necessariamente con l'utilizzatore finale del software, ma deve possedere una conoscenza adeguata delle esigenze di business e l'autorità necessaria per assumere le decisioni di propria competenza.
12. Standard di codifica (coding standards): richiede l'adozione di convenzioni condivise per la scrittura del codice sorgente. Tali convenzioni riguardano, tra gli altri aspetti, la denominazione degli elementi del programma, l'organizzazione del codice e la sua formattazione. L'uniformità dello stile favorisce la comprensione delle modifiche e la collaborazione tra programmatori, contribuendo a rendere praticabile la proprietà collettiva del codice.

Nella formulazione originaria, le dodici pratiche non erano presentate come tecniche indipendenti, ma come un insieme coordinato. La programmazione in coppia e la proprietà collettiva del codice favoriscono la condivisione delle conoscenze; i test automatizzati e l'integrazione continua sostengono la possibilità di apportare modifiche frequenti; la collaborazione con il cliente e i piccoli rilasci permettono di verificare progressivamente i requisiti. La successiva revisione del metodo, pubblicata nel 2004, riorganizzò questo insieme di pratiche, modificandone alcune e introducendone altre.

Le pratiche nella seconda edizione

Nella seconda edizione di Extreme Programming Explained: Embrace Change, pubblicata nel 2004, Kent Beck e Cynthia Andres riorganizzarono le pratiche dell'extreme programming, distinguendo tredici pratiche primarie (primary practices) e undici pratiche corollarie (corollary practices). La nuova classificazione sostituì l'elenco unitario delle dodici pratiche originarie e introdusse una distinzione basata sulle condizioni necessarie per la loro adozione.

Le pratiche primarie sono presentate come possibili punti di partenza per migliorare il processo di sviluppo. Le pratiche corollarie, invece, possono risultare difficili o rischiose da applicare prima di aver consolidato determinate capacità tecniche e organizzative. Gli autori sottolineano che le pratiche non costituiscono regole immutabili, ma strumenti da valutare e adattare alle caratteristiche del progetto.

Pratiche primarie

Le tredici pratiche primarie, descritte nel settimo capitolo della seconda edizione, riguardano l'organizzazione del gruppo, la pianificazione e le attività tecniche di sviluppo.

1. Lavorare nello stesso spazio (sit together): prevede che i membri del gruppo di sviluppo condividano uno spazio di lavoro nel quale possano comunicare e collaborare direttamente. L'organizzazione dello spazio deve comunque tenere conto delle esigenze individuali di concentrazione e riservatezza.
2. Gruppo di lavoro completo (whole team): consiste nel riunire le competenze e le responsabilità necessarie alla realizzazione del prodotto. Il gruppo può comprendere programmatori, esperti di test, progettisti e rappresentanti delle esigenze del cliente, favorendo la collaborazione tra persone con ruoli differenti.
3. Ambiente di lavoro informativo (informative workspace): prevede che le informazioni relative allo stato del progetto siano facilmente accessibili e comprensibili. Indicatori visivi, rappresentazioni delle attività e risultati delle verifiche permettono ai membri del gruppo di conoscere l'avanzamento del lavoro e individuare eventuali difficoltà.
4. Lavoro sostenibile (energized work): attribuisce importanza al mantenimento di condizioni di lavoro che consentano ai programmatori di operare con continuità e concentrazione. Riprende e amplia la precedente pratica della settimana lavorativa di quaranta ore, ponendo l'accento sulla sostenibilità dell'impegno professionale anziché su un limite orario prestabilito.
5. Programmazione in coppia (pair programming): prevede che due programmatori collaborino alla realizzazione del codice utilizzando una stessa postazione di lavoro. La collaborazione permette di discutere le soluzioni, esaminare continuamente il codice e condividere le conoscenze tecniche. La pratica era già presente nella formulazione originaria dell'XP.
6. Storie utente (stories): utilizza descrizioni sintetiche delle funzionalità richieste per organizzare e pianificare lo sviluppo. Le storie rappresentano elementi di valore per il cliente e costituiscono una base per la discussione dei requisiti, la valutazione dell'impegno necessario e la definizione delle priorità.
7. Ciclo settimanale (weekly cycle): organizza il lavoro attraverso brevi iterazioni, generalmente della durata di una settimana. All'inizio del ciclo vengono selezionate le funzionalità da realizzare, mentre al termine vengono valutati i risultati ottenuti. Il ciclo fornisce occasioni ricorrenti per aggiornare la pianificazione.
8. Ciclo trimestrale (quarterly cycle): introduce un orizzonte di pianificazione più ampio rispetto alle iterazioni settimanali. Il gruppo definisce obiettivi e temi prioritari per un periodo indicativamente trimestrale, riesaminando le esigenze del progetto e gli eventuali impedimenti organizzativi.
9. Margine di flessibilità (slack): consiste nel prevedere, durante la pianificazione, alcune attività di priorità inferiore che possono essere rinviate senza compromettere gli obiettivi principali dell'iterazione. Questo margine permette di assorbire parte dell'incertezza nelle stime e di ridurre il rischio di assumere impegni eccessivi.
10. Compilazione e verifica in dieci minuti (ten-minute build): prevede un processo automatizzato di compilazione e verifica del sistema sufficientemente rapido da essere eseguito frequentemente. Il riferimento ai dieci minuti esprime l'obiettivo di contenere i tempi di attesa, permettendo agli sviluppatori di ottenere rapidamente informazioni sull'esito delle modifiche.
11. Integrazione continua (continuous integration): consiste nell'integrare e verificare frequentemente le modifiche apportate al codice condiviso. L'integrazione viene accompagnata dall'esecuzione di controlli automatizzati, con l'obiettivo di individuare tempestivamente errori e incompatibilità tra i diversi contributi.
12. Programmazione con test preliminari (test-first programming): prevede la scrittura di un test automatizzato prima dell'implementazione della funzionalità corrispondente. Lo sviluppatore introduce quindi il codice necessario per soddisfare il test e può successivamente migliorarne la struttura, preservando il comportamento verificato. La pratica è strettamente collegata allo sviluppo guidato dai test.
13. Progettazione incrementale (incremental design): consiste nel migliorare progressivamente la struttura del software durante lo sviluppo. Le decisioni progettuali vengono assunte sulla base delle esigenze conosciute e riviste quando emergono nuovi requisiti. La pratica comprende attività di refactoring e mira a evitare sia una progettazione anticipata eccessivamente complessa sia il deterioramento della struttura del codice.

Pratiche corollarie

Le undici pratiche corollarie sono descritte nel nono capitolo della seconda edizione. Beck e Andres le presentano come pratiche la cui applicazione può richiedere un maggiore consolidamento delle capacità del gruppo di sviluppo. Gli autori osservano, per esempio, che una distribuzione quotidiana del software può comportare rischi elevati se il processo di verifica non è sufficientemente affidabile.

1. Coinvolgimento diretto del cliente (real customer involvement): prevede la partecipazione al processo di sviluppo delle persone direttamente interessate al funzionamento e ai risultati del sistema. Rispetto alla precedente pratica del cliente presente sul posto, pone maggiormente l'accento sul rapporto tra sviluppatori e soggetti che possiedono conoscenze dirette delle esigenze da soddisfare.
2. Distribuzione incrementale (incremental deployment): consiste nell'introdurre gradualmente un nuovo sistema nell'ambiente operativo, anziché sostituire integralmente quello precedente in un'unica operazione. La pratica è particolarmente rilevante nella sostituzione di sistemi preesistenti, poiché consente di trasferire progressivamente funzionalità e carichi di lavoro.
3. Continuità del gruppo (team continuity): attribuisce valore alla stabilità dei gruppi di sviluppo che hanno dimostrato di collaborare efficacemente. Il mantenimento delle relazioni e delle conoscenze condivise può ridurre le difficoltà derivanti dalla frequente sostituzione dei componenti del gruppo.
4. Riduzione progressiva del gruppo (shrinking teams): propone, quando aumentano le capacità e l'efficienza del gruppo, di mantenerne relativamente stabile il carico di lavoro riducendo gradualmente il numero delle persone coinvolte. Le risorse rese disponibili possono essere assegnate ad altri progetti. Questa pratica è distinta dalla continuità del gruppo e presuppone un miglioramento delle sue capacità operative.
5. Analisi delle cause profonde (root-cause analysis): prevede che, in presenza di errori o problemi ricorrenti, il gruppo cerchi di individuarne le cause anziché limitarsi a correggerne le manifestazioni immediate. L'analisi può portare a modifiche del codice, degli strumenti o delle modalità di lavoro, con l'obiettivo di prevenire il ripetersi di problemi analoghi.
6. Codice condiviso (shared code): estende il principio della proprietà collettiva del codice, consentendo ai membri del gruppo di apportare miglioramenti alle diverse parti del sistema. La responsabilità condivisa richiede pratiche di collaborazione e verifica che permettano di mantenere coerente il funzionamento del software.
7. Codice e test (code and tests): privilegia il codice sorgente e i test automatizzati come principali artefatti tecnici da mantenere aggiornati nel tempo. Le altre forme di documentazione possono essere prodotte quando necessarie, anche a partire dalle informazioni ricavabili dal codice e dai test. La pratica non equivale all'eliminazione di qualsiasi documentazione.
8. Base di codice unica (single code base): prevede il mantenimento di un flusso principale condiviso del codice sorgente, limitando la proliferazione di versioni divergenti dello stesso sistema. La pratica è collegata all'integrazione frequente e mira a ridurre i problemi derivanti dal mantenimento prolungato di sviluppi separati.
9. Distribuzione quotidiana (daily deployment): propone di rendere possibile la distribuzione di nuove versioni del software nell'ambiente di produzione con frequenza quotidiana. L'applicazione della pratica richiede un processo di integrazione, verifica e distribuzione sufficientemente affidabile da contenere i rischi associati ai rilasci frequenti.
10. Contratto con ambito negoziabile (negotiated scope contract): propone accordi nei quali il contenuto funzionale del prodotto possa essere ridefinito nel corso del progetto, attraverso la collaborazione tra cliente e sviluppatori. L'approccio permette di adattare le funzionalità da realizzare alle priorità emergenti, mantenendo sotto controllo altri vincoli contrattuali, quali tempi e costi.
11. Pagamento in base all'utilizzo (pay-per-use): propone un modello economico nel quale il compenso per il software è collegato al suo utilizzo effettivo. Il modello può fornire al produttore informazioni sull'impiego del sistema e creare un collegamento tra valore percepito dagli utilizzatori e ricavi. Si tratta di una pratica relativa al rapporto economico con il cliente, distinta dalle tecniche di programmazione e distribuzione.

La classificazione del 2004 mantiene alcuni elementi della formulazione originaria, come la programmazione in coppia e l'integrazione continua, mentre ne riformula altri. La proprietà collettiva del codice compare tra le pratiche corollarie nella forma di codice condiviso; la progettazione semplice e il refactoring confluiscono nella progettazione incrementale; la pianificazione viene articolata nelle storie utente e nei cicli settimanale e trimestrale. Altre pratiche, come l'ambiente di lavoro informativo e la distribuzione quotidiana, ricevono una trattazione autonoma.

La revisione testimonia il passaggio da un elenco relativamente circoscritto di pratiche a una descrizione più articolata degli aspetti tecnici, organizzativi ed economici dello sviluppo software. Tale evoluzione è documentata anche nella letteratura scientifica successiva alla pubblicazione della seconda edizione.

Organizzazione del processo di sviluppo

Ruoli e collaborazione

L'extreme programming attribuisce particolare importanza alla collaborazione tra le persone coinvolte nello sviluppo software e alla distinzione delle responsabilità tecniche e decisionali. A differenza di altri approcci che prevedono una struttura organizzativa rigidamente definita, l'XP considera i ruoli come insiemi di responsabilità che possono essere distribuite tra i membri del gruppo in funzione delle competenze e delle esigenze del progetto.

Nella prima edizione di Extreme Programming Explained del 1999, Kent Beck descrisse sette ruoli, comprendenti figure direttamente impegnate nello sviluppo e altre con funzioni di supporto, coordinamento o direzione. La classificazione venne ripresa anche da Pekka Abrahamsson e collaboratori nella loro analisi comparativa delle metodologie agili pubblicata nel 2002.

I ruoli descritti nella formulazione originaria sono:

• Programmatore (programmer): si occupa della realizzazione del software, della scrittura del codice sorgente e dei test automatizzati. Partecipa alla valutazione della complessità delle funzionalità richieste e collabora con gli altri programmatori attraverso pratiche quali la programmazione in coppia e la proprietà collettiva del codice. La responsabilità del programmatore comprende anche il mantenimento della semplicità e della qualità della struttura del software.

• Cliente (customer): rappresenta le esigenze che il sistema deve soddisfare e assume le decisioni relative alle funzionalità da realizzare e alla loro priorità. Partecipa alla definizione delle storie utente e dei criteri di accettazione, fornendo chiarimenti sui requisiti durante lo sviluppo. Il ruolo non coincide necessariamente con quello dell'utilizzatore finale: può essere svolto da una persona autorizzata a rappresentare le esigenze del committente.

• Responsabile dei test (tester): collabora con il cliente nella definizione dei test di accettazione e contribuisce alla loro realizzazione ed esecuzione. Si occupa inoltre di rendere disponibili i risultati delle verifiche e di supportare il mantenimento degli strumenti necessari all'esecuzione dei test. Questo ruolo è distinto dalla responsabilità dei programmatori di verificare il codice mediante test automatizzati.

• Responsabile del monitoraggio (tracker): raccoglie e analizza informazioni sull'andamento del progetto, confrontando le stime delle attività con i risultati effettivamente ottenuti. Le informazioni raccolte permettono al gruppo di valutare l'avanzamento delle iterazioni, individuare eventuali scostamenti e migliorare le previsioni relative al lavoro futuro.

• Facilitatore del metodo (coach): sostiene il gruppo nell'applicazione dei valori, dei principi e delle pratiche dell'extreme programming. Il suo compito consiste nell'osservare il processo di sviluppo, individuare difficoltà organizzative e favorire il miglioramento delle modalità di collaborazione. Il coach non coincide necessariamente con un responsabile gerarchico e può contribuire alla progressiva autonomia del gruppo.

• Consulente (consultant): fornisce competenze specialistiche necessarie alla soluzione di problemi tecnici o organizzativi che il gruppo non è in grado di affrontare autonomamente. Il suo intervento può essere temporaneo e limitato a specifiche esigenze del progetto.

• Responsabile organizzativo (big boss): rappresenta la figura dirigenziale incaricata di sostenere il progetto e assicurare le condizioni organizzative necessarie al suo svolgimento. Si occupa delle decisioni di propria competenza relative alle risorse e all'organizzazione, mantenendo il collegamento tra il gruppo di sviluppo e la struttura aziendale.

La distinzione tra responsabilità tecniche e responsabilità relative al prodotto costituisce un elemento centrale dell'organizzazione XP. Gli sviluppatori valutano gli aspetti tecnici e l'impegno necessario alla realizzazione delle funzionalità, mentre il cliente ne determina il valore e le priorità. Le decisioni vengono coordinate attraverso la collaborazione continuativa, anziché essere demandate esclusivamente a una pianificazione iniziale.

Nella seconda edizione di Extreme Programming Explained, pubblicata nel 2004, Beck e Cynthia Andres dedicarono maggiore attenzione alla composizione interdisciplinare del gruppo di sviluppo. La pratica del whole team prevede la collaborazione delle persone in possesso delle competenze necessarie alla realizzazione del prodotto, superando una concezione del processo centrata esclusivamente sui programmatori.

Nel capitolo dedicato al gruppo XP completo, gli autori esaminano il contributo di diverse figure professionali, tra cui esperti di test, progettisti dell'interazione, architetti software, responsabili di progetto e di prodotto, dirigenti, redattori tecnici, utilizzatori, programmatori e personale delle risorse umane. Tali figure non costituiscono un elenco di posizioni obbligatorie per ogni progetto, ma rappresentano competenze e prospettive che possono contribuire allo sviluppo del sistema.

La collaborazione interdisciplinare è collegata alle pratiche di comunicazione diretta, condivisione delle conoscenze e coinvolgimento del cliente. Anche i ruoli di coach e tracker possono essere svolti da persone che ricoprono altre responsabilità, qualora le caratteristiche del gruppo lo consentano. L'Agile Alliance sottolinea, in particolare, che tali funzioni di supporto non richiedono necessariamente la creazione di posizioni autonome e permanenti.

L'organizzazione del gruppo XP si fonda pertanto sulla definizione delle responsabilità necessarie al progetto e sulla collaborazione tra le diverse competenze, senza richiedere l'adozione di un unico modello gerarchico.

Pianificazione e storie utente

Nell'extreme programming, la pianificazione è un'attività ricorrente, attraverso la quale il cliente e il gruppo di sviluppo definiscono le funzionalità da realizzare e aggiornano le decisioni in base ai risultati ottenuti. Nella formulazione originaria del metodo, questo processo prende il nome di planning game («gioco della pianificazione») e si fonda sulla distinzione tra decisioni relative al valore del prodotto, affidate al cliente, e valutazioni tecniche, di competenza degli sviluppatori.

Le funzionalità richieste vengono descritte mediante storie utente (user stories), brevi descrizioni di comportamenti o caratteristiche del sistema formulate dal punto di vista delle esigenze degli utilizzatori o del cliente. Nella pratica originaria dell'XP, le storie venivano generalmente annotate su schede cartacee, utilizzate come strumenti di comunicazione e pianificazione. La loro formulazione sintetica non intende sostituire ogni forma di analisi dei requisiti: i dettagli vengono approfonditi attraverso il confronto tra cliente e sviluppatori e la definizione dei criteri di accettazione.

La pianificazione dei rilasci (release planning) determina quali storie utente includere nelle successive versioni del prodotto. Gli sviluppatori forniscono una stima dell'impegno necessario per realizzare ciascuna storia, mentre il cliente ne stabilisce la priorità sulla base del valore atteso e delle esigenze del progetto. La pianificazione può partire da una data di rilascio prestabilita, selezionando le funzionalità compatibili con il tempo disponibile, oppure da un insieme di funzionalità desiderate, stimando il tempo necessario per completarle.

Le stime vengono confrontate con la capacità di lavoro dimostrata dal gruppo nelle iterazioni precedenti. Nell'XP, questa capacità è comunemente espressa attraverso la velocity, una misura della quantità di lavoro completato durante un'iterazione, calcolata sulla base delle stime associate alle storie effettivamente terminate. Tale informazione viene utilizzata per aggiornare le previsioni e adeguare il contenuto dei rilasci, tenendo conto dell'incertezza delle stime.

La pianificazione delle iterazioni (iteration planning) riguarda invece l'organizzazione del lavoro a breve termine. Le storie selezionate vengono esaminate e suddivise dagli sviluppatori in attività tecniche di dimensioni più contenute. I programmatori assumono la responsabilità delle singole attività, ne valutano l'impegno e verificano che il lavoro complessivamente previsto sia compatibile con la capacità disponibile. Se le stime superano tale capacità, il contenuto dell'iterazione viene rinegoziato con il cliente.

Nel corso dello sviluppo, le storie possono essere chiarite, suddivise o modificate quando emergono nuove informazioni. La pianificazione dei rilasci e quella delle iterazioni sono pertanto collegate da un processo di revisione continua: i risultati effettivi dello sviluppo contribuiscono ad aggiornare le stime, mentre le esigenze del cliente possono modificare le priorità delle attività ancora da svolgere.

Nella seconda edizione di Extreme Programming Explained del 2004, Beck e Cynthia Andres riorganizzarono la pianificazione introducendo esplicitamente le pratiche del ciclo settimanale (weekly cycle) e del ciclo trimestrale (quarterly cycle). La distinzione tra un orizzonte operativo breve e uno più ampio conserva il principio della pianificazione ricorrente, adattandone l'organizzazione rispetto alla formulazione originaria.

Iterazioni e rilasci

Nell'extreme programming, lo sviluppo del software procede attraverso una successione di iterazioni di durata limitata, durante le quali vengono realizzate, integrate e verificate nuove funzionalità del sistema. Ogni iterazione costituisce un ciclo di lavoro che comprende attività di progettazione, programmazione e verifica, con l'obiettivo di produrre un incremento funzionante del software. La durata delle iterazioni può variare in relazione alla formulazione del metodo e alle caratteristiche del progetto.

Nelle prime descrizioni dell'XP, risalenti alla fine degli anni novanta, venivano utilizzate iterazioni della durata di alcune settimane, generalmente inserite in un ciclo di rilascio più ampio. La seconda edizione di Extreme Programming Explained, pubblicata nel 2004, introdusse esplicitamente la pratica del ciclo settimanale (weekly cycle), affiancandola a quella del ciclo trimestrale (quarterly cycle), destinata a coordinare gli obiettivi e la pianificazione dei rilasci su un orizzonte temporale maggiore.

All'inizio di un'iterazione, il gruppo di sviluppo e il cliente esaminano le funzionalità previste e concordano il lavoro da svolgere. Durante il ciclo, gli sviluppatori realizzano le attività tecniche necessarie, integrando frequentemente le modifiche e verificando il comportamento del sistema mediante test automatizzati. La progettazione può essere modificata nel corso dell'iterazione, anche attraverso interventi di refactoring, senza attendere una fase successiva dedicata esclusivamente alla revisione del codice.

Al termine dell'iterazione, le funzionalità completate vengono esaminate con il cliente, che può verificarne la corrispondenza ai requisiti attraverso i risultati dei test di accettazione e la valutazione del software funzionante. Le funzionalità non completate vengono considerate nella successiva pianificazione. Le informazioni raccolte contribuiscono inoltre a individuare problemi, chiarire requisiti e modificare le priorità del lavoro futuro.

Un elemento caratteristico dell'XP è la pratica dei piccoli rilasci (small releases), già presente nella formulazione del 1999. Essa prevede la distribuzione frequente di versioni utilizzabili del software, contenenti incrementi funzionali relativamente limitati. L'impiego effettivo del sistema permette di raccogliere informazioni sul suo comportamento e sulla corrispondenza delle funzionalità alle esigenze degli utilizzatori.

Il completamento di un'iterazione non comporta necessariamente la distribuzione immediata del software nell'ambiente di produzione. Un incremento può essere funzionante e verificato senza essere ancora disponibile agli utilizzatori finali. Il rilascio costituisce invece il momento in cui una versione viene resa disponibile per l'impiego o la valutazione da parte degli utenti. La frequenza dei rilasci dipende dalle caratteristiche tecniche del sistema e dalle esigenze del contesto applicativo.

Nella formulazione del 2004, il ciclo trimestrale fornisce un riferimento per coordinare le attività delle singole iterazioni con gli obiettivi complessivi del progetto. Le funzionalità previste e il loro ordine di realizzazione possono essere modificati durante il ciclo, sulla base delle informazioni acquisite. Il periodo trimestrale rappresenta quindi un orizzonte di pianificazione proposto dal metodo, non un obbligo di distribuire il software esclusivamente ogni tre mesi.

La successione di iterazioni e rilasci permette di acquisire informazioni durante lo sviluppo e di utilizzarle per orientare le decisioni successive. L'approccio si distingue da una sequenza rigidamente separata di analisi, progettazione, implementazione e collaudo, poiché queste attività vengono ripetute e coordinate durante l'evoluzione del prodotto.

Sviluppo, test e integrazione

Nell'extreme programming, la realizzazione del software si basa sull'integrazione continua delle attività di programmazione, verifica e miglioramento del codice. Il metodo prevede l'esecuzione frequente di test automatizzati e la modifica progressiva della struttura del sistema, con l'obiettivo di mantenere il software funzionante durante l'introduzione di nuove funzionalità. Le diverse pratiche tecniche sono concepite per sostenersi reciprocamente, riducendo l'intervallo tra una modifica del codice e la disponibilità di informazioni sui suoi effetti.

Una delle caratteristiche dell'approccio è la programmazione con test preliminari (test-first programming), strettamente collegata allo sviluppo guidato dai test (test-driven development, TDD). Lo sviluppatore definisce inizialmente un test automatizzato relativo a un comportamento atteso del programma e ne verifica il fallimento. Successivamente scrive il codice necessario per soddisfare il test e, dopo averne verificato il superamento, può procedere al miglioramento della struttura del codice. La sequenza viene ripetuta per le successive funzionalità, contribuendo alla formazione progressiva di un insieme di test automatizzati.

Il refactoring costituisce una componente di questo processo. Esso consiste nell'apportare modifiche alla struttura interna del software senza alterarne il comportamento osservabile. Nell'XP viene utilizzato per contenere la complessità del codice, eliminare duplicazioni e adattare progressivamente la progettazione alle esigenze emergenti. L'esistenza di test automatizzati permette di controllare il comportamento del sistema dopo le modifiche, pur non garantendo da sola l'assenza di errori.

La programmazione in coppia (pair programming) e la proprietà collettiva del codice favoriscono la collaborazione durante queste attività. I programmatori possono discutere le scelte implementative e progettuali mentre lavorano sullo stesso codice, contribuendo alla sua revisione e alla circolazione delle conoscenze. La possibilità di intervenire sulle diverse parti del sistema permette inoltre di effettuare modifiche senza vincolarle esclusivamente agli autori originari dei singoli componenti.

Accanto ai test utilizzati dai programmatori, l'XP prevede test di accettazione destinati a verificare la corrispondenza del sistema ai requisiti del cliente. Questi test descrivono comportamenti attesi dal punto di vista funzionale e vengono definiti con il contributo del cliente o di persone che conoscono il dominio applicativo. Possono essere automatizzati e ripetuti nel corso dello sviluppo, fornendo un ulteriore riscontro sulle funzionalità realizzate. I test dei programmatori e quelli di accettazione svolgono quindi funzioni complementari.

Le modifiche vengono successivamente incorporate nella versione condivisa del codice attraverso l'integrazione continua (continuous integration). Questa pratica prevede integrazioni frequenti, accompagnate dalla compilazione, quando necessaria, e dall'esecuzione dei controlli automatizzati. L'obiettivo è individuare tempestivamente incompatibilità tra le modifiche effettuate dai diversi programmatori ed evitare che le versioni del codice rimangano separate per periodi prolungati.

Nella seconda edizione di Extreme Programming Explained, Beck e Cynthia Andres associano all'integrazione continua la pratica della compilazione e verifica in dieci minuti (ten-minute build), che propone di mantenere sufficientemente breve il processo automatizzato di costruzione e controllo del sistema. Un processo rapido consente agli sviluppatori di eseguire verifiche frequenti senza interrompere a lungo le attività di programmazione.

L'integrazione continua non coincide necessariamente con la distribuzione del software nell'ambiente di produzione. Essa riguarda principalmente la combinazione e la verifica delle modifiche nella base di codice condivisa, mentre il rilascio e la distribuzione costituiscono attività distinte. L'automazione può supportare entrambi i processi, ma non ne elimina la differenza funzionale.

Nel loro insieme, queste pratiche costituiscono un sistema di verifiche e adattamenti frequenti, nel quale lo sviluppo di nuove funzionalità è accompagnato dalla revisione della struttura del codice e dal controllo del comportamento del software. La loro interdipendenza rappresenta uno degli elementi caratteristici dell'approccio XP rispetto a metodi che non prescrivono specifiche tecniche di programmazione.

Ambiti di applicazione e limiti

Contesti di applicazione

L'extreme programming fu originariamente concepito per lo sviluppo di software da parte di gruppi relativamente piccoli, impegnati in progetti caratterizzati da requisiti incompleti, incerti o soggetti a frequenti cambiamenti. Nella prima edizione di Extreme Programming Explained, pubblicata nel 1999, Kent Beck presentò il metodo come un approccio rivolto principalmente a situazioni nelle quali fosse necessario adattare ripetutamente il software alle esigenze del cliente, attraverso cicli brevi di sviluppo e verifica.

Secondo la descrizione dell'Agile Alliance, i contesti considerati particolarmente favorevoli all'applicazione dell'XP comprendono progetti con requisiti variabili, attività soggette a rischi derivanti dall'utilizzo di nuove tecnologie entro scadenze prestabilite, gruppi di sviluppo di piccole dimensioni che lavorano nello stesso luogo e ambienti tecnologici nei quali sia possibile automatizzare i test unitari e funzionali.

La disponibilità del cliente a collaborare frequentemente con gli sviluppatori costituisce un'altra condizione rilevante. Il metodo prevede infatti che le decisioni relative alle funzionalità e alle priorità possano essere aggiornate durante il progetto. La possibilità di ottenere rapidamente chiarimenti e valutazioni sui risultati del lavoro favorisce l'applicazione delle pratiche di pianificazione ricorrente e rilascio frequente.

Le caratteristiche tecniche del sistema influiscono inoltre sulla possibilità di applicare le pratiche XP. L'esecuzione frequente dei test, l'integrazione continua e il refactoring presuppongono la disponibilità di strumenti e condizioni che consentano di modificare e verificare il software con costi e tempi compatibili con cicli di sviluppo brevi. In una recensione critica del volume di Beck, pubblicata nel 2000 su IEEE Software, Diomidis Spinellis individuò tra le principali limitazioni dell'approccio originario i sistemi difficili da sottoporre a test automatici, gli ambienti con lunghi tempi di compilazione e i progetti nei quali le modifiche comportano un elevato impegno aggiuntivo.

Nella seconda edizione di Extreme Programming Explained, pubblicata nel 2004, Beck e Cynthia Andres ampliarono la prospettiva del metodo, affrontandone l'applicazione in gruppi e organizzazioni di dimensioni maggiori. Il volume dedica un capitolo specifico all'estensione dell'XP (Scaling XP), esaminando fattori quali il numero delle persone coinvolte, la dimensione dell'organizzazione, la durata del progetto, la complessità del problema e le conseguenze di eventuali malfunzionamenti. Gli autori considerarono inoltre le possibilità e le difficoltà dello sviluppo realizzato da gruppi geograficamente distribuiti.

L'applicazione dell'XP in contesti industriali è stata esaminata anche attraverso studi empirici. Nel 2004 Pekka Abrahamsson e Juha Koskela pubblicarono uno studio su un progetto di sviluppo di un'applicazione web realizzato da quattro ingegneri del software nell'arco di otto settimane. La ricerca documentò cinque rilasci del sistema e raccolse dati relativi ai tempi di sviluppo, alle dimensioni del codice e ai difetti rilevati. Lo studio costituisce un esempio di osservazione quantitativa dell'XP in un contesto applicativo circoscritto.

Un diverso contesto di applicazione fu analizzato nel 2006 da Lucas Layman, Laurie Williams, Daniela Damian e Hynek Bures in uno studio pubblicato su Information and Software Technology. Gli autori esaminarono un progetto industriale nel quale il personale di sviluppo operava nella Repubblica Ceca, mentre parte delle responsabilità di gestione e del rapporto con il cliente era collocata negli Stati Uniti. Lo studio individuò alcune condizioni organizzative e comunicative che avevano consentito di utilizzare pratiche XP nonostante la separazione geografica, evidenziando l'importanza di adattare le modalità di collaborazione alla distribuzione del gruppo.

Le applicazioni documentate mostrano che le pratiche dell'extreme programming sono state impiegate anche al di fuori delle condizioni originariamente considerate più favorevoli. Tuttavia, i risultati ottenuti in singoli progetti non consentono di generalizzare automaticamente l'efficacia del metodo ad ambienti differenti. La possibilità di applicare l'XP dipende dalle caratteristiche tecniche e organizzative del progetto, nonché dal grado di adattamento delle sue pratiche al contesto.

Difficoltà e limitazioni

L'applicazione dell'extreme programming può incontrare difficoltà legate alle caratteristiche organizzative dei progetti, alla disponibilità delle persone coinvolte e ai requisiti tecnici del sistema da sviluppare. La letteratura scientifica ha analizzato questi problemi attraverso studi di caso e ricerche empiriche, evidenziando che l'adozione delle pratiche XP può richiedere adattamenti rispetto alla formulazione originaria del metodo.

Una prima difficoltà riguarda la partecipazione del cliente. La pratica originaria del cliente presente sul posto richiede la disponibilità continuativa di una persona in grado di chiarire i requisiti e assumere decisioni sulle priorità del prodotto. In alcune organizzazioni, tuttavia, può risultare difficile destinare una figura a tale funzione per tutta la durata dello sviluppo. Uno studio di Juha Koskela e Pekka Abrahamsson del 2004 ha evidenziato il carattere impegnativo di questo ruolo, mostrando anche come la presenza continuativa del cliente non implichi necessariamente un suo coinvolgimento costante nelle attività del gruppo.

Le dimensioni del gruppo di sviluppo rappresentano un ulteriore elemento critico. La formulazione originaria dell'XP attribuisce particolare importanza alla comunicazione diretta e informale tra i partecipanti, condizione più facilmente realizzabile in gruppi di dimensioni contenute. All'aumentare del numero degli sviluppatori possono emergere difficoltà di coordinamento e integrazione delle attività. Goldman e collaboratori hanno descritto adattamenti del metodo basati sulla suddivisione dei gruppi più numerosi in unità più piccole, accompagnata dall'integrazione periodica del software prodotto.

La distribuzione geografica dei membri del gruppo può complicare ulteriormente la collaborazione. La distanza fisica, le differenze di fuso orario e le eventuali barriere linguistiche possono ostacolare la comunicazione informale, sulla quale si fondano diverse pratiche XP. Uno studio industriale pubblicato nel 2006 da Lucas Layman e collaboratori ha esaminato un progetto distribuito tra gli Stati Uniti e la Repubblica Ceca, documentando le difficoltà incontrate e le soluzioni comunicative adottate. Il caso indica che l'applicazione dell'XP in gruppi distribuiti è possibile, ma può richiedere specifici adattamenti organizzativi.

Anche le caratteristiche tecniche del software possono influire sull'applicabilità del metodo. Le pratiche di sviluppo guidato dai test, refactoring e integrazione continua presuppongono la possibilità di verificare frequentemente il comportamento del sistema. Quando la compilazione e l'esecuzione dei test richiedono tempi elevati, oppure quando risulta particolarmente difficile automatizzare le verifiche, l'adozione di tali pratiche può incontrare ostacoli. Goldman e collaboratori hanno individuato nella durata dei cicli di compilazione e test una delle condizioni da valutare prima di adottare l'XP.

L'introduzione dell'extreme programming può inoltre richiedere cambiamenti nelle abitudini professionali e nelle modalità di organizzazione del lavoro. La programmazione in coppia, la proprietà collettiva del codice e la pianificazione condivisa modificano la distribuzione tradizionale delle responsabilità tra gli sviluppatori. Uno studio di George Mangalaraj, RadhaKanta Mahapatra e Sridhar Nerur, pubblicato nel 2009, ha esaminato i fattori individuali, organizzativi e tecnologici che possono favorire oppure ostacolare l'accettazione del metodo, rilevando differenze nell'adozione delle singole pratiche all'interno della stessa organizzazione.

Un'altra limitazione discussa nella letteratura riguarda il rapporto tra l'XP e la progettazione dell'usabilità. Timo Jokela e Pekka Abrahamsson, in uno studio pubblicato nel 2004, hanno esaminato un progetto XP rilevando una scarsa attenzione esplicita ai metodi di valutazione dell'usabilità. Gli autori hanno osservato che il coinvolgimento del cliente non è necessariamente sufficiente a rappresentare tutte le esigenze degli utilizzatori finali, soprattutto quando il cliente assume prevalentemente decisioni relative alle funzionalità del prodotto. I risultati riguardano il caso analizzato e non dimostrano che ogni progetto XP trascuri l'usabilità.

Le difficoltà documentate non implicano l'inapplicabilità generale dell'extreme programming nei contesti esaminati. Gli studi disponibili mostrano piuttosto che le condizioni organizzative, le competenze del gruppo e le caratteristiche del prodotto possono influenzare l'adozione delle pratiche. La valutazione della loro efficacia richiede pertanto di considerare il contesto specifico e i limiti metodologici delle ricerche empiriche.

Valutazioni critiche e studi empirici

L'efficacia dell'extreme programming è stata oggetto di studi empirici e di valutazioni critiche fin dalla diffusione del metodo alla fine degli anni novanta. Le ricerche hanno esaminato aspetti quali la qualità del software prodotto, la produttività dei gruppi di sviluppo, l'organizzazione del lavoro e gli effetti di specifiche pratiche tecniche. La varietà dei contesti studiati e dei metodi di ricerca utilizzati rende tuttavia complesso attribuire risultati generali all'adozione dell'XP nel suo insieme.

Tra le prime analisi critiche pubblicate in Italia figura l'articolo Extreme programming: programmazione estrema o revisionismo estremista?, scritto da Carlo Ghezzi e Mattia Monga nel 2002. Gli autori riconobbero l'utilità di alcuni concetti promossi dall'XP, ma ne contestarono la presentazione come approccio radicalmente nuovo e come possibile soluzione generale ai problemi dello sviluppo software. Secondo la loro analisi, diverse pratiche del metodo riprendevano principi già conosciuti nell'ingegneria del software e la loro applicabilità dipendeva dalle caratteristiche del progetto. L'articolo riguardava la formulazione originaria del metodo, precedente alla revisione pubblicata nel 2004.

Nel 2004 Lucas Layman, Laurie Williams e Lynn Cunningham pubblicarono uno studio longitudinale condotto presso Sabre Airline Solutions, confrontando due versioni successive di uno stesso prodotto software, realizzate rispettivamente prima e dopo circa due anni di utilizzo dell'XP. Gli autori rilevarono un aumento del 50% della produttività misurata e miglioramenti negli indicatori di qualità precedenti e successivi al rilascio. I risultati suggerivano possibili benefici nell'adozione del metodo, ma riguardavano un singolo gruppo e non permettevano di isolare con certezza l'influenza dell'XP da quella di altri cambiamenti intervenuti nel progetto.

Nel 2008 Tore Dybå e Torgeir Dingsøyr pubblicarono una revisione sistematica degli studi empirici sullo sviluppo agile. La ricerca esaminò la letteratura disponibile fino al 2005, identificando 36 studi ritenuti pertinenti e sufficientemente rigorosi, dei quali 33 primari e tre secondari. Gli studi riguardavano diversi metodi agili, non esclusivamente l'extreme programming, e affrontavano temi quali l'adozione dei metodi, i fattori sociali, le percezioni dei partecipanti e il confronto tra approcci di sviluppo. Gli autori evidenziarono la necessità di ulteriori ricerche empiriche, più numerose e metodologicamente solide, per valutare i benefici e i limiti delle metodologie agili.

Uno studio pubblicato nel 2013 da Stephen Wood, George Michaelides e Chris Thomson esaminò quaranta piccoli gruppi di sviluppo composti da studenti universitari, impegnati in progetti software destinati a clienti reali. Gli autori analizzarono il rapporto tra l'adozione delle pratiche XP, le caratteristiche della collaborazione e i risultati dei progetti. La pianificazione con il cliente e le pratiche relative alla gestione condivisa del codice risultarono positivamente associate alle prestazioni, mentre altre pratiche tecniche mostrarono associazioni più complesse, comprese alcune negative, influenzate dalle modalità di progettazione e di lavoro del gruppo. Lo studio evidenziò l'importanza della cooperazione e delle pratiche specifiche di collaborazione dell'XP, senza dimostrare che tutte le pratiche contribuiscano nella stessa misura ai risultati. La composizione dei gruppi e il particolare contesto universitario limitano la generalizzabilità dei risultati.

Altre ricerche si sono concentrate sull'efficacia delle singole pratiche associate all'extreme programming. Una metanalisi pubblicata nel 2009 da Jo E. Hannay, Tore Dybå, Erik Arisholm e Dag I. K. Sjøberg, basata su diciotto studi, esaminò gli effetti della programmazione in coppia rispetto alla programmazione individuale. I risultati indicarono, complessivamente, un piccolo effetto positivo sulla qualità e una riduzione del tempo necessario al completamento delle attività, accompagnati però da un maggiore impiego complessivo di lavoro. Gli effetti variavano sensibilmente in funzione della complessità delle attività e delle condizioni sperimentali; gli autori segnalarono inoltre possibili distorsioni dovute alla pubblicazione selettiva degli studi.

Per quanto riguarda lo sviluppo guidato dai test, una metanalisi di Yahya Rafique e Vojislav B. Mišić, pubblicata nel 2013 e comprendente 27 studi, rilevò nel complesso un piccolo effetto positivo sulla qualità esterna del software e un effetto sulla produttività poco significativo o non chiaramente distinguibile. L'analisi individuò inoltre differenze tra studi industriali e accademici, con variazioni negli effetti osservati sulla qualità e sull'impegno necessario allo sviluppo.

I risultati degli studi sulle singole pratiche non possono essere attribuiti automaticamente all'extreme programming considerato nel suo insieme, poiché tecniche come la programmazione in coppia e lo sviluppo guidato dai test possono essere adottate anche indipendentemente dal metodo. Analogamente, i risultati degli studi di caso devono essere interpretati tenendo conto della composizione dei gruppi, delle caratteristiche dei prodotti e dei criteri utilizzati per misurarne le prestazioni. La letteratura esaminata documenta pertanto risultati differenti e non permette di considerare l'XP una soluzione universalmente superiore agli altri approcci di sviluppo software.

Bibliografia

Opere fondamentali

• (EN) Pekka Abrahamsson, Outi Salo, Jussi Ronkainen e Juhani Warsta, Agile Software Development Methods: Review and Analysis (PDF), collana VTT Publications, vol. 478, Espoo, VTT Technical Research Centre of Finland, 2002, ISBN 9513860094.
• (EN) Kent Beck, Extreme Programming Explained: Embrace Change, Addison-Wesley, 1999, ISBN 9780201616415.
• (EN) Kent Beck e Cynthia Andres, Extreme Programming Explained: Embrace Change, 2ª, Addison-Wesley, 2004, ISBN 9780321278654.
• (EN) Kent Beck e Martin Fowler, Planning Extreme Programming, Addison-Wesley, 2000, ISBN 9780201710915.

Studi e analisi

• (EN) Kent Beck, Embracing Change with Extreme Programming, in Computer, vol. 32, n. 10, 1999, pp. 70-77, DOI:10.1109/2.796139.
• (EN) Tore Dybå e Torgeir Dingsøyr, Empirical studies of agile software development: A systematic review, in Information and Software Technology, vol. 50, n. 9-10, 2008, pp. 833-859, DOI:10.1016/j.infsof.2008.01.006.
• Carlo Ghezzi e Mattia Monga, Extreme programming: programmazione estrema o revisionismo estremista? (PDF), in Mondo Digitale, vol. 1, n. 4, 2002, pp. 3-14.
• (EN) Alfredo Goldman, Fabio Kon, Paulo J. S. Silva e Joseph W. Yoder, Being Extreme in the Classroom: Experiences Teaching XP, in Journal of the Brazilian Computer Society, vol. 10, n. 2, 2004, DOI:10.1007/BF03192356.
• (EN) Jo E. Hannay, Tore Dybå, Erik Arisholm e Dag I. K. Sjøberg, The effectiveness of pair programming: A meta-analysis, in Information and Software Technology, vol. 51, n. 7, 2009, pp. 1110-1122, DOI:10.1016/j.infsof.2009.02.001.
• (EN) Lucas Layman, Laurie Williams e Lynn Cunningham, Exploring Extreme Programming in Context: An Industrial Case Study, in Proceedings of the Agile Development Conference, IEEE, 2004, pp. 32-41, DOI:10.1109/ADEVC.2004.15.
• (EN) Lucas Layman, Laurie Williams, Daniela Damian e Hynek Bures, Essential communication practices for Extreme Programming in a global software development team, in Information and Software Technology, vol. 48, n. 9, 2006, pp. 781-794, DOI:10.1016/j.infsof.2006.01.004.
• (EN) George Mangalaraj, RadhaKanta Mahapatra e Sridhar Nerur, Acceptance of software process innovations – the case of extreme programming, in European Journal of Information Systems, vol. 18, n. 4, 2009, pp. 344-354, DOI:10.1057/ejis.2009.23.
• (EN) Yahya Rafique e Vojislav B. Mišić, The Effects of Test-Driven Development on External Quality and Productivity: A Meta-Analysis, in IEEE Transactions on Software Engineering, vol. 39, n. 6, 2013, pp. 835-856, DOI:10.1109/TSE.2012.28.
• (EN) Danilo Sato, Dairton Bassi, Mariana Bravo, Alfredo Goldman e Fabio Kon, Experiences tracking agile projects: an empirical study, in Journal of the Brazilian Computer Society, vol. 12, n. 3, 2006, pp. 45-64, DOI:10.1007/BF03194495.
• (EN) Helen Sharp e Hugh Robinson, An Ethnographic Study of XP Practice, in Empirical Software Engineering, vol. 9, 2004, pp. 353-375, DOI:10.1023/B:EMSE.0000039884.79385.54.
• (EN) Stephen Wood, George Michaelides e Chris Thomson, Successful extreme programming: Fidelity to the methodology or good teamworking?, in Information and Software Technology, vol. 55, n. 4, 2013, pp. 660-672, DOI:10.1016/j.infsof.2012.10.002.

Voci correlate

• Integrazione continua
• Metodologia agile
• Pair programming
• Refactoring
• Scrum (informatica)
• Test driven development

Altri progetti

Altri progetti

• Wikimedia Commons

• Wikimedia Commons contiene immagini o altri file su extreme programming

Collegamenti esterni

• (EN) Extreme Programming, su Agile Alliance. URL consultato il 28 ottobre 2026.
• (EN) Don Wells, Extreme Programming: A Gentle Introduction, su person.dibris.unige.it. URL consultato il 28 ottobre 2026.