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 e la frequente reingegnerizzazione del software, di solito in piccoli passi incrementali, senza dover rispettare fasi di sviluppo particolari.
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à.
- 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);
- Feedback (sin dal primo giorno si testa 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);
- Testing (Unit Test Framework, Bug's found, Functional Test o Acceptance Tests).
Ruolo di XP nell'ingegneria del software
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, la 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. Da questo punto di vista la bibliografia su Extreme Programming è vastissima ed è utile sfruttarne le risorse disponibili per una riflessione approfondita sui particolari delle metodologie leggere in generale.
Bibliografia
- Kent Beck: Extreme programming explained: Embrace change, Addison-Wesley, ISBN 0201616416
- Kent Beck: Programmazione estrema - Introduzione, Addison-Wesley, ISBN 8871920880
- Alistair Cockburn: Agile Software Development, Addison-Wesley, ISBN 0201699699
- Kim Man Lui: Software Development Rhythms, John Wiley and Sons, ISBN 0470073861
Voci correlate
Altri progetti
Wikimedia Commons contiene immagini o altri file su extreme programming