Extreme programming

L'extreme programming (abbreviato in XP), espressione inglese per programmazione estrema, è una metodologia di sviluppo del software che enfatizza la scrittura di codice di qualità e la rapidità di risposta ai cambiamenti di requisiti. Appartiene alla famiglia delle metodologie agili, e come tale prescrive lo sviluppo iterativo e incrementale strutturato in brevi cicli di sviluppo. Altri elementi chiave dell'XP sono il pair programming, l'uso sistematico di unit testing e refactoring, il divieto ai programmatori di sviluppare codice non strettamente necessario, l'enfasi sulla chiarezza e la semplicità del codice, la preferenza per strutture gestionali non gerarchiche, e l'importanza data alla comunicazione diretta e frequente fra sviluppatori e cliente e fra gli sviluppatori stessi.

Regole

Le dodici regole (o pratiche) che sono alla base di Extreme Programming possono essere raggruppate in quattro aree.

Feedback a scala fine

Pair programming - Due programmatori lavorano insieme su una sola workstation, uno sta alla tastiera e l'altro ragiona sull'approccio e pensa se può funzionare. Questo rende il codice prodotto di migliore qualità. I due programmatori devono avere la stessa esperienza.
Planning Game - è una riunione di pianificazione che avviene una volta per iterazione, tipicamente una volta a settimana.
Test driven development - i test automatici (sia unitari che di accettazione) vengono scritti prima di scrivere il 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 (sono consigliate riunioni settimanali o Jour fixe).

Processo continuo

Continuous integration - Integrare continuamente i cambiamenti al codice eviterà ritardi più avanti nel ciclo del progetto, causati da problemi d'integrazione.
Refactoring o Design Improvement - riscrivere il codice senza alterarne le funzionalità esterne, cambiando l'architettura, in modo da renderlo più semplice e generico.
Small Releases - consegna del software avviene tramite frequenti rilasci di funzionalità che creano del valore concreto.

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.

Benessere dei programmatori

Sustainable pace - il concetto è che i programmatori o gli sviluppatori software non dovrebbero lavorare più di 40 ore a settimana.

Modello dei processi

James Donovan Wells individua quattro linee guida:

comunicazione (tutti possono parlare con tutti, persino l'ultimo dei programmatori con il cliente);
semplicità (gli analisti mantengano la descrizione formale il più semplice e chiara possibile);
verifica (sin dal primo giorno si prova il codice);
coraggio (si dà in uso il sistema il prima possibile e si implementano i cambiamenti richiesti man mano).

Individua inoltre quattro fasi di progetto, ognuna delle quali con le sue regole interne:

pianificazione (user stories, release planning, small releases, project velocity, load factor, iterative development, iteration planning, move people around, daily stand up meeting, fix XP);
progettazione (simplicity, system metaphor, CRC cards, spike solution, never add early, refactoring);
sviluppo (Customer Always Available, Standards, Unit Test First, Pair Programming, Sequential Integration, Integrate Often, Collective Code Ownership, Optimize Last, No Overtime);
collaudo (unit test framework, bug's found, functional test o acceptance tests).

Bibliografia

Kent Beck: Extreme programming explained: Embrace change, Addison-Wesley, ISBN 0-201-61641-6
Kent Beck: Programmazione estrema - Introduzione, Addison-Wesley, ISBN 88-7192-088-0
Alistair Cockburn: Agile Software Development, Addison-Wesley, ISBN 0-201-69969-9
Kim Man Lui: Software Development Rhythms, John Wiley and Sons, ISBN 0-470-07386-1

Voci correlate

Altri progetti

Wikimedia Commons contiene immagini o altri file su extreme programming

Collegamenti esterni

Extreme Programming: A gentle introduction., su extremeprogramming.org.
Carlo Ghezzi, Mattia Monga, "eXtreme Programming: Programmazione estrema o revisionismo estremista?", Mondo Digitale (PDF), su mondodigitale.net.