eXtreme Programming

L'eXtreme Programming (espressione inglese per programmazione estrema, spesso abbreviato in XP) è una metodologia agile e un approccio all'ingegneria del software formulato da Kent Beck, Ward Cunningham e Ron Jeffries.

Beck scrisse il primo libro sull'XP, Extreme Programming Explained, pubblicato nel 1999. Tra gli aspetti caratteristici dell'eXtreme Programming vi sono:

• La programmazione a più mani (generalmente in coppia);
• La verifica continua del programma durante lo sviluppo per mezzo di programmi di test;
• La frequente reingegnerizzazione del software, di solito in piccoli passi incrementali, senza dover rispettare fasi di sviluppo particolari.

La metodologia XP si fonda su 12 regole (o pratiche) base che possono essere raggruppate in quattro aree:

1. Feedback a scala fine

• Pair Programming - significa che tutto il codice viene prodotto da due programmatori che lavorano insieme su una sola workstation. Il primo scrive il codice, mentre l'altro rivede ogni riga di codice mentre viene digitato. La persona che scrive è chiamata il conducente. La persona che fa la revisione del codice è chiamato l'osservatore o navigatore. I due programmatori si scambiano spesso ruoli (possibilmente ogni 30 minuti).
• Planning Game - è una riunione di pianificazione che avviene una volta per iterazione, tipicamente una volta a settimana.
• Test Driven Development - i test unitari vengono scritti prima di scrivere il codice. Test funzionali e unitari. Obiettivo primario di questo processo è quindi la specificazione e non la validazione del codice.
• Whole Team - in XP, il "cliente" non è colui che paga il conto, ma la persona che realmente utilizza il sistema. Il cliente deve essere presente e disponibile a verificare il prodotto.

2. Processo continuo

• Continuous Integration - Integrare continuamente i cambiamenti al codice eviterà ritardi più avanti nel ciclo del progetto, causati da problemi d'integrazione. L'integrazione continua punta a migliorare la qualità del software e a ridurre il tempo speso per rilasciarlo, sostituendo la pratica tradizione dell'applicazione del controllo di qualità posteriore al completamento dello sviluppo.
• Refactoring o Design Improvement - riscrivere il codice senza alterarne le funzionalità esterne, cambiando l'architettura, in modo da renderlo più semplice e generico. Vengono ad esempio migliorate le proprietà quali la leggibilità e la struttura del codice, la sua aderenza al paradigma di programmazione, il suo grado di manutenibilità, la sua estensibilità, le prestazioni, e così via.
• Small Releases - consegna del software avviene tramite frequenti rilasci di funzionalità che creano del valore concreto.

3. Comprensione condivisa

• Coding Standards - Scegliere ed utilizzare un preciso standard di scrittura del codice. Questo rappresenta un insieme di regole concordate, che l'intero team di sviluppo accetta di rispettare nel corso del progetto.
• Collective Code Ownership - significa che ognuno è responsabile di tutto il codice; quindi contribuisce alla stesura chiunque sia coinvolto nel progetto.
• Simple Design - i programmatori dovrebbero utilizzare un approccio del tipo "semplice è meglio" alla progettazione software. Progettare al minimo e con il cliente.
• System Metaphor - descrivere il sistema con una metafora, anche per la descrizione formale. Questa può essere considerata come una storia che ognuno - clienti, programmatori, e manager - può raccontare circa il funzionamento del sistema.

4. Benessere dei programmatori

• Sustainable Pace - il concetto è che i programmatori o gli sviluppatori software non dovrebbero lavorare più di 40 ore di lavoro settimanali.

Su eXtreme Programming c'è da dire che, essendo una metodologia molto famosa, è anche molto controversa. In effetti si può notare che, per quanto particolareggiata, è comunque una metodologia leggera non troppo differente dalle altre. Deve sicuramente la sua fortuna al lavoro dell'autore che ha saputo coglierne gli aspetti positivi e trasmetterli, anche quando i progetti gestiti sono falliti, fra questi il primo in assoluto.

D'altronde è Kent Beck stesso ad ammettere questi fallimenti, anzi a considerarli parte integrante della filosofia di fondo della metodologia ed a confermare che di tutte le pratiche di eXtreme Programming, l'aspetto più importante è il carisma del project manager.

eXtreme Programming però ha dato un impulso importante alla diffusione delle metodologie leggere ed alla discussione sulle singole pratiche e sulle conseguenze dei loro utilizzi.