Gabriele: due stili nella pianificazione dell'iterazione. Lo stile classico, velocity driven consiste nello stimare una "velocità", ovvero una quantità di punti-storia disponibili per l'iterazione, e assegnare all'iterazione tutte le storie prioritarie fino a quando la somma dei punti-storia non supera il numero di punti-storia disponibili.

Uno stile più moderno, committment driven (vedi Agile Estimating and Planning) prevede di un approcio più iterativo: prima viene definito un obiettivo dell'iterazione, obiettivo che deve portare valore al cliente, in seguito si prende la storia con la più alta priorità assegnata (priorità che viene rivista dal cliente anche in base all'obiettivo preposto), la si divide in task, i task vengono stimati, infine viene chiesto al team se inserirla all'interno dell'iterazione o meno; a questo punto se la storia viene accettata e se si ritiene vi sia ancora spazio per altre storie, si sceglie un'altra storia (ripetendo il lavoro appena fatto con la precedente), altrimenti l'iteration plan viene dichiarato finito

Siamo tornati sul tema dei task "di infrastruttura". Gabriele: ai vecchi tempi questi task, tipo "installare il database" non venivano conteggiati come tali, ora invece si tende a segnare come task anche cose tipo "scrivere gli acceptance test". Per cui abbiamo aggiunto un paio di task infrastrutturali alle storie. Vedi Testing Extreme Programming

Le storie per la nostra iterazione sono le seguenti, con associati i costi stimati in pomodori (mezz'ore). I costi sono stati stimati da ognuno, e abbiamo preso la moda (non la media) delle stime.

Elenco news (8 ore)

• Recupero dei file dal loro path, 1
• Parsing del contenuto dei file, 2
• Ordinamento cronologico news, 2
• Filtro delle news scadute, 2
• Page design, produzione html, 4
• Configurazione progetto, 1
• Acceptance test, ?

Inserimento news (10 ore)

• Validazione dati, 3
• Creazione e salvataggio file secondo formato, 2
• Page design, 4
• Acceptance test, ?

C'è stata un po' di discussione sull'uso di JSP vs. Velocity. Matteo ha obiettato che non puoi facilmente testare l'output di una pagina JSP, argomento in favore di Velocity. Giannandrea risponde che il template Jsp o Velocity comunque dovrebbe contenere quasi zero logica; tutta la logica dovrebbe andare negli oggetti di presentazione che vengono passati al template. Abbiamo quindi oggetti che se hanno un campo "data" questo campo data è di tipo stringa già formattato nella maniera voluta, non quindi di tipo java.util.Date. In qs modo posso testare agevolmente che gli oggetti di presentazione siano corretti, e il template non viene testato in quanto "too simple to break". Matteo: io non mi sento soddisfatto se non posso verificare, ad esempio, che l'output del template è XML valido.

Giannandrea ha raccontato (più in pizzeria che nel meet) che nel loro codice modellano l'applicazione web come un grafo di pagine (nodi) e azioni get o post (archi). Possono quindi testare la logica di interconnessione delle pagine senza passare per HTML. Ci dice che il sistema è molto vantaggioso per app complesse, ma un po' troppo complesso per app semplici.

Discussione sugli acceptance test. Non sappiamo con che notazione/tecnologia realizzarli. Si conclude di prevedere uno spike di 4 pomodori per la prossima iterazione. Si propone di usare inizialmente HttpUnit in JUnit, per arrivare magari a un microlinguaggio di scripting realizzato ad hoc. Rimandiamo Fitnesse a tempi futuri.

conta di più esprimere chiaramente gli AT che non la tecnologia usata. Arriviamo a definire i segg. AT

AT per elenco news:

• IF una news è presente nel sistema THEN appare nella pagina elenco
• IF ho due news THEN appaiono ordinate per data inserimento
• IF la data di scadenza di una news è passata THEN non appare nella pagina elenco

AT per Inserimento news:

• IF news inserita con dati corretti THEN presente nel sistema
• IF news presente nel sistema THEN formato file corretto
• IF news inserita con dati NON corretti THEN non presente nel sistema

Gabriele: gli AT mi danno un'ulteriore confidenza che il sistema è corretto, perché lo esercitano secondo una prospettiva differente, e poi posso usarli come "smoke test".

Alberto: no!! gli AT servono esclusivamente per dare confidenza al cliente, che stiamo sviluppando il sistema secondo i suoi requisiti. Non servono per dare maggiore confidenza agli sviluppatori. Devo poter buttar via gli AT e avere comunque tutta la confidenza che mi serve dagli UT.

domanda per Alberto: allora i tuoi UT contengono test di infrastruttura, tipo che il web server sia correttamente configurato?

Domanda: dobbiamo testare che cosa succede se inserisco un tag html nel testo di una news? Se può un responsabile di UG danneggiare involontariamente la struttura html della pagina? Si decide di rimandare a una storia successiva (anche se secondo Matteo dovrebbe essere un AT della storia elenco news.)

Gabriele suggerisce che per semplificare gli AT, assegnamo attributi semantici all'html generato. Che in parole semplici significa che il contenuto sarà etichettato con attributi "class" e "id" che identificano il significato di quello che racchiudono: ad esempio

 <div class='news' id='20060327_milanoxpug_2'>
   <p class='title'>Abbiamo le news!</p>
   <div class='text'>
     Era ora.  Quanto cavolo di tempo ci avete messo?!?
   </div>
 </div>

Gabriele promette che useremo i burndown chart mostrateci da Renzo per tracciare la nostra performance.

Non siamo riusciti a partire con lo sviluppo; per cui deleghiamo un volontario (Fabio) a svolgere da casa il primo task tecnico, che consiste nel configurare il progetto Eclipse in maniera da avere una "casa" in cui alloggiare gli altri task ed essere pronti a partire in parallelo alla prossima riunione.

Essendo ormai giunte le 20:45 aggiorniamo la serata all'ottimo ristopizzaro cinese.