PMI-ACP Approfondimenti
Agile User Stories
“Preparazione Esame di Certificazione Agile PMI-ACP®”
Per consultare questi approfondimenti, devi essere almeno registrato al sito (Registrati se non lo sei già)
Le “User Stories” sono descrizioni sintetiche degli utenti, in attesa di essere eseguite dal team di sviluppo che utilizzerà una metodologia Agile ed in particolare la tecnica Scrum.
Su un progetto Agile/SCRUM incontriamo le seguenti figure:
- Product Owner
- Scrum Master
- Team di sviluppo
- Scrum Architect.
Le “User Stories” alimentano il Backlog di Prodotto al quale attinge il team di sviluppo, estraendo le user story che andranno a costituire il backlog del prossimo Sprint (prossima iterazione).
Scrum Master e Scrum Architect verificano l’utilizzo appropriato dei processi Scrum e l’aderenza alle architetture disponibili.
Ogni membro del team di sviluppo, ogni giorno, in una breve riunione, risponde alle seguenti domande:
- Cosa hai fatto ieri?
- Cosa farai oggi?
- Quali ostacoli vedi nel tuo lavoro?
Ogni user story viene lavorata, dopo essere stata pienamente compresa e stimata con la tecnica Agile: Planning Poker, un modo divertente per creare consenso sulle stime da proporre.
Come nasce una storia
La scrittura di una “Story” deve tenere presente per chi viene scritta. L’utente non può comunicare solo con il suo linguaggio, ma deve sforzarsi di considerare che la story dovrà essere compresa e valutata da più punti di vista.
- lo sponsor ha in mente solo il valore di business di una soluzione. Non ha nessuna voglia di farsi coinvolgere in aspetti tecnici del prodotto. Vuole capire subito la bontà della soluzione e il vantaggio economico che ne potrà trarre.
- lo sviluppatore ha in mente l’architettura software sulla quale dovrà realizzare il processo che richiede la story. Non sa che farsene di descrizioni vaghe, ha bisogno di affermazioni ben determinate in modo da poter effettuare delle scelte.
Ad esempio ci si può trovare di fronte all’affermazione a proposito di un sito web che deve mostrare qualcosa sulle sue pagine:
“Vorrei dei bottoni sulle pagine del sito, in modo che quando io vi clicco sopra il possessore del sito guadagni in pubblicità e continui a finanziarlo.”
Sarà vero, ma forse sarebbe preferibile che la story dicesse:
“Come proprietario del sito, vorrei aggiungere dei bottoni su tutte le pagine web, in modo da guadagnare in pubblicità quando i visitatori vi cliccano sopra.”
Apparentemente le due definizione dicono la stessa cosa, ma la seconda è molto più chiara. in effetti, le storie devono essere semplici e chiare.
L’utente ha un ruolo determinante nella stesura delle storie, anche se nelle iterazioni successive avrà la possibilità di essere più preciso. Non dobbiamo confondere la ricchezza di dettagli con l’esigenza di chiarezza. Non è aggiungendo un altro dettagli che si guadagna in chiarezza.
Nelle iterazioni Agile bisogna pensare in termini di valore di business.
Se l’utente non è in grado di esprimere una storia a livello di sistema, dovrà farlo lo sviluppatore. Prima di lavorare la storia, la dovrà normalizzare per poterla adattare al sistema che sta costruendo.
Conviene anche all’utente essere chiaro e diretto, in modo che lo sviluppatore non abbia bisogno di porre altre domande prima di selezionare la sua “User Story” per il prossimo Sprint, finendo con l’assegnare la priorità sempre alle storie più chiare.
User Stories, Epics e Themes secondo Mike Cohn
A user story is simply something a user wants. User stories are more than just text written on an index card but for our purposes here, just think of user story as a bit of text saying something like, “Paginate the monthly sales report” or, “Change tax calculations on invoices.” Many teams have learned the benefits of writing user stories in the form of: “As a I so that .” But it is not necessary that a user story be written that way.
A Scrum epic is a large user story. There’s no magic threshold at which we call a particular story an epic. It just means “big user story.” I like to think of this in relation to movies. If I tell you a particular movie was an “action-adventure movie” that tells you something about the movie. There’s probably some car chases, probably some shooting, and so on. It tells you this even though there is no universal definition that we’ve agreed to follow, and that an action-adventure movie must contain at least three car chases, at least 45 bullets must be shot, and …. So, “epic” is just a label we apply to a large story. Calling a story an epic can sometimes convey additional meaning. Suppose you ask me if I had time yesterday to write the user stories about the monthly reporting part of the system. “Yes,” I reply, “but they are mostly epics.” That tells you that while I did write them, I didn’t get the chance to break most of them down into stories that are probably small enough to implement directly.
Finally, “theme” is a collection of user stories. We could put a rubber band around that group of stories I wrote about monthly reporting and we’d call that a “theme.” Sometimes it’s helpful to think about a group of stories so we have a term for that. Sticking with the movie analogy above, in my DVD rack I have filed the James Bond movies together. They are a theme or grouping.
Modulo di Iscrizione
Modulo di Comunicazione
