Sinapsi agile day 2006
Da Sinapsi.
Sinapsi ha partecipato anche quest'anno all'Agile Day 2006 tenutosi il 1 Dicembre presso Centro Congressi Jolly Hotel di Milanofiori. Ecco qui un resoconto della giornata.
Contents |
Cos'e' l'Agile Day
L'Agile Day e' una conferenza di un giorno dedicata alle metodologie Agili. Per ulteriori informazioni rimandiamo al sito ufficiale.
Il format
Quest'anno solo due riunioni plenarie: la prima del mattino e la prima del pomeriggio e tante piccole riunioni che si sono svolte contemporaneamente ai quattro angoli della sala del centro congressi. Questo particolare format e' detto OpenSpace ma forse il concetto e' meglio reso dalla macchinetta del caffe' .
Essere Agili nel diventar Agili
Abbiamo assistito a una presentazione molto interessante dei simpaticissimi Nicola Canalini e Luca Minudel del gruppo di sviluppo software della Ferrari, Gestione Sportiva (formula 1, software vario, tra cui gestione corse ai gran premi). Storia ricca di spunti per i [| Wallabiez] di Sinapsi!
Stand Up Meeting
Lo stand up meeting aumenta la comunicazione, ma perche' la comunicazione sia efficace in team di 20 persone e' stato necessario introdurre delle regole. Quali preparare le cose da dire rispondendo alle domande:
- cosa ho fatto ieri?
- sono in anticipo/ritardo?
- quale e' la data di consegna?
- cosa faro' oggi?
- di cosa ho bisogno?
- comunicazioni varie?
Un altra regola importante perche' gli stand up meeting giornalieri siano efficienti ed efficaci e' la regola del no feedback. Ognuno sottopone agli altri i propri dubbi ma le risposte a queste dubbi vengon date al di fuori dello stand up.
Collective Ownership
Il codice e' egoless e questo si realizza facendo girare il piu' possibile le persone sui vari progetti. Per favorire l'idea che il codice e' di tutti, i ragazzi di Ferrari hanno adattato il concetto di varianza. Un progetto ha elevata varianza quando il cliente ne richiede molte variazioni. Cosi' i progetti a bassa varianza hanno uno specialista, i progetti ad alta varianza invece sono di dominio del team perche' tutti ci lavorano a turno.
Alla domanda: uno standard di codifica aumenta la collective ownership? la risposta di Nicola e Luca e': no!. Invece pattern comuni per la risoluzione di problemi e la leggibilita' del codice si'. L'accesso alla base di dati, la lettura di un file oppure l'upload di una risorsa implementati nello stesso modo su tutti i progetti aiutano a diminuire la complesita'.
Altra tecnica che aiuta a mantenere bassa la complessita' e' la regola del no branch. Si parla di repository dei sorgenti: tutto si committa sulla head o sul main trunk (la terminologia dipende dallo strumento utilizzato).
Planning Game
Il team descrive le storie e stima i task entrando nel codice. L'errore sulle stime e' conosciuto e misurato e le storie durano generalmente un'iterazione. L'iterazione coincide col rilascio e il rilascio e' fatto in modo che il contenga del valore per l'utilizzatore.
Continuos Integration
Per tutti i progetti viene eseguito un build automatico notturno con test e tutto e' sempre pronto per essere rilasciato in BETA. Il check-in (o il commit) sul repository si fa del solo codice buono, ma si cerca di farlo il piu' spesso possibile.
Pair Programming
Il pair programming e' applicato dai membrei del team in modo spontaneo. E' una cosa che piace ma che viene fatta solo per parti critiche o poco conosciute. Il pair programming arricchisce e permette di creare del codice senza ego. Inoltre, superate le difficolta' iniziali, si impara ad accettare il sufficientemente buono e ad esser critici nei punti e nei momenti giusti.
Refactoring
Il refactoring si fa ogni volta che si apre il codice a va fatto anche sul codice della suite di test. Il big refatoring invece e' di difficile realizzazione e ancor piu' difficile da farsi pagare dall'utente. Si cerca di mantenere il design il piu' semplice possibile poiche' la complessita' e' il nemico piu' grande. Il design va sempre semplificato: questo tipo di interventi sono remunerativi quasi subito.
Miglioramento continuo
E' questa un'attivita' dedicata al team che si autoorganizza e condivide gli obiettivi al fine di decidere come affrontarli. Per spiegarci questa attivita' Nicola e Luca ci dicono di immaginare un gruppo di persone che spingono un carro. quanto e' piu' efficace questa azione rispetto ad una persona sola che lo tira?
Programmers Test
Parte della giornata e' dedicata alla scrittura dei test che verranno fatti girare durante il nigthly build. Il team ha poi deciso che se un test fallisce, il rilascio non viene realizzato. Quando un test fallisce e' positivo: il test ha rilevato un baco! Allora e' stato scritto un buon test! Al fine di aumentare la suite di test (obiettivo) e' sono stati raccolti i seguenti dati (misurazione):
- nr. unit test
- nr. di assert
- nr. di nuovi test settimanali
Cosi' la morale e':
Definire chiaramente l'obiettivo e come si misura i progresso
Customer test
Nonostante il cliente sia quasi on-site e' molto difficile farlo testare, cosi' il team Ferrari intervista il cliente sul comportamento che dovrebbe avere l'applicazione e codifica. Nella categoria dei customer test si trovano anche i test funzionali.
No overtime
Orari d'ufficio nonostante le scadenze pressanti, tranne in rari casi di fusi orari particolari o di eventi speciali.
Come diventare agili agilmente?
Il consiglio e': fatevi guidare dal valore da consegnare all'utente :-) !
In numeri
Info varie:
- 20 sviluppatori, sw per ca. 1000 utenti (max; tutti clienti interni) in ca. 50 centri di costo
- 2 suite sw principali: TrackSuite (pista) ProductionSuite (progettazione auto)
- ca. 100 progetti on-going; ca. 10 change request al giorno
- i 20 sono in 3 sedi, due a qualche km tra loro, una in Sardegna (3 persone)
- tempi di consegna vincolati ai gran premi: ogni 15 gg, non possibili ritardi; in più un test ogni settimana
- incontri giornalieri: 30'/20 persone, ca. 1-2 minuti a testa; un altro incontro a settimana
- nessun progetto assegnato a un singolo individuo
- design: max semplificazione + leggibilità
- molto testing: build notturne con testing, un test fallito invalida il build. 10.000 unit test; 100.000 assert; 100 nuovi test/settimana, per loro questo numero è l'indice di qualità
- il team è stato "internizzato" negli ultimi anni, prima avevano esterni che andavano e venivano
- condivisione know-how di progetto: wiki, pair programming
- tutto Microsoft: C++, MFC, legacy VBasic ma non considerato un peso
Planning Legacy Code
Marco Trincardi ha condotto una sessione in cui sono state confrontate diverse esperienze relative alla gestione di codice Legacy.
La sessione si è aperta con un'eccellente definizione di codice Legacy:
- è codice per il quale sono assenti unit test o test automatici in generale;
- il codice è fortemente accoppiato e quindi fragile;
- gli sviluppatori che hanno ideato il codice non sono più disponibili.
In base a questa definizione, bisogna prendere atto che molto del codice che vediamo tutti i giorni è Legacy.
Marco ha descritto una sua significativa esperienza, nella quale sono state create numerose "storie" o "card" di refactoring. Le storie non sono però state affrontate "in blocco" su base pregiudiziale: si sono selezionate solo le storie che avrebbero avuto un significativo impatto positivo su una storia "business" collegata.
Per esempio, potrei avere una card relativa alla rimozione del codice duplicato nel package bancax.bonifico e una seconda card relativa alla duplicazione di codice nel package bancax.titoli. Se devo modificare la funzionalità di bonifico, e riducendo la duplicazione di codice faccio un intervento in un punto solo invece che in punti diversi, attivo la card relativa a bancax.bonifico. Se però la funzionalità titoli non deve essere modificata, accetto di convivere con il codice duplicato nell'ambito del package bancax.titoli.
Nel corso della discussione sono emersi diversi aspetti interessanti.
Qualcuno ha ammesso di aver praticato un "gonfiaggio" delle stime di una storia per includere le attività di refactoring relativa. Tale soluzione è certamente una tentazione, ma ha il limite di non rendere esplicito il trade-off tra i costi della fattorizzazione ed il vantaggio nel realizzare una storia di business. In altri termini, si rischia di decidere di realizzare un refactoring il cui ritorno è minore del costo.
Un aspetto che è stato evidenziato unanimamente (e che abbiamo sperimentato anche in Sinapsi) è che un utile primo passo nell'affrontare il codice legacy è la creazione di test funzionali. Si tratta di test automatici la cui granularità è però estremamente grossolana. Ciò consente di sopperire alla mancanza di test automatici facendo quanto può essere fatto senza costi eccessivi nell'ambito di un'applicazione che presenta caratteristiche di forte accoppiamento.
Nell'ambito della discussione, è stato presentato il problema della manutenzione evolutiva di una complessa applicazione interattiva sviluppata in Delphi. In tale ambito, il primo passo potrebbe essere la creazione di test automatici che simulino una serie di operazioni sulla GUI. Un test di questo tipo può fornire quel minimo di rete di sicurezza che consente di affrontare il refactoring senza troppo timore, evitando la tentazione letale di buttare via tutto e riscrivere da zero.
E' stato citato più volte il testo Working Effectively with Legacy Code (Robert C. Martin Series) di Michael Feathers...ha tutta l'aria di essere una lettura eccellente!
Le Foto
Seguendo la nostra naming convetion ;-) ringraziamo per le foto (rigorosamente in ordine lessicografico):
- Fabiob
- Gabrielel
