Extreme Programming

Cosa è Extreme Programming

Extreme Programming (XP) è un framework agile dedicato allo sviluppo software, che definisce valori e pratiche volti alla produzione di codice di qualità.
A differenza di framework quali Scrum o Kanban, XP non si focalizza sul processo, bensì sulle pratiche ingegneristiche: questo fa sì che Scrum e XP, ad esempio, possano essere adottati allo stesso tempo (vedremo più avanti come questo connubio siano non solo fattibile, ma anche auspicabile).
XP si basa su cinque valori, quattordici principi e ventiquattro pratiche (tredici pratiche e undici a corollario); le fondamenta per attuare le pratiche XP sono quattro attività basilari del processo di sviluppo software: sviluppo del codice, sviluppo del test, ascolto e design.
Cosa caratterizza XP, secondo Kent Beck:

• I cicli brevi di sviluppo, che si traducono in un flusso di feedback continuo.
• L’approccio alla pianificazione incrementale: la definizione di un piano generale, che si evolve durante la vita del progetto.
• La capacità di pianificare l’implementazione di funzionalità in modo flessibile, rispondendo alle mutevoli esigenze di business.
• Affidarsi a test automatici per monitorare i progressi dello sviluppo e consentire al sistema di evolvere e evidenziare i difetti in anticipo.
• La documentazione scritta è sostituita dalla comunicazione orale, dai test e dal codice.
• La consapevolezza che il design della soluzione evolve fintanto che il sistema vive.
• Fiducia nella collaborazione attiva di persone motivate.
• Si affida a pratiche che funzionano sia nelle dinamiche di team, che in quelle di progetto.

Vedremo di seguito perchè quando è efficace l’adozione di XP e il dettaglio di valori, pratiche e attività.

Perchè XP

Extreme Programming è stato sviluppato da Kent Beck (uno dei firmatari del Manifesto Agile) a partire dal 1996 ed è stato formalizzato per la prima volta dallo stesso Beck nel 1999 nel suo libro ‘Extreme Programming Explained’ (la seconda edizione del libro è disponibile su Amazon QUI).
Nonostante il nome ‘programmazione estrema’, che potrebbe essere fuorviante, vedremo come le pratiche XP tendano principalmente a valutare massimizzare l’efficacia del prodotto nell’accogliere i cambiamenti dei requisiti e a rilasciare software con un rischio controllato.
Le condizioni nelle quali XP risulta particolarmente efficace possono essere riassunte come segue:

• Situazioni nelle quali i requisiti variano velocemente.
• Progetti con una data di scadenza stringente e un elevato rischio dovuto all’utilizzo di nuove tecnologie.
• Gruppi di sviluppi piccoli.
• Le tecnologie utilizzate permettono l’automazione di test di unità e test funzionali.

A QUESTO link potete trovare un’interessante approfondimento sul tema ‘quando XP dovrebbe essere utilizzato’.
Da tenere in considerazione che, così come per Scrum, anche per XP avere dei team co-locati è senz’altro una caratteristica che ne facilita l’utilizzo e la pratica; d’altra parte questo non può essere considerato un vincolo ferreo, a nostro parere, dato che il mondo del lavoro sta sempre più accogliendo il remote working e le tecnologie, così come gli strumenti e i processi, stanno sempre più facilitando questo tipo di approccio.

Così come alcune condizioni esaltano l’efficacia di XP, altre la limitano fortemente; fra queste, vogliamo citarne un paio, non così inusuali:

• Sistemi nei quali i vincoli sugli scenari di utilizzo sono (volutamente o casualmente) laschi: in questi casi le condizioni di funzionamento del sistema non sono sempre note a priori e le casistiche di adozione (e do testing del sistema risultano impredicibili). Un esempio relativamente comune è l’integrazione fra due o più sistemi che non condividono interfacce con contratti specifici.
• Sistemi legacy instabili dove la complessità e il volume del codice comporterebbero un effort-XP smisurato rispetto alla banda a disposizione.

A QUESTO link potete trovare un’interessante approfondimento sul tema ‘quando XP non dovrebbe essere utilizzato’.

Valori di Extreme Programming

Vediamo i cinque valori sui quali XP si basa:

• Semplicità: faremo ciò che è necessario e richiesto, ma niente di più. Ciò massimizzerà il valore creato per l’investimento fatto fino ad oggi. Adotteremo piccoli e semplici passi verso il nostro obiettivo e mitigheremo i fallimenti man mano che si verificano. Creeremo qualcosa di cui siamo orgogliosi e lo terremo a lungo termine a costi ragionevoli .

XP incoraggia ad iniziare sempre con la soluzione più semplice ed aggiungere funzionalità extra in un secondo momento. Una delle caratteristiche dell’approccio di Extreme Programming è la progettazione del software basata sulle esigenze contingenti, piuttosto che il design e l’architettura per il domani (spesso viene utilizzato l’acronimo YAGNI - You ain’t gonna need it - ovvero - Non ne avrai bisogno -). Anche in XP troviamo più di una caratteristica che ricorda il principio del ‘last responsible moment’: è bene sottolineare che questo tipo di approccio comporta inevitabilmente un rework; la sua forza, d’altronde, è proprio quella di non ipotizzare soluzioni a lungo termine quando non abbiamo certezze (ricordiamo che una delle condizioni che massimizzano l’efficacia di XP è proprio un contesto con requisiti che cambiano frequentemente).
Tutto ciò ricorda molto il decimo principio agile: Simplicity - the art of maximizing the amount of work not done - is essential.

• Comunicazione: tutti fanno parte del team e comunichiamo faccia a faccia ogni giorno. Lavoreremo insieme su tutto, dai requisiti al codice. Creeremo insieme la migliore soluzione al nostro problema .

Una comunicazione efficace fra il team di sviluppo e gli stakeholder, ma anche all’interno del team favorisce le performance e la qualità del prodotto e, soprattutto, abbassa il rischio di divergenza fra le aspettative dei clienti e l’incremento di prodotto.
Tutto ciò ricorda molto il secondo valore agile (Customer collaboration over contract negotiation) e il seguente dei cinque valori di Scrum: Apertura - I team di Scrum cercano costantemente nuove idee e opportunità di apprendimento. I team agili sono anche onesti quando hanno bisogno di aiuto.

• Feedback: ci impegneremo al massimo sul commitment di ogni iterazione, fornendo software funzionante. Portiamo in demo il nostro software il prima possibile e frequentemente, ascoltiamo i feedback attentamente e apportiamo di conseguenza le modifiche necessarie. Parleremo del progetto e vi adatteremo il nostro processo, non viceversa .

Grazie ad un feedback frequente, il team può identificare le aree di improvement e rivedere le sue pratiche e i suoi processi. Il valore del Feedback è strettamente legato anche ai valori di Comunicazione e Semplicità: una comunicazione efficace e diretta esalta la qualità del feedback; un design semplice massimizza l’efficacia del feedback, permettendo una conversazione focalizzata.

• Rispetto: *ognuno di noi prova e dimostra all’altro il rispetto che merita, in quanto team member stimato. Tutti contribuiscono al valore, anche semplicemente con l’entusiasmo. Gli sviluppatori rispettano le competenze dei clienti e viceversa. Il management rispetta il nostro diritto di accettare la responsabilità e ricevere autorità sul nostro lavoro.
• Coraggio: saremo onesti su progressi e stime. Non ci prepariamo delle scuse per eventuali fallimenti, perché intendiamo avere successo. Non temiamo nulla perché nessuno lavora mai da solo. Ci adatteremo ai cambiamenti ogni volta che accadranno.

Come vedremo di seguito, più di una pratica incarna il valore del coraggio. Una di queste pratiche è quella di progettare e codificare sempre per l’oggi e non per il domani. Il coraggio consente essere confidenti con il refactoring del codice, quando necessario e permettere alle modifiche future di essere implementate più facilmente. Ancora: il coraggio è sapere quando eliminare il codice: rimuovere il codice sorgente che è obsoleto, non importa quanto sforzo sia stato fatto per creare quel codice sorgente. Inoltre, coraggio significa perseveranza: un programmatore potrebbe rimanere bloccato su un problema complesso per un giorno intero, quindi risolverlo rapidamente il giorno successivo, ma solo se si usa la perseveranza.

Principi di Extreme Programming

I Principi di XP sono visti come una specificazione dei Valori, permettono di dare indicazioni più concrete per guidare il comportamento. Vedremo di seguito i Principi basilari di Extreme Programming.

###Humanity
Il software è scritto dalle persone: dietro a questo semplice e, a prima vista, scontato principio, c’è una consapevolezza profonda dei bisogni che spesso vengono sottovalutati. Il processo di sviluppo deve tenere in considerazione le necessità della persone; Kent Beck, nella descrizione di questo principio, si riferisce implicitamente alla piramide di Maslow nel descrivere questo principio:

• prima di tutto le persone hanno bisogno di sicurezza, per sè stessi e per i propri cari, in modo da essere a loro agio e poter dare il meglio: il posto di lavoro non deve essere a rischio. Maslow esprime queste necessità nei primi tre livelli della piramide: ‘Psychological needs’, ‘Safety needs’.
• le persone si sentono realizzate quando provano un senso di appartenenza e si identificano in un gruppo, con il quale condividono degli obiettivi, quando possono contribuire alla crescita della società. Maslow esprime queste necessità nei seguenti due livelli della piramide: ‘Love and Belonging’, ‘Esteem’.
• le persone hanno bisogno della loro privacy e di spazio per raggiungere i miei obiettivi, che non contrastano con quelli del team. I dettagli della vita privata non rientrano nei piani del team, ma ognuno deve essere libero di poter auto determinarsi e poter dedicare del tempo per sè stesso (sustainable pace). Per Maslow questa è la punta della piramide: Self-actualization.

Economics

Tutto quello che facciamo deve essere pagato da qualcuno: assicurati che tutto quello che fai abbia un valore di business, altrimenti rischi che di ottenere solo un inutile successo tecnico. Le priorità sono date dal business e, spesso, ciò che conviene al business è di fare scelte che anticipano gli introiti e posticipano le uscite: questo principio ha un perfetto connubio con la pratica del Design Incrementale: ogni pratica che segue il principio del Last Responsible Moment tende a difendere le necessità del business.

Mutual Benefit

Ogni scelta deve sempre considerare il giusto compromesso fra tutte le parti interessate: quando si prende una decisione, soprattutto quando i vincoli di tempo sono stretti, questo principio va tenuto in considerazione per evitare di fare degli errori che pagheremo in futuro e creare delle situazioni di tensione fra le persone. Un semplice esempio può essere la scrittura di un’ampia documentazione tecnica del software che sto scrivendo: questa potrebbe aiutare un domani un altro sviluppatore, ma sicuramente rallenterà il mio lavoro oggi e costringerà entrambi a un notevole sforzo per la manutenzione e l’aggiornamento della documentazione. Il compromesso è quello di scrivere dei test automatizzati esaustivi, che aiuteranno me a definire il design ed essere più confidente nello sviluppo e nel refactoring, aiuteranno inoltre il prossimo sviluppatore che ne otterrà gli stessi benefici.

Self-Similarity

Quando la natura trova una forma che funziona, la usa
ovunque può; lo stesso principio si applica allo sviluppo del software: prova a copiare la struttura di una soluzione in un nuovo contesto, anche su scala diversa. Per chi già conosce o ha letto di Scrum@Scale, questo principio non suona come nuovo.
Pensiamo alla pianificazione trimestrale, dove vengono trattati i Temi e si pianificano le Storie, lo stesso principio su usa su scala settimanale, dove si trattano le Storie e si pianificano i Test (solitamente ‘System-Level
Tests’); quotidianamente tratto i Test, decido quali test di unità sviluppare che mi faranno passare anche il System-Level Test e sviluppo il codice che mi farà passare questi test.

Improvement

Non tendere alla perfezione, ma cerca di perfezionare il tuo processo, il tuo design, le tue storie.
La frase ‘il meglio è nemico del bene’, o più precisamente ‘Best is the enemy of good enough’ dà un senso a questo principio XP, ma non lo chiarisce del tutto: dobbiamo rifuggire l’immobilismo causato dalla ricerca della soluzione perfetta e agire con il meglio che possiamo fare oggi; inoltre dobbiamo agire ogni giorno per perfezionare quello che abbiamo messo in campo: Extreme Programming punta a raggiungere l’eccellenza nello sviluppo software tramite il continuo miglioramento.

Diversity

I team di sviluppo software dove ognuno è uguale all’altro non sono efficaci: i team devono essere composti da persone con differenti capacità, attitudini e prospettive, in modo da sfruttare le diversità e l’intelligenza collettiva per trovare soluzioni ai problemi. I conflitti e le diverse opinioni all’interno del team sono considerate da XP delle opportunità e non situazioni da evitare. Il principio di Diversity si traduce nella pratica di Whole Team, che vedremo più avanti.

Reflection

I team performanti non si limitano a fare il loro lavoro, ma pensano a come possono farlo meglio, analizzano i loro successi e i loro fallimenti, non nascondono i loro errori, ma li evidenziano per poter imparare da questi.
I cicli trimestrali e settimanali includono del tempo per la riflessione del team: il principio di Reflection, oltre ad essere codificato anche nell’Agile Manifesto, risulterà familiare a chi già conosce Scrum. Il momento di riflessione ha due principali vincoli da rispettare:

• solitamente si analizzano azioni ed accadimenti del passato, cosicché i feedback possano riferirsi a qualcosa di concreto;
• si prendono azioni per il futuro, in modo da tradurre la riflessione in qualcosa che abbia un valore tangibile.

Flow

Lo sviluppo software predilige un processo che prevede un flusso continuo, piuttosto che una serie di fasi successive. Prevedere un processo a step porta ad avere una peggiore gestione del rischio, una bassa frequenza del feedback e una scarsa predicibilità. In XP vengono rilasciati piccoli incrementi di valore frequentemente, l’integrazione e la build sono continui e il feedback sulla qualità del proprio lavoro avviene quotidianamente.

Opportunity

Impara a vedere i problemi come opportunità di cambiamento: per raggiungere l’eccellenza, i problemi devono diventare opportunità di apprendimento e di miglioramento. XP, come ogni Agile framework, non è fatto per nascondere i problemi, ma, al contrario, per farli emergere e ti offre principi e pratiche per poterli affrontare; parte dell’essere estremi, per XP, è proprio la scelta consapevole di trasformare ogni problemi in una opportunità: una opportunità per crescere professionalmente, per approfondire delle relazioni e per migliorare il software.

Redundancy

I problemi critici (alto impatto, alta probabilità) dovrebbero essere gestiti in più modi contemporaneamente: introdurre ridondanza ha un costo, ma concorre a mitigare i rischi, abbattendo la probabilità di accadimento: affinché un problema si verifichi, infatti, ogni fattore della ridondanza dovrebbe fallire. Ad esempio, i difetti software, in XP, sono risolti da diverse pratiche:

• Pair Programming
• Continuous Integration
• Sitting Together
• Real Customer Involvement
• Daily Deployment

Failure

Se non conosci il modo migliore per risolvere un problema, allora agisci per fallire in fretta: anche il fallimento ha un importante valore, ovvero la conoscenza e la consapevolezza che ne derivano. Talvolta il fallimento non è una scelta: ad esempio quando non si hanno sufficienti informazioni per poter prendere una scelta ponderata; in tali casi, anziché posticipare l’azione, una scelta vincente potrebbe essere quella di agire sbagliando (consapevolmente): preparati accuratamente per poter accogliere il feedback che deriverà dal fallimento, evidenzia i punti critici, le informazioni mancanti e le opzioni che potrebbero chiarirsi dopo l’attività, che possiamo considerare un esperimento. Questo principio richiama il mantra ‘fail fast, fail often’, citato ance dal PopcornFlow nella formula ‘learn fast, learn often’.

Quality

La qualità non è una variabile per la gestione di progetto: sacrificare la qualità non comporta necessariamente un incremento della Velocity, così come una maggiore qualità non comporta necessariamente un calo di Velocity. In XP la gestione di un progetto la si fa negoziando lo scope: i cicli di pianificazione trimestrale e settimanale sono momenti esplicitamente dedicati al monitoraggio e alla contrattazione dello scope.

Baby Steps

Il cambiamento deve essere suddiviso e implementato in piccoli passi: talvolta sembra conveniente attuare cambiamenti radicali tutto in una volta, ma questo approccio è spesso pericoloso. Quando le organizzazioni sono complesse, tanti piccoli cambiamenti possono costituire, insieme, dei cambiamenti radicali.
XP traduce in pratiche questo principio attraverso il Test-first programming e la Continuous Integration.
Due concetti che vogliamo solo accennare qui e approfondiremo in altre sezioni, sono alla base del Lean e del Toyota Production System:

• Kaizen: il cambiamento continuo, dato dall’attuazione di numerosi e piccoli cambiamenti incrementali.
• Kaikaku: un cambiamento radicale e implementato in un arco temporale limitato

Accepted Responsibility

La responsabilità non può essere assegnata; può solo essere accettata. Le pratiche XP rispeccchiano questo principio: le persone del team stimano i task e decidono autonomamente quali assegnarsi. Responsabilità e autorità viaggiano di pari passo: quando sono responsible di una certa attività, devo avere anche l’autonomia (autorità) per poter decidere come metterla in atto.

Pratiche di Extreme Programming

Le pratiche (o regole) di Extreme Programming dette ‘primarie’ possono essere adottate per iniziare ad applicare XP e migliorare il ciclo di sviluppo del software; l’ordine con il quale vengono messe in campo dipende dal contesto nel quale ci troviamo: potremmo aver bisogno dapprima di migliorare la nostra fase di pianificazione, oppure potrebbe essere prioritario adottare le regole relative alla programmazione per migliorare migliorare la qualità del prodotto.

Pratiche Primarie

### Sit Togheter
Il team deve avere a disposizione un open space dedicato: la comunicazione, uno dei cinque valori di XP è fondamentale per un team che lavora in Extreme Programming e, per migliorare l’efficacia della comunicazione, una delle più semplici ed efficaci azioni che si possono prendere è di mettere le persone nella situazione di poter comunicare senza barriere: si creeranno dei link che porteranno ad efficientare la comunicazione ed abbattere la burocrazia. Alcune possibilità sono:

• Posizionare i computer in un’area comune: questo incoraggia e facilita il pair programming.
• Dedicare delle zone dell’open space ai meeting ricorrenti, come il daily stand up: aiuta le persone a non perdersi la riunione.
• Posizionare dei tavoli per i meeting all’interno dell’open space: facilita le persone nell’organizzazione dei meeting e incoraggia ad allineamenti spontanei.
• Avere a disposizione delle whiteboard permette di ottenere dei meeting più efficaci e aiuta nell’allineamento aggiungendo il canale visivo alla comunicazione.

Whole Team

Un team deve avere tutte le competenze necessarie per il successo del progetto: questa è l’idea di cross-functional team, presente anche il altri framewor, come Scrum. Lo spirito di squadra e l’unione di intenti permette al team di essere resiliente e adattivo. Il team cresce e accresce le sue competenze coltivando la collaborazione e la cooperazione; il team può accogliere nuovi membri se servono nuove skill; se, invece, qualcuno dovesse risultare non più necessario, allora sarà per lui l’occasione di esserlo altrove.
Un team di oltre dodici persone inizia ad essere disfunzionale a livello comunicativo: mantenere una dimensione adeguata del team è importante per massimizzarne l’efficacia. Ricordiamo che Scrum consiglia che la dimensione di un team sia non minore di tre persone e non maggiore di nove.

Informative Workspace

Lo spazio di lavoro deve rispecchiare il tuo lavoro: un osservatore interessato dovrebbe essere in grado, attraversando il tuo workspace, di ottenere un’idea generale di come sta andando il progetto in quindici secondi. Molti team implementano (parzialmente) questa pratica utilizzando post-it e board cartacee attaccati al muro. L’ordinamento delle card trasmette, spazialmente, informazioni rapide.
Lo spazio di lavoro deve anche fare attenzione ad altre necessità: avere a disposizione acqua e snack offre comfort e incoraggiare interazioni sociali positive. La pulizia e l’ordine lascia le menti libere di pensare ai problemi. Mentre la fase di programmazione viene svolta in open space, altri spazi separati potrebbero lasciare alle persone un po’ di privacy, in orari dedicati.

Energized Work

Lavora solo quante più ore puoi essere produttivo e solo
quante ore riesci a sostenere: andare in burnout e rendere improduttivi i prossimi giorni di lavoro non fa bene né alla persona, né al team. In un progetto software non è difficile introdurre degli errori e smettere di produrre valore, ma quando si è stanchi è difficile saperlo riconoscere. Il consiglio è di non dedicare più tempo al lavoro, ma sfruttare meglio il tempo: ad esempio, potresti usare il seguente working agreement in due delle ore che quotidianamente dedichi allo sviluppo: spegni il telefono e le notifiche delle email, questo potrà portare già un miglioramento evidente.

Pair Programming

Scrivi il codice in coppia allo stesso PC: una delle pratiche più note e più utilizzate di XP, il pair programming è un dialogo fra due persone che programmano simultaneamente, esaltando, in tal modo, le fasi di analisi, design e test.
Il pair aiuta a chiarirsi le idee, facilita l’allineamento, esalta il principio della ‘Collective Code Ownership’ e mantiene alta la produttività: quando una persona è confusa, o frustrata, l’altra persona della coppia prende l’iniziativa. Quando si è in una fase di prototipazione o di indagine e si ritiene più efficace lavorare da soli, magari in parallelo, lo si può fare; in un secondo momento ci si allinea con il team, mantenendo il focus più sull’idea, che sul codice: questo permette di non condizionare gli altri sulla specifica soluzione e mettersi nelle condizioni di poter evolvere il sistema in modo collaborativo.

Pairing and Personal Space

Tieni in considerazione che ogni persona ha una sensibilità diversa nell’utilizzo dello spazio fisico: per alcune culture è più comune avere una prossimità fisica con il proprio interlocutore, in altri casi le persone sono più a loro agio mantenendo una maggiore distanza. Dobbiamo tenere in considerazione entrambi i casi per poter lavorare efficacemente con i nostri colleghi. Anche e soprattutto quando si lavora in pair, è fondamentale tenere in considerazione e rispettare le caratteristiche personali, dando la giusta attenzione ai segnali che le altre persone ti mandano.

Stories

Pianifica utilizzando funzionalità visibili all’utente: svincolati dal significato di ‘requisito’ come work item richiesto, concentrati sul problema del cliente e trova una soluzione innovativa per risolverlo.
Le User Story hanno tipicamente le seguenti caratteristiche:

• hanno una stima, data dal team, che indirettamente si riflette sull’effort necessario per sviluppare la funzionalità;
• hanno una descrizione breve;
• sono scritte su una card (solitamente in Post-it).

Ron Jeffries ha formalizzato le caratteristiche di una User Story secondo le ormai note 3C:

• Card: le User Story sono scritte su Card, che contengono la descrizione dell’obiettivo, la priorità e la stima.
• Conversation: la richiesta della funzionalità (meglio: l’esplicitazione del problema) viene comunicata dal cliente al team di sviluppo attraverso una conversazione (in larga parte verbale).
• Confirmation: il cliente comunica al team quali Acceptance Test verranno usati per accettare la storia una volta terminata.

Weekly Cycle

Pianifica il lavoro una settimana alla volta: durante questo meeting:

• Controlla il progresso del lavoro del team, in relazione a quanto pianificato
• Chiedi ai clienti di scegliere le storie da pianificare per la settimana successiva
• Suddividi le storie in task: i team member potranno committarsi sui task e stimarli.

Inizia la settimana scrivendo test automatici che verranno eseguiti quando
le storie sono completate. Con un ciclo di sviluppo così breve e con un piano di test pronto, dopo soli due giorni sarà facile capire se la pianificazione sarà rispettata o meno.
Kent Beck punta molto sul valore di suddividere le storie in task, avere per ogni task il commitment e la stima di un team member; questo approccio tende a valorizzare il senso di ownership.

Quarterly Cycle

Pianifica il lavoro un trimestre alla volta: ogni tre mesi rifletti sul team, sul progetto, sul suo progresso e sull’allineamento sui macro-obiettivi.
Durante la pianificazione trimestrale:

• identifica i colli di bottiglia;
• avvia le azioni correttive
• pianifica le epiche del trimestre
• scegli le storie per indirizzare i Temi
• focalizzati sulla big picture, dove il progetto si inquadra all’interno dell’organizzazione.

Il trimestre è una scala temporale largamente utilizzata all’interno delle organizzazioni: questo aiuta a sincronizzarsi con altre attività di business dell’azienda e con i fornitori.
Differenziare i Temi (o Epiche) dalle storie serve anche a contrastare la tendenza dei team a concentrarsi sui dettagli, senza riflettere sul quadro generale. Inoltre i Temi sono estremamente utili per disegnare una roadmap.

Slack

Nei tuoi piani introduci delle piccole attività che possono essere eliminate se sei in ritardo: è importante rispettare il commitment per coltivare un clima di fiducia; raggiungere pochi obiettivi concordati permettono di mantenere un rapporto saldo.
Lo Slack time può essere strutturato in molti modi: possiamo pianificare una Geek Week, oppure riservare il 20% della banda a Spike e attività di innovazione.

Ten-Minute Build

Esegui la build del sistema e tutti i test in dieci minuti: una build che impiega più di dieci minuti verrà eseguita molto meno spesso e perderai delle importanti opportunità per ottenere un feedback. Una build più breve non ti constringe a fare una pausa caffè nell’attesa. Un processo automatizzato di esecuzione della build e di tutti i test che impiega meno di dieci minuti mette nelle condizioni gli sviluppatori di potervi lavorare e apportare miglioramenti continuamente.

Continuous Integration

Integra e testa le modifiche dopo non più di un paio di ore: la fase di integrazione è spesso imprevedibile: se non eseguito frequentemente, potrebbe richiedere più tempo di quello dedicato allo sviluppo.
I modelli di integrazione possono essere sincroni (concludo le modifiche al codice, le integro, quindi vengono eseguiti i test e la build, ne attendo il termine e verifico che tutto sia corretto prima di ricominciare a programmare), oppure asincroni (integro le modifiche e ricomincio a programmare; i test e la build vengono eseguiti con un certo delay e vengo notificato dell’esito da una mail o una notifica su un radiator). Kent Beck consiglia di tendere verso l’integrazione sincrona, cosicché la coppia possa avere il tempo di riflettere su ciò che ha fatto, nel momento in cui l’ha fatto.

Test-First Programming

Scrivi un test automatico che fallisce prima di modificare qualsiasi codice: il test-first programming indirizza diversi problemi in una sola volta:

• Evoluzione minimale dello scope: dichiarando esplicitamente ciò che il programma dovrebbe fare, si evita di scrivere codice ‘just in case’, che potrebbe non servire, ma potrebbe comunque generare bug.
• Accoppiamento e coesione: se risulta difficile scrivere il test, questo è un segnale di un probabile problema a livello di design. Un codice è facilmente testabile se è liberamente accoppiato e molto coeso (Coesione significa che una classe dovrebbe rappresentare un unico concetto; Accoppiamento: una classe dipende da un’altra mentre usa gli oggetti della classe)
• Fiducia: scrivendo codice testato, aiuterete i vostri colleghi ad avere fiducia in voi e nel vostro codice.
• Ritmo: scrivere prima il test aiuta a essere focalizzati sull’obiettivo e non perdersi nella scrittura del codice.

Incremental Design

Investi del tempo ogni giorno nel design del sistema: quando ci si rende conto che il design dovrebbe essere migliorato per adattarsi alle necessità del progetto, allora è opportuno lavorarci in modo iterativo e incrementale. Tieni sempre in considerazione il rapporto fra i costi dei cambiamenti (di design) e i costi dei bug. Tieni monitorato il tuo sistema e adattalo velocemente alle esigenze, evitare di arrivare nella situazione in cui il costo di un cambiamento sia drasticamente alto. L’indicazione che dà XP sul Design Incrementale (o emergente) non è che progettare in anticipo sia necessariamente un male, ma il design fatto vicino a quando viene utilizzato è più efficiente. Le best practice che esaltano il design emergente sono il riuso del codice e il continuo refactoring.

Pratiche a corollario

Dopo aver messo in campo le pratiche primarie, è possibile focalizzarsi sulle pratiche a corollario; è importante rispettare l’ordine se si vogliono evitare dei possibili disastri.
Ad esempio: il Daily Deployment è una pratica che può essere messa in campo solo dopo aver lavorato sulla qualità e aver portato il rate dei difetti vicino allo zero, grazie alle pratiche primarie di Pair Programming, Continuous Integration e Test-First Programming.

Real Customer Involvement

Rendi parte del team le persone che sono direttamente influenzate dal prodotto del team. Lascia che i clienti visionari diano il loro contributo durante i Planning trimestrali e quelli settimanali. Se riesci a rendere il prodotto del team veramente prezioso per il cliente, quest’ultimo pagherà pur di partecipare allo sviluppo. Mettendo insieme il cliente finale (chi ha un bisogno) e il team (chi può soddisfare questo bisogno), riuscirai a minimizzare gli sprechi e massimizzare il lavoro non svolto. L’impegno del team sarà quello di soddisfare il cliente con il minimo effort e cercare di mantenere il prodotto meno specifico possibile, in modo che possa soddisfare anche le richieste di altri clienti.

Incremental Deployment

Quando devi rimpiazzare un sistema legacy, fallo gradualmente. Bisogna fare attenzione al fatto che non stiamo parlando di come implementare il nuovo codice (es: strangulation vs greenfield), ma di come farne emergere il valore e acquisire i feedback (ovvero: come portarlo in produzione): sostituisci una piccola funzionalità e mandala in produzione raccogliendone i feedback, magari utilizzando un A/B testing: questo ti permetterà di mitigare i rischi di fallimento.

Team Continuity

Mantieni stabili i team efficienti. Le performance di un team non sono date solo dalla somma delle hard skill, ma anche dall’equilibrio che il team stesso riesce a stabilire. Il tutto è maggiore della somma delle parti. Spesso la programmazione delle risorse basata sulle hard skill e sulla schedulazione è una attività di micro-management che porta a una disottimizzazione a livello sistemico. Mantenere team stabili può voler dire che il core team rimane stabile e un limitato numero di team member può fare job rotation in base alla necessità.

Shrinking Teams

Man mano che il potenziale di un team aumenta, mantieni stabile il carico di lavoro e riduci gradualmente le sue dimensioni. Quando un team inizia ad avere troppo pochi membri (molto competenti), fondilo con un altro team di ridotte dimensioni. Kent Beck racconta come questa pratica derivi dal Toyota Production System; ho trovato questa idea illuminante: piuttosto che aumentare il carico su un team e renderlo potenzialmente un anello debole come rischio per la delivery, porta le competenze su altri team e fai crescere il sistema.

Root-Cause Analysis

Ogniqualvolta venga rilevato un difetto dopo lo sviluppo, elimina il difetto e la sua causa; l’obiettivo è duplice: evitare che il difetto si ripresenti e far sì che il team impari dai propri errori.
In XP il fix di un bug si schematizza in 4 passi:

• Scrivi un end-to-end test che riproduca il difetto;
• Scrivi un test di unità, con scope più ridotto possibile, che riproduca il difetto;
• Correggi il sistema in modo che il test di unità passi; questo farà passare anche il test end-to-end (in caso contrario, modifica il test di unità);
• Una volta che il difetto è risolto, capisci perché il difetto era sfuggito e metti in campo le modifiche necessarie per prevenire questo tipo di difetto in futuro.

Taiichi Ohno, padre del Toyota Production System, ci lascia un fondamentale strumento per questa ultima fase: la cosiddetta Five Whys Analysis: chiediti cinque volte il perché il problema si è verificato, raggiungendone la radice e lavora su quella.

Shared Code

Chiunque nel team può migliorare qualsiasi parte del sistema in qualunque momento. Avere una responsabilità condivisa sul codice del sistema massimizza la resilienza del team. Una possibile obiezione è che una ownership non definita riduce il senso di accountability: per evitare che questo succeda è opportuno che ci sia un forte senso di responsabilità collettiva all’interno del team; alcune pratiche che possono aiutare nel senso della Collective Code Ownership sono il Pair Programming e la Continuous Integration.

Code and Tests

Manutieni solo il codice e i test come artefatti permanenti: la documentazione può essere generata dal codice di produzione e dai test. Questa pratica può essere messa in campo in modo incrementale, riducendo la documentazione prodotta un po’ alla volta; ad esempio, il manuale utente potrebbe essere un tipo di documentazione più difficile da superare, rispetto alla documentazione tecnica.

Single Code Base

Esiste un unico code stream: puoi sviluppare su un branch temporaneo, ma non lasciare vivo per più di qualche ora. Questa pratica non intende ovviamente limitare la modularità del sistema, si riferisce piuttosto a sottolineare il costo del backporting in caso di più versioni contemporaneamente in produzione. Se si hanno molteplici code base contemporaneamente attive, ci troveremo inesorabilmente in contesti di lavoro bug prone, con alta probabilità di introdurre difetti e regressioni: in questi casi è opportuno mettere in atto un piano per ridurre gradualmente le versioni in produzione.

Daily Deployment

Manda in produzione il codice ogni notte: il gap fra il codice in sviluppo e il codice in produzione è un ritardo di feedback che può tradursi in un rischio per lo sviluppo. Questa pratica risulta difficile, se non impossibile da applicare, qualora non siano state messe in campo altre pratiche primarie, in modo da limitare il defect rate, automatizzare l’integrazione e la build del sistema, rendere incrementali il roll out e il roll back del sistema. Il Daily Deployment, inoltre, richiede un processo di product management e, in particolare, di prioritizzazione, estremamente efficace e in sintonia con il cliente, al fine di ricevere feedback immediati sui nuovi sviluppi.

Negotiated Scope Contract

I contratti che stipuli con il cliente abbiano tempi, costi e qualità fissi, ma lo scope deve poter essere negoziato in corso dello sviluppo del sistema. Anzichè scrivere contratti di lunga durata che prevedono elevati costi per le change request, scrivi più contratti brevi, con bassi costi per i cambiamenti.

Pay-Per-Use

Con i sistemi Pay-Per-Use il sistema addebita i costi al momento dell’utilizzo, rendendo i soldi l’ultimo feedback per lo sviluppo. Questo sistema stimola al miglioramento continuo.
Un’alternativa al Pay-Per-Use è il modello a sottoscrizione, nel quale l’utilizzo del software viene pagato mensilmente o trimestralmente: con questo modello, il team può utilizzare la customer retention come misura dell’efficacia del proprio operato.