Extreme Programming in pratica
L’eXtreme Programming o anche detto XP appartiene alla famiglia delle metodologie Agile e quindi si basa sullo sviluppo iterativo ed incrementale organizzato con cicli brevi di sviluppo (gli sprint). Si potrebbe dire che XP sia nato ufficialmente verso la fine degli anni ’90 in un progetto sviluppato da Kent Beck in Daimler Chrysle, dopo aver lavorato per parecchi anni con Ward Cunningham alla ricerca di un nuovo approccio per garantire lo sviluppo del solo codice strettamente necessario, enfatizzando semplicità e chiarezza del codice cercando quindi di costruire una metodologia che permettesse risultati rapidi ed efficaci. Alla base di questa metodologia sono da sottolineare anche le preferenza di strutture gestionali non gerarchiche e la costituzione di cerimonie giornaliere che agevolino la comunicazione diretta tra tutti i soggetti del team.
Tutte le fasi della metodologia XP le potete trovare nell’immagine di questo articolo. Non andrò a descrivervi ogni fase del processo queste le potete già trovare su decine di siti qui di seguito vi racconterò invece quelle regole pratiche “che ho testato sul campo” che mi hanno permesso di adottare con soddisfazione l’eXtreme Programming:
Planning Game: consiste nel pianificare due incontro giornalieri, uno al mattino presto e uno a fine giornata. Durante il meeting mattutino si definiscono le attività che ognuno si incaricherà di svolgere nella giornata mentre nel meeting di fine giornata ognuno effettuerà la demo di quanto ha prodotto durante la giornata. L’eXtreme Programming si basa sempre sulla metodologia Agile quindi vengono rispettate le fasi di Planning, Development e Retrospective che si svolgono nel classico arco temporale di 2-4 settimane ma con il Planning Game si ha l’effetto di realizzare un micro sprint giornaliero con la verifica immediata dell’artefatto prodotto.
Pair Programming: è molto efficace adottare il pair programmino e quindi gli sviluppatori lavorano a coppie su una sola workstation. Il Driver scrive il codice ed il Navigator valuta l’efficacia dell’approccio ed il suo corretto funzionamento. Questa modalità non è facile da adottare è importante che ci sia feeling tra gli sviluppatori e che ci sia un livello di esperienza equilibrato.
Test Driven: vengono scritti prima i test e poi si inizia a scrivere il codice. I test scritti sono il mezzo poi utilizzato per la demo di fine giornata. In caso di modifiche a software già esistente prima vanno integrati i test e poi si interviene con la modifica del codice.
Delivery Giornaliero: ogni giorno viene rilasciato codice, viene testato e come previsto dal Planning Game viene eseguita una breve demo alla fine di ogni giornata.
Standards: prima di iniziare a scrivere la prima riga di codice è fondamentale condividere e scegliere un preciso standard di scrittura del codice che l’intero team di sviluppo accetta di rispettare nel corso del progetto.
Ownership: la responsabilità del codice prodotto non è solo di chi lo ha scritto ma è responsabilità di tutto il team quindi ognuno è tenuto a dare contributi per migliorarlo.
Simple design: l’approccio alla progettazione e scrittura del software deve essere orientata al concetto di “semplice è meglio”. E’ concesso quindi il refactoring per realizzare software più semplice sempre tenendo presente che è fondamentale rispettare i requisiti dei test inizialmente scritti.
Metaphor: Il funzionamento del sistema viene descritto utilizzando delle metafore, quindi ogni funzionalità sarà raccontata con una storia che possa essere raccontata ad un soggetto esterno al team per spiegare il funzionamento del sistema.
Sustainable pace: l’eXtreme Programming è un modello di lavoro che richiede molte energie e quindi è buona regola mantenere il team su un volume non superiore alle 40 ore a settimana.
Una chiave di successo per l’applicazione con successo della metodologia XP è la sintonia del team, ho personalmente sperimentato che un fattore facilitante è che il team sia composto da persone che abbiano già lavorato insieme su altri progetti e che il livello di esperienza dei componenti del team sia Medio\Alto.
Chiudo questo articolo con una frase presa dal libro di Kent Beck per darvi un’idea di quale siano stati i suoi spunti nella costruzione del metodo XP: Tutto cambia nel software. I requisiti cambiano. La progettazione cambia. Gli aspetti commerciali cambiano. La tecnologia cambia. I componenti del team cambiano. Il problema non è il cambiamento, di per sé, perché i cambiamenti avverranno; il problema, piuttosto, è l’inabilità di far fronte ai cambiamenti quando essi avvengono.
