In questo post vorrei introdurre a livello generale
alcune riflessioni sulle metodologie agili di sviluppo sw che sto "elucubrando"
cercando di mettere insieme quanto emerso all'Agile Day 2004 e al
workshop UGI di govedì.
In principio fu: essere agili _non_ significa meramente applicare tecniche
come SCRUM o XP. Questa frase me la sono scolpita nella pietra dopo che è stata
ripetuta tutto il giorno all'Agile Day, bene di qui sono partite tutte le mie
considerazioni.
In genere si dice che per mangiare un'elefante da solo c'è solo un modo:
mangiarlo a pezzi. Insomma dividi et impera. La prima operazione di sgrossatura
del malloppo non può non partire da du concetti che secondo me sono basilari, o
almeno quelli che mi hanno colpito di più, sempre assorbiti all'Agile
Day.
Concetto numero 1: essere agili nello sviluppo sw significa soprattutto
non soltanto gestire il cambiamento, ma anzi desiderarlo, in modo che diventi
perpetuo l'andamento ondulatorio che porta l'evoluzione del codice a
stabilizzare e quindi a destabilizzare quanto prodotto. Questo è il concetto di
base, quallo che implica la vera chiave di volta rispetto alle metodologie
tradizionali che invece cercano di essere pesantemente predittive in modo da
eliminare sin da subito (o almeno ci provano...) le zone d'ombra in un ambito
monolitico e immutabile (ci potremmo applicare il pattern Utopia di Andrea
Saltarello!).
Concetto numero 2: essere agili significa anche esserlo
all'interno di un ecosistema di cui siamo parte e con cui manteniamo relazioni
complesse. Ecco, probabilmente questo concetto lo reputo fondamentale affinchè
si possa dare una chiave di lettura al primo. Perchè? Perchè se non viene tenuto
in grande considerazione, ma anzi lo si cerca di evitare si cade secondo me in
due errori da cui gli orartori dell'Agile Day hanno martellato tutto il giorno.
I due errori a mio avviso sono: evitare di relazionarsi con l'ecosistema
circostante significa comportarsi come un corpo estraneo che mal si integra e
che quindi presto o tardi verrà considerato come incompatibile (con tutte le
sgradevoli conseguenze del caso), ridursi ad una sorta di integralista
metodologico inviso a chi ci circonda in quanto percepito come il solito unico
depositario della "Verità" (e non solo, si cadrebbe in quanto cerca di evitare
come la peste il pensare agile e cioè tutto quello che fa riferimento a
posizioni d'opinione che hanno a che fare più con la religione o la politica,
nel loro senso più ampio).
In soldoni tutto questo per dire una banalità: non
possiamo esimerci assolutamente dal considerare dove viviamo e lavoriamo quando
il nostro proposito è divenire agili, d'altra parte però è possibile comunque
essere agili anche senza seguire alla lettera tutto quanto teorizzato nelle più
famose tecniche di sviluppo sw agile.
A questo punto ho cominciato a impilare
su questa base quanto appreso giovedì, in particolar modo quanto ascoltato nelle
sessioni di Lorenzo Barbieri su MSF e di Andrea Saltarello sui design
patterns.
MSF: Lorenzo ha ribadito più volte che MSF è un framework di best
practices e metodologie (a me piace definirlo una toolbox, una cassetta degli
attrezzi) che _non_ deve essere preso in considerazione nel suo complesso e così
applicato (addirittura sarebbe formalmente scorretto), ma a cui si deve
attingere nella misura in cui è necessario. Ebbene mi è sembrato, ma posso
sbagliarmi, che alcune delle direttive di MSF si pongano ad un livello un po'
meno drastico di quanto suggerisca XP, soprattutto per quanto riguarda
l'evoluzione di un progetto sw a spirale in cui si parla di un numero vicino a 3
iterazioni del modello standard di progettazione (envision, design, ecc, ecc.).
Voglio approcciare MSF più in profondità perchè potrebbe ben adattarsi
all'ecosistema in cui vivo e cioè un ecosistema che è impostato nel modo più
classico che si possa immaginare ed in cui la produzione di documentazione
preliminare è irrinunciabile. In questo contesto parlare di "sprint" o di "pair
programming" sarebbe come dire alla Santa Inquisizione che il sole gira intorno
alla terra e che questa è sferica... Però posso provare ad introdurre la
documentazione (che continuerebbero ad esistere) viva, sfrondare un po' di
gerarchia delle figure professionali, applicare la continuous integration in
un'ottica di un movimento a spirale della produzione del codice con 3-4
iterazioni. One step towards...
I patterns. C'è una cosa che di XP ad oggi
ancora non mi piace, che non sento mia. Forse mi sbaglio, ma la visione dello
scrivere codice e rifattorizzarlo più volte al giorno in un ciclo temporale
davvero stretto, mi lascia perplesso di fronte alla potenza dei patterns. La
visione che Andrea ha dato dei patterns ha codificato in maniera formale la
stessa idea che ho in testa pure io, e che onestamente la vedo molto poco
applicabile o comunque difficilmente raggiungibile con XP. I patterns sono
il brodo primordiale in cui gli ammassi pluricellulari del nostro codice ai
primi stadi si sviluppano. Non posso in cuor mio rinunciare ai patterns, ma
d'altro canto i patterns devono essere pensati, non posso solo agire per poi
refattorizzare. OK, posso refattorizzare in direzione di un pattern, ma se così
è voglio essere proattivo già nello scrivere il codice e sapere dove vado a
parare. In soldoni ancora una volta, la fese di envisioning e design a volte
_non_ posso renderla compiuta nell'arco di pochi minuti, a volte ci vuole tempo
come quando si fa lievitare un panettone (scegliere se applicare un pattern o
meno non la reputo un'attività di poco conto).
Insomma agile nel senso di muoversi agili nel cambiamento (di specifiche, di
tempi, di vision, di quello che si vuole), in un processo ondivago e
convergente, ma muoversi agili anche nel proprio ambiente sia lavorativo, sia di
inclinazione personale. In un film che amo moltissimo (Contact con Jody Foster)
il padre della protagonsita, quando questa aveva circa 8-10 anni le diceva
"piccole mosse Elly, piccole mosse" mentre lei cercava di contattatre con il suo
CB persone sempre più lontane e doveva agire sulla manopola delle frequenze.
Ebbene credo che a volte il cambiamento anche nelle propria abitudini debba
essere fatto con piccole mosse, piccoli accorgimenti.
Butterfly effect: un
lieve sbattere d'ali di farfalla oggi, domani porterà ad un uragano...
My god: sto divenatndo pure io blogorroico!
MesBlog powered by IMHO