Agile Day Retrospective – IAD16

Ad uno sprint di distanza dallo IAD 2016 di Pavia sono qui a dedicare un po’ di tempo a fare retrospettiva. Che ne è stato dei bei propositi inseriti nel mio personale Backlog (che forse non è altro che una to-do-list ben organizzata)?

Le sessioni nell’arco delle due giornata sono state molte, e molte sono state interessanti, ma ne prendo fra tutte 3:

 

 

Riordinare il BackLog

Sicuramente uno speech molto concreto che ha già dato i suoi frutti, è stato quello di Susanna Ferrario su come mettere ordine agli impegni che come Product Owner e Development Team ci siamo presi nei confronti di clienti e utenti. Infatti Susanna oltre a spiegare che cos’è il decluttering  (il contrario di clutter, mettere in disordine) ha anche dato buone motivazioni per farlo.

 

 

Credo che il consiglio fra tutti che mi è servito è stato quello di non aver paura di buttare via le cose vecchie: se nel tuo BackLog ci sono degli elementi che stanno lì da molto tempo e vengono costantemente superati da altre attività più urgenti, è venuto il momento di disfartene.

Non aver paura di cancellare dal backlog un item che forse è solo una buona idea ma venuta nel momento sbagliato, se è veramente buona ritornerà in un futuro.

E così ho applicato i consigli direttamente al PBI del progetto che sto seguendo: cancellando PBI orfani, eliminando quelli già fatti o doppi, e spostando nel box delle idee quelli abbozzati ecco che la lista si è ridotta da 132 a 23 gustosi e valorosi items.

 

 

Chi è il Product Owner?

Perché sopra parlo di valorosi items? Perché di valore parla Alessio del Toro nel suo talk che va velocemente al punto: chi è il product owner e soprattutto qual è il suo compito primario. Qual è? Massimizzare valore…. (a me piace la versione anglosassone: deliver value che ha un’eccezione un po’ diversa in quanto il termine “deliver” porta con se un “a chi”).

A chi bisogna consegnare il “valore” da generare (oppure per chi si vuole massimizzare il valore)?

Al cliente e all’utente che ovviamente possono essere persone diverse, secondo le loro esigenze e necessità, e qui, schematizza bene Alessio, che le necessità delle persone compongono una piramide.

 

 

I 5 punti cardine dell’attività del Product Owner sono alla fine questi:

  • massimizzare il valore (deliver value)
  • avere una vision chiara (questo è ovvio per qualsiasi “condottiero”, ma va ripetuto)
  • essere la voce dei clienti (quelli che pagano per il valore consegnato)
  • gestire il Product Backlog (il valore assegnato agli items infatti permette sia di dare le priorità che gestire un decluttering efficace, vedi sopra)
  • collaborare col team e gli stakeholder (il P.O. non lavora da solo)

 

 

Programmare all’indietro ovvero: Test Driven Development

Ma tra il dire e il fare c’è di mezzo “e il” cioè: per trasformare in realtà il Backlog, bisognerà pur scrivere qualche riga di codice corretto e funzionante.

Per questo ci viene in aiuto Ferdinando Santacroce che in una sessione riesce a farmi capire come “invertire” la metodologia di programmazione: partire dai test per sviluppare un codice completo e corretto. Questo stravolge un po’ il paradigma del normale dello sviluppo (almeno per il sottoscritto).
Verso normale:

  • scrivo codice
  • scrivo il test (o per la maggioranza degli sviluppatori, provo alcuni percorsi critici nella speranza di non trovare errori)
  • se ho errori correggo il codice

Verso guidato dal test (Test-Driven Development):

  • scrivo il test
  • se va a buon fine, scrivo un altro test
  • se fallisce, scrivo il codice
  • se va a buon esito, posso fare refactoring

 

 

 

 

La prima volta che ne ho sentito parlare ho pensato che è da pazzi… poi nella sessione allo IAD Ferdinando ha mostrato una demo breve ma significativa e mi ha convinto che dovrei almeno provare. Il grande vantaggio è che tutti i percorsi vengono testati…. ma la cosa grande è che lo sviluppo diventa test-centrico. Poi è vero il mondo è pieno di software funzionanti scritti da programmatori infallibili, gli unit test sono una cazzata e la Apple è una Onlus per technopati.

Conclusione

Il mondo del software è in continuo cambiamento e lo IAD risponde all’esigenza delle aziende di maturare i processi di sviluppo del software: per questo molti speech (cui non ho partecipato) erano orientati al change management.
Andare allo IAD16 è stata un’esperienza arricchente che sicuramente ripeterò e consiglio a tutti quelli che come me amano “fare software” e lo vogliono fare bene.