Francesco Cirillo: i programmatori agili, una nuova filosofia dello sviluppo software

Wiki@Home Wikimedia Italia in cerca di segnali dal mondo intervista a cura di Erato "Agile girl"

lunedì 28 gennaio 2008

Microbiografia

Francesco Cirillo

Francesco Cirillo è uno dei maggiori rappresentanti italiani delle metodologie agili: in particolare dell' eXtreme Programming (XP). Ha iniziato a lavorare con XP nel 1999 a Zurigo. Rientrato in Italia nel 2000 ha fondato XPLabs, società che offre consulenze nel campo delle metodologie agili. Siamo nell'ambito dell'ingegneria del software ovvero quella branca dell'ingegneria che si occupa dei processi e dei metodi di sviluppo del software.

Intervista agile

La location, Italian Agile Day 2007: conferenza nazionale e gratuita che raccoglie esperti, neofiti e curiosi delle metodologie agili, organizzata da Marco Abis con l'aiuto della comunità agile italiana è il luogo dove abbiamo incontrato Francesco Cirillo. Quest'anno la conferenza ha avuto diversi ospiti di rilievo esteri e italiani e ha potuto contare sulle presenza di 250 persone.

Il nostro contatto, Erato: Mi trovavo all'Italian Agile Day 2007 non solo in qualità di inviata di Wiki@Home ma anche come relatrice poiché sono coach (ovvero guida, allenatore) di un team di sviluppo agile che ha deciso di presentarsi alla comunità agile italiana.

Intervista

Erato presenzia come speaker all'agile day
2007

Il movimento agile e le sue pratiche

W@H: come si puo' spiegare il movimento agile ai lettori non tecnici di WikiNews?

Francesco Cirillo: Il movimento agile nasce con l'obiettivo di cercare maggiore efficacia e concretezza nello sviluppo del software: efficacia e concretezza si traducono in possibilità di maggiori guadagni per le aziende. Chi, davanti alla propria applicazione preferita o a quella di lavoro, non si è detto almeno una volta: "Certo che se si potesse aggiungere questa funzionalità...". Oggi la richiesta di cambiamento da parte di clienti ed utenti, è la richiesta primaria da soddisfare per chi sviluppa e commercializza software, saper rispondere in tempi brevi a questa esigenza rappresenta un vantaggio economico e competitivo notevole. Ecco perché essere reattivi al cambiamento diventa determinante quando un'azienda decide di mettere online i propri servizi primari.

Cercherò di spiegarmi meglio: se il mercato cambia bisogni, le aziende per essere vincenti hanno bisogno di adattarsi immediatamente al nuovo business e questo vuol dire disporre di team di sviluppo (NdR un gruppo di programmatori che lavorano insieme ad uno stesso software) in grado di realizzare i cambiamenti richiesti con qualità, in tempi brevi e a costi bassi. Il software oggi non può essere più visto come un prodotto statico, ma come valore in continuo mutamento. Non è raro trovare team che ostacolino il cambiamento. Non per volontà, ma spesso per incapacità di gestirlo. Non saper gestire il cambiamento induce ad avere paura del cambiamento. I metodi agili forniscono una strategia per rispondere efficacemente al cambiamento offrendo pratiche sia tecniche, sia organizzative ad hoc (design emergente, pair programming, planning game, etc.). Imparando a gestire il cambiamento, il team di sviluppo cambia prospettiva e vede in esso una opportunità e non più un problema. Così si raggiunge lo scopo finale, che è sia lavorare in modo piacevole, sia condividere la visione dell'utente finale o del cliente, sia ottenere un vantaggio economico per l'azienda.

W@H: ma è solo una "questione tecnica per tecnici"?

FC: No. Direi che è una questione di buon senso. Il principio alla base dei metodi agili è che il processo di sviluppo, il modo di lavorare, può migliorare continuamente se a farlo sono gli stessi membri del team attraverso una interazione efficace.

W@H: il programmatore è una persona chiusa e individualista e collaborare significa comunicare. Come aiuti i programmatori dei vari team con cui lavori a superare questa difficoltà comunicativa?

FC: Se i programmatori non amano comunicare è perché non gli conviene farlo :). Nei team capita che quando si prova a comunicare si viene giudicati dal proprio manager o dagli altri membri del team. Può non essere un'esperienza positiva. Può addirittura risultare frustrante. Si può finire per avere paura di farlo. Più semplicemente: può non convenire. In breve tempo il bisogno di comunicare sembra ridursi. Non comunicando però il team trova soluzioni sub-ottimali e nell'individuo aumenta il livello di frustrazione. L'attività primaria di un programmatore è risolvere problemi. Per collaborare alla soluzione di un problema, trovare nuove idee, occorre abbassare la soglia nell'imbarazzo. Come si può arrivare a questo se "Luigi al solito non riesce ad essere concreto"? :)

Troppo spesso nel lavoro in team i problemi subiscono personalizzazioni. Ogni proposta sembra far partire attacchi personali. La soglia dell'imbarazzo si alza e questo non favorisce la soluzione semplice di problemi. Come li aiuto? Anche io sono stato un esperto nel non sapere comunicare. Con il tempo ho imparato che bisogna essere "duri con i problemi, morbidi con le persone" e che è utile vedere i problemi come opportunità di miglioramento. Se noi come team, condividiamo una serie di principi oggettivi sarà più facile riconoscere la violazione di questi principi in quello che facciamo, e la critica sarà diretta verso l'azione che ha violato il principio e non verso la presunta scarsa concretezza di Luigi. Se riesco ad esprimere questo, collaborare e comunicare diventa conveniente. Una sorta di egoismo illuminato :)

W@H: ed è così che si riesce a dominare l'emotività delle persone?

FC: L'obiettivo non è dominare l'emotività, ma essere efficaci.

W@H: come reagiscono le persone al cambiamento personale?

FC: La reazione iniziale può non essere semplice. Ad ognuno di noi piacerebbe essere convinto che con poco sforzo si riescano ad ottenere grandi vantaggi. Non è così. È utile informare sin dall'inizio i membri del team che piccoli cambiamenti si raggiungeranno con grande sforzo. Sarà la continuità di quei piccoli cambiamenti a produrre miglioramenti in termini di produttività. Se le persone hanno chiaro questo punto, la loro motivazione sarà maggiore e ridurranno il rischio di delusioni. Le aziende traggono profitti investendo nella continuità di piccoli miglioramenti individuali.

W@H: cos'è il pomodoro? è stato applicato in ambiti diversi da quello informatico?

Il Pomodoro

FC: La Tecnica del Pomodoro è il nome che ho dato ad una pratica che seguo da quando scoprii di non essere efficace nello studio e decisi di voler migliorare, facendo lavorare meglio la mente. L'obiettivo principale è raccogliere in modo semplice e non intrusivo utili informazioni su come si sta lavorando, in modo da potersi osservare e individuare possibilità di miglioramento. Lo strumento di base di questa tecnica è molto semplice: un timer da cucina, di qui il nome della tecnica. Da quando ho scritto il paper, l'ho visto applicare con successo a contesti molto diversi tra loro: sviluppatori software, organizzatori di conferenze, medici, architetti, etc. Mi ha molto stupito venire a sapere che i bambini si divertissero a studiare con il Pomodoro. Ricevo con piacere il feedback di adulti che con il Pomodoro hanno trovato un modo per riprendere gli studi.

W@H: quando ti chiamano a far da mentore a un team (NdR il mentore in questo contesto è un consigliere fidato, una guida saggia di un team di sviluppo che interviene per dare un guida di massima e si distingue dal coach perché non ha una responsabilità diretto sul team e sui progetti in corso), è il team che deve aver richiesto il tuo intervento?

FC: Sì. Questa è una condizione indispensabile. Essere mentore vuol dire mettere in grado un team di migliorare il proprio processo autonomamente. In questo il mentoring è diverso dalla consulenza. Solo un team consapevole dei propri problemi e che sente la necessità di disporre di strumenti efficaci per migliorare il proprio processo, può sentire l'esigenza di chiamare un mentore.

W@H: possiamo dire che una delle differenze fondamentali tra l'ingegneria del software tradizionale e le metodologie agili è che le persone sono al centro del processo di sviluppo?

FC: È esatto. Nei metodi agili ogni membro del team contribuisce al miglioramento del processo di sviluppo. Si considera appartenente al team chiunque abbia interesse al buon esito del progetto, quindi anche il cliente fa parte del team. È un po' come se, in un'industria manifatturiera, operai, progettisti, clienti, venditori si trovassero tutti sulla catena di montaggio per trovare modi migliori per organizzarsi e realizzare il prodotto finale. Questa capacità auto-regolativa che caratterizza i team agili richiede responsabilità e capacità di collaborazione. Per questo le persone hanno un ruolo centrale nei metodi agili.

Nell'ingegneria del software tradizionale spesso si è fatto il contrario, dando la priorità ai processi piuttosto che alle persone. I processi sono imposti alle persone, che devono adattarsi ad essi. È evidente il senso di spersonalizzazione e demotivazione che questo può produrre, con una riduzione finale della produttività aziendale. È anche interessante notare che spesso questo adattamento al processo finisce per produrre un fenomeno schizofrenico: convivono due processi paralleli, quello "che si dovrebbe applicare" e quello "che applichiamo".

Far diventare le persone il "fattore di primo ordine", come propongono i metodi agili, è la migliore garanzia per reagire a cambiamenti anche violenti, richiesti dal cliente o dettati direttamente dal mercato. Perché saranno proprio le persone ad individuare opportunità di miglioramento ed adattare il processo alle mutate condizioni ambientali.

W@H: un processo di sviluppo fatto per le persone, per valorizzare le esperienze e le qualità delle persone. Ma come?

FC: Nei metodi agili si cerca una soluzione vincente in cui gli sviluppatori abbiano migliori condizioni e contenuti di lavoro e le aziende maggiori profitti. Come? In un team agile ogni suo membro ha la possibilità di contribuire a migliorare il processo. Ogni membro del team si assume la responsabilità di realizzare intere funzionalità (e non se le fa assegnare da qualcuno). Sa che può proporre idee nuove, anche molto creative. Le sue idee saranno criticate duramente ma oggettivamente e sempre con rispetto verso la persona. Realizza il software di produzione in coppia con un altro sviluppatore per aumentare la qualità del lavoro, imparare da chi ne sa di più di lui, o scoprire nuove cose attraverso il confronto. Può comunicare i suoi problemi di sviluppo senza paura, sapendo che sarà aiutato dal team. Si impegna a scrivere software di qualità e comprensibile per tutti. E soprattutto realizza software che cresce in modo evolutivo guidato dai test.

Tutto questo porta ad una riduzione dei difetti, una maggiore flessibilità complessiva e un conseguente minor costo del cambiamento. I manager riducono le attività di controllo - è il team a interessarsi al proprio miglioramento - e soprattutto smettono di motivare le persone. Il team è motivato dai contenuti del lavoro e dal processo che ha deciso di seguire. Si lavora con maggiore soddisfazione e si aumentano la produttività e l'utile dell'azienda.

W@H: agile è anche una filosofia di vita?

FC: In generale rispondere al cambiamento è una necessità sempre più avvertita, non solo nel campo dello sviluppo software. I valori ed i principi dei metodi agili offrono una soluzione efficace per rispondere al cambiamento sostenendo la comunicazione e la semplicità, valorizzando il coraggio degli individui, puntando sulla responsabilità e sulla collaborazione. Tutto questo al fine di raggiungere obiettivi pragmatici, cose che funzionano.

W@H: per gestire qualcosa di complesso attraverso comportamenti semplici penso che bisogna essere davvero bravi.

FC: Occorre conoscere i principi e saperli applicare. E, quando non li si applica, bisogna essere consapevoli delle relative conseguenze. Tutte cose che si possono imparare.

W@H: prima si diceva che nell'approccio classico c'è qualcuno che prende subito decisioni di design, e allo sviluppatore non rimane che tradurre in codice l'analisi, ora si parla di sviluppatori che prendono decisioni.

FC: Per "abbracciare il cambiamento", le strutture, il design, devono seguire le funzionalità di una applicazione, in modo continuo. In un mondo in cui il cambiamento è un fattore primario e spesso violento, per seguire le funzionalità, le strutture devono essere continuamente messe in discussione e rimodellate. Questo caratterizza il design emergente. È un po' come quando da bambini giocavamo con il pongo e trasformavamo un aereo in una nave con poche manipolazioni. Allo stesso modo, lo sviluppatore agile fa emergere le strutture riconoscendole, invece di definirle ed imporle sin dall'inizio (con il rischio di non riuscire poi a modificarle). La malleabilità è la qualità del software con cui si confronta quotidianamente lo sviluppatore agile.

Gli approcci tradizionali prevedono ruoli specializzati: l'analista, il progettista, il programmatore, il tester. Nei metodi agili invece si realizza una sorta di de-specializzazione: lo sviluppatore agile si assume tutti quei ruoli. Proprio questa sua completezza gli consente di prendere in carico una intera funzionalità e portarla a termine prendendo le decisioni necessarie: da analista, da progettista, da sviluppatore, da tester. Da mero codificatore, lo sviluppatore agile deve ora prendere decisioni consapevoli e responsabili. Questo contribuisce ad aumentare motivazione e piacevolezza del lavoro.

W@H: le metodologie agili hanno trovato applicazioni in campo diverso da quello informatico?

FC: Nel settore manifatturiero, la lean production presenta evidenti similarità con i metodi agili. Toyota è il riferimento più rilevante. Il coinvolgimento del team che lavora per eliminare i difetti e migliorare il proprio processo, è l'elemento per me più significativo. Il legame tra lean production e metodi agili è interessante pensando che l'industria manifatturiera sembra piuttosto lontana, almeno idealmente, dalla produzione di qualcosa di intangibile come il software.

W@H: quest'anno qui allo IAD 2007 siamo in 250, l'anno scorso eravamo in 180. Sembra che anche in Italia qualcosa comincia a muoversi, a cambiare. È da valutare positivamente questo aumento di interesse?

FC: Sì. Oltre che aumentare di numero, l'interesse si sta spostando da programmatori e studenti inizialmente incuriositi dalla novità dei metodi agili, a manager di imprese interessati a sfruttare i vantaggi economici offerti da questi metodi.

W@H: è vero che avete un forno a legna per fare le pizze in XPLabs?

FC: Sì. Dal 2000 l'XPLabs Collaborative Engineering Center, la sede storica di XPLabs - una villa ristrutturata nella campagna vicino Sutri -, accoglie team che desiderano apprendere come diventare più efficaci attraverso Extreme Programming (XP) e i Metodi Agili. Il martedì sera, allora, si teneva la chat settimanale della mailing list di XP-IT: di qui l'idea di cucinare insieme. Provammo a farlo applicando i principi di XP e fu divertente. Nel tempo, questo nostro gioco ha raccolto l'interesse di molti "addetti ai lavori". Il Centro ha ospitato numerosi metodologi del campo dell'ingegneria del software, compreso Ward Cunningham - ideatore di Extreme Programming e del Wiki. Nessuno si è sottratto alla pratica del martedì, prestandosi a tagliare pomodori o a realizzare l'attività che avevano scelto, così come avrebbero fatto in un vero team agile. Il forno per la pizza è la naturale evoluzione di quella pratica :).

Wiki

W.Cunningham, il papà di Wiki

W@H: conosci wikipedia e wikinews? e come li utilizzi?

FC: Li conosco e li uso spesso. Come dicevo, il wiki stesso è una idea che nasce da Ward Cunningham, il papà di uno dei metodi agili. Il wiki applica il concetto di design emergente alla raccolta di informazioni. L'emergere di concetti e definizioni in Wikipedia è molto simile a come gli sviluppatori agili fanno crescere il software.

W@H: Wiki@home è "citizen journalism", ovvero un insieme di interviste fatte da persone normali come la sottoscritta, non giornalisti, a personaggi famosi o esperti che vengono pubblicate su internet. Cosa ne pensi?

FC: Penso che questo sia un modo semplice per arrivare ad una comunicazione diretta ed efficace tra intervistato e lettori.

Collegamenti esterni

• XPLabs l'azienda fondata da F.Cirillo