eXtreme Programming (XP) 101
Tempo di lettura: 20 minuti
EXtreme Programming è un framework concepito esclusivamente per lo sviluppo di software. Molte delle tecniche che compongono questo metodo hanno visto la luce nell’ambito del progetto C3 di Chrysler che si poneva l’obiettivo di riscrivere il sistema di paghe e stipendi utilizzato dall’azienda. Gli ideatori della metodologia sono due dei firmatari dell’Agile Manifesto, Kent Beck e Ward Cunningham. Come sarà possibile constatare, questo metodo ha molto in comune con Scrum. Alcuni elementi di vicinanza sono le iterazioni rapide al termine delle quali si avrà il rilascio di una versione funzionante del prodotto, la realizzazione di rapide riunioni giornaliere (Daily Stand Up Meeting), l’importante pratica dei feedback da parte degli stakeholders ed in particolare il forte coinvolgimento del cliente che è parte integrante del team di progetto.
Il fondamento della metodologia di XP è il processo di apprendimento noto come Shu-Ha-Ri, che ha origine dal metodo di insegnamento (e apprendimento) tipico delle arti marziali ed in particolare dell’Aikido. Questo processo attraversa, in maniera ordinata, i seguenti stadi:
Shu: lo studente segue pedissequamente gli insegnamenti del maestro concentrandosi sul compito più che sulle ragioni teoriche sulle quali esso si fonda;
Ha: lo studente amplia la sua base di conoscenze indagando i fondamenti teorici sui quali si basano le tecniche apprese nella fase precedente; nel fare ciò è compresa anche l’integrazione dell’apprendimento con il consulto di altri maestri;
Ri: lo studente ha tutto ciò che gli serve per imparare non più dalle persone ma dalla pratica stessa ed è lui a definire gli approcci alla materia e il modo di agire, adattando ciò che ha imparato ai diversi contesti nei quali si trova.
Tutto questo si può contestualizzare, nelle seguenti fasi di apprendimento e utilizzo del framework eXtreme Programming: applicazione di principi e pratiche (Shu), integrazione delle pratiche con altre pratiche (Ha) e creazione di nuove pratiche e di nuovi principi che si ispirino sempre ai valori fondanti di XP in particolare e Agile in generale (Ri).
I valori di XP
I valori sui quali XP si fonda sono:
simplicity: indica la capacità di massimizzare il lavoro non svolto; questa idea permette al team di concentrarsi veramente solo sulle cose che contano. Per individuare la soluzione ottimale per il cliente, bisogna partire da quella più semplice, che può essere poi arricchita di altri contenuti;
communication: una comunicazione efficace è sempre il mezzo migliore per far passare messaggi, confrontarsi, ecc… Come tutta la metodologia Agile, anche questo framework pone grande attenzione all’importanza della comunicazione faccia-a-faccia come mezzo per garantire un riscontro immediato. Come vedremo nei paragrafi successivi, sono state sviluppate delle vere e proprie pratiche in grado di garantire la comunicazione tra le parti più fortemente coinvolte;
feedback: permettono di capire se è giusta la direzione che si è presa nello sviluppo del progetto. Essi possono essere di diversa natura: esistono feedback dati dal sistema (quando il programmatore scrive il codice), forniti ai clienti (quando gli sviluppatori stimano le User Stories scritte dai clienti) e dai clienti (quando analizzano il rilascio al termine di ogni iterazione);
courage: inteso come assenza di paura, deve essere introdotto quando il gruppo incontra ostacoli particolarmente difficili da superare;
respect: il rispetto deve essere alla base di tutti i rapporti all’interno del team: in mancanza, difetteranno gli ultimi tre valori appena descritti.
I princìpi di XP
Con l’obiettivo di dare maggiore concretezza ai valori appena riportati, è stata stilata una lista di quindici princìpi che possono essere considerati come linee guida da applicarsi in situazioni reali. Riportiamoli di seguito per avere la possibilità di realizzare un breve commento e capire a quale valore ogni principio si abbina maggiormente:
allow rapid feedback: i feedback devono essere forniti nella maniera più veloce possibile, provengano essi dal codice che si sta scrivendo, dai clienti interessati o dal mercato nel quale ci si sta muovendo;
assume simplicity: ogni problema che viene posto deve essere trattato in modo da fornire la soluzione più semplice possibile. Non bisogna affrontare solo cose semplici, ma affrontare i problemi nella maniera più semplice possibile diceva Einstein;
make incremental change: partendo dalla soluzione semplice si possono sviluppare più facilmente degli incrementi, che devono essere sufficientemente grandi da portare un effettivo cambiamento, ma anche significativamente piccoli da poter identificare più rapidamente eventuali problemi derivanti dagli incrementi stessi;
embrace change: questo principio è strettamente legato al valore del coraggio. In questo caso, infatti, non bisogna lasciare che le difficoltà e i cambiamenti ci opprimano, ma tutte devono essere affrontate e accettate senza eccessiva paura;
deliver high-quality work: realizzare un prodotto di bassa qualità e di scarso interesse per il team e per il cliente non ha senso, per questo il gruppo deve sempre pretendere da se stesso un lavoro all’altezza delle aspettative;
teach learning: come visto dal concetto di Shu-Ha-Ri, l’apprendimento e il processo che vi sta dietro sono alla base del framework eXtreme Programming;
make a small initial investement: il cliente, inizialmente, non avrà idee chiare su cosa voglia realizzare. In questa fase è bene mantenere un piccolo gruppo di progetto in modo da non sprecare risorse, che dovrebbero interpretare tutta la vaghezza derivante da richieste poco precise del cliente; in un secondo momento sarà sempre possibile ampliare il team di progetto;
play to win: nessuno gioca per perdere e, proprio per evitare di ricevere dei no dal cliente, è bene che gli sviluppatori lascino più strade aperte possibili per futuri incrementi che potranno rientrare nell’ambito del progetto;
conduct concrete experiment: la fase di test è una delle più importanti per questo framework, per tanto si pone grande attenzione sulla necessità di effettuare test corretti che permettano poi al cliente di fornire adeguati riscontri;
promote open, honest communication: la comunicazione tra i membri del gruppo e con i clienti deve essere più aperta e onesta possibile; in questo modo sarà più facile accrescere altri valori come quello del rispetto;
work with people’s instincts, not against them: la creatività messa a disposizione dalle persone deve essere sfruttata al meglio, non solo per analizzare possibili varianti progettuali;
accept responsability: il team deve sentirsi fortemente coinvolto nel progetto, pronto ad assumersi la responsabilità delle scelte fatte, tutto ciò ha l’obiettivo di formare un forte senso di gruppo e sviluppare il valore del coraggio;
adapt as necessary: quanto realizzato non può essere uguale a quanto fatto in precedenza, su altri progetti, con altri clienti e con elementi differenti a comporre il team di sviluppo;
travel light: non esagerare mai nella documentazione ma cercare di mantenere alta la semplicità del prodotto; fare report, testi scritti, statistiche, ecc… risulta utile fino a che il loro effettivo utilizzo trova senso nel progetto;
meausure honestly: scegliere unità di misura che siano le più oggettive e corrette possibili al fine di verificare, anche a posteriori, la bontà del lavoro svolto.
Le pratiche di XP
Per fornire ulteriore concretezza ai principi appena esaminati, sono state definite una serie di pratiche. Esse possono essere considerate come delle best practices che i gruppi di sviluppo utilizzano durante il ciclo di vita del progetto. Come già visto quando si è parlato del metodo di apprendimento alla base di questo framework, conoscere bene le pratiche e la tecnica è il punto di partenza per implementare correttamente la metodologia.
Le pratiche sono divise in primarie e secondarie. Le riporteremo in due elenchi separati in modo da poterle più facilmente distinguere. Può essere interessante notare come le pratiche non si debbano intendere come tanti elementi separati ma, anzi, devono essere considerate nel loro insieme per garantire una certa efficacia. Iniziamo quindi riportando le dodici pratiche primarie:
on site customer: coinvolgere il cliente durante tutto il progetto permette di ridurre la documentazione che normalmente viene fornita nella fase iniziale di definizione dei requisiti o quando essi vengono modificati, oltre alla possibilità di fornire feedback in maniera più rapida e tempestiva su quanto viene sviluppato;
pair programming: pratica che può sembrare inefficiente e costosa, riguarda due programmatori che condividono la stessa tastiera e lo stesso monitor. Un giorno il primo scrive il codice e il secondo osserva ciò che viene fatto, mentre il secondo giorno i ruoli si invertono e così via. Questo metodo permette di ridurre i bug del codice (poiché lo sviluppatore che osserva può riferire subito all’altro gli errori), compresi quelli di battitura, scrivere un minor numero di righe di codice (necessarie per risolvere gli errori di cui sopra) ed avere una visione più ampia e condivisa tra tutto il team;
collective code ownership: il senso di squadra che deve nascere e svilupparsi durante il progetto serve anche per definire il codice come proprietà di tutto il gruppo e non solo di qualcuno in particolare; ogni coppia di sviluppatori può permettersi di modificare parte del codice anche scritto direttamente da altri;
coding standard: avere una proprietà condivisa del codice favorisce l’utilizzo di una sintassi comune in fase di scrittura;
refactoring: riscrittura del codice con l’obiettivo di migliorarlo senza inficiare il suo comportamento esterno. È lo stesso sviluppatore che si interessa di una modifica al codice che deve operarsi per primo nella realizzazione del refactoring essendo conscio che tutto deve essere realizzato in modo da evitare l’obsolescenza del codice stesso;
testing: come già ampliamente riportato, i test sono tra gli elementi più importanti del framewok XP e, per quel che riguarda il programma, essi dovrebbero essere definiti prima della stesura del codice in modo che il secondo possa essere assolutamente autonomo e non vada a modificare la validità dei test stessi. Nelle fasi iniziali, però, si effettuano test anche sulle User stories forniti dal cliente per garantire che tutte siano sviluppate in conformità con le aspettative;
continuous integration: gli avanzamenti devono essere integrati quotidianamente per evitare che si accumulino problemi e quindi trovare soluzioni in tempi brevi che risultino poco invasive per il tutto il resto del codice;
planning game: cliente e gruppo di sviluppo realizzano previsioni sul futuro preparando User stories che verranno poi stimate in termini di costo e grandezza e prioritizzate dal cliente. Quanto definito viene suddiviso nelle diverse iterazioni e si decide, dopo un certo numero di queste, di rilasciare una prima release del prodotto. Tutto ciò viene ripetuto fino ad ottenere il prodotto finito;
small releases: ad ogni rilascio di funzionalità non si deve perdere di completezza nella soluzione fornita né di qualità e, visto che le iterazioni hanno tempistiche fissate tra le due e le quattro settimane, si dovrà fare in modo che l’ambito si adatti ad ogni singola iterazione fornendo così piccoli incrementi di prodotto;
system metaphor: la metafora consente di semplificare il linguaggio utilizzato riducendo al minimo i tecnicismi; in questo modo, clienti, sviluppatori e utenti potranno utilizzare un linguaggio comune e sufficientemente diffuso e padroneggiato;
simple design: il design di codifica del software deve essere il più semplice possibile e deve permettere al team di realizzare tutte le funzionalità che il cliente si aspetta di trovare;
sustainable pace: il ritmo di processamento delle User stories deve essere il più costante possibile e deve essere mantenuto fino alla fine del progetto.
Le pratiche secondarie, anche definite corollarie, derivano da quelle primarie appena elencate e sono:
real customer involvement: anche in XP il responsabile della definizione dei test e della prioritizzazione delle User stories è il Product Owner. Questa pratica vuole aggiungere, però, un altro livello di coinvolgimento del cliente chiedendo che anche il Real customer sia una figura facente parte del gruppo di sviluppo. Questo ruolo può essere ricoperto da uno o più dei seguenti soggetti: Product Owner, Domanin expert (deve fornire informazioni al gruppo in merito al settore nel quale l’azienda opera), Interaction designer (cura l’interfaccia grafica del prodotto basandosi sulle aspettative e i bisogni del cliente finale) e Business analyst (collegamento di lunga durata tra cliente e sviluppatori);
incremental deployment: pratica derivante dalla difficile integrazione tra sistemi più datati e sistemi di più recente costituzione. Il problema nasce dall’inerzia al cambiamento dovuta spesso agli importanti investimenti iniziali fatti in questo ambito. Rilasciare piccoli incrementi di prodotto permette di adattare il tutto con maggiore facilità rispetto ad effettuare lanci di un’unica release conclusiva;
team continuity: un gruppo di progetto ha difficoltà a formarsi dal nulla e ci impiega tempo prima di essere in grado di performare adeguatamente. Perdere tutto questo sforzo fatto è impensabile per una metodologia Agile che punta, invece, alla crescita dei membri di un gruppo sia a livello professionale che relazionale. In quest’ottica risulta molto più efficace assegnare un progetto ad un intero team che ha già lavorato insieme più che a singoli individui;
shrinking team: con l’avanzare del progetto, il carico di lavoro tende a diminuire. Al fine di evitare che le risorse si sentano sottoutilizzate e che perdano la motivazione, risulta utile cercare di mantenere costante la pressione sul team andando, di volta in volta, a ridurre il numero di membri. In questo modo si possono perseguire tre obiettivi: evitare che ci siano risorse sotto allocate, continuare a gestire team di piccole dimensioni e a formare nuovi team Agile riposizionando gli elementi che sono usciti dal gruppo di progetto originario;
root cause analysis: obiettivo importante è sempre quello di comprendere l’errore ed eliminarlo, oltre che conoscerne la causa. Per fare ciò, uno degli strumenti più utilizzati è il diagramma di Ishikawa (o spina di pesce) che ha proprio il compito di aiutare i membri del gruppo ad inquadrare un problema e, in maniera sempre più approfondita, individuarne le cause;
shared code: come già visto in precedenza, il codice è una proprietà condivisa alla quale tutti possono apportare miglioramenti; questo sviluppo positivo del tutto è possibile, però, solo quando tutti i membri del team si sentono pienamente responsabili di ciò che stanno realizzando. Propedeuticamente a questo, uno strumento utile sono le pratiche di team building;
code and tests: il codice e il piano di test sono l’unico artefatto permanente a cui ogni incremento deve poter portare un aumento di valore, tutto il resto deve essere considerato come uno spreco;
single code base: il flusso e la modifica di una unica forma del codice sono di aiuto alla pratica di incremento continuo. Per mantenere evidenti le modifiche e gli aggiornamenti è possibile utilizzare un sistema di controllo di versione;
daily development: il rilascio quotidiano di piccoli incrementi permette di ridurre il tasso di difettosità e, allo stesso tempo, migliora il rapporto tra cliente e team di sviluppo;
negotiated scope contract: nella metodologia Agile le caratteristiche più importanti di un progetto sono il tempo, i costi e la qualità; la parte più flessibile è invece l’ambito di ogni iterazione che può anche essere rinegoziata di volta in volta con piccoli contratti;
pay per use: i sistemi pay per use permettono di guadagnare ogni volta che il prodotto viene utilizzato. In questo modo è possibile sfruttare il flusso di denaro come feedback finale; collegare questo con la fase di sviluppo permetterebbe ai progettisti di comprendere meglio quali funzionalità siano quelle più utilizzate e lavorarci sopra per migliorarle ulteriormente.
Il ciclo di vita di XP
Come è stato possibile evincere dalla trattazione fatta fino ad ora, il ciclo di vita definito dal framework eXtreme Programming contiene molte delle fasi già viste per altri metodi Agile.
Cercando di seguire il percorso descritto dall’immagine riportata sotto, analizziamo i momenti principali che caratterizzano questo metodo.
Ciclo di eXtreme Programming su WeAreMarketing
Il primo passo è detto Architectural spike ed inizia con l’aggregazione di clienti e sviluppatori in modo da capire cosa realizzare e come farlo. Obiettivo di questa prima fase non è fornire la soluzione intera al problema, ma solo una prima idea sulla quale iniziare a lavorare tenendo a mente il valore della semplicità, che aiuterà a sviluppare un design più flessibile e facilmente aggiornabile.
Durante la definizione di questo primo embrione, il gruppo inizia a comprendere meglio l’ambito del progetto oltre ai requisiti e alle funzionalità richieste dal cliente. Tutto questo viene sviluppato esplicitando le cosiddette User stories. Esse risultano generalmente composte da una descrizione (resa per iscritto) di quanto si vuole implementare (card), una discussione tra gruppo di progetto e cliente al fine di far emergere ulteriori dettagli (conversation) e dalla definizione di un test di accettabilità della funzionalità sviluppata alla conclusione della User story in esame (confirmation). Il tutto deve essere scritto in linguaggio molto naturale e poco tecnico esplicitato nella forma: as (ruolo, persona di interesse), I want (cosa ricerco, quale funzionalità) so that (quale beneficio voglio trarre dalla funzionalità che viene richiesta). Queste richieste non sono da confondere con dei casi di utilizzo da parte di utenti, ma sono dei desideri dimostrati lato utente. Una User story ben definita deve presentare le seguenti caratteristiche: indipendent (indipendente da altre User stories in modo da poter essere riprioritizzata e quindi traslata nelle iterazioni), negotiable (il team deve poterla negoziare con il business al fine di creare qualcosa di congruo e consistente), valuable (il beneficio deve essere chiaro da identificare), estimatable (il team deve riuscire a stimare lo sforzo richiesto per la realizzazione della User story), small enought (più è piccola e definita, meglio è) e testable (la fase di test rimane importante per capire quando la richiesta sia effettivamente soddisfatta o meno).
Come per il framework Scrum, anche in questo caso ad ogni User story sono associati degli story points che possono essere definiti come il prodotto tra la sua grandezza in termini di attività di analisi, design, codifica e test e la sua complessità messa in relazione alle altre User stories. Come già visto, non sono un’unità di misura per valutare il tempo necessario a rilasciare quella specifica funzionalità, ma il loro consumo permette di definire un parametro importante per il gruppo di progetto, la project velocity. Questa non è altro che la velocità di processamento dei diversi Story points. Questo parametro dovrebbe già essere noto al primo rilascio in modo da poter stimare meglio le attività che si riescono o meno a fare in ogni iterazione. Ciò, però, non è sempre possibile a causa di fattori come l’inesperienza del team; per questo motivo alle prime iterazioni si può procedere secondo una delle seguenti strade:
stimare il numero di Story points processabili come un terzo del tempo a disposizione del gruppo di progetto; es. (5 membri x 12 gg/iterazione) / 3 = 20 Story points/iterazione. Questo metodo è un po’ spartano ma risulta immediato ed utile per gruppi che si approcciano per la prima volta a questa realtà;
divisione le diverse attività in task elementari valutabili in ore e chiedere al team per quali e quante di queste è in grado di prendersi la responsabilità di portarle a termine in modo da colmare la capacità produttiva del gruppo.
I dati emersi da questa prima iterazione saranno poi utilizzati per pianificare quella successiva. La parte conclusiva di questa prima fase porta al secondo passo del ciclo di vita di un progetto XP, la (ri)modellazione del Release plan in funzione della fattibilità di raggiungimento degli obiettivi che ci si è prefissati.
In questa fase, i momenti principali sono fondamentalmente due: il Planning game e il Planning poker. Il primo è un momento di brainstorming durante il quale Product owner e gruppo di sviluppo valutano la priorità di ogni User story, il cliente comunica le sue necessità e gli sviluppatori definiscono il loro impegno e la fattibilità tecnica di quanto richiesto.
Il secondo momento è invece legato ad una tecnica Agile che mira ad aumentare il consenso tra i membri del gruppo di progetto in merito alla valutazione delle User stories. Ogni membro del team ha un mazzo che contiene carte con i valori 1, 2, 3, 5, 8, 13, 21 e una tazza di caffè; questi valori rappresentano il numero di Story points che è possibile fornire ad una User story. Il facilitatore legge uno dei requisiti portati dal cliente e ogni membro del gruppo sceglie una carta che rappresenta la sua stima in termini di grandezza e complessità. Tutte le carte vengono mostrate allo stesso istante e il team inizia a discutere delle proprie stime fino a che non si decide che è il momento di procedere con una nuova votazione e così via fino a che non si raggiunge il consenso tra tutti i membri del gruppo. Se non si dovesse raggiungere la convergenza ma la differenza fosse poca si può procedere facendo la media tra i valori ottenuti. Se la divergenza fosse molto ampia, sarebbe invece consigliabile proseguire nella discussione in modo da poterla ridurre. La carta contenente la tazza di caffè serve invece per dire che al gruppo serve una pausa per poter staccare momentaneamente dal problema e riprendere la discussione a mente più libera. Il vantaggio di questo metodo è che sono proprio le persone direttamente coinvolte nel progetto ad esprimere le loro stime, cosicché saranno maggiormente coinvolte e pronte ad assumersi delle responsabilità.
A differenza del framework Scrum, la durata di un’iterazione non ha un limite massimo ma esso può essere fissato liberamente dal team tenendo conto di alcuni parametri come: durata della release (definire a priori quando un cliente vorrà avere un prodotto vendibile), incertezza (maggiore è, minore dovrà essere il tempo dell’iterazione), facilità di ottenere feedback e stabilità delle priorità assegnate alle User stories. Importante è tenere a mente cosa risulta essere prioritario. Nel caso fosse il tempo, esso sarà mantenuto ben fissato e si negozierà continuamente l’ambito della parte di progetto che si ritiene realizzabile entro la data fissata. Se invece fosse prioritario l’ambito, il team chiederà più tempo per realizzare tutto quanto richiesto (con un conseguente aumento dei costi).
L’ultimo passaggio è l’iterazione vera e propria. In questa fase il gruppo lavora sul progetto senza interruzioni e, al termine, rilascia le funzionalità richieste, testate, riviste e accattate dal cliente. Al termine di questa fase, si conoscerà anche il valore di velocità di conseguimento degli Story points che si è riusciti a tenere nel corso dell’iterazione stessa. Questo dato sarà utile per calibrare meglio quella successiva.
