User Story - Test Intermedi_ PDF

**User Story** Focalizziamo la nostra attenzione adesso, sul fatto che nel Framework Scrum alcune tecniche creative incentrate sul cliente, come la mappatura delle storie utente, sono utilizzate per guidare e mettere in pratica la Metodologie di sviluppo Agile. Un rischio che deriva dallo sviluppo...

**User Story** Focalizziamo la nostra attenzione adesso, sul fatto che nel Framework Scrum alcune tecniche creative incentrate sul cliente, come la mappatura delle storie utente, sono utilizzate per guidare e mettere in pratica la Metodologie di sviluppo Agile. Un rischio che deriva dallo sviluppo di software è che gli utenti finali riscontrano un valore limitato nella funzionalità sviluppata. Ma c\'è una risposta semplice a questo dilemma: scrivere user story efficaci prima dell\'inizio dello sviluppo. L\'applicazione pratica delle user story fornisce un framework per identificare il valore dell\'utente sollecitando le conversazioni nel corso del ciclo di vita della creazione del software. Andiamo a scoprire insieme ciò che una user story è e non è; come scrivere una user story efficace e l\'importanza della Mappatura delle User Story. Prima di procedere ricordiamoci però che l\'Empatia è fondamentale per il processo di sviluppo di user story e anche se molti sostengono che sia più facile sviluppare un elenco di requisiti, i vantaggi di prendersi il tempo necessario per comprendere il tuo utente sono essenziali per fornire un valore reale. ***Cosa sono quindi le User Story?*** Le User Story sono emerse di conseguenza alla necessità di Extreme Programming (XP), Kanban e Scrum di suddividere i progetti in segmenti più piccoli e incrementali per sprint e iterazioni. Differiscono dai casi d\'uso in quanto si concentrano sulle unità di lavoro più piccole possibili. I casi d\'uso, originariamente introdotti da Ivar Jacobson, possono essere creati da diverse storie basate su un tema comune. Le user story sono semplici narrazioni che delineano un\'unica aspettativa o obiettivo dell\'utente. È possibile suddividere la creazione di una user story in tre fasi: 1. Descrizione della necessità. 2. Pianificazione dell\'iterazione. 3. Implementazione e verifica del completamento della storia. In ogni fase, la User Story può essere perfezionata. Le User Story non contengono un elenco di requisiti o istruzioni di codifica, ma verranno associate ai criteri di accettazione o test. L\'obiettivo di una user story non è concentrarsi su come costruire, tuttavia. L\'attenzione è piuttosto rivolta a chi vuole la funzione, ciò che farà e sul perché è importante. Le user story apportano un elemento umano alle caratteristiche che alla fine compongono l\'elenco di cose da fare. **Ma Chi scrive la User Story?** I proprietari dei prodotti, le parti interessate, i product manager e altri membri del team aziendale partecipano alla scrittura delle user story. Molti dicono, tuttavia, che chi scrive è meno importante di chi partecipa alle discussioni e alle conversazioni che danno vita alle user story. Inizia identificando chi utilizzerà la funzione (la *persona*), che può essere dettagliata in base alle necessità. L\'utente può essere definito in termini di funzione o descrizione del lavoro, come studente, frequentatore o responsabile marketing. Avere una forte comprensione degli utenti finali limita i pregiudizi o le ipotesi degli sviluppatori. Se gli utenti sono disponibili, possono partecipare, ma spesso il team ha progettisti, manager, scrittori e altri che agiscono come proxy dei clienti. I partecipanti possono variare in base all\'utilizzo della user story. Per esempio: - **Creazione della user story: **i partecipanti possono includere clienti, gestione del prodotto, tecnici e altre parti interessate quali le risorse umane, la contabilità e il reparto vendite. - **Manutenzione della user story:** i partecipanti includono la gestione del prodotto o il proprietario del prodotto. - **Applicazione e utilizzo di user story:** i partecipanti includono ingegneri/sviluppatori, scrittori tecnici e tester di garanzia della qualità. **Come scrivere User Story efficaci** Le User Story sono dichiarazioni semplici e utili di una riga su una funzione di valore. Prima di scrivere la user story, conducete sondaggi e interviste con gli utenti per chiedere il loro parere sulla funzionalità necessaria. Iniziate scrivendo un percorso cliente, dichiarato in storie incrementali, su cartellini da 3x5 pollici o post-it. Questi cartellini possono essere inseriti immediatamente nella produzione o fornire un contesto per il backlog. Nel caso della Mappatura di User Story, che vedremo fra poco, potete visualizzare i post-it lungo una parete della sala conferenze, in modo che l\'intero team possa osservarli e lavorare alla pianificazione a lungo termine. Esistono alcune tecniche da utilizzare per aiutare a scrivere le user story di cui hai bisogno. Una tecnica comune è la struttura Role-Feature-Reason o Benefit (RGB), che si costruisce riempiendo gli spazi vuoti di questa frase: - In qualità di (utente/persona/cliente), voglio (fare qualcosa), in modo da (beneficio ricevuto). Aggiungere la domanda RGB è un metodo pionieristico di Ron Jeffries che evidenzia il suo \"approccio delle tre C\": - **Cartellino: **scrivi la risposta alla domanda RGB (descritta sopra) sul cartellino. - **Conversazione: **i dettagli limitati sul cartellino sono la base di una promesse soddisfatta dalla secondo C. Durante questa fase, il team discute dei dettagli e stabilisce una definizione di \"fatto\". - **Conferma:** è il risultato del feedback che determina i criteri di test o accettazione. Questo criterio di accettazione è spesso scritto sulla parte posteriore del cartellino e viene utilizzato come checklist iniziale durante i meeting futuri per determinare il completamento. Introdotto originariamente in un articolo di Bill Wake nel 2003 e diffuso dal libro di Mike Cohn, *User Story Applied for Agile Software Development*, l\'acronimo INVEST rappresenta un metodo di valutazione delle user story. I criteri INVEST sono i seguenti:    - **Indipendenza** per poter sviluppare in qualsiasi sequenza. - Capacità di **Negoziare** la portata della storia da sviluppare. - Fornire **Valore** all\'utente o all\'azienda.   - Possibilità di **stimare (Estimate) **il completamento. - Dimensioni **abbastanza ridotte (Small)** per progettare, codificare e testare in un\'unica iterazione. - Infine, possibilità di essere sottoposto a **Test**. Scrivere User Story che seguono i metodi RGB e delle tre C sono buoni punti di partenza. Valutare l\'efficacia rispetto agli obiettivi INVEST consente di mantenere le story contenute, funzionali e testabili. **Come scrivere una buona User Story** Sembra controintuitivo che lo sviluppo di grandi iniziative software si basi sul successo e sull\'efficienza della vecchia scuola.   I cartellini semplici da 3x5 di diversi colori e un indicatore permanente forniscono la base per l\'autore delle user story, che porta il contesto in un processo di sviluppo Agile. I cartellini di dimensioni ridotte incoraggiano descrizioni di base basate sui vantaggi che vengono scoperti attraverso la collaborazione in team. Tutte le user story sono uniche e devono essere completate da mappe di user story, diagrammi, storyboard e modellini, ma qui di seguito sono riportate alcune best practice che possono aiutarti a scrivere una user story efficace: - **Conosci il tuo utente:** definisci e capisci il tuo utente. - **Includi tutte le parti interessate:** assicurati di includere tutte le parti interessate pertinenti nel processo di scrittura della user story. - **Concentrati sull\'utente: **discussioni e conversazioni dal punto di vista dell\'utente forniscono un contesto e una definizione di ciò che è considerato \"fatto\".   - **Brevità e semplicità:** descrivi solo un pezzo di funzionalità in ogni user story. - **Discuti e collabora: **discussioni sulle dimensioni del progetto, sul prodotto minimo funzionante (MVP), su chi lo utilizzerà, su ciò che farà e perché aiuteranno nelle decisioni sull\'inclusione e sull\'ambito. - **Evita dettagli tecnici:** non scrivere attività tecniche o \"come costruire\" dichiarazioni nelle user story, in quanto possono ostacolare creatività e collaborazione. - **Concentrati sulle 3 W: **chi (who) lo utilizzerà, che cos\'è (what) e perché (why) è importante. - **Incoraggia la visualizzazione:** utilizza qualsiasi metodo (disegni, storia e mappatura dell\'impatto, storyboard e modellini o prototipi) sia appropriato per visualizzare il prodotto finito. - **Chiarisci il valore e il vantaggio:** assicurati che lo scopo della story sia chiaro, l\'urgenza sia indicata e la story sia completa. **Sfide e insidie comuni nella scrittura di user story** Una User Story risponde a domande come chi utilizzerà la funzione, cosa farà la funzione e perché la funzione è importante. I dettagli della user story forniscono il contesto aziendale, il valore dell\'utente e guidano le discussioni del team. Una sfida comune quando si scrive user story è garantire che sia abbastanza completa da articolare valore, ma abbastanza semplice da consegnare in un breve periodo di tempo, come uno sprint (che generalmente impegna da uno a quattro settimane). La story non dovrebbe contenere dettagli tecnici su come verrà costruita o istruzioni di codifica. Questi dettagli non sono necessari in questo punto dello sviluppo. Se una storia è troppo grande o troppo ampia, può essere suddivisa in piccole parti. Ecco un buon esempio:   - Come cliente bancario, voglio essere in grado di vedere il mio saldo, in modo da poter pianificare i pagamenti delle fatture. La tentazione potrebbe essere di aggiungere più dettagli o altre funzioni, ma si creerà una narrazione troppo lunga. Questo tipo di story sarebbe simile a questa: - Come sales manager, voglio ottenere report su previsioni, vendite e personale, in modo da poter impostare il mio budget per un intero anno. Questo esempio contiene più componenti (generare report individuali: previsioni, vendite e personale) che devono essere suddivise in diverse user story più piccole. Inoltre, assicurati di includere criteri di accettazione, che identificano cosa può essere considerato \"fatto\". Come indicato sopra, i criteri di accettazione sono spesso scritti in forma di checklist sul retro del cartellino della user story. Ulteriori sfide durante la scrittura dei criteri di accettazione includono le seguenti: - La tendenza naturale a concentrarsi su come costruire. - Tuttavia, lasciando questo dettaglio tecnico fuori dalla story le conversazioni saranno più significative e porteranno a soluzioni creative, oltre a consentire l\'inclusione di utenti e membri del team non tecnici nelle discussioni. - Dialogo e conversazioni possono richiedere tempo e sono spesso dimenticati, il che limita l\'impatto positivo delle user story. - La mancanza di dati o di una comprensione reale dell\'utente o della persona mette in pericolo l\'accettazione della funzionalità quando consegnata all\'utente finale. - Limitare le user story in incrementi minimi non è facile, ma troppi dettagli rendono la user story troppo lunga. - Omettere informazioni essenziali, come i criteri di accettazione o i vantaggi del cliente, può lasciare in sospeso delle domande durante il processo di sviluppo. Il libro *User Story di Mike Cohn Applicato a Agile* Software identifica il problema principale nello sviluppo di software con questa semplice osservazione: \"*I requisiti software sono un problema di comunicazione.*\" Il linguaggio tecnico associato allo sviluppo software e alle metodologie Agile può essere un ostacolo per molti. Durante il processo di sviluppo, scrivere user story significa incorporare il dialogo e le conversazioni aperte, suddividendo le attività per mantenere il flusso di slancio e definendo in modo chiaro le condizioni per cui un elemento è considerato \"fatto\". Sviluppare un software è un processo su larga scala che richiede tempo, con molte parti interessate e aspettative elevate. Tuttavia, seguendo alcune semplici linee guida e tecniche vecchio stile, le complessità legate a tale processo diventano più visibili per l\'intero team e, alla fine, più fattibili. **Come scrivere un caso di Test da una User Story** Una User Story fornisce la guida per lo sviluppo di test o criteri di accettazione. Questa checklist aiuta gli sviluppatori a determinare quando viene eseguita la funzione. Come per tutti gli elementi delle user story, i criteri di accettazione vengono scritti anche dal punto di vista dell\'utente. I criteri di test o accettazione delineano gli elementi necessari per eseguire con successo la funzione necessaria. Questi criteri dovrebbero includere quanto segue: - I requisiti funzionali e non funzionali previsti - Scenari negativi della funzionalità - Linee guida sulle prestazioni - Flusso di lavoro utente corretto - Impatto su altre funzionalità - Esperienza dell\'utente **La mappatura delle User Story** La mappa delle storie utente Agile è un approccio visivo che \"mostra\" più di quanto \"racconta\" il processo di avanzamento di una trama o di un prodotto attraverso un caso d\'uso o un processo definito, molto simile al processo di storyboard utilizzato nella produzione cinematografica. Ed è dimostrato che funziona. Che il prodotto finale sia Il Re Leone o un nuovo sistema point-of-service (POS), la mappa delle storie utente è un elemento chiave nella definizione e nella creazione di un prodotto di alto valore per l\'utente finale. In questa parte del nostro Corso esploreremo quindi gli elementi della mappatura delle storie utente come processo di esperienza utente (UX) integrale. Osservando un progetto attraverso il prisma del cliente o del percorso utente, Jeff Patton, autore di User Story Mapping, afferma che: \"*La mappatura delle storie ci mantiene concentrati sugli utenti e sulla loro esperienza, e il risultato è una conversazione migliore e, in definitiva, un prodotto migliore*". **Cos\'è la mappatura delle Storie Utente?** La mappatura delle storie utente è stata definita per la prima volta per lo sviluppo Agile e Lean nel 2005 ed è discussa nel libro User Story Mapping di Jeff Patton. L\'\"idea semplicissima\", come la definisce Patton, consente ad un team o a un\'organizzazione di visualizzare il prodotto dal punto di vista dell\'utente. Le storie utente rappresentano l\'esperienza del cliente mentre naviga nel tuo prodotto. Queste storie utente forniscono contesto alle funzionalità che sono nuove o che necessitano di miglioramenti. Quando queste funzionalità vengono approvate per lo sviluppo, vengono aggiunte al product backlog e assegnate loro la priorità. Una lamentela comune sui product backlog è che sviluppatori e product manager perdono di vista il quadro generale. Le storie utente offrono una presentazione visiva dinamica e utile di tipici scenari di casi d\'uso dei clienti. **Vantaggi delle User Story** Secondo Jeff Patton, una mappa delle storie utente può essere sviluppata da una sola persona, ma questo annulla i principali vantaggi che derivano dalla partecipazione del team. Ogni partecipante, inclusi product manager e designer, troverà valore in ciò che gli altri membri del team (marketing, vendite e assistenza clienti) portano sul tavolo. Il processo fornisce una visione illuminante che migliora la capacità di servire i clienti. Ad esempio, gli stakeholder di operazioni e finanza hanno una visione su come ottenere il massimo ROI quando si includono le funzionalità.