| 
  • If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • You already know Dokkio is an AI-powered assistant to organize & manage your digital files & messages. Very soon, Dokkio will support Outlook as well as One Drive. Check it out today!

View
 

ReportMeet2

Page history last edited by PBworks 18 years ago

Tema della serata: scrivere le storie per il progetto UgAggregator

 


 

Cosa s'intende per Storia-UserStory-Carta

Una mini bibliografia dei temi della serata

 

Il Proxy ci ha spiegato cosa UG-Aggregator deve fare

Qualche esempio di storia su mezzo foglio A4

Quale dev'essere il formato della carta?

Qualcuno del gruppo che ha avuto esperienze precedenti nell'utilizzo e nella scrittura delle UserStories ha commentato sulla dimensione dei cartoncini preparati da Renzo, tutti erano concordi considerandoli troppo grandi (mezzo foglio A4) e che sarebbe stato piu' opportuno dividerli ulteriormente, non tanto per la dimensione in se, ma piu' che altro per non invogliare le persone a scrivere troppo. Renzo ha spiegato che il formato da lui scelto e da lui utilizzato gli permette di scrivere le storie con un pennarello e quindi di renderle visibili da lontano.

 

Una mia fissa è la bella scrittura... non so cosa ne pensino Beck e soci, ma a me piace vedere le storie scritte in maniera leggibile e ordinata piuttosto che scarabocchiate velocemente. -- Matteo

 

Ognuno scriva le proprie storie riascoltando il Proxy

Ci sono storie e storie. Cosa scrivere?

Durante la serata sono emerse le caratteristiche che deve avere una carta:

  • Dare valore al cliente. Quindi puo' andare bene una carta del tipo 'Il responsabile di un gruppo deve poter inserire una news' mentre non avrebbe molto senso una carta come 'Il sistema deve utilizzare un pool di connessione al db'
  • Individuare una precisa funzionalita'. E' meglio se si indicano azioni del tipo Inserire/Modificare/Cancellare/Ordinare piuttosto che Gestire/Controllare o simili che lasciano molta indeterminazione
  • Utilizzare un lessico comune tra sviluppatori e customer. E' importante che i termini utilizzati nello scrivere le carte (ma anche nel parlare, naturalmente) sia condiviso ed accettato tra sviluppatori e customer. A questo proposito Gabriele ha parlato della sua esperienza che consiste nell'utilizzare un wiki per mantenere un dizionario dei termini specifici del progetto, in modo da creare un PatternLanguage condiviso fra sviluppatori e cliente, nella sua esperienza questa pratica ha migliorato alcuni aspetti comunicativi, sia fra i componenti del team, sia fra il team e l'esterno

 

Contatto telefonico col cliente

Dopo esserci confrontati abbiamo scelto le storie che dovevano essere presentate al cliente, le abbiamo scritte, e Renzo ha chiamato Francesco al telefono. Il nostro cliente si e' dimostrato particolarmente disponibile, ha ascoltato le storie, e ci ha confermato il fatto che le funzionalita' chiave erano state catturate, ma il pubblico esigeva qualcosa di piu', eravamo tutti ansiosi di sapere se "tecnicamente" avevamo fatto un buon lavoro o meno, allora Francesco ha tolto il cappello da cliente e indossando il cappello da tecnico ci ha dato un paio di consigli

  • Considerare la storia come un titolo. Ovvero le storie dovrebbero avere la lunghezza e l'incisivita' di un titolo
  • Aggiungere una descrizione narrativa alla storia. La descrizione dovrebbe descrivere in maniera piu' dinamica l'interazione con il sistema, nonche' il luogo naturale per contenere i dettagli tipo: come e' formata una news? Quali sono i dati che caratterizzano un gruppo? ecc...
  • Aggregare le funzionalita' in un piccolo numero di storie. In particolare e' stata commentata una delle storie che avevamo inserito: 'Le news dopo la data di scadenza non devono essere piu' essere visualizzate', Francesco non l'ha ritenuta una storia valida, ma piuttosto un AcceptanceTest di un'altra storia: 'Un utente puo' vedere le news di tutti i gruppi'. Il consiglio e' stato quello di considerare solo le funzionalita' di altissimo livello come UserStories (come la visualizzazione delle news), e di includere tutti i dettagli nella parte descrittiva oppure di segnalarli come AcceptanceTest. Questo ci consentira' di avere all'inizio un quadro piu' compatto della situazione lasciandoci la possibilita' di poter Splittare le storie piu' avanti.

 

Sempre parlando col cappellino del coach XP, Francesco ha suggerito che "non mostrare le storie scadute" potrebbe essere un task tecnico associato alla storia. Cioè, il team potrebbe, nel momento in cui affronta la storia "Pagina News", spezzarla in un numero di task tecnici, ad esempio "faccio una pagina che mostra tutte le news", "mostro le news in ordine cronologico", "non mostro le news scadute". La suddivisione in task è interna al team di sviluppo e non coinvolge il cliente; questi task possono sì essere di natura tecnica (es., "creo un task di ant per installare l'applicazione", "installo mysql")

 

REK - Real Extreme Kebab (tm)

Abbiamo continuato la discussione di fronte al REK, il vero extreme Kebab. Sono volati aneddoti informatici di rara vena artistica e qualche inevitabile confronto fra Java e Ruby. I 10 sopravvissuti dell'extreme kebab li potete vedere qui sotto.

 

L'allegra tavolata

 

Sulla sinistra: Matteo, Alberto, Mattia, Marco; sulla destra Tommaso, Silvano, Giannandrea, Simone, Gabriele. Renzo non appare perché sta scattando :)

 

The REK, Real Extreme Kebab (tm)

Comments (0)

You don't have permission to comment on this page.