XP, variazioni sul tema

Autore: Martin Fowler, Chief Scientist - ThoughtWorks

Versione italiana: Paolo Bettini e D'Elia Giovanni (traduzione: agosto 2012)

Articolo Originale: Variations on a Theme of XP

Uno degli aspetti principali di XP è definito dagli statements che vengono forniti circa cosa dovrebbe essere fatto per lavorare in XP. Inoltre la serie di "practice" è attentamente progettata per adattarsi l'una con l'altra. Non considerarne qualcuna potrebbe portare a serie conseguenze.

Uno dei principi di XP e altri metodi agili riguardano il fatto che essi sono "self adaptive": potresti cambiare il processo in base al progetto di sviluppo. Ma come questa nozione si adatta alle rigide practice di XP?

Supponiamo di creare una metodologia. Chiamiamola Metodologia di Martin o per semplificare MM. Qualcun'altro sostiene che stanno sviluppando MM. Come faccio a sapere se lo fanno? (il cinico in me dice che loro stanno sempre lavorando su MM se è un successo, mai se fosse il contrario!). Che importa ciò che dico?

Questa è una vecchia regola che vale per i processi software, e ora queste domande vengono chieste per XP e altri metodi "agili". con XP è particolarmente interessante la questione perchè XP ha una serie rigida di "practice" e una serie di condizioni limite.

Eppure la gente, incluso noi di ThoughtWorks, applichiamo XP fuori da questi confini. In che punto ci lasciamo XP alle spalle?

Inoltre una chiave dei metodi agili è la loro adattività: il fatto che si supponga di cambiare un metodo così come serve. Come si concilia con la rigidità di XP?

Perché comprare una metodologia?

Per aiutare a rispondere a queste domande, io penso che bisogna tornare indietro un attimo per chiedere a noi stessi: Che cosa è una Metodologia? Perché chiunque vorrebbe poter usare una Metodologia? Supporrò che la risposta a questa domanda sia che l'utente interessato alla Metodologia è qualcuno che concerne come sviluppare software attentamente e che si aspetta che seguendo una Metodologia segue un percorso provato che aumenta le possibilità di successo.

Si potrebbe anche dire che seguendo una metodologia si è protetti dalle conseguenze di fallimento dicendo:"Ho fatto tutto quello che potevo fare - ho seguito una Metodologia rispettosa". Anche se è comune denigrare questo motivo, è comune in molte discipline di aspettarsi di seguire un preciso processo per svolgere un "task", e se non si seguono le conseguenze si potrebbe essere più responsabili per i problemi via via incontrati nel processo.

In entrambi i casi la gente richiede alcuni passi da seguire perché aumentino le loro possibilità di successo. Questo è ragionevole. Dopo tutto abbiamo sviluppato software per un decennio. Sicuramente dovremmo essere abilit per imparare dalle esperienze degli altri.

La variabilità delle metodologie

La maggior parte delle metodologie sono stabilite a partire dalle una singola esperienza. In sostanza si ha un solo soggetto che si basa su di una sola esperienza (anche se in realtà probabilmente tale soggetto si basa solo su ciò a cui sarebbe voluto arrivare e non su ciò che ha realmente attuato). Nella migliore delle ipotesi non si ha una singola persona ma un gruppo di persone che uniscono le loro idee: ma qualcuno ha applicato realmente ciò che il gruppo ha teorizzato? Questo è un altro discorso.

Il software è incredibilmente variabile. Una delle sue variabili chiave sono le persone. Stessi metodi funzionano in modo diverso se applicati da persone diverse. Un'altra variablie da non sottovalutare è la cultura aziendale nella quale le persone sono immerse. Il software ha anche uno stile. Ad esempio, unprocesso progettato per la telefonia può non essere appropriato per sistemi informativi ed esserlo per i giochi.

Ad essere onesti gran parte dei teorici di metodologie riconoscono tutto ciò. Sono a conoscenza del fatto che non possono dare una semplice sequenza di operazioni che la gente dovrebbe seguire per ottenere risultati perfetti. C'è sempre qualche adattamento, anche un po' sartoriale da fare. Il punto è come fare a guidare questi cambiamenti? In che modo il soggetto che utilizza una ben determinata metodologia può venire a conoscenza di ciò che è ragionevole cambiare e di ciò che, se cambiato, invaliderebbe la metodologia?

Questa è una domanda molto importante per coloro che seguono le cosiddette “Metodologie Agili”. Una delle caratteristiche principali di queste metodologie è quell'aspetto che viene denominato “self-adaptive”: ovvero ci si aspetta che la metodologia evolva in base all'utilizzo che ne viene fatto nel corso del tempo. Solo in questo caso la metodologia sarà resa molto fluida e le variazioni più accettabili. Non solo: può essere che anche all'interno di uno stesso progetto si hanno variazioni di metodologia nel tempo.

Questo è il maggior dilemma: è meglio descrivere variazioni all'interno di una metodologia in modo da poter essere recepite anche dalle persone che realmente cercano di applicarla perché vogliono ottenere i benefici che si aspettano, o permettere loro di applicare direttamente il consiglio di variazione per soddisfare meglio le loro specifiche esigenze in base alle circostanze in cui si trovano?

Metodologie e variabilità

Nel modo sono state teorizzate diversi tipi di metodologie. Ciascuno di questi tipi può portare ad una serie di problemi diversi da quello delle variazioni. Quindi è bene classificare le principali metodologie in diverse famiglie (è molto importante, per il proseguo, tener presente che i termini utilizzati sono stati definiti apposta per questo articolo).

- Concrete Process: un processo concreto (concrete process) fornisce una serie fissa di pratiche che si dovrebbero seguire. Tale tipo di processo consentirà poche (o nessuna) variazione. La forza di questi tipi di processi sta nel fatto che tutti i passi da seguire per metterlo in pratica sono molto chiari. Di contro, la principale limitazione risiede nella sua staticità. In realtà si possono apportare piccole modifiche locali al processo concreto. Il problema sta nel fatto che questo tipo di metodologia non fornisce indicazioni su come attuare queste modifiche. Inoltre non appena si inizia ad apportare variazioni, che sono palesemente al di fuori del processo concreto, anche se abbastanza vicine ad esso, c'è il rischio che i suoi sostenitori sostengano che il processo utilizzato è proprio il processo concreto (soprattutto se le variazioni apportate portano ad un successo).
- Tailorable processes: vengono così denominati quei processi che al loro interno hanno specifiche indicazioni su come possono essere variati. Infatti, i processi “Tailorabili” di solito hanno una parte significativa che descrive le variazioni accettate e quando è opportuno attuarle/utilizzarle. Questo aspetto è quello che li caratterizza positivamente rispetto ai processi concreti (che non hanno indicazioni su come apportare loro delle variazioni). Tuttavia anche in questo caso non si è in una situazione di perfezione in quanto spesso è molto difficile capire come apportare correttamente le variazioni indicate: si deve infatti capire sia il processo di base che tutte le variazioni consentite prima di poter prendere una decisione in merito alle operazioni da seguire.

A questo punto è importante pensare anche alla dimensione di un processo. Non è semplice stabilire la dimensione di un processo: uno dei possibili modi è quello di pensare alla mole di materiale consultato per poter applicare parte del medesimo. Prassi comune è quella di indicare un processo come un grande “processo tailorabile”. L'idea è quella di indicare tutto ciò che si dovrebbe fare, successivamente indicare anche tutto ciò che non si dovrebbe fare. Tuttavia per far ciò è necessario comprendere tutto il processo (che è di grandi dimensioni) prima di poter indicare i piccoli dettagli. Se si necessita di un processo di piccole dimensioni tutto ciò potrebbe essere lavoro inutile per ciò che si vuole ottenere.

Ci sono molti esempi di processi tailorabili. Forse il più conosciuto in questo momento è il Rational Unified Process (RUP). Questo processo è ancor più che tailorabile tanto che è definito come process framework. Il punto forte del RUP sta nel fatto che non viene definito un singolo, specifico processo, bensì un insieme adattabile che può dar luogo a diverse istanze del RUP stesso. Queste istanze dal canto loro possono essere utilizzate senza necessariamente usare o capire il RUP nella sua completezza. Ne consegue che è sempre possibile utilizzare allo stesso tempo un processo concreto unitamente a una istanza di RUP (che è un processo tailorabile). Bisogna fare attenzione quando si applica questa pratica in quanto se non ci si preoccupa molto del RUP in realtà ci si riduce all'utilizzo del solo processo concreto. RUP può tuttavia aiutare con indicazioni sulle variazioni che possono essere apportate al processo concreto così come può agevolare la comunicazione con altri soggetti/sistemi che utilizzano altri casi concreti di RUP.

Alcuni processi non forniscono indicazioni concrete, si incentrano piuttosto sull'insegnamento della filosofia di sviluppo del software che risiede alla loro base. Tale aspetto filosofico è intrinsecamente flessibile: ci sono infatti molti modi per realizzare un progetto in cui è inserita la filosofia di sviluppo software. Non entrare nei dettagli di fasi e varianti infatti aiuta la maneggiabilità e la velocità di applicazione del processo. Tuttavia per questi processi mancano applicazioni reali e concrete senza le quali il tutto è più complicato. Un eccelente esempio di processo filosofico è ASD (Adaptive Software Development) di Jim Highsmith.

Anche se la maggior parte della gente non li vede come processi, sono molto importanti anche le cosiddette collections of best practices un buon esempio di best practices è la collezione di McConnel che raccoglie e spiega le buone pratiche nel suo eccellente libro Rapid. Queste best practices è un insieme di buone pratiche relativamente indipendenti e che è possibile applicare praticamente in qualsiasi ordine. A differenza dei processi filosofici (molto granitici) nelle best practices si ha più libertà di applicazione. In ogni caso molto sta alle decisioni di chi si deve occupare di seguire il progetto software.

Il maggior vantaggio delle best practice risiede nal fatto che non c'è bisogno di capire una complessa rete di passaggi per poterle utilizzare. È possibile infatti scegliere pratiche che si pensa possano fornire i migliori risultati senza preoccuparsi di quelle pratiche che non si utilizzano. Dal momento che ho sempre diffidato dalle Metodologie, mi piaceva questo approccio. Una delle cose che ha chiarito XP è questa: le pratiche non sono completamente indipendenti. La potenza di XP non proviene tanto da pratiche individuali, bensì dall'interazione tra diverse di esse. Se si vedessero le pratiche XP come entità individuali si perdono gran parte dei vantaggi di XP. Da ciò emerge che l'interazione tra le pratiche è altrettanto importante delle pratiche stesse. Ed è proprio questa interazione che un buon processo (sia esso concreto o tailorabile) dovrebbe essere in grado a “catturare” ed esporre.

Quindi, tutti questi approcci sono in qualche modo imperfetti: un processo concreto in teoria non è del tutto invariante, tuttavia non vengono fornite indicazioni su come variarlo. Un processo tailorabile è un buon processo a livello teorico, tuttavia per poterlo variare serve conoscere una miriade di altri aspetti del processo stesso. Un processo filosofico fornisce un buon sostegno di base ma non fornisce indicazioni pratiche su come attuare un processo software. Le best practices forniscono una serie di operazioni semplici ed individuali da seguire, tuttavia non vi è alcuna indicazione sull'interazione che queste operazioni hanno tra di esse.

Cos'è XP?

Per molti è palese che XP sia un processo concreto. È formato da dodici indicazioni che devono essere seguite. Anche se è emerso da diversi gruppi di discussione su XP che è molto faticoso convincere le persone che utilizzano XP ad attuare tutte le 12 pratiche. Addirittura l'insistenza dei maggiori sostenitori di XP nel cercare di far passare il messaggio che è importante eseguire tutte le 12 indicazioni è visto come eccessivo fanatismo.

Gran parte del fascino di XP proviene da persone che hanno dimestichezza con la filosofia che sta alla base di questa metodologia. L'adattabilità, l'orientamento alla persona, la semplicità di comprensione, la leggerezza di comprensione ed il fatto che XP sta diventando una metodologia emergente è un mix irresistibile. Purtroppo ci sono molti che vogliono attuare XP ma sono al di fuori dei limiti del processo concreto.

Una delle particolarità su XP che mi piace sottolineare sta nel fatto che non si è posto limiti ben precisi. Se si avesse a disposizione un gruppo di una dozzina di sviluppatori i limiti sono abbastanza chiari, ma molte pratiche indicate da XP si rivolge a progetti anche al di fuori di questi limiti. Cosa succede se si dispone di un progetto con una trentina di sviluppatori? O ancora, se si avesse un progetto con molte risorse in telelavoro? I principi di adattabilità e di orientamento alla persona sono ancora validi. Quindi perché non arrivare sempre a cercare di applicare XP ove possibile?

Da questo si apre il dibattito fra coloro che preferiscono la visione ristretta di XP e quelli che preferiscono la visione più ampia. Il dibattito è intensificato dal fatto che XP ha guadagnato molti consensi ed è quindi diventato molto diffuso. Quindi le persone sono portate a dire che usano XP perché sanno che ciò comunica molto circa i valori che stanno alla base del loro valore, quei valori che contano, anche se si dispone di un team di grandi dimensioni o distribuiti.

XP non ha un comitato direttivo che fornisce dichiarazioni ufficiali su ciò che è o non è XP. Si è alla presenza di una comunità con soli accordi informali che tuttavia è ancora un po' indecisa su questa questione. Kent ha dichiarato che preferirebbe che XP fosse visto come processo concreto. Visto che lui è il “maschio alfa” della comunità XP la sua preferenza ha molto peso. Quindi, ad ora, la visione predominante è che XP significa anche processo concreto.

XP e la "Self-Adaptivity"

Quindi prendiamo XP come il processo ben definito, la famosa visione di Kent come processo concreto. Come si fa a conciliare questo con la necessità di self-adaptivity (ovvero di auto-adattamento)?

L'indizio per la risposta arriva direttamente da una dichiarazione fatta da Kent Beck quando qualcuno gli pone una domanda si come configurare livelli di maturità del software a livello di XP. Molti non hanno gradito la domanda in quanto poteva portare a pensare che una qualsiasi definizione di CMM (Capability Maturity Model) fosse applicabile a XP. Kent, come fa spesso, ha risposto con la consueta serietà (anche se spesso da lui ci si possono attendere sorprese). Ha detto che ci sono tre livelli di maturità per XP:

- Livello 1: si applicano esattamente tutte le pratiche previste.
- Livello 2: si adatta XP alle condizioni locali.
- Livello 3: non importa se si sta attuando o meno XP.

Ecco qui la self-adaptivity: è necessario adattare XP nel divenire del progetto per sostenere che si sta ancora attuando XP. In altre parole se alla 6° iterazione si sta ancora attuando XP come lo si stava attuando nella 1° iterazione significa che non si sta seguendo una pratica XP.

I livelli di maturità forniti da Kent presuppongono questo fatto: prima della fase di adattamento (Livello 2) serve seguire tutte le fasi indicate per XP (Livello 1). Il punto è che è difficile vedere come funziona XP senza mai provarlo. Gli effetti di XP sono tanto più apprezzabili quanto più si lavora in un gruppo e si hanno più interazioni fra i diversi soggetti.

Questo è il motivo per cui molti dei sostenitori di XP hanno messo tanta enfasi sul Livello 1 prima di impegnarsi a fondo sul Livello 2. Spesso ciò può essere considerato come mentalità chiusa. È passato un sacco di tempo prima che gli attuali sostenitori di XP si resero conto del loro scetticismo iniziale e la loro inclinazione a fare le cose in maniera diversa. Solo quando hanno utilizzato XP, li sorprese molto ed in modo positivo. Quindi una volta che si resta sorpresi in prima persona si è inclini a pensare che anche gli altri saranno sorpresi e quindi si diventerà riluttanti ad ascoltare qualcuno che non è passato attraverso questa esperienza.

XP nel concreto

Tutto ciò implica un modo diverso di pensare. Serve capire come un processo concreto sia anche variabile. Invece di iniziare a capire come utilizzare un processo complicato (di tipo tailorabile) è bene iniziare con un processo concreto anche se non è il migliore per le esigenze richieste. Così facendo si è in grado di capire concetti importanti e fondamentali per la teoria dei processi che, altrimenti, sarebbero mancati. Una volta che si è venuti a conoscenza di questi concetti basilari si può iniziare ad apportare modifiche al proprio processo (anche utilizzando suggerimenti provenienti da altri tipi di processo).

È quindi questo il punto cruciale di come possono essere implementati variazioni sul tema XP. Se una metodologia è stata compresa a fondo allora si è anche in grado di capire come questa può essere adattata alle esigenze. Per una metodologia complessa e pesante questo richiede un sacco di lavoro. Al contrario una metodologia agile (solo con alcune pratiche) ed una forte propensione allo sviluppo incrementale e all'apprendimento del ciclo di vita del software, rende molto più facile le variazioni di metodologia.

La parte più difficile riguardo alla metodologia XP è la compresione: essa infatti è molto difficile se non si prova XP in concreto. Tra l'altro bisogna stare molto attenti ad apportare modifiche in base alle proprie esigenze: queste dovrebbero essere fatte solo dopo che la metodologia XP sia stata capita a fondo tramite l'utilizzo.

La soluzione migliore è quella di iniziare dal Livello 1 ovvero dall'applicazione della metodologia XP per poche iterazioni, senza variazioni. Purtroppo nella maggior dei casi non si è in grado di farlo. Spesso viene applicata la metodologia in modo frammentario per risolvere i problemi che via via si pongono. Questo secondo approccio (sicuramente più semplice da affrontare) porta anche ad un maggio rischio: si può perdere il concetto di iterazioni fra le fasi della metodologia. Quindi si può sostenere che con quest ultimo approccio è importate avere nel team qualcuno che conosce la metodologia XP per poter così guidare gli altri.

L'importante per iniziare con XP è quello di partire con un insieme di pratiche ed esperienze già provate o vissute, successivamente si può adattare XP alle circostanze; l'importante è che ciò sia fatto sempre con l'obiettivo di capire realmente come funziona la metodologia. Quindi si dovrebbe provare XP così come indicato dalle 12 pratiche che lo compongono, senza apportare variazioni, trattando questa fase come una fase di apprendimento. Dopo qualche iterazione si può iniziare con la fase di adattamento. Sarebbe sorprendente se le variazioni che si vorrebbero applicare sono le medesimi degli adattamenti pensati inizialmente (di solito non è così).

XP e i suoi confini

Quale futuro ha XP oltre i suoi confini? In una fase di sperimentazione in ThoughtWorks è stato usato XP come base per un progetto con circa 60 persone (metà delle quali sviluppatori). Questo caso è sicuramente sovradimensionato per essere definito XP, tuttavia è stato definito XP perché l'eXtremeProgramming è stata la filosofia di guida di ciò che è stato fatto. Sicuramente le 12 pratiche sono state variate di molto per far funzionare XP su un gruppo così ampio, tra l'altro non si è mai stati in una situazione in cui tutto il team ha sperimentato la metodologia “pura”, senza variazioni, così come indicato dalle 12 pratiche base.

Nonostante tutto ciò è preferibile che XP rimanga ben definito all'interno dei suoi confini al fine di non snaturarlo eccessivamente. In realtà la sperimentazione attuata è stata influenzata da XP ma si è trattato sostanzialmente di un processo diverso. Tale processo continuerà ad adattarsi al progetto indipendentemente dal fatto che resti XP o meno. Forse la chiave è proprio questa: vedere XP come un seme, come radici, non come un albero.

Così quando si è deciso di “comprare” XP (dopo tutto non costa niente), ciò che si ottiene è il seme. Si è in grado di avviare e sfruttare l'esperienza della comunità XP con un processo piccolo, concreto e quindi più facile da capire, e anche più facilmente adattabile alle esigenze. Per alcune iterazioni si seguono alla lettera le 12 pratiche base. Ben presto tuttavia si devono costruire su di esse pratiche personalizzate, adattate alle specifiche esigenze e circostanze. L'importante è non utilizzare XP (o altri metodi agili) come metodo sbrigativo, per mettersi al riparo da eventuali grandi sforzi per l'applicazione di metodologie di sviluppo software più complesse. Anche perché i metodi agili non funzionano se non si ha un team che vuole veramente capire a fondo il processo che si sta attuando. Il seme e la radice sono le parte più importante di qualsiasi albero ma, come ogni giardiniere potrà confermare, non è una garanzia di successo per poter far nascere l'albero in tutti i tipi di terreno...