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

  • Stop wasting time looking for files and revisions. Connect your Gmail, DriveDropbox, and Slack accounts and in less than 2 minutes, Dokkio will automatically organize all your file attachments. Learn more and claim your free account.

View
 

ReportMeet3

Page history last edited by PBworks 14 years, 6 months ago

Terzo meet, terza sede! Questa volta eravamo in D&T, in una sala corsi attrezzatissima. Non ho contato esattamente i presenti, ma credo fossimo una quindicina. E i soliti 10 temerari hanno anche affrontato l'extreme-ristorante-cinese. La serata e' stata come sempre registrata e divisa in due parti per praticita': e' disponibile il video e l'audio della prima parte e video e l'audio della seconda.

Tema della serata: stima delle storie per il nostro progetto

 


 

Quanto dev'essere grande una storia?

Una storia potrebbe essere stata creata o troppo grande o troppo piccola. Troppo grande significa non poterla inserire perfettamente all'interno di un'iterazione ed anche che sara' piu' difficile da stimare perche' racchiude troppi requisiti. Troppo piccola significa essere piu' precisi nella stima ma anche scendere ad un livello di dettaglio troppo fine, dove i particolari tecnici e di design emergono con troppa evidenza rischiando poi di diventare obsoleti non appena il team si addentra nelle prime storie dove il "vero" design emerge dallo sviluppo.

 

La lunghezza di un'iterazione

Il nostro team affronta un caso particolare. Abbiamo a disposizione 4 ore al mese in confronto alle 40x4 ore medie mensili di un classico team di lavoro. Significa che per noi una settimana di lavoro dura 10 mesi circa, ed anche se paralelizziamo su piu' coppie rischiamo di scordarci quello che stiamo facendo dato che il tutto e' partito mesi prima.

 

Abbiamo pensato di provare un'iterazione molto piu' corta, nell'ordine delle 4 ore e di considerarla come un espediente per lavorare in scala. Questo porta altre conseguenze, come quella di avere delle storie particolarmente corte che possano rientrare in iterazioni da 4 ore. In pratica le nostre storie diventeranno i tasks e cercheremo di pianificare quelli nel planning game al posto delle classiche storie XP. Faremo di tutto comunque per ricordare tutte le volte che e' possibile che stiamo ragionando in scala e quale sarebbe invece l'iter regolare se il team fosse un team reale da 40 ore alla settimana.

 

Come stimare una storia?

Data la specifica della storia, devo cercare quali sono i passi logici (e macroscopici) necessari al sistema software per portarla a termine. In definitiva il processo si riduce a cercare blocchi coerenti di responsabilita' in cui il sistema potrebbe essere suddiviso per implementare la funzionalita' richiesta. Ad esempio "Elenco delle News" potrebbe essere implementata pensando cosa e' necessario per portare i contenuti salvati come file con un certo formalismo ad una pagina html adeguatamente formattata. Potrebbe servire:

  • un componente che sa interfacciarsi al file system per recuperare i file dal loro path
  • un componente che sappia interpretarne il contenuto
  • un componente in grado di ordinare e filtrare le news che sa come gestire i giorni del calendario e la data di sistema
  • un componente di disegno della pagina che sa come renderizzare oggetti in html

 

L'elenco precedente e' uno delle possibili suddivisioni dell'applicazione in nuclei di responsabilita' coerenti, ognuno col suo scopo delineato. Altri ce ne potrebbero essere, ma lo scopo non e' censirli ma trovarne uno di comune accordo ed utilizzarlo per la stima. Facendo mentalmente un ragionamento come il precedente per tutte le storie sto, di fatto, suddividendo la storia principale in una serie di miniprogetti coerenti, ognuno con la propria interfaccia e responsabilita'. Questo processo e' necessario solo se no ho esperienza di una storia simile, caso in cui potrei semplicemente basarmi sulla stima gia' fatta fidandomi che sara' sufficiente per la stima.

 

I precedenti "passi" potranno coincidere o meno con i task di sviluppo. Non e' importante a questo livello arrivare al processo di sviluppo vero e proprio, cosa che sara' fatta all'inizio dell'iterazione. L'iportante e' poter stimare la storia.

 

I test di accettazione, devono rientrare nella stima?

 

Mi pare che il consenso fosse che sì, il lavoro totale per terminare una storia deve comprendere il lavoro di scrivere i test di accettazione. C'è stata la domanda "ma i test di accettazione, servono solo al cliente o li usa anche lo sviluppatore per supportare il proprio lavoro? La risposta di Giannandrea (con il cappellino dell'esperto XPer) è stata che sì, in teoria lo sviluppatore non ha bisogno dei test di accettazione perché ha fatto programmer test che coprono tutto; ma in pratica scrivere test ha un costo, per cui i test di accettazione vengono fatti girare spesso anche dallo sviluppatore.'

 

Ore, giorni, pomodori, punti...

Che unita' di misura usare per stimare una storia? Sono state vagliate due possibilità, quella di basarci su un'unità di tempo e quella di basarci su un'unita di misura della complessità. Giannandrea ha consigliato il gruppo di utilizzare un'unità di tempo in quanto risulta molto più semplice per un team neonato come il nostro, mentre invece la stima basata sulla complessità viene utilizzata maggiormente da quei team che hanno una storia di sviluppo alle spalle, per i quali la stima per confronto risulta molto più semplice

 

La stima di una storia, influisce sulla stima delle altre?

Ci siamo chiesti se storie che in un qualche modo hanno dipendenze debbano influire sulla stima. Ad esempio: la prima storia, nella quale c'e' molta attivita' di startup (infrastruttura di progetto), dovra' essere piu' lunga perche' devo inserire i tempi di startup? Oppure va valutata per il suo esclusivo contenuto di business? Un altro esempio e' quello di una storia per ogni report di un ipotetico software di reportistica da sviluppare. Ovviamente il primo report portera' al sistema tutta l'infrastruttura per gli altri. Le storie per gli altri report saranno piu' corte?

 

Sono stati discussi alcuni approci alternativi

  • Le storie possono essere splittate in modo da renderle indipendenti
  • Le storie possono essere in un primo momento stimate in modo tale che ognuna di esse inglobi equamente una parte del lavoro architetturale necessario per la loro realizzazione. Sicuramente all'inizio la velocità del team sarà inferiore, ma resta comunque possibile introdurre in maniera incrementale la parte architetturale delle storie, facendola emergere di storia in storia
  • Le storie possono essere in un primo momento stimate in modo tale che ognuna di esse inglobi tutto il lavoro architetturale necessario, nell'iterazione successiva sara' sempre possibile rivedere la stima delle storie alla luce delle facilitazioni create nell'iterazione precedente, oppure le stime possono essere lasciate come sono confidando nel fatto che la velocità del team aumenterà nell'iterazione successiva
  • Quando il team prevede che nella successiva iterazione ci sara' parecchio lavoro architetturale potrebbe decidere di abbassare volontariamente la velocità prevista, in modo da potersi occupare dei task necessari per la creazione della parte architetturale
  • Splittare le storie in modo da isolare il lavoro architetturale in una storia a parte, associando però alla storia un "bonus" che consiste in un aumento della velocità del team per le prossime iterazioni. La strada più semplice infatti sarebbe quella di isolare i task architetturali in una storia a parte, ma questo impedirebbe al cliente di poter valutare il valore della storia, in questo modo invece, promettendo una maggior velocità e quindi maggior valore per unità di tempo, la storia può essere stimata dal cliente. Questo approcio risulta particolarmente utile quando il team capisce che un determinato task architetturale potrebbe portare grandi benefici alla produttività del team stesso

 

Tutti questi approci tentano di affrontare il problema mantenente le buone proprietà che dovrebbe esibire una storia

 

Indipendenza delle storie

 

C'è stato questo dubbio: come faccio a comprendere nella storia "inserimento news" ll costo dell'autenticazione, se non ho ancora sviluppato una storia su "inserimento responsabili"? Cioè, se non ho ancora un meccanismo per inserire il responsabile del UG di Milano, come faccio a autenticarlo? Giannandrea (con il cappellino del proxy cliente) ha detto che Francesco (con il cappellino di quello che la sa lunga) ha suggerito di cablare nell'applicazione login e password dell'amministratore e login e password del responsabile di un UG. In questo modo, si può sviluppare l'inserimento news prima dell'inserimento responsabili, in base alle priorità stabilite dal cliente.

 

In generale, pare che ci sia un sotterraneo timore da parte del cliente che noi dell'UG ci perdiamo a definire schemi XML o altre complessità fuori luogo. Il consiglio è sempre "keep it simple!!!"

Comments (0)

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