Agile Day – Result day

Raccolgo l’invito di Tommaso a pubblicare successi ed insuccessi conseguiti dall’Agile Day (21 Novembre 2008 ) ad oggi.

Design emergente, non è mitologia, negli ultimi mesi siamo riusciti nell’impresa di trasformare una situazione in cui implementare una nuova storia costava molto, ai limiti di un’iterazione di 2 settimane, a quella attuale in cui per storie della stessa complessità servono pochi giorni (2 o meno), tutto questo è stato raggiunto tramite:

  • l’introduzione delle “Quick design session” come le chiama Matteo o “Iteration Planning” come me lo ha insegnato Paolo (Polce) e Gerri (Bascianelli), impagabili (ex)colleghi.
  • Il confronto, a momenti anche teso, con il team, sul design corrente e lo studio collettivo che ha permesso a tutti di uniformare conoscenze, terminologie.
  • Non cedere alla tentazione dei “Big refactoring” ma la ricerca continua del più piccolo passo possibile per poter committare.
  • l’applicazione dei principi di design (S.O.L.I.D.) più o meno conscia.
  • Con la regola del “Boy Scout” ovvero lascia il codice più pulito di quando ci sei entrato

Fertig ist Fertig l’articolo ce lo ha fatto leggere il nostro coach ed è stata una lezione dura da imparare.
La storia: fino a un paio di mesi fa, consideravamo (noi e il cliente) chiuse le carte quando le stesse venivano verificate sui server di Sviluppo (il processo prevede Sviluppo->Test->Pre-Produzione->Produzione), solo perchè non avevamo mai “osato” di chiedere di andare in TEST… figurati in PRE.
Il risultato è stato che, quando il progetto è stato ad un buon punto dello sviluppo, il cliente ha iniziato a verificare tutte le carte in TEST e.. magia…. son saltati fuori mille problemi e problemi che di fatto hanno riaperto molte delle carte fino ad allora consegnate Non contenti, al passaggio in PRE, è saltato fuori un problema di performance che abbiamo risolto con un cambio architetturale.
Alla fine ci è andata bene perchè il Design a quel punto era già “emerso” e quindi il cambio è stato assolto con un refactoring durato un paio di giorni (con molti commit intermedi😉 )
Le lezioni che ho, abbiamo imparato sono state:

  • una carta è finita solo quando è accettata in PRE.
  • che dobbiamo tenere costantemente aperto il dialogo con il team del cliente che conosce a menadito il loro sistema.

A

Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...