Venerdì 19 Novembre 2010 si tenuto a Genova L’Italian Agile Day,l’annuale conferenza quest’anno è arrivata alla sua settima edizione. L’Italian Agile Day è un appuntamento dedicato alle metodologie Agili per lo sviluppo e la gestione dei progetti software ed è si rivolge non solo agli sviluppatori ma sopratutto, secondo me, anche ai project leaders, IT managers.

Oltre 500 le presone intervenute all’evento sono state, persone che hanno esperienze da condividere o che semplicemente iniziano solo ora ad interessarsi a queste tematiche.

L’obiettivo della giornata organizzata dall’ Italian Agile Movement, è la diffusione della conoscenza oltre che la condivisione di esperienze e approfondimento di specifiche tematiche.  Come ogni anno l’accesso è stato libero, previa registrazione.

Prima di dare il resoconto della giornata volevo esprimere il mio apprezzamento e fare i complimenti per l’alta qualità dell’organizzazione e la qualità degli interventi e la preparazione degli speaker.

Keynote – Paolo Perrotta
Paolo Perrotta, apre la giornata con il keynote, in modo molto brillante ha esplorato la storia dell’ingegneria del software fin dalle sue origini.

Il software è in crisi, accusa Paolo Perrotta, i progetti sono molto costosi, non hanno la qualità che ci si aspetta(hanno bugs), non consegnano nei tempi previsti e spesso non rispettano i requisiti stabiliti. In definitiva sono un caos da gestire.

La parola crisi nel sw risale a molto tempo fa, nel 68 per la precisione durante la conferenza NATO “software crisis” e da qui nasce anche la parola “Software engineering“, in somma nasce il modo si fare software e nasce gia in crisi.

Ma la crisi “dura” (si fa per dire) 20 anni solo perchè non puoi essere sempre in crisi, quindi la crisi diventa un dato di fatto, non viene risolta ma accettata come uno status quo. Si stima che i progetti sw che falliscono sono il 24%.

Software”dentro” è complicato, ci serve uno “specialista”,  un programmatore. Dal codice macchina si è passato all’Assembly poi al linguaggio procedurale e alla fine a quello ad oggetti, si è provato a togliere complessità al codice ma nulla da fare, “Senza Programmatori” è un mito.
Ma anche se hai lo specialista, per sua natura umana, commette degli sbagli, l’ingegneria del sw vorrebbe formalizzare e validare  i processi ma anche questo approccio è costoso e non privo di errori come insegna il caso della NASA con il progetto Pathfinder.
Ok non possiamo fare a meno del programmatore e questo commette degli errori, ma possiamo tenerlo sotto controllo, eliminado la variabilità dei processi ma purtroppo anche questo non è possibile.

Se si fa un paragone edilizia/informatica, quello che è  il progetto di un palazzo è  per l’informatica lo sviluppo , mentre la costruzione del palazzo è quello che in informatica è la build. Nell’edilizia il progetto costa relativamente poco mentre la costruzione costa molto, nell’informatica avviene l’opposto, il processo di sviluppo costa moltissimo l’installazione del sw è praticamente gratis, tolto il costo del hardware.

In questi anni, non siamo riusciti ad eliminare i problemi che affliggono l’informatica e la sua crisi. L’alternativa è prendiamo coscienza della situazione. L’Agile Programming ci dice accetta la variabilità, dividi il progetto in tappe e fai tre cose:
– osserva quello che accade.
– fai un’ipotesi.
– vedi se funziona la tua ipotesi fai degli esperimenti.

Questo è il metodo scentifico, bisogna trattare un progetto sw come tanti progetti di ricerca e sviluppo, questo perchè lo sviluppo del sw non è un processo definito ma bensì un processo empirico.

Due uomini ed una lavagna – Alberto Brandolini
Alberto Brandolini, con molta ironia gira attorno alla strumento più usato dai team agili, che non è il computer bensì la lavagna. Questo perchè è necessario un’attenta attività di analisi ed organizzazione prima di mettersi a scrivere codice a testa bassa. Questo emerge dalla più che brillante esposizione di Brandolini, ma è anche strumento del post sviluppo. Ma andiamo per ordine.
Per molti committenti e managers, gli sviluppatori/consulenti informatici sono come il personaggio di Quentin Tarantino “Sono Wolf, risolvo problemi…”, invece, dice Brandolini, il modello che più si avvicina alla realtà è quella del Dr House, il quale utilizza la lavagna come strumento al supporto delle sue analisi.

Un’altro strumento importante dei team agili sono le riunioni, che, definisce Alberto, sono un’evento/incontro per raggiungere un obiettivo, una di queste riunioni è quella che prende il nome di retrospettiva. Durante questa riunione devono emergere i problemi o i rallentamenti che frenano il team. Il risultato di questa riunione è una serie di azioni pratiche e risolutive, che migliorano l’efficienza del team, “Non ho una sedia…”, “Ok prendi la mia”. Spesso i problemi non emergono da soli, il livello di tolleranza è tale per cui è più facile aggirarli che superarli.

Esistono strumenti o tecniche che riescono ad evidenziare le “ostruzioni” alla produzione o avvolte a prevenirle. Questo è il caso delle Kanban board (per tornare al tema della lavagna). In pratica ogni task passa attraverso degli stati (“To Do”, “In progress”, ecc…) ma solo un certo numero di task puo stare in uno stato, ad esempio solo due task alla volta possono essere nello stato “In progress” se ne arriva un terzo scatta l’evidenza del possibile problema. Per risolvere l’impedimento si crea quello che prende il nome di effetto sciame, dove tutte le risorse sono impegnate alla risoluzione della momentanea emergenza.

Lavagna, ancora come analisi della complessità di un sistema, utilizzando anche modelli stile mymap, perchè non è semplice ridurre per punti problemi di complessità elevata come spesso ci richiedono (committenti e/o managers). Ma anche lavagne per coordinare una discussione, un pennarello per ogni membro del team,  e la lavagna ci permette di :
– confronto con tutti
– essere efficienti
-apertura a nuove soluzioni

Annunci