I team XP condividono informazione spesso, volentieri e su più livelli. Utilizzano il pair programming, per trasferire rapidamente conoscenza da uno sviluppatore all’altro; spazi di lavoro condivisi corredati di grandi radiatori di informazione – come tabelloni, lavagne e poster, per permettere a tutti, anche ai non-sviluppatori, di vedere e sentire la situazione; utilizzano i brevi standup meeting quotidiani per aggiornare l’intero team sui problemi percepiti; i test automatici e la continous integration, per condividere un’oggettiva metrica dell’integrità del codice; incentivano il cliente a collaborare attivamente al progetto giorno dopo giorno per facilitare la comunicazione del lavoro svolto da una parte e del mutare dei requisiti più volatili dall’altra.

Una forma forse ancora più preziosa di comunicazione, anzi, di metacomunicazione permette il miglioramento incrementale della comunicazione stessa: la restrospettiva. Con questo meccanismo il team riflette sul proprio operato e sulle pratiche di comunicazione e di condivisione, arrivando a decidere se interrompere quelle meno fruttuose, se provarne di più promettenti o semplicemente se migliorare l’attuazione di quelle che sembra potrebbero funzionare meglio.

La comunicazione insomma è un valore prezioso all’interno di un team Extreme Programming ed ogni dubbio, ogni decisione andrebbero risolti dopo essersi posti questa domanda: cosa permetterà al mio team oggi di comunicare al meglio?

Ieri ti sei posto questa domanda? Oggi te la porrai?

La parola “coraggio” non va letta con riferimento ad un atteggiamento sprezzante del pericolo da parte dei membri del team di sviluppo – ma sì iniziamo a scrivere codice, poi si vedrà! – quanto piuttosto all’assenza di paura.

“Ma io non ho paura quando programmo!” molti di voi staranno pensando in questo momento. Bene, sono pronto a smentirne molti; mi sarà sufficiente porre una sola domanda:

Avete appena finito di lavorare ad un componente che ha richiesto 10 giornate (2 settimane!) del vostro prezioso lavoro. Ora il cliente ha ragionevolmente deciso, sulla base di ulteriori informazioni tecniche e di mercato di cui prima non disponeva, di modificare quel componente. Ciò richiederà di modificare ed integrare il lavoro appena concluso in misura tale da rischiare di compromettere il lavoro perfettamente compiuto fino a quel momento.
L’idea di manomettere il codice già scritto vi lascia perfettamente tranquilli?

Ok. Voi che vi guardate intorno con aria distratta piantatela lì: avete la risposta scritta in faccia. Voialtri che conoscete perfettamente il vostro codice, del quale non vi sfugge nemmeno una riga, che pertanto sapete cambiarne il comportamento modificandolo alla velocità del pensiero (sic) e che vorreste sapere come può mai accadere che uno sviluppatore tema la propria docile, cara, complessa e privatissima creatura… beh… voi siete dei geni che, per manifesta superiorità, non sono nello scope di questo articolo ed in generale del project management agile. Voi che applicate già Scrum o qualche altra metodologia agile forse siete già tranquilli, ma… tutti gli altri, lo so: la risposta è che non vi sentireste affatto tranquilli!

Questa assenza di tranquillità che avete appena immaginato – e forse anche ricordato in situazioni passate – è la mancanza di coraggio cui mi riferisco in questo articolo.

Extreme programming cerca di ingaggiare la tradizionale paura nei confronti del cambiamento direttamente alle sue origini, con una serie di pratiche atte ad indurre gli sviluppatori a fare senza timore – e quando necessario – modifiche al sistema su cui lavorano per migliorarne l’architettura, al scalabilità e la mantenibilità.

Le pratiche del test driven development e del refactoring infondono nello sviluppatore il coraggio di apportare questo tipo di modifiche in maniera incrementale via via che sono richieste, ben supportati da una solida rete di sicurezza costituita dagli unit test e dagli acceptance test.

Il cliente, d’altra parte, non incontrando la tipica resistenza al cambiamento che caratterizza i team di sviluppo tradizionali, ha anche lui la possibilità di vivere il suo ruolo con coraggio, rimuovendo la paura di chiedere modifiche. Nuovi requisiti possono arrivare per un cambiamento del mercato, per l’analisi svolta dagli stessi sviluppatori e anche, perché no, per il semplice fatto che c’è una nuova buona idea che prima non c’era.

I requisiti nei progetti software cambiano, punto e basta. Tentare di lavorare opponendosi a questo dato di fatto significa cercare di progettare un aereo sperando che la Legge di Gravità ci conceda delle pause permettendoci di volare da Malpensa a Lione! Essere bravi sviluppatori e bravi project manager non significa nascondere la testa nella sabbia e dare risposte ad una realtà che non esiste, ma reagire alla realtà dei fatti tutelandosi con strumenti e tecniche che inducano a vivere lo sviluppo con serenità e coraggio permettendo di… accogliere il cambiamento!