Wallabiez IAD 2007
Da Sinapsi.
Contents |
AGILE DAY 2007
Il team Wallabiez di Sinapsi presenta la sua Transizione pragmaticamente agile allo IAD 2007.
A questo link potrete trovare le slides presentate dai Walabiez.
Invece di seguito un breve riassunto di alcuni degli interventi seguiti.
From Amber to Green in 4 weeks with Agile di Antonio Terreno
Antonio Terreno lavora come Application Developer in ThoughtWorks UK e ha presentato la storia di come il suo team sia riuscito ad applicare un buon numero di pratiche e principi agili per far spostare un progetto dall'orlo di un disastro ad uno strepitoso successo.
Si tratta di un progetto agile ma con contratto fixed price e con rilascio fisso. Antonio presenta un elenco delle pratiche introdotte e lo fa con delle slides sperimentali, degne di nota perchè fatte solo da fotografie e da un titolo. Nessuna parola scritta, se non quello nei suoi cartoncini delle dimensioni delle storie.
Ed ecco le pratiche utilizzate dal team di Antonio seguite da un breve commento.
Stand-Up Meeting
Tutti giorni ad un orario fisso, cioè le 9.30, il team si trova davamti alla lavagna per lo Stand-Up. E' un token rappresentato da un maialino di pezza, a decidere di chi è il turno di parlare. Chi ha il maialino può parlare, gli altri ascoltano. Una volta terminato il proprio turno, si passa il maialino al compagno, che cosi' puo' prendere la parola.
User Stories
Il team di Antonio stima le user stories utilizzando i giorni ideali. Registrano poi i giorni di lavoro effettivi e tengono traccia del rapporto tra giorni ideali e giorni effettivi.
La lavagne del team e' divisa in piu' colonne:
- analyst: dalla quale l'analista preleva le storie per stimarle. Le storie vengono messe qui dal cliente e dal manager. Le storie stimate finisco in
- dev ready: sono pronte per essere sviluppate. Quando una coppia di sviluppatori prende in carico una storia questa viene spostata in:
- work in progress: dove rimane ferma fino al completamento. Una volta terminata la storia viene spostata nella colonna
- show case: quando una storia si trova in questa colonna cliente e manager possono testarla e rimandarla indietro in caso vengano rilevati bachi o malfunzionamenti, oppure spostarla nella colonna
- dev completed: la storia e' finita e testata e pronta per il passaggio in produzione
Pair Programming
Il team di Antonio ha sperimentato sia il pair programming classico che variazioni sul tema, sviluppando sempre e comunque in pair. Alcune variazioni sperimentate:
- ping pong pairing: cambio frequente di tastiera, cioe' frequente alternarsi di driver e navigator;
- timeboxing pairing: o per noi italiani pomodoro di coppia :-) cioe' sviluppare in pair concentrandosi per un periodo limitato seguito da una breve pausa, e cosi' via. IL timeboxing si e' rilevato funzionare molto molto bene coi junior, ma non altrettanto bene col team leader. Questo perche' quest'ultimo e' una persona in grado di mantenere alta concentrazione per molto tempo, e il timeboxing spezzava il suo ritmo.
Test Driven Development
Anche in questo caso il team di Antonio ha adottato il TDD classico ove possibile, alternando al Test First. Poiche' il software e' stato sviluppato in ambiente Windows il suo team si e' avvalso della tecnologia ALT.NET
Per testare il layer di presentazione sono stati utilizzati mock objects.
Oltre ai test unitari hanno anche i test di integrazione.
Continous Integration
I test di integrazione girano sulla macchina di integrazione continua con Cruise Control. Il codice viene caricato su questa macchina e solo dopo aver passato i test di integrazione viene committato sul repository.
E' Homer Simpson con un "Mitico" a segnalare la build andata a buon fine; e' invece un "Doh" a segnalare una buil rotta. Chi rompe la build si preoccupa di ripararla.
Spikes
Tutti gli spikes sono storie e sono stimati.
Heartbeat Retrospective
Ad inizio progetto il team di Antonio aveva una retrospettiva settimanale. Con l'avanzare del progetto nelle retrospettive settimanali mancava contenuto, cosi' il team ha deciso di farle bi-settimanali. La frequenza si e' poi ridotta ulteriormente fino ad arrivare ad una mensile. Ora il team si incontra per la retrospettiva una volta ogni due settimane.
A queste retrospettive si aggiungono quelle di release e quella di fine progetto.
Per far in modo che le retrospettive siano sempre interessanti e ricche di contenuti, Antonio consiglia di cambiare spesso stile e giochi.
Customer Availability
Il cliente era poco on-site ma molto al telefono :-) : disponibile praticamente sempre nonostante la distanza.
Tuning
Serve a ragionare sul perche' si fa cosi' .
Set Design
Il team di Antonio ha modificato liberamente il design del'intera applicazione grazie ai test scritti.
A un certo punto dell'evoluzione del loro software e' stato necessario rivoluzionare l'architettura per poter permettere al software di continuare a crescere e ad evolvere. Antonio racconta che in quei giorni Martin Fowler passava di li' e che in un'ora ha inquadrato il problema e trovato la soluzione. Soluzione che il team ha implementato in una settimana e che ha permesso al software di continuare a crescere e ad evolvere.
Removing technical and process waste
La segnalazione dei rifiuti nel software o nel processo di sviluppo viene fatta tramite la waste box: una scatola di cartone nella tutti i membri del team possono inserire segnalazione inerenti frustrazioni o technical death. Entrambe da eliminare!
Qualche conclusione
Sull'esperienza in questo team Antonio trae poi delle conclusioni:
- quando si vuole cambiare il team deve affrontare coeso il cambiamento: in caso contrario potrebbe spezzarsi qualcosa;
- l'umore deve essere tenuto alto ed e' necessario pensare che ce la si puo' sempre fare;
- la velocita' del team varia e non in maniera lineare;
- bisogna essere pragmatici;
- dare vita alle nuove idee provandole;
- tenere basso il costo del proceso;
- i problemi vanno rimossi. E' necessario capire quali sono, dove sono, come si rimuovono e che non sono le persone il problema
Come ridurre all'obbedienza il codice ereditato di Tommaso Torti e Matteo Vaccari
Tommaso e Matteo raccontano la loro esperienza con il porting di un progetto ereditato e ci dicono che' e' importantissimo chiedersi il perche' le cose sono state realizzate in un determinato modo. Poi consigliano un metodo per procedere accompagnato da un testo.
Il metodo e':
- trova il punto da modificare
- rompi le dipendenze
- scrivi i test
- modifica
Il libro e': Working Effectively with Legacy Code di Micheal C. Feathers.
