Extreme Programming è una metodologia di sviluppo software, conosciuta anche con l’abbreviazione di XP, appartenente alla famiglia delle metodologie Agile che stanno prendendo sempre più campo.

In questo articolo parlerò di due libri sull’Extreme Programming, libri che mi hanno consigliato e che si sono dimostrati particolarmente validi:

• Extreme Programming Explained: Embrace Change
• Planning Extreme Programming

Autore (o co-autore nel secondo caso) dei libri, Kent Beck è una “superstar” del panorama sviluppo software Agile: tra i 17 autori dell’originale manifesto Agile, è stato tra il creatore della metodologia di sviluppo Test Driven Development e tra i creatori dell’Extreme Programming stesso. Dal punto di vista software, il suo contributo più grande al mondo degli sviluppatori Java è stato senza dubbio la creazione del framework per il testing JUnit.

Extreme Programming Explained – di Kent Beck

Che cos’è l’Extreme Programming

XP prende un insieme di regole di “buon senso”, applicandole fino ad “estremi” livelli. Queste regole di buon senso permettono ai programmatori di lavorare su quello che importa davvero, permettendo di vedere concretamente i progressi sugli obiettivi di interesse, anche ai manager e ai clienti in modo di permetter loro di modificare eventualmente il corso del progetto prima che sia troppo tardi (XP riduce i rischi del progetto, riduce i tempi di risposta a modifiche nelle specifiche ed aumenta la produttività dei programmatori.

Punti base dell’Extreme Programming

Forse con un pò troppa benevolenza XP viene definito da Kent Beck come una metodologia leggera, efficiente, flessibile, predicibile, scientifica e divertente per lo sviluppo del software. Si distingue dalle altre metodologie per:

• Concretezza, rapidità e capacità di fornire feedback continuo grazie a cicli di sviluppo brevi
• Approccio di pianificazione incrementale, che permette di creare un piano in continua evoluzione durante la vita del progetto
• Pianificazione flessibile dell’implementazione delle funzionalità, in risposta alle modifiche richieste dai clienti
• Affidabilità grazie ai test automatici, che permettono di osservare in ogni momento l’evoluzione dei progressi, risolvendo eventuali problemi prontamente
• Affidamento sulla comunicazione orale, sui test e sul codice sorgente per comunicare la struttura e l’intento del sistema
• E’ orientato a progetti realizzabili da team da 2 a 10 programmatori

I problemi delle metodologie classiche di sviluppo

Il problema principale dello sviluppo software è dato dal rischio. Il rischio può essere di vario tipo: slittamenti temporali, cancellazione del progetto, defect rate (difettosità) del sistema tale da rendere inutilizzabile lo stesso, incomprensione delle specifiche di business, modifiche alle specifiche di business, funzionalità fasulle (divertenti da programmare, ma inutili per il cliente), turnover dello staff (i programmatori iniziano ad odiare il programma e lo lasciano).

XP cerca di rimediare a tutto ciò:

• SLITTAMENTI -> grazie ai brevi cicli di rilascio del software, la dimensione di eventuali slittamenti è limitati; per ogni rilascio XP usa iterazioni di 1-4 settimane per rilasciare specifiche features richieste dal processo; all’interno di una iterazione vengono definiti task più piccoli da completare, da 1-3 giorni.
• CANCELLAZIONE DEL PROGETTO -> grazie alle release di piccole dimensioni è meno probabile
• DEFECT RATE -> vengono eseguiti test continuamente, sia dai programmatori (funzione per funzione) che dai clienti (feature per feature)
• INCOMPRENSIONE DELLE SPECIFICHE -> il cliente nell’XP è una parte integrale del team di sviluppo: le specifiche sono continuamente raffinate durante lo sviluppo
• MODIFICHE ALLE SPECIFICHE -> con brevi cicli di release è più difficile che queste vengano modificate
• FALSE FEATURE -> utilizzando XP si cerca di concentrarsi sui task ad alta
• STAFF TURNOVER -> il programmatore ha sotto occhio il piano, conosce quali sono le tempistiche, è più difficile che risulti frustrato e voglia andarsene

Variabili nel modello progettazione software

Sono quattro: COSTO, TEMPO, QUALITA’, FEATURES.

XP cerca di rendere le quattro variabili costantemente monitorabili a tutti: programmatori, clienti e manager. Monitorando le variabili i manager e i clienti loro possono decidere quali variabili controllare e sulle quali lasciare libertà agli sviluppatori.

• COSTI -> Troppo denaro può creare più problemi di quelli che risolve, mentre troppo poco non permetterà la risoluzione dei problemi di business
• TEMPI ->Allungare i tempi a disposizione può aumentare le features e la qualità, ma dato che il miglior feedback è quello che si ottiene dal sistema finito, troppo tempo a disposizione è dannoso.
• QUALITA' -> Posso guadagnare sul tempo tagliando in qualità, ma potrei avere problemi di risorse umane, tecniche e feature notevoli. Inoltre bisogna specificare che la qualità è di due tipi esterna, cioè misurata dai clienti ed interna cioè quella misurata dai programmatori.
• FEATURES ->Con meno feature posso aumentare la qualità, devo comunque tenere a mente di risolvere il problema principale.
• INTERAZIONE CON LE VARIABLI -> Non è semplice e lineare: esempi
  • non posso semplicemente ridurre i tempi aumentando il budget
  • non posso aumentare semplicemente i programmatori per ridurre i tempi di consegna: ad esempio non posso partire con 40 programmatori, dovrò partire con un piccolo team e poi incrementarlo (un team da 10, poi 2 e poi 4).

I benefici della Extreme Programming

Il costo delle modifiche

XP permette di mantenere il costo di eventuali modifiche il più basso possibile. Tradizionalmente una modifica in fase di produzione costa esponenzialmente di più a mano a mano che si superano le fasi raccolta dei requisiti, analisi, design, implementazione , eccetera.

XP tiene questa curva più o meno costante, grazie alla sua natura.

Feedback

Nella XP il feedback è rapido: esso è fondamentale per l’apprendimento. Una volta in produzione esso è anche più significativo, ottenendo il feedback, ed interpretando è possibile re-immettere tutto ciò che si è appreso dall’interpretazione del feedback il più velocemente possibile.

Il feedback è quello in generale fornito dagli utenti, e si differenzia dai test.

Test

I test vengono eseguiti dai programmatori, sono sia una risorsa che una responsabilità: non basta scrivere il test, e considerare conclusa la faccenda, bisogna assicurarsi che questi saranno eseguiti e che coprano tutte le varie eventualità.

La realizzazione di una suite di test automatica è giustificata da una ragione a lungo termine, ovvero mantenere il programma in vita il più a lungo possibile (aumento la fiducia e la mantenibilità del sistema) ed una a breve termine: è divertente, offre maggior sicurezza al codice.

Bisogna dire che i test si dividono principalmente in due: gli Unit Test scritti dal programmatore per verificare che funzioni come da loro programmato e quelli funzionali scritti dal cliente per verificare che il sistemi lavori come da loro specificato.

Semplicità

Bisogna sempre pensare in semplice: ogni problema deve essere considerato estremamente semplice (e difatti lo è), secondo l’autore ben il 98% dei problemi è molto semplice e va risolto subito, in modo da lasciare tempo necessario alla soluzione dei problemi difficili, che sono solo una minima parte. Semplificare il problema è uno dei mantra del Test Driven Development, dove parto con una implementazione essenziale ed aggiungerò complessità in eguito.

Modifiche incrementali

Si ricollega al punto precedente: eseguire modifiche piccole, grandi cambiamenti tutti assieme funzionano più difficilmente.

Design

Non basta scrivere codice e test, bisogna organizzare la logica del sistema in qualche struttura. Un buon design:

Evita la duplicazione del codice

Rende la struttura non troppo complessa e logica da seguire Permette di estendere il sistema aggiungendo nuove funzionalità senza stravolgere tutto

Comunicazione aperta e onesta

Bisogna dirsi quando ci sono problemi nel codice, essere liberi di esprimere le proprie paura, e supportarle. Bisogna inoltre saper comunicare le cattive notizie anche a manager e customer, e il più presto possibile.

Mettere in pratica la XP

Finora sono stati visti i principi generali, ora sarà visto come applicare in pratica la XP:

1° Fase: pianificazione

I clienti, alle “business people” devono specificare: FEATURES RICHIESTE, PRIORITA’ DELLE FEATURES, COMPOSIZIONE DELLE RELEASE, DATE DELLE RELEASE.

I programmatori devono decidere: STIME TEMPORALI, PROCESSO DI SVILUPPO (team, membri, modalità di lavoro), ORGANIZZAZIONE DEL PIANO (quali feature per prime? quando?)

2° Fase: piccole release

Si parte subito a lavorare, rilasciando release il più piccole possibili, che implementano la maggior parte dei requisiti.

Design semplice

Si punti a ottenere un design semplice nelle vari release, il design giusto è quello che: funziona (i test vengono completati con successo), non contiene logica duplicata, esprime le intenzioni dei programmatori, e soprattutto ha il minimo numero possibile di classi e di metodi. Un design semplice implica un investimento iniziale ridotto, che sarà appesantito in seguito dalle modifiche incrementali: la cosa fondamentale è evitare di scrivere codice per quello che penso mi possa servire dopo.

Strategie di testing

E’ impossibile testare assolutamente tutto, il test diventerebbe complicato e probabile contenitore di errori come il codice originale. Ma devo assicurarmi di testare tutto quello che potrebbe essere rotto. I test devono essere presenti per ogni feature del programma, sia unit test che test funzionali (scritto dal cliente, storia per storia). Non importa che ci siano test per ogni metodo, ma solo per quei metodi che potrebbero non funzionare. Nell’ottica del Test Driven Development, può essere utile scrivere i test ancor prima dell’implementazione, questo è utile soprattutto nel caso in cui l’interfaccia non sia del tutto chiara. Un altro caso in cui un test è d’aiuto è nel caso si identifichi un problema: scrivo un test apposito per quel problema, ed eseguendolo mi assicurerò che il problema sia stato risolto: bisogna prima scrivere il test e poi fixare il problema!

Ci sono poi altri tipi di test, ad esempio i Parallel Test nei quali verifico che un nuovo sistemi funzioni allo stesso modo del precedente che va a sostituire, oppure lo Stress test (non ha bisogno di presentazioni) o il Monkey test che si occupa di assicurarsi che di fronte ad un input senza senso il sistema agirà in modo appropriato.

Continuous Integration o integrazione continua è la parola chiave: il codice è integrato e testato dopo un paio di ore, un giorno di sviluppo al massimo: è importante avere tool che supportano test veloci di integrazione/build/testing.

Il vantaggio di questo approccio è che se un bug emerge una volta inserito nel sistema, mi ricordo come è stata scritta la feature perchè è stato fatto in giornata, e debuggherò al meglio.

Rifattorizzare

Quando si implementa una feature, ci si accorge sempre che si potrebbe modificare il programma esistente per rendere l’aggiunta della nuova feature più semplici. Si può sempre migliorare il sistema, ma bisogna farlo solo quando è necessario, ad esempio per rimuovere codice duplicato o se la modifica è ovvia e prenderà poco tempo (10 min).

Pair programming

Questa è una feature di XP molto peculiare, il codice di produzione si scrive con 2 persone per pc. Uno ha tastiera e mouse e pensa al miglior modo per implementare un metodo, l’altro pensa più strategicamente (questo approccio funzionerà? Quali possono essere i test case da inserire qua? In quale modo i test possono fallire? C’è modo di semplificare il sistema in modo che il problema scompaia?)

Le coppie possono essere dinamiche e scambiate con altre persone.

On-Site customer

E’ necessario avere i clienti (o almeno una persona di riferimento) disponibile per il team per rispondere a domande, risolvere dubbi e dispute e stabilire le priorità. Deve essere una persona che utilizzerà il sistema in produzione, non un manager esterno al tutto.

Planning Extreme Programming – di Kent Beck e Martin Fowler

Questo secondo libro è più dedicato alla pianificazione nell’ambito XP. La pianificazione è importante per vari motivi:

• Assicurarci in ogni momento di lavorare alla cosa giusta (la più importante)
• Coordinare al meglio il lavoro tra più persone
• Comprendere le conseguenze a livello dei primi due punti quando succedono eventi inattesi

La pianificazione esiste a vari livelli: a livello giornaliero per le attività del giorno, a livello annuale per quanto riguarda lo sviluppo lato business, eccetera. In ogni caso la pianificazione ad ogni livello consiste nell’individuare un probabile corso degli eventi, in modo da potersi attenere in linea di massima a quello e rimediare in caso di inevitabili cambiamenti che possono accadere.

E’ fondamentale che un piano però, affinché funzioni, sia aggiornato, con tutti i progressi raggiunte ed informazioni aggiornate, in caso contrario è destinato ad essere un peso o comunque poco utile. Bisogna capire che lo scopo principale di un piano non è controllare gli eventi, ma controllare la proprie reazioni agli eventi: vedendo questa definizione risulta più evidente come avere informazioni aggiornate è fondamentale per gestire le reazioni.

Ovviamente ad un evento inaspettato seguirà una reazione e un aggiustamento al piano, è fisiologico quindi, che il piano si evolva.

Perchè un piano? Per proteggersi dalle paure

La realizzazione di un software è rischiosa, molte cose possono andare storte. Un piano è un parziale scudo, un supporto, non garantisce nulla ma comunque da una sicurezza in più.

In particolare esistono varie paure, i clienti hanno paura che le loro specifiche non saranno soddisfatte, saranno incomplete o mal comprese, pagheranno troppo per troppo poco, saranno nelle mani di tecnici a cui non importa, non comprenderanno i piani o questi saranno irrealizzabili, non capiranno cosa sta succedendo, saranno condizionati dalle loro prime scelte e impediti a modificare qualcosa per reagire a modifiche richieste dal mercato.

Le paure degli sviluppatori sono diverse: gli sarà chiesto di fare cose al di sopra delle loro possibilità, o che addirittura non hanno senso, saranno investiti di responsabilità senza avere l’autorità necessaria, non avranno specifiche chiare, dovranno sacrificare la qualità sull’altare delle scadenze, dovranno risolvere complessi problemi senza aiuto, non avranno abbastanza tempo per completare il lavoro.

Tutte queste paure vanno messe nero su bianco per evitare che si concretizzano, solo in questo modo ci si protegge, definendo una sorta di carta dei diritti del cliente ed una dello sviluppatore.

La carta dei diritti del programmatore

• Ha il diritto di sapere che cosa è richiesto, con una chiara definizione della priorità
• Ha il diritto di produrre un lavoro di qualità, sempre
• Ha il diritto di richiedere ed ottenere aiuto da colleghi, manager, e clienti
• Ha il diritto di fare e aggiornare le proprie stime
• Ha il diritto di accettare le responsabilità consapevolmente invece di vedersele imposte dall’alto

La carta dei diritti del cliente

• Ha il diritto di pianificare a livello generale, di sapere con precisione cosa sarà conseguito e a che costo
• Ha il diritto di ottenere il maggior valore possibile dalla settimana di programmazione
• Ha il diritto di cambiare idea, sostituire funzionalità e cambiare priorità senza dover affrontare incrementi dei costi esorbitanti
• Ha il diritto di vedere i progressi in un sistema in esecuzione, e di veder passare determinati test specificati da lui stesso
• Ha il diritto di essere informato in cambi di tempi di consegne, in tempo per scegliere come ridurre o modificare le feature se è fondamentale tornare al tempo di consegna prestabilito.
• Ha il diritto di cancellare il progetto in ogni istante ed avere in mano un sistema parzialmente funzionante che rifletta l’investimento fino al momento

In quest’ottica del programmatore vs cliente, è importante stabilire un equilibrio di poteri: chi comanda?

Per quel che riguarda le decisioni di business, il cliente, per quel che riguarda le decisioni tecniche, i tecnici. Ad esempio, dati dei requisiti, delle date di consegna e delle priorità da parte dei clienti, le stime devono essere fatte dai programmatori (tecnici), che diranno se una cosa è o meno possibile.

Ma chi deve essere il cliente? Nella pianificazione è importante avere una persona rappresentante dell’azienda cliente che abbia determinate caratteristiche se vuole facilitare il compito degli sviluppatori. In particolare deve comprendere bene il dominio di business, comprendere come il software apporterà valore al dominio, non aver paura di stabilire obiettivi intermedi troppo piccoli, purchè portino valore, saper stabilire le priorità tra varie funzionalità, essere disposto ad avere la sua fetta di responsabilità nel fallimento o successo del progetto (quest’ultimo punto è il più gravoso sicuramente).

Panoramica sul processo XP

Le release sono di alcuni mesi, divise al loro interno in iterazioni di 1-2 settimane, suddivise a loro volta in task di alcuni giorni.

La pianificazione permette di assegnare Storie (frammenti di funzionalità) in release ed iterazioni, in reazione ad eventuali reazioni nello sviluppo.

Spesso il problema nel lavoro è troppo da fare e/o troppo poco tempo. In realtà ci si concentra sulla seconda parte del problema e non a sufficienza sul primo. Non possiamo manipolare più di tanto il tempo, ma sul troppo da fare si può lavorare: è possibile prioritizzare alcune cose, ed eliminarne o ridurre la dimensione di altre, oppure, potremmo chiedere aiuto per alcune parti del problema.

La stima dei tempi

E’ un aspetto cruciale nella pianificazione. Come si fa? La regola più semplice è misurare la produttività di un giorno e assumere che sarà la stessa di domani.

Iniziare un progetto

Dove iniziare? Principalmente da quattro fattori:

• Gli oggetti, le storie principali che necessitano un software da implementare
• Il prezzo: la stima dei tempi di implementazione di ciascuna storia
• Il budget: quante persone saranno necessarie per completare il progetto
• Vincoli forniti da qualcuno con conoscenze funzionali sull’argomento

Sincronizzare progetto e business

Una volta stabilito grosso modo il progetto dal punto di vista tecnico, occorre sincronizzarlo con due esigenze dell’azienda cliente:

• Date di release
• Feature da implementare ad ogni release, quindi quali user stories

E’ importante sottolineare che il cliente parla in termini di user stories, deve elencarle, darle un peso e appunto decidere quali vorrà implementate per ogni release. Il piano delle release non è stabile, a causa di imprevisti durante lo sviluppo, cambiamenti di idea del cliente, oppure aumento nella produttività degli sviluppatori.

Il piano è solo uno snapshot momentaneo per dare un’idea al cliente/programmatori di che cosa aspettarsi, ma come detto sarà sicuramente modificato.

Orizzonte temporale della pianificazione

Che orizzonte temporale deve avere il piano? Fin quanto in là deve spingersi?

Si tratta di un tradeoff: più avanti vado con la pianificazione meno dettagli avrò, e quindi vedere troppo in là diventa poco significativo. Viene suggerito nel libro di pianificare 1-2 iterazioni e 1-2 release, non di più.

Concentrarsi su poche release/iterazioni permette al programmatore di focalizzare le proprie attenzioni sulle user stories che contano e le successive, trascurando le altre. Al cliente invece interessa sapere quali sono le funzionalità che sono in corso di implementazione e che quindi avrà a disposizione dalla prossima release.

Pianificazione dell’infrastruttura del progetto

Per infrastruttura si intendono quelle funzionalità come framework per GUI, oggetti distribuiti, persistenza dei database, eccetera.

Per partire il più veloce possibile non sceglierò l’infrastruttura definitiva ancor prima di iniziare, sceglierò l’infrastruttura a mano a mano che sarà necessario, che il suo utilizzo sarà previsto all’interno dell’iterazione in programma.

L’infrastruttura può poi evolversi con l’evoluzione del progetto, se il design è stato fatto bene con alta riusabilità e le giuste interfacce, sarà possibile modificare in seguito l’infrastruttura.

Scrivere le user stories

La storia è l’unità di funzionalità in un progetto XP. Il progresso di un progetto XP è misurato in storie consegnate, integrate all’interno nel sistema.

Una storia deve essere comprensibile (per il cliente, in linguaggio naturale), testabile, apportare un qualche valore al cliente, ma essere allo stesso tempo sufficientemente piccola da rendere possibile la realizzazione di diverse (5?) all’interno di un’iterazione.

Se una user story è troppo grande, sarà suddivisa in due o più storie, le quali durate saranno stimate, prioritizzate dal cliente eccetera.

Creare una scala di priorità tra le storie è molto importante: prima vanno implementate quelle storie che forniscono il più alto valore all’utente, facendo però attenzione alle dipendenze tra storie. Per misurare il valore di una storia, bisogna rivolgersi al cliente, non possono farlo i project manager ne i programmatori (in questo modo si delega anche parte delle responsabilità).

E’ importante specificare che non si finisce mai di scrivere storie, un progetto può cambiare in corsa, oppure posso suddividere storie esistenti, la scrittura delle storie va avanti in continuazione.

Per stimare il tempo necessario a implementare una storia, come regola generale si confronta con il tempo utilizzato per implementare una storia simile in precedenza. Se non esiste nessuna storia pre-implementata simile, mi atterrò all’esperienza, prendendone una grande il doppio e dividendo per due, ad esempio.

Le iterazioni

Una iterazione è un contenitore, al suo interno svilupperò alcune storie. Quante? Dipende dalla durata dell’iterazione e dalla stima delle storie.

Modifiche al piano: come reagire

Cambio di priorità di una storia

Non comporta nulla di particolare, nel business è possibile che ci sia un cambio di priorità secondo nuove valutazioni o informazioni aggiornate.

Aggiunta di una storia

Una delle principali differenze di XP da altre metodologie è che non sono fornite inizialmente una serie enorme di specifiche dettagliate. I requisiti possono fluire a mano a mano durante la vita del progetto, per accompagnare anche modifiche ai requisiti desiderati dal cliente o dal mercato stesso.

Ricostruire il piano delle release

Con molte modifiche a molte storie, potrebbe modificarsi molto il deliverable di una release. In particolare ricostruirò il piano delle release quando:

Ho troppe storie posticipate rispetto al piano originale La velocità di sviluppo del team cambia, e le assunzioni precedenti non sono più valide

Come si ricostruisce un piano? Bisogna stimare nuovamente le storie, ora con maggior esperienza e quindi maggior precisione.

Il cliente deve poi selezionare tra le storie quelle a maggior priorità e che vorrà per prime, all’interno della prossima release.

Di solito il piano sarà ricostruito ogni tre o quattro iterazioni, non ogni volta perchè comunque richiede tempo, ma va fatto regolarmente.

Realizzare il primo piano

Abbandonando l’argomento dei piani successivi che vanno ricostruiti, gli autori del libro ricordano che comunque il piano più importante, il più difficile da realizzare, è il primo.

I punti di incertezza durante la realizzazione del primo piano sono la velocità di sviluppo del team, e la dimensione (o meglio granularità) delle storie. Col tempo ci saranno riferimenti per la velocità (bastano 1-2 iterazioni), mentre per stimare le storie non ci sono raccomandazioni particolari.

Nella creazione di un piano, per ogni iterazione oltre a pianificazione, sviluppo e test bisogna inserire anche aspetti che coinvolgono meno i programmatori e che magari potrebbero dimenticare/sottovalutare, cioè eseguire i test di accettazione (o funzionali) specificati dal cliente, pianificare l’iterazione stessa, e comunicare i progressi al management.

Iniziare a programmare

Una volta realizzato il piano si inizierà a programmare. Alcuni consigli degli autori del libro sono:

• Preparare il framework per il testing
• Preparare una struttura per il build rapido
• Impostare la rete ed i permessi adatti
• Predisporre vari script base di installazione Questo risparmierà tempo in seguito e una volta che si partirà con lo sviluppo vero e proprio del software ci si concentrerà su quello.

Modifiche locali al piano originale

Possono essere release anticipate o più brevi, più lunghe, storie più brevi, eccetera.

Ad esempio potrebbe essere necessario rilasciare release più spesso, magari ogni iterazione: in quel caso i 2 concetti concidono e conviene abbandonare del tutto le release a concentrarsi sulle iterazioni.

Oppure potrebbe essere necessario avere delle release più lunghe, ad esempio un anno, ad esempio nel caso vada sostituito un sistema preesistente, e non è possibile farlo parzialmente.

Nel caso di storie più piccole invece, potrebbero essere richieste per una iterazione 25 storie da 2 giorni di lavoro piuttosto che 4 da 2 settimane, è la stessa cosa, ma con le storie più brevi il cliente ha un controllo più puntuale.

Pianificare una singola iterazione

Esiste un piano per l’iterazione, che la suddivide in task di alcuni giorni, ciascuno con un programmatore responsabile per il suo completamento.

Il programmatore da una stima durante la riunione iniziale dell’iterazione, assieme ad un feedback al cliente o al project manager per dimostrare di aver compreso bene la storia. Durante la riunione inoltre vengono elencati i task dell’iterazione, con alcune dipendenze tra gli stessi.

Dopo la riunione iniziale inizia il lavoro vero e proprio: i task vanno implementati, ed i progressi tracciati. Durante un’iterazione ciascun membro tiene traccia dei suoi progressi e se qualcosa va a rilento il Project Manager può aggiungere risorse addizionali o bilanciare in qualche modo le storie successive per compensare il ritardo. Può anche succedere il contrario (uno sviluppatore con extra time), e in quel caso si utilizzerà la risorsa in eccedenza per bilanciare la situazione.

L’aspetto fondamentale da tenere sotto controllo è “che cosa resta ancora da fare“, perché è legato alla data di release.

Gestione dei bug nell’XP

In fase di pianificazione vanno previsti dei tempi per la risoluzione dei bug. Eventualmente il cliente potrà scegliere se preferisce che tutti i bug siano fixati in una release o nell’avere delle storie (funzionalità) in più implementate (alla fine il tempo è limitato, o sarà utilizzato per cercare di correggere tutti i bug o per progredire con le altre storie).

Se si riceve dal cliente la richiesta di fixare un bug, è come se ci venisse chiesta una nuova funzionalità, e va trattata esattamente allo stesso modo: con specifiche, dettagli sulla priorità, eccetera. E il tutto sarà integrato alla fine della prossima iterazione. Se un bug invece è critico e non può aspettare, bisogna farlo subito ovviamente.

Gli autori del libro raccontano di uno dei possibili modi di gestire il bug fixing che per loro ha funzionato, cioè istituire un Team di Supporto alla produzione, che si concentra appunto nella correzione dei bug. Qui si conclude il mio “antipasto” dei libri Extreme Programming Explained: Embrace Change e Planning Extreme Programming , che vi ricordo possono essere acquistati su Amazon (in lingua inglese, non è presente una traduzione italiana del libro).