Una transizione pragmatica dal micro caos ai metodi agili

Capitolo 1
Introduzione
Sono le persone a realizzare i cambiamenti e se il cambiamento ha dato buoni
frutti allora quelle erano le persone giuste, nel posto giusto, al momento giusto.
E cos   e accaduto anche per il mio team di sviluppo. Le persone giuste eravamo
io e un mio collega con un paio d’anni di esperienza e due progetti visti, un
altro collega con maggior esperienza e un suo metodo di lavoro e l’allora respon-
sabile di progetto. Stavamo lavorando a una funzionalit a abbastanza articolata
con tanto di documento di specica visto e rivisto insieme al cliente. Una volta
ritenuto concluso lo sviluppo, abbiamo consegnato la nuova funzionalit a. Dopo
qualche test, il cliente si  e accorto che uno dei requisiti inclusi nella specica
non era stato consegnato. Una volta segnalata la mancanza, abbiamo letto at-
tentamente il documento e ci siamo accorti che il cliente aveva ragione: avevamo
un problema nel processo di sviluppo. Era proprio il caso di fermarsi a riettere
sulla soluzione.
In quei mesi la mia societ a ospitava lo XPUG
1
di Milano e cominciava-
mo a sentire parole come User Story, Card, Task, Planning Game e a esserne
incuriositi a tal punto da iniziare a leggere qualcosa.
Intorno al tavolo della riunione, indetta in seguito alla segnalazione della non
aderenza alla specica, discutevamo sul cosa aveva fatto in modo che un requi-
sito venisse ignorato e su come si poteva evitare che ci o accadesse nuovamente.
La soluzione sembrava essere una di quelle parole prima sentite pronunciare
alle riunioni dello XPUG e poi lette sui libri: la User Story. Poich e non era e
non  e nostra intenzione diventare la fotograa di un libro, c’eravamo fermati
a riettere su come dovesse essere la nostra User Story. Abbiamo deciso per
un foglio pi u piccolo di un A4, dove fosse sicamente impossibile scrivere trop-
pe informazioni, riportante l’identicativo numerico della storia, il nome di chi
l’avrebbe sviluppata, un titolo, una breve descrizione e la suddivisione in task
con le relative stime e i consuntivi: una proto-storia. Da quel giorno abbiamo
cominciato a scrivere tutte le attivit a su queste proto-storie e gi a solo questo
ha dato un primo risultato: non si sono pi u vericate mancate implementazioni
di speciche. Avevamo iniziato il nostro cammino agile. I primi passi sono stati
lenti, talvolta contrastati da quei membri del team con un metodo di lavoro gi a
1
eXtreme Programming User Group: un gruppo di persone che si trovano periodicamente
per discutere e applicare, sviluppando codice vero ma senza acquirente, valori e principi dei
metodi agili.
2 Introduzione
avviato, ma hanno prodotto risultati soddisfacenti, che hanno poi giusticato i
diversi cambi di direzione.
L’anno in cui abbiamo cominciato il nostro cammino ha visto il frequente
alternarsi dei membri del team per un elevato turn over dovuto alla ripresa del
mercato informatico, che ha rallentato molto il cambiamento. L’accelerazione  e
stata possibile grazie ad un po’ di stabilit a raggiunta nell’ultimo anno, quello
oggetto dell’elaborato, e all’arrivo di un mentore.
Quello che ci ha spinto a cambiare il nostro metodo di lavoro  e stato pertanto
il desiderio di lavorare meglio e in modo pi u soddisfacente, realizzando software
con pochi difetti e scrivendo codice comprensibile e di qualit a.
L’obiettivo di questo elaborato  e raccontare come  e stata possibile la tran-
sizione da una situazione quasi priva di regole all’attuale; come le regole sono
scelte e rispettate da tutti i membri del team; come queste regole aiutino a svol-
gere meglio e in modo pi u soddisfacente il proprio lavoro. Il percorso proposto
 e il seguente:
Capitolo 2 descrive il contesto nel quale si  e realizzata la transizione introdu-
cendo brevemente il team di sviluppo che l’ha voluta e l’ha resa possibile
e l’ambiente dove si  e realizzata.
Capitolo 3 accenna a tutti progetti manutenuti dal team, arontando con
maggior dettaglio i due pi u importanti.
Capitolo 4 introduce i valori e le pratiche dei metodi agili che hanno ispirato
il cambiamento.
Capitolo 5 racconta come il processo di sviluppo  e stato modicato dai valori
e dalle pratiche agili introdotte nel Capitolo 4; descrive come le pratiche
sono state adattate al team; mostra, attraverso fatti realmente accaduti,
quali pratiche sono state introdotte con successo e quali difetti di processo
hanno eliminato o attenuato; spiega perch e alcune pratiche sono state
abbandonate.
Capitolo 6 misura la bont a del cambiamento riportando alcune metriche rac-
colte prima dell’inizio della transizione e durante l’accelerazione dell’ulti-
mo anno.
Capitolo 7 trae le conclusioni su questa esperienza mettendo in risalto i pro
e contro nonch e i fattori determinati di successi e insuccessi raccolti.
Appendice A l’elenco delle domande poste ai membri del team, ai colleghi
della software house e al cliente per il quale il team lavora.
Chi gi a conoscesse valori e pratiche dei metodi agili pu o evitare la lettura
del Capitolo 4; gli altri capitoli invece sono da leggere nell’ordine poich e il testo
 e strutturato cos  da descrivere un contesto inizialmente ampio che va stringen-
dosi di capitolo in capitolo no a entrare nel dettaglio delle pratiche utilizzate
realmente dal team.
Capitolo 2
Sinapsi
Nella prima parte di questo capitolo verr a introdotto il contesto nel quale si  e
realizzata la transizione, descrivendo brevemente la software house dove il team
si  e formato, le persone che lo hanno fatto nascere e quelle che lo stanno aiutando
a crescere. Verranno descritti brevemente il tipo di attivit a della software house
e i suoi clienti. La seconda parte del capitolo sar a invece dedicata al team e ne
fornir a una breve storia e qualche dettaglio statistico. La descrizione del contesto
aiuter a a comprendere come e perch e la transizione ha avuto inizio.
2.1 Cos’ e
Sinapsi
1
 e un system integrator, ovvero una software house la cui specialit a
 e far convivere in modo armonico software scritto da terzi, specializzato nello
sviluppo di soluzioni personalizzate basate su piattaforma J2EE
2
e su tecnologie
Free and Open Source Software (FOSS).
Sinapsi crede siano le persone a rappresentare il valore pi u importante delle
aziende che fanno system integration, proprio come i metodi agili credono siano
le persone il fulcro del processo di sviluppo e che sia quest’ultimo a dover adat-
tarsi a loro. Sono infatti le persone a capire le esigenze dei clienti e a guidarli
attraverso scelte tecnologiche in grado di soddisfare le loro necessit a; sono anco-
ra le persone che traducono in software le scelte eettuate e che le manutengono
nel tempo.
2.2 Cosa fa
Sinapsi ore servizi di consulenza professionale, sviluppo di applicazioni per-
sonalizzate con contratti a prezzo sso e manutenzione evolutiva di software
esistente.
Durante lo svolgimento di queste attivit a Sinapsi ha sviluppato competenze
tecnologiche e di dominio, sia relative ai mercati su cui operano i diversi clien-
1
La connessione funzionale tra due cellule nervose o fra cellula nervosa e organo periferico
di reazione.
2
Java 2 Enterprise Edition: versione della piattaforma Java per la creazione di applicazioni
di grandi dimensioni.
4 Sinapsi
ti (bancario, farmaceutico e telecomunicazioni) che trasversali (risorse umane,
media digitali).
2.3 Come  e strutturata
Sinapsi  e stata fondata da quattro soci assortiti in modo decisamente sui generis
rispetto ad analoghe realt a: due loso, laureatisi a indirizzo logico-matematico,
e due ingegneri. Oltre ai soci, fanno parte della dirigenza un responsabile di pro-
duzione e una responsabile della parte amministrativa e nanziaria: le restanti
diverse mansioni sono coperte da una ventina di programmatori con pi u o meno
anni di esperienza. L’organigramma della societ a  e pertanto piuttosto semplice
non esistendo particolari gerarchie. Al momento vi  e un unico team agile: gli altri
collaboratori lavorano presso il cliente (servizi professionali) oppure all’interno
di team tradizionali.
2.4 I clienti
I principali clienti di Sinapsi operano nel campo bancario, farmaceutico o nelle
telecomunicazioni: alcuni di questi clienti sono storici poich e lavorano con Si-
napsi sin da quando  e stata fondata. Le persone che lavorano per uno di questi
clienti hanno deciso di dar vita al primo team agile di Sinapsi: il cliente  e Banca
Popolare di Sondrio e gli sviluppatori che lavorano sul progetto BPS si sono dati
il nome di Wallabiez.
2.5 I colleghi
Esiste un unico team agile all’interno della societ a; altri colleghi lavorano presso
il cliente e altri ancora formano team tradizionali alla partenza di progetti che
richiedono l’impiego di diverse conoscenze.
La creazione di un team agile ha generato, nei colleghi che non vivono questa
esperienza, diversi sentimenti che vanno dall’ammirazione all’indierenza e in
alcuni casi arrivano all’invidia poich e la situazione del team  e talvolta percepita
di privilegio.
2.6 Il Team
2.6.1 La storia
Entrai a far parte del gruppo che lavorava sul progetto Banca Popolare di Son-
drio (BPS) nel 2003, dopo aver partecipato ad un progetto fallimentare nel quale
si utilizzava uno strumento di content management
3
per la creazione, attraver-
so un linguaggio proprietario, di siti dinamici. Il progetto BPS, al contrario,
 e sempre stato interamente basato sul linguaggio Java e composto da diverse
applicazioni web e non, come verr a dettagliatamente spiegato nel capitolo 3. Il
gruppo che lavorava sul progetto era composto da me, che ancora non conoscevo
3
Gli strumenti di gestione dei contenuti forniscono implementazioni per modello, vista e
controllo di applicazioni web.
2.6 Il Team 5
il linguaggio, e da tre sviluppatori senior. Per permettermi di imparare il lin-
guaggio era stato deciso che avrei dovuto allocare parte della mia giornata alla
lettura di un libro su Java [9].
La gestione dei compiti era piuttosto caotica e solitamente non si condi-
videvano le conoscenze acquisite durante lo sviluppo. Ad ogni programmatore
era assegnato un compito adeguato alle sue capacit a, in modo che potesse por-
tarlo a termine in autonomia, limitando le interruzioni del lavoro altrui. Non
mancavano le proposte di svecchiamento tecnologico anche se motivate pi u dal
desiderio di sperimentare una nuova tecnlogia che da un’eettiva necessit a del
cliente. Quando si metteva mano al codice scritto da altri capitava si preferisse
riscriverlo, poich e comprenderlo rendendolo proprio costava quanto rifarlo. In
questo periodo i test erano solo funzionali e la loro esecuzione manuale.
Con la ripresa del mercato alcuni senior lasciarono la societ a e furono so-
stituiti sia da altri senior che da junior: nel frattempo avevo sviluppato il mio
primo servizio web in Java pur non sfruttando completamente le potenzialit a
dell’approccio a oggetti. Conoscevo il linguaggio ma non il paradigma, compli-
ce il fatto che non avevo ancora sostenuto l’esame di Programmazione 1 sui
linguaggi a oggetti.
Il primo signicativo cambiamento nel processo di sviluppo si  e avuto quan-
do il responsabile della produzione, a causa dell’elevato turnover, ha cominciato
ad occuparsi del progetto.
 E stato in questo periodo che abbiamo cominciato
a scrivere metodi main come proto-test al ne di provare il codice delle classi.
 E sempre in questo periodo che abbiamo dato il via a un progetto di test fun-
zionali automatizzati, introdotto le proto-storie con la relativa registrazione in
Bugzilla
4
[4], e lo stand up meeting giornaliero. Il team  e nato per o verso la ne
del 2006, quando ho sostituito il responsabile della produzione sul progetto e
insieme abbiamo denito cosa si intende quando si parla di team: un gruppo di
persone che collaborano e che si aiutano reciprocamente al ne di raggiungere
degli obiettivi comuni. Abbozzati i cambiamenti necessari, abbiamo appurato
che era desiderio di tutti provare a diventare un team.
Gli ultimi mesi di quell’anno furono impegnativi poich e il lavoro era tanto,
importante e delicato e il team appena nato era composto solo da un senior e
due junior. Con l’inizio del 2007 arrivarono una nuova stabilit a e tranquillit a:
uno dei due junior fu sostituito da un senior con particolari doti di analisi. Nel
frattempo le richieste del cliente rientrano nell’ordinario. Era il terreno migliore
per dare un’accelerazione al cambiamento e per chiedere aiuto a un mentore
esterno. Durante quell’anno il team si ingrand  nuovamente acquisendo un altro
senior e due junior.
Ogni responsabile di progetto ha dato la sua impronta al processo produt-
tivo e al rapporto col cliente. La crescente divisone delle responsabilit a e la
trasparenza nella gestione hanno permesso una maturazione sia dei membri del
team che del cliente. La transizione ha avuto inizio in modo quasi naturale per
correggere un difetto nel processo di sviluppo. La decisione di diventare agili  e
stata resa uciale implicitamente alla richiesta di aiuto esterna. Al cliente non
 e stata comunicata: avrebbe potuto godere degli eventuali beneci derivati dal
cambiamento in modo inconsapevole. Dal canto suo comunque ha dimostrato di
sapersi adattare alla realt a in trasformazione accettando anche nuove pratiche
quali il planning game o l’introduzione della fase di stesura dei test.
4
Applicazione con interfaccia web per gestire il workow dei difetti segnalati.