Extreme programming

La programmazione estrema, meglio nota come extreme programming (XP), è una metodologia di sviluppo del software mirata a migliorare la qualità del codice e la responsività al cambiamento dei requisiti del cliente. In quanto tipo di metodologia di sviluppo agile, prescrive uno sviluppo in cicli brevi con pubblicazioni frequenti, con lo scopo di migliorare la produttività e introdurre punti di controllo nei quali i nuovi requisiti possono essere adottati.

Altri elementi della programmazione estrema comprendono la cosiddetta programmazione in coppia (pair programming) o fare un'estesa revisione di codice, test unitari del codice, non lavorare su funzionalità finché non sono necessarie, una struttura di gestione piatta, semplicità e chiarezza del codice, aspettarsi cambiamenti dei requisiti con il passare del tempo e con la migliore comprensione del problema e infine l'importanza data alla comunicazione diretta e frequente fra sviluppatori e cliente e fra gli sviluppatori stessi. La metodologia prende il nome dall'idea di portare a livelli "estremi" gli elementi positivi delle consuete pratiche di ingegneria del software. Ad esempio, portare all'estremo le revisioni di codice, considerate una buona prassi, implica che il codice possa essere revisionato continuativamente, come nella programmazione in coppia.

Regole

Le dodici regole (o pratiche) che sono alla base dell'extreme programming possono essere raggruppate in quattro aree.

Feedback a scala fine

• Pair programming - Due programmatori lavorano insieme su una sola workstation, il driver è colui che scrive il codice mentre il navigator 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

• Integrazione continua - 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

• Metodologia agile
• Scrum (informatica)
• Pair programming

Altri progetti

Altri progetti

• Wikimedia Commons

• 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. URL consultato il 20 gennaio 2010 (archiviato dall'url originale il 29 dicembre 2009).