Extreme Programming (XP) come metodologia di sviluppo agile

Extreme Programming (XP)

EXtreme Programming è un approccio all’ingegneria del software formulato da Kent Beck, Ward Cunningham e Ron Jeffries. Essa implementa un ambiente semplice ma efficace che consente ai team di diventare altamente produttivi. Il gruppo si auto-organizza intorno al problema da risolvere nel modo più efficiente possibile.
Gli elementi chiave della metodologia sono la velocità di risposta alle variazioni dei requisiti del cliente e il rilascio frequente di incrementi di prodotto.

Alla base di Extreme Programming vi sono 12 pratiche raggruppabili in 4 categorie:

Prima categoria: feedback rapid

Pair Programming: significa che tutto il codice viene prodotto da due persone che programmano assieme sullo stesso task.
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.
Il processo di pianificazione è diviso in due fasi:

1. Pianificazione del rilascio
2. Pianificazione dell’iterazione

Test Driven Development (TDD): in Extreme programming è previsto la stesura dei test automatici prima di quella del software che deve essere sottoposto a test, e lo sviluppo del software applicativo sia orientato esclusivamente al superamento di questi test automatici precedentemente predisposti.

Il TDD prevede la ripetizione di un breve ciclo di sviluppo diviso in tre fasi, detto “ciclo TDD”. Nella prima fase (detta “fase rossa”), il programmatore scrive un test automatico per la nuova funzione da sviluppare, che deve fallire in quanto la funzione non è stata ancora realizzata.
Nella seconda fase (detta “fase verde”), il programmatore sviluppa la quantità minima di codice necessaria per passare il test e si verifica che effettivamente il test venga superato.

Nella terza fase (detta “fase grigia”), il programmatore esegue il refactoring del codice per adeguarlo a determinati standard di qualità.

Seconda categoria: processi continui

Continuous Integration: Il team di sviluppo dovrebbe sempre lavorare sull’ultima versione
del software. Per questo motivo ciascun dovrebbe caricare frequentemente la sua versione nel repository del codice permettendo cosi a tutto il team di lavorare sulla versione più aggiornata del codice. L’integrazione continua serve ad evitare dei ritardi più avanti nel ciclo di sviluppo causati da problemi di integrazione.

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.

Terza categoria: condivisione delle conoscenze

Standard del Codice: 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. Chi scrive il codice deve chiedersi se esiste una via
più semplice per introdurre la stessa funzionalità, se si deve usare quella.

Quarta categoria: salute dei programmatori

Ritmo di lavoro sostenibile: i programmatori non dovrebbero lavorare per più di quaranta ore a settimana.

Sono 4 i valori principali che caratterizzano la metodologia Extreme Programming, a cui è stato aggiunto un quinto valore che è il Rispetto.

1. Comunicazione: è I membri di un team di sviluppo devono comunicare costantemente fra di loro così come con il cliente. In XP l’obiettivo è dare a tutti gli sviluppatori una visione condivisa del sistema e a questo scopo è importante la collaborazione tra utilizzatore e sviluppatore, la comunicazione verbale e i feedback.
2. Semplicità: Semplici devono essere i processi di sviluppo, divieto assoluto di complicazioni inutili, del resto è molto più semplice abbozzare un’idea o una parte di software e poi migliorarla successivamente quando si ha una conoscenza della situazione più approfondita.
3. Feedback: ci sono vari tipi di feedback.
   1. Feedback dal sistema: che si ottiene scrivendo test di unità o svolgendo dei test di integrazione periodici, permettono al programmatore di ottenere un riscontro immediato sullo stato del sistema.
   2. Feedback dal cliente: i test di accettazione, sono scritti dal cliente e dai tester e danno un feedback concreto sullo stato del sistema.
   3. Feedback dal team: il team da una stima del tempo che sarà necessario a sviluppare un nuovo requisito dato dal cliente.
4. Coraggio: Prendere decisioni importanti risulta fondamentale, anche ammettere però i propri errori è parte integrante di un “coraggioso processo” con il conseguente riesame del sistema esistente e l’effettuazione di eventuali modifiche.
5. Rispetto: Umiltà e rispetto sempre e comunque di tutte le persone coinvolte nel progetto: in pratica in XP tutti coloro che prendono parte al progetto hanno voce in capitolo senza distinzione alcuna.