Wallabiez IAD 2007

Da Sinapsi.

Jump to: navigation, search

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:

  1. 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
  2. dev ready: sono pronte per essere sviluppate. Quando una coppia di sviluppatori prende in carico una storia questa viene spostata in:
  3. work in progress: dove rimane ferma fino al completamento. Una volta terminata la storia viene spostata nella colonna
  4. 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
  5. 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:

  1. ping pong pairing: cambio frequente di tastiera, cioe' frequente alternarsi di driver e navigator;
  2. 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.

Rompere le dipendenze

Views
Personal tools