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 od 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