Extreme Programming: Caratteristiche e utilizzo della tecnica del Planning Game

Extreme Programming

L’Extreme Programming (XP) è una metodologia di sviluppo adottata per mettere in pratica le filosofie Agili durante lo sviluppo di uno o più processi software. Tramite questa metodologia i team di sviluppo sono in grado di rilasciare il software richiesto in tempi rapidi, così come è stato richiesto e mette in condizione gli sviluppatori di rispondere in maniera tempestiva alle mutate esigenze del committente o del Product Owner, aspetto molto importante.
L’extreme programming enfatizza il lavoro di team: manager, clienti e sviluppatori sono tutti parte di un team collaborativo, in grado di auto-organizzarsi in modo che il problema (lo sviluppo di un progetto software in questo caso) venga risolto nel metodo più efficiente possibile.
Un aspetto sorprendente dell’XP sono le sue semplici regole, dal significato trascurabile, se prese singolarmente, di grande efficacia se applicate, anche solo in parte, assieme.

Di seguito una breve descrizione di una delle tecniche utilizzata ampiamente in XP con una serie di accorgimenti utili, suddivisi per fase di progetto.

Pianificazione e Planning Game

Il Planning Game è una riunione tenuta tipicamente una volta a settimana, ed è composta da due fasi.
La fase di Release Planning ha lo scopo di determinare, coinvolgendo il cliente, quali requisiti devono essere lavorati nelle le prossime tre/quattro iterazioni e quando il software che li soddisfa dovrebbe essere rilasciato. I requisiti vengono tracciati sotto forma di User Stories per le quali gli sviluppatori forniranno, una volta appresi i requisiti, una stima, espressa in story-points della mole di lavoro necessaria per poterla rilasciare. Una volta che la storia è stata stimata, sviluppatori e cliente definiscono in quale sprint sarà lavorata e, di conseguenza, quando il lavoro verrà consegnato. In questa fase gli sviluppatori devono tenere conto della capacità di lavoro a loro disposizione ed il cliente sarà quindi chiamato a fare delle scelte assegnando una priorità alle sue richieste.

La seconda fase invece è quella nominata Iteration Planning, durante la quale il cliente non è coinvolto. In questa fase gli sviluppatori pianificano la propria attività da svolgere sulle storie definite durante la fase precedente. Durante questa fase le User Stories possono venire suddivise in task tecnici. Gli sviluppatori (o le coppie di sviluppatori) prendono in carico i task ai quali intendono lavorare nell’ambito dell’iterazione.

Gestione

Accorgimenti gestionali utili, volti a mettere il team in condizione di lavorare al meglio:

Sistemare il team in un unico open space.
Impostare un ritmo sostenibile. La capacità di lavoro del team è limitata. E’ bene che sia chiaro cosa il team è in grado di fare durante uno sprint e quali attività invece devono essere suddivise su più sprint. Non ha senso, se non in casi di emergenza, fare affidamento su straordinari ed eroismi individuali per terminare in tempo quanto pianificato.
Stand up meeting. 10′, in piedi, all’inizio di ogni giorno lavorativo per condividere le attività svolte e quel che si prevede di fare in giornata.
Misurare la Project Velocity. La Velocity indica quanto lavoro stà venendo effettivamente fatto nell’ambito del progetto. Un metodo per misurarla consiste nel confrontare quanti story-points sono stati evasi (storie completate) con quanti ne sarebbero stati evasi con un andamento regolare. Esempio: in uno sprint da 40 story points della durata di 20 giorni lavorativi ci si aspetterebbe che al 14° giorno il numero di story-points evasi non si discosti troppo da 28. Nel caso vi sia uno scostamento è necessaria una analisi delle cause (stime errate? Urgenze?)
Spostare la gente. Tutti devono essere in grado di lavorare ad ogni aspetto del progetto, in modo da evitare colli di bottiglia o squilibri del carico di lavoro all’interno del team.
Cambiare quel che non funziona. Nel puro spirito auto-organizzativo del team, ogni cosa che “non va” deve essere affrontata e risolta assieme.

Design

Semplicità. Non andare a ricercare sempre soluzioni sofisticate, e non reinventare sempre la ruota.
Impiegare Metafore di sistema. Ovvero assegnare nomi consistenti e facilmente intuitivi a tutti gli oggetti coinvolti, in modo che siano facilmente spiegabili e comprensibili.
CRC (Class Responsibility Collaboration) cards game durante le sessioni di design. Si impiega un foglietto di carta per ogni oggetto (classe) ipotizzato. Il foglio riporta nome, responsabilità e collaboratori della classe. In questo modo il team definisce “su carta” (è proprio il caso di dirlo) l’architettura di un insieme di classi deputate alla soluzione di un problema. Tutto il team è coinvolto e tutti hanno una chiara visione dell’architettura prodotta.
Creare soluzioni spike per ridurre i rischi. In caso di problemi a soluzione incerta o fumosa, il team deputa una o due persone allo studio del problema e di una o più possibili soluzioni, per un periodo predefinito di tempo, in modo che il problema possa essere affrontato meglio in un prossimo sprint.
Non introdurre funzionalità in anticipo. Le funzionalità rilasciate devono essere quelle richieste, non quelle che “potrebbero servire in futuro”. Se serviranno, verranno richieste.
Refactor ovunque, quando possibile. Riscrivere parti di codice di difficile comprensione (“marcite”) in modo da renderne più semplice la leggibilità e la manutenibilità.

Coding

Cliente sempre disponibile. In XP il cliente è inteso come un rappresentante dell’utenza finale. E’ fondamentale che ogni membro del team possa chiarire al più presto direttamente con lui eventuali dubbi che dovessero insorgere. Chi sia questo interlocutore deve essere chiaro a tutti i membri del team.
Il codice deve essere scritto seguendo standard concordati (code-conventions).
Test Driven Development (TDD). Il codice viene scritto a partire dai test. Vista l’importanza e soprattutto l’efficacia della pratica, verrà trattata in un paragrafo apposta.
Pair Programming. Il codice viene scritto da una coppia di sviluppatori usufruendo di una singola workstation. Uno sviluppatore utilizza tastiera e mouse ed è focalizzato sul codice in scrittura. L’altro segue più la visione di insieme ed opera una continua review del codice scritto dal collega. I ruoli vengono invertiti dopo non più di un’ora, l’ideale è introdurre una pausa durante lo scambio di ruoli.
Commit (integrazioni) frequenti. Ideale 2 volte al giorno.
Code Review. Il codice committato nel sistema di controllo versione (VCS) è frutto di revisione da parte di altri membri del team, che possono fornire utili suggerimenti ed indicazioni circa quanto scritto tramite commenti nel codice che verranno recepiti o meno dall’autore del pezzo interessato.
Impiegare un computer dedicato all’integrazione. Esistono numerosi tools (Jenkins, ad esempio) che permettono di avere sempre sotto controllo la compilazione ed il processo di build e packaging della code base integrata.
Collective ownership. “Il codice è di tutti”, tutti devono essere liberi di modificarlo allo scopo di refattorizzarlo, fixare bug, etc. senza chiedere il permesso all’autore originale. Questo contribuisce alla diffusione della conoscenza e quindi alla riduzione dei colli di bottiglia.

Testing

Tutto il codice deve essere coperto da classi di Test Unitari (Unit Test). I test unitari coprono singole classi o gruppi ristretti di classi a forte collaborazione e vengono eseguiti durante la build del codice.
Il codice deve superare i test unitari prima che possa essere rilasciato. Il team deve assicurare sempre il corretto funzionamento dei test unitari. La manutenzione dei test deve essere importante tanto quanto quella del codice dell’applicazione.
Quando viene rilevato un bug, vanno creati i test che assicurino che non si ripresenti in futuro.
I test di accettazione (Acceptance tests) vanno eseguiti spesso ed il loro risultato viene pubblicato. Questa tipologia di test sono test a scatola chiusa, scritti sulla base delle User Stories e verificano che il sistema dia il risultato atteso.