Sviluppo Agile

Due giorni di sviluppo agile – Seconda parte

Proseguo il racconto che ho iniziato qui, dove avevamo visto l’avvio di un progetto di sviluppo adottando pratiche tipiche dell’extreme programming. Arrivati ad avere un backlog ben definito e distillato col forte contributo degli utenti esperti di dominio, vediamo ora la fase di release planning.

Release planning

In questa foto Francesco e Michele ragionano in coppia sulla assegnazione di alcune user story a ciascuna iterazione prevista dal release planning.

Chiaramente la pianificazione è fatta con un grado di approssimazione via via decrescente rispetto a quanto l’iterazione si trovi avanti nel futuro. Solo il planning eseguito all’inizio di ogni singola iterazione assicurerà l’esatta assegnazione user story – iterazione.

La project velocity stimata ci ha permesso di valutare quanti story points includere in ogni iterazione, perlomeno con quella che speriamo si rivelerà una buona approssimazione. Sulla tecnica utilizzata per stimare la project velocity in assenza di dati storici relativi a questo progetto e a questo team scriverò presto un post a parte…

Release planning remoto

Una significativa porzione del release planning è stata basata sulle importanti valutazioni di impegno di Alberto, il nostro esperto di User Experience. Lo sviluppo dei wireframe necessari alla definizione delle effettive features da implementare nel corso delle iterazioni è infatti un’attività che abbiamo deciso di includere nel computo del tempo e delle propedeuticità di sviluppo, di fatto rendendo agile anche il processo sottostante il concepimento della user experience.

Essendo Alberto già partito alla volta di casa, abbiamo allestito un piccolo apparato di telepresenza che ci ha permessi di lavorare perfettamente, condividendo voci, immagini, file, web e lavagne senza limitazione alcuna, come mostrato nelle due foto qui sotto.

L’approccio che abbiamo deciso di adottare è consistito nel considerare aspetti critici il design dell’interfaccia utente insieme alla realizzazione epicentrica delle features. Essendo l’applicazione fortemente orientata ai dati, le considerazioni di usabilità sono state ritenute essenziali fin dalle prime fasi del progetto – motivo in più per avere Alberto con noi raccogliendo le user story.

Inoltre, ritenendo particolarmente rischiosi i compiti di Alberto, abbiamo deciso di anticipare alle prime iterazioni le user story che lo coinvolgevano di più, ritenendo addirittura percentualmente minoritario l’apporto degli sviluppatori nella prima iterazione – ipotizzando un rapporto sviluppo/design pari a 30/70 del tempo disponibile.

Release plan

Qui un soddisfatto Michele – ti assicuro che la faccia che sta facendo è proprio quella – osserva il frutto di due intense giornate di lavoro.

Ti voglio far notare che per ogni iterazione è riportato il numero di story points che – allo stato attuale di conoscenza – stimiamo di riuscire ad evadere e anche che le prime due iterazioni sono marcate con bordo doppio poiché ritenute stimate in modo più affidabile delle successive.

Nonostante all’occhio profano dei foglietti attaccati ad una lavagna bianca possano sembrare ben poco risultato per due giornate di lavoro di un gruppo di professionisti, questo insieme di oggetti concreti è il punto finale di una descrizione sintetica, condivisa e completa di almeno due degli aspetti più difficili da trattare nell’ingegneria del software:

1. i requisiti
2. la pianificazione del lavoro

A te sembra poco?

Ciao, alla prossima!

July 21 2008 12:00 am | Dalle trincee

7 Responses to “Due giorni di sviluppo agile – Seconda parte”

1. Due giorni di sviluppo agile - Prima parte | Sviluppo Agile on 21 Jul 2008 at 00:27 #

   [...] A prestissimo per il seguito! [...]

2. Daniel on 21 Jul 2008 at 18:03 #

   Ciao Jacopo, alcune precisazioni sulle iterazioni individuate. Il numero di story points è la somma dei punteggi associati ad ogni story durante il planning game? Inoltre l’identificazione dell’iterazione è basata sulla criticità delle singole user story raggruppandole magari per “vicinanza” nella struttura generale? Conclusa l’iterazione viene rilasciata la parte realizzata per avere subito feedback dal cliente ed eventualmente correggere subito il tiro prima che sia troppo tardi?

   Grazie
   Daniel

3. Jacopo Romei on 22 Jul 2008 at 02:07 #

   Ciao Daniel,

   sì, il valore indicato per ogni iterazione è dato dalla somma delle user story a quella associate.

   L’assegnazione delle user story alle prime iterazioni è regolata da diversi criteri; per esempio si anticipano le storie più critiche o rischiose, o quelle che introducono più know-how nel team… Sicuramente si cerca di non accorpare troppe storie legate allo stesso aspetto dell’applicazione, per ottenere un feedback più ’sparso’ sull’andamento dello sviluppo man mano che si procede…
   Inoltre, se e quando si può, io preferisco anticipare le user story che daranno un buon feedback al cliente, sempre avido di nuove sensazioni , il che risponde al tuo ultimo dubbio.

   Sommario, ma spero chiaro nella sua superficialità. Non esitare a fare ulteriori commenti, ciao!

4. Daniel on 25 Jul 2008 at 11:03 #

   Ottimo, molto chiara la tua risposta. Sull’anticipazione del critico sono pienamente d’accordo visto che permette subito di capire dove si sta andando; interessante invece l’ordine sparso per saggiare un po’ tutti gli aspetti dello sviluppo.

   Grazie
   Daniel

5. Jacopo Romei on 25 Jul 2008 at 12:37 #

   Daniel, dimenticavo:
   http://www.sviluppoagile.it/user-story-e-task-adatti-al-planning-game

6. Daniel on 25 Jul 2008 at 16:28 #

   Si si avevo già letto a suo tempo, sono iscritto al feed dal giorno dopo il workshop al PHPDay

7. User-Centered Design e Sviluppo Agile: l’inizio di un progetto - Alberto Mucignat on 24 Nov 2008 at 20:55 #

   [...] ha dettagliatamente descritto i primi due giorni di lavoro con il team e gli [...]

Trackback URI | Comments RSS

Leave a Reply

Name (required)

Mail (hidden) (required)

Website

Avvisami dei prossimi commenti via e-mail