Il coraggio, un valore nell’extreme programming

Molte pratiche extreme programming hanno a che fare con il coraggio.

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!

May 18 2008 11:19 am | I valori XP

Trackback URI | Comments RSS

Leave a Reply