User Story acquisisce ciò che l'utente vuole fare con il sistema ad alto livello. Capisco che la storia dell'utente possa ulteriormente guidare un numero di requisiti di basso livello. La storia utente è la stessa dei requisiti di alto livello per il sistema?
Per essere onesti, dopo aver trascorso circa due anni immersi nello sviluppo Agile, penso ancora che "User story" sia solo un termine di fantasia per "requisito funzionale".
È diverso a un livello superficiale , ad es. prende sempre una certa forma ( "come X, voglio Y in modo che Z ..." ), ma gli elementi chiave - identificando lo stakeholder e la logica - sono anche inerenti a una scrittura ben scritta richieste funzionali. È altrettanto facile scrivere una brutta storia per l'utente quanto scrivere un brutto requisito ( "come [nome della nostra azienda], voglio [caratteristica vaga] in modo che io possa fare qualcosa che è evidentemente parte della mia lavoro, come "vendere di più ai clienti"] ").
Quali user story quasi mai catturare, nella mia esperienza, sono requisiti non-funzionali come prestazioni e sicurezza. Questi tipi di requisiti sono molto difficili da scrivere correttamente e il formato della user story semplicemente non è molto buono per catturarli, perché riguardano più la qualità generale del prodotto e mitigano (ma non eliminano) i rischi piuttosto che incontrare gli utenti specifici hanno bisogno.
Quindi, penso davvero alle storie degli utenti come un sottoinsieme di requisiti, con una formula specifica, e comunque uso i termini in modo quasi intercambiabile.
Il principale vantaggio che le storie degli utenti hanno sui requisiti è che la parola "requisito" suggerisce che una caratteristica è richiesta dove spesso è desiderata . In teoria, le storie degli utenti possono essere prioritarie e inserite per qualsiasi rilascio, mentre i requisiti sembrano essere un prerequisito per il rilascio di ogni .
Naturalmente, per la distinzione sopra menzionata, i tuoi clienti e / o la direzione devono adottarla; non ti va bene se hai 30 storie di utenti tutte raggruppate in un "progetto" che deve essere completato nello stesso momento. Potresti anche chiamarli "requisiti" in quel caso perché sono richiesti.
Ron Jeffries ha scritto molto tempo fa sulle 3C di user story ( link ) con l'enfasi su una carta (breve descrizione), conversazione tra i clienti e il team di consegna una volta che la storia di un utente diventa fruibile e la conferma concordata di una storia dopo quella conversazione.
essenzialmente, prima della conversazione, le user story sono solo degli obiettivi pianificati: idee approssimative su cosa potremmo fare. dopo la conversazione, dovresti avere un modo per confermare che la storia è completa. Quindi, a seconda del momento in cui guardi la storia in questa timeline, una storia potrebbe essere solo un'idea generale dell'ambito o un requisito dettagliato.
In questi giorni, il significato di "User story" sembra essere ristretto solo alla parte "card" delle 3C di Jeffries. in tal caso, una user story non è un requisito ma una promessa di tenere una conversazione sui requriements.
Puoi trovare un sacco di pepite d'oro sulla saggezza delle storie degli utenti sul wiki c2 ( link )
Per me, un elemento critico di una User Story è che cattura Perché e come un utente utilizza il sistema. È particolarmente utile perché non specifica molto nel modo in cui il sistema fornisce la funzionalità richiesta. Quando sono necessari i test dell'interfaccia utente e dell'usabilità, la User Story potrebbe essere il documento più importante.
Certo, puoi avere il selenio per verificare che alcuni nodi siano presenti nell'HTML o scattare schermate, o verificare che alcuni pixel siano dove speri che siano. Ma se c'è un testo fuorviante, o non è chiaro come l'utente debba usare il sistema o è difficile per un utente capire come raggiungere il proprio obiettivo, improvvisamente non si ha più un sistema completo. Ora è necessario un addestramento per utilizzare il sistema. La revisione del sistema completato rispetto agli scenari utente è un componente fondamentale del test manuale.
Esiste un set mentale catturato in storie / scenari di utenti che dovrebbero influenzare molte decisioni di progettazione dettagliate sull'implementazione. A meno che gli sviluppatori non parlino direttamente agli utenti o li guardino mentre utilizzano il sistema, lo scenario utente potrebbe essere l'unico collegamento per consentire loro di comprendere le esigenze degli utenti.
Infine, consentono agli uomini d'affari di specificare ciò di cui hanno bisogno senza suggerire come ciò dovrebbe essere realizzato. È molto più semplice descrivere una soluzione rispetto a una necessità e gli scenari utente forniscono una struttura per descrivere i bisogni senza proporre una soluzione specifica. Il requisito aziendale più comune che ho sentito è: "Voglio che sia esattamente come Excel, ma sul Web", che non è mai stato ancora quello di cui avevano effettivamente bisogno.
Quindi direi che una buona storia non dovrebbe includere dettagli specifici su come il sistema dovrebbe essere implementato. Dovrebbe dire, "Una volta al mese, il sistema A deve essere aggiornato con tutti i nuovi dati dal sistema B. I dati potrebbero richiedere correzioni.Il client ha una storia di inserimento di dati non validi e non ha realizzato il problema per settimane." Non dovrebbe dire: "Il sistema deve accettare un file CSV latin1 almeno una volta al mese e lanciare un NumberFormatException se la colonna 3 non è un numero." Vedi la differenza? Lo scenario descrive la necessità, non una soluzione specifica. Quindi, durante i test, torna allo scenario per assicurarti che la soluzione soddisfi le necessità. I requisiti possono mescolare alcune esigenze con alcune soluzioni o anche concentrarsi interamente sulle soluzioni.
Le storie e i requisiti degli utenti sono animali molto diversi.
I requisiti presuppongono che il design dell'applicazione sia fatto in anticipo e che lo sviluppo sia l'implementazione di quel progetto. I requisiti quindi si concentrano su come implementare una funzionalità.
Esempio di requisito:
Le storie degli utenti si concentrano su che ottenere, e insistono sul fatto che il design del prodotto è fatto all'ultimo minuto ed è una collaborazione tra una persona del prodotto e una persona sviluppatore. I dettagli vengono decisi durante l'implementazione in base alle opportunità.
Esempio di una storia:
Come puoi vedere, c'è sicuramente una differenza nella quantità di dettagli forniti, ma ci sono anche molte informazioni che sono disponibili solo nella storia, ovvero lo scopo che cos'è stiamo cercando di ottenere con questa funzione.
Sebbene possa sembrare che lo scopo sia relativamente irrilevante, questo è un presupposto errato nello sviluppo agile. In genere, sono due i casi in cui la conoscenza dello scopo è molto importante: ridurre il costo delle opportunità e consentire l'agilità.
Se ci sono ipotesi nascoste nel requisito, potrebbe essere molto difficile da raggiungere. Ad esempio: c'è un server di posta disponibile? In caso contrario, il requisito potrebbe richiedere molto più tempo per essere sviluppato. In alcuni altri casi potrebbe essere mancato un modo più semplice per raggiungere lo stesso obiettivo a causa del design.
Al contrario, la storia dell'utente riguarda un utente che contatta il nostro dipartimento di supporto. Se l'invio di una posta è irrealizzabile o troppo costoso, possiamo escogitare una soluzione diversa sul posto: scrivere ad un database, ad esempio, o usare un modulo tramite Google docs, o semplicemente inserire un indirizzo email al posto del modulo. Questo non può essere fatto facilmente con un requisito, ma è fatto facilmente con una storia e una persona presente al prodotto.
Per questo motivo, con i requisiti in genere tendiamo a pensare preventivamente a queste supposizioni nascoste e ci assicuriamo che non ci siano intoppi. Quindi in questo caso potrebbe esserci un diverso requisito, programmato in anticipo, che assicurava la presenza di un server di posta.
Questo ci porta a un'altra enorme differenza tra storie e requisiti che è gerarchia . Come ho esemplificato sopra, i requisiti devono, per loro natura, essere ordinati in una gerarchia naturale in modo che le dipendenze siano soddisfatte. Le storie, d'altra parte, si concentrano sullo scopo e non hanno tali vincoli.
Questo è in base alla progettazione, poiché in agile è di fondamentale importanza aggiungere, rimuovere, riprogrammare e modificare le storie secondo necessità durante l'esecuzione del progetto. I requisiti possono generalmente essere aggiunti, a volte modificati o rimossi, ma in genere è molto doloroso spostarli a causa di tutte le dipendenze. Semplicemente non viene fatto molto spesso. Se stai lavorando con i requisiti, la tua implementazione agile ne risentirà, o probabilmente non sarà affatto molto agile, nel senso di essere in grado di abbracciare il cambiamento.
Ci siamo imbattuti in questo durante una ricerca su google e ho pensato di esprimere la mia opinione.
Non c'è davvero alcuna differenza tra un requisito e una storia utente. Entrambi stanno affermando il risultato desiderato o l'obiettivo dal punto di vista dell'utente.
L'unica differenza è il modo in cui questo obiettivo o risultato viene acquisito da un analista aziendale. In questo caso è nella formulazione.
Esempio:
Come guida di una squadra, voglio vedere chi della mia squadra sta lavorando a casi di mutui, in modo da poter monitorare le loro prestazioni.
La soluzione mostrerà i membri del team che lavorano sui casi di mutuo.
Entrambi i precedenti potrebbero essere interpretati allo stesso modo ma entrambi hanno anche un sacco di ambiguità. Il punto principale qui è una differenza di stile. Penso che il problema che vediamo maggiormente è fino a che punto siamo nella definizione della soluzione, prima di spostarci dal mondo dei requisiti e nel mondo del design funzionale. Spetta all'analista aziendale indicare "elenco degli utenti che hanno effettuato l'accesso per nome e secondo nome nel menu principale dell'applicazione" o troppe informazioni? Quando siamo seduti a parlare con i nostri stakeholder e conosciamo tutti la soluzione e possiamo interpretare come sarà, anche il probabile linguaggio in codice su cui sarà costruito e il modo in cui verrà implementato, abbiamo davvero bisogno di giocare al gioco purista di " definiamo obiettivi e non soluzioni ". È qui che sento che la confusione è davvero.
I requisiti spesso fanno presupporre che non sappiamo nulla della soluzione solo i risultati desiderati. Sì, tutto ciò rende agevole la soluzione, ma ci aiuta davvero nel ciclo di sviluppo? Se possiamo definire con precisione qualcosa in anticipo allora perché non farlo?
Tutto sommato, anche se non mi preoccuperei delle storie degli utenti e delle differenze dei requisiti. In definitiva, si vogliono definire sufficienti informazioni per consentire a qualcuno di sviluppare una soluzione. Una user story di livello troppo elevato verrà semplicemente respinta e verrà richiesta la suddivisione in user story più piccoli. Lo stesso di un "stile del sistema". Probabilmente il requisito verrà respinto in quanto troppo ambiguo se non ha abbastanza dettagli.
Alla fine vai con ciò che i tuoi sviluppatori e le parti interessate amano vedere e lavorare da quello.
Penso che ci sia molta incoerenza su cosa significhi la parola requisito, anche all'interno di libri di testo classici. La stessa incoerenza si applica alle storie degli utenti. Diverse organizzazioni e libri di testo trattano questi termini in modo diverso. Ad esempio, il classico libro di How Engineering Pressman di How Roger Pressman parla dei requisiti è molto diverso dal libro dei requisiti del software Agile di Dean Leffingwell. Li rispetto entrambi ed entrambi possono essere validi.
I requisiti possono essere quelli che codifichiamo con una specificità straordinaria con poco spazio all'immaginazione. D'altra parte, si può sostenere che i requisiti dovrebbero specificare qual è il problema aziendale e non specificare la soluzione. Penso che sia più sfumato e la risposta è da qualche parte su uno spettro che è unico per ogni azienda e industria (non tutto lo sviluppo del software si verifica in IT).
Mi è stato insegnato che i requisiti elicitazione conducono all'analisi, che porta al design, che porta all'architettura che porta ai requisiti elaborazione o specifica, che porta a qualcosa che può essere codificato. Non credo che questo vada via con agilità. Il momento in cui accadono queste cose cambia e questa è la differenza più importante. Nel modello a cascata, l'elicitazione e l'elaborazione avvengono presto. Nella magra e nella mischia, l'elicitazione e l'elaborazione avvengono in varie fasi con più elaborazioni mentre si avvicina all'implementazione in uno sprint. Come il lavoro di progettazione emergente.
Nella nostra organizzazione, ci stiamo orientando verso il modello Leffingwell di Epics, Features e Stories, non come requisiti ma come suddivisione del lavoro e priorità. I requisiti sono una cosa diversa. I requisiti sono gestiti separatamente perché ci viene richiesto di farlo per le agenzie di regolamentazione. Eppure alcuni team stanno certamente sviluppando requisiti all'interno delle storie degli utenti durante l'incremento del programma e la pianificazione dello sprint.
I requisiti funzionali sono solitamente una specifica formale che ti consente di sapere esattamente se il tuo software funziona o meno. La storia degli utenti di solito è un modo molto più informale per descrivere la necessità di una storia utente. Non specifica una specifica rigida per determinare se il software è "valido" o "non valido". Mentre puoi testarne una parte, il vero completamento di una storia di un utente (se le fai bene) è quando il tuo utente dice "sì, questo risolve il mio problema!". Ricorda il manifesto agile:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Nel suo libro "User Story Applied", Mike Cohn dice specificatamente che alcune cose non si riferiscono alla trama dell'utente e non devi usare solo quella.
Nel mio team, usiamo il seguente:
I requisiti funzionali non ci consentirebbero di comprendere che una funzionalità implementata non risolve il bisogno di un utente, anche se il test sui cetrioli è stato superato e abbiamo implementato ogni parola scritta. Una storia è una discussione ed è informale. Il punto è per l'implementazione ragazzi per capire qual è il problema. Non sono uno strumento contrattuale. Se fai "scrum but ... " e la tua storia è semplicemente un modo divertente per scrivere i requisiti del software, allora sì, c'è no differenza.
Il punto non è la user story, il punto è l'enorme cambiamento di paradigma nel modo in cui ti avvicini al lavoro da fare. Non stai facendo un contratto, stai aiutando qualcuno dei tuoi utenti a risolvere un problema. Se non vedi le tue storie utente come strumento di discussione con un utente reale , quindi non stai utilizzando le storie degli utenti, stai utilizzando una sintassi dei requisiti funky .
Il resto qui è la mia opinione: la storia dell'utente non può mai avere successo in modo unilaterale. Hai bisogno che il tuo cliente lavori con esso. La caduta d'acqua è destinata a essere un pasticcio di requisiti, ma non di requisiti. Se hai un contratto di offerta fisso con requisiti specifici, non utilizzare le iterazioni e la storia utente, c'è nessun punto . Usa il resto del toolkit agile: test unitario automatico / funzionale, revisione del codice, integrazione continua, refactoring, ecc. Assicurati che il tuo software funzioni continuamente e che tu possa spedirlo in un attimo. Rendilo disponibile nella sua forma incompleta al cliente in modo che possa dare il maggior numero di feedback possibile. Se lo fai amico mio, anche se non hai fatto "User story" e "Scrum", saresti stato più agile di molti negozi "Agili".
Credo che tutti implementeranno e etichetteranno tutto in modo diverso a seconda dell'esperienza passata e qualunque linguaggio funzioni per quella società che svolge il lavoro non vale la pena di discutere.
Tuttavia, IMO, A User Story segue l'approccio di Agile di "un cliente nell'edificio o il cliente è immediatamente disponibile", in cui la documentazione non è necessariamente necessaria perché i dettagli sono nella testa del cliente e prontamente disponibili potrebbe non essere richiesto un SRS formale. Ora un "compito" di una "User story" è come uno sviluppatore costruirà le user story in modo digeribile.
Un esempio di storia utente potrebbe essere:
As an admin user I want to view my clients data listed in a grid
e un "compito" potrebbe essere:
Create a Grid which lists the data to be displayed
Enable Sorting on the grid which will sort the column selected
Ora ciascuna delle attività è stimata e completata nel relativo sprint.
Da una prospettiva "tradizionale", in cui "il cliente è difficile da afferrare, dobbiamo scrivere questo in modo che possano confermare che abbiamo capito bene prima di iniziare a pianificare / codificare" l'approccio, il software Le specifiche del requisito saranno le idee che erano nella testa del cliente e suscitate e poi scritte e formalizzate e poi baselined e gestite.
In questo caso, un "requisito funzionale" è il dettaglio nitido di tale SRS e una parte dell'idea più grande. Quindi, secondo me, una user story potrebbe essere vista come una (parte del) Requisito formale, e il compito di quella user story è un (o uno dei tanti) requisiti funzionali.
Nell'esempio della user story, il "Requisito" formale sarebbe un lungo documento con diagrammi di flusso e generalmente sarà incentrato sulla documentazione, in contrapposizione all'approccio più "Agile" che è incentrato sul cliente.
Essendo la differenza, il formale "Requisito" sarà sulla falsariga di un documento di 10 pagine che delinea la sezione di amministrazione dell'app che indica che saranno necessarie alcune schede, alcuni di sicurezza basata sui ruoli, ecc. e poi alcuni dei requisiti funzionali saranno "le griglie di quotazione dovranno consentire l'ordinamento", "le informazioni dell'utente dovranno essere elencate in una griglia", ecc.
e credo che in questi giorni i termini siano tutti mescolati e mescolati ... il che non ha alcuna importanza
Leggi altre domande sui tag requirements user-story requirements-management