User Story vs Requisito

User Story cattura ciò che l'utente vuole fare con il sistema ad alto livello. Comprendo che la user story determinerebbe ulteriori requisiti di basso livello. La user story è uguale ai requisiti di alto livello del sistema?

Ad essere sincero, dopo aver trascorso quasi due anni immerso nello sviluppo Agile, penso ancora che "user story" sia solo un termine fantasioso per "requisito funzionale".

È diverso a livello superficiale , ad esempio prende sempre una certa forma ( "come X, voglio Y in modo che Z ..." ), ma gli elementi chiave - l'identificazione degli stakeholder e la logica - sono anche inerenti a requisiti funzionali scritti. È altrettanto facile scrivere una brutta storia utente quanto scrivere un cattivo requisito ( "come [il nome della nostra azienda], voglio [funzione vaga] in modo che io possa [fare qualcosa che è evidentemente parte del mio lavoro, come 'vendi di più ai clienti'] " ).

Ciò che le storie degli utenti non catturano quasi mai , secondo la 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 la mitigazione (ma non l'eliminazione) dei rischi piuttosto che il rispetto di uno specifico utente bisogno.

Quindi, penso davvero alle storie degli utenti come a un sottoinsieme di requisiti, con una formula specifica, e uso ancora i termini in modo abbastanza intercambiabile.

L'unico vantaggio principale che le storie utente hanno rispetto ai requisiti è che la parola "requisito" suggerisce che una funzionalità è richiesta laddove è spesso desiderata . In teoria, le storie degli utenti possono essere prioritarie e inserite per ogni versione, mentre i requisiti sembrano essere un prerequisito per ogni versione.

Naturalmente, affinché la suddetta distinzione abbia importanza, i vostri clienti e / o il senior management devono accettarla; non ti va bene se hai 30 storie utente tutte raggruppate in un "progetto" che devono essere completate tutte contemporaneamente. Potresti anche chiamarli "requisiti" in quel caso perché sono effettivamente richiesti.

Ron Jeffries ha scritto molto tempo fa sulle 3C delle storie degli utenti ( http://xprogramming.com/articles/expcardconversationconfirmation/ ) con l'accento su una carta (breve descrizione), la conversazione tra i clienti e il team di consegna una volta una storia utente diventa utilizzabile e la conferma concordata di una storia dopo quella conversazione.

in sostanza, prima della conversazione, le storie degli utenti sono solo un ambito pianificato - 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 sequenza temporale, una storia potrebbe essere solo un'idea generale di portata o un requisito dettagliato.

al giorno d'oggi, il significato di "user story" sembra essere limitato alla sola "carta" delle 3C di Jeffries. in tal caso, una user story non è un requisito ma una promessa di tenere una conversazione sui requisiti.

Puoi trovare un sacco di pepite d'oro di saggezza sulle storie degli utenti sul wiki di c2 ( http://xp.c2.com/UserStory.html )

Le storie e i requisiti degli utenti sono bestie molto diverse.

Requisiti

I requisiti presuppongono che la progettazione dell'applicazione venga eseguita in anticipo e che lo sviluppo sia l'implementazione di tale progettazione. I requisiti si concentrano quindi su come implementare una funzionalità.

Esempio di requisito:

• Crea un modulo di contatto utente con i seguenti campi: nome, cognome, e-mail, testo libero e un pulsante di invio. Quando viene premuto il pulsante di invio, viene inviata un'e-mail al nostro team di supporto.

Storie degli utenti

Le storie degli utenti si concentrano su cosa raggiungere e insistono sul fatto che la progettazione del prodotto viene eseguita all'ultimo minuto ed è una collaborazione tra una persona del prodotto e una persona dello sviluppatore. I dettagli vengono decisi durante l'implementazione in base alle opportunità.

Esempio di una storia:

• Come utente di Jimmy voglio contattare il tuo team di supporto quando non riesco a utilizzare correttamente il sito in modo che possano aiutarmi.

Qual è la differenza?

Come puoi vedere, c'è sicuramente una differenza nella quantità di dettagli forniti, ma ci sono anche molte informazioni che sono disponibili solo nella storia, vale a dire lo scopo di ciò che stiamo cercando di ottenere con questa funzione.

Mentre può sembrare che lo scopo sia relativamente poco importante, si tratta di un'ipotesi errata nello sviluppo agile. In genere ci sono due casi in cui conoscere lo scopo è molto importante: ridurre il costo delle opportunità e consentire l'agilità.

Costo dell'opportunità

Se ci sono presupposti nascosti nel requisito, potrebbe essere molto difficile da raggiungere. Ad esempio: è disponibile un server di posta? In caso contrario, il requisito potrebbe richiedere molto più tempo per essere sviluppato. In alcuni altri casi, a causa del design, si potrebbe perdere un modo più semplice per raggiungere lo stesso obiettivo.

Al contrario, la user story parla di un utente che contatta il nostro dipartimento di supporto. Se l'invio di un messaggio di posta elettronica è irrealizzabile o troppo costoso, possiamo escogitare una soluzione diversa sul posto: ad esempio, scrivere in un database o utilizzare un modulo tramite documenti di Google o semplicemente inserire un indirizzo e-mail anziché il modulo. Questo non può essere fatto facilmente con un requisito, ma facilmente con una storia e un prodotto presente.

Agilità

Per questo motivo, con i requisiti generalmente tendiamo a pensare in anticipo a questi presupposti nascosti e assicurarci che non ci siano intoppi. Quindi, in questo caso, potrebbe esserci un requisito diverso, programmato in anticipo, che garantiva la presenza di un server di posta.

Questo ci porta a un'altra enorme differenza tra storie e requisiti che è la gerarchia . Come ho esemplificato sopra, i requisiti devono, per loro stessa natura, essere ordinati in una gerarchia naturale in modo da soddisfare le dipendenze. Le storie, d'altra parte, si concentrano di proposito 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 è generalmente molto doloroso spostarli a causa di tutte le dipendenze. Semplicemente non viene fatto molto spesso. Se stai lavorando con i requisiti, la tua agile implementazione soffrirà, o probabilmente non sarà affatto molto agile, nel senso di essere in grado di abbracciare il cambiamento.

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 offre la funzionalità richiesta. Quando sono necessari test dell'interfaccia utente e dell'usabilità, la User Story potrebbe essere il documento più importante.

Certo, puoi fare in modo che il selenio verifichi che determinati nodi siano presenti nell'HTML o catturare schermate o verificare che determinati 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 l'addestramento per utilizzare il sistema. La revisione del sistema completo rispetto agli scenari utente è un componente fondamentale del test manuale.

C'è una mentalità catturata nelle storie / scenari degli utenti che dovrebbe influenzare molte decisioni di progettazione dettagliate sull'implementazione. A meno che gli sviluppatori non parlino direttamente con gli utenti o non li vedano usare il sistema, lo scenario utente potrebbe essere l'unico link 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 raggiungere questo obiettivo. È molto più semplice descrivere una soluzione, piuttosto che un'esigenza, e gli scenari utente forniscono un quadro per la descrizione delle esigenze 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 ciò di cui avevano effettivamente bisogno.

Quindi direi che una buona storia non dovrebbe includere dettagli specifici su come il sistema dovrebbe essere implementato. Dovrebbe essere indicato: "Una volta al mese, il sistema A deve essere aggiornato con tutti i nuovi dati del sistema B. Tali dati potrebbero richiedere correzioni. Il cliente ha una cronologia di immissione di dati non validi e di non realizzare il problema per settimane". Non dovrebbe dire "Il sistema deve accettare un file CSV latin1 almeno una volta al mese e generare un NumberFormatException se la colonna 3 non è un numero". Vedi la differenza? Lo scenario descrive la necessità, non una soluzione specifica. Quindi, nel test, si ritorna allo scenario per assicurarsi che la soluzione si adatti alle esigenze. I requisiti possono mescolare alcune esigenze con alcune soluzioni o persino concentrarsi interamente sulle soluzioni.

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 user story. Entrambi dichiarano il risultato o l'obiettivo desiderato 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 capo di una squadra voglio vedere quale della mia squadra sta lavorando su casi di mutuo in modo da poter monitorare le loro prestazioni.

La soluzione deve mostrare i membri del team che lavorano su casi di mutuo.

Entrambi i precedenti potrebbero essere interpretati allo stesso modo, ma entrambi hanno anche molta ambiguità. Il punto principale qui è una differenza di stile. Penso che il problema che vediamo principalmente sia quanto lontano nella definizione della soluzione dobbiamo andare prima di uscire dal mondo dei requisiti e nel mondo del design funzionale. Spetta all'analista aziendale dichiarare "elenco utenti registrati per nome e secondo nome nel menu principale dell'applicazione" o sono 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 di codice su cui sarà costruito e il modo in cui verrà distribuito, 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 presumere che non sappiamo nulla della soluzione solo dei risultati desiderati. Sì, questo rende tutto agnostico, ma ci aiuta davvero nel ciclo di sviluppo? Se riusciamo a definire accuratamente qualcosa in anticipo, allora perché non farlo?

Tutto sommato, però, non mi preoccuperei delle storie degli utenti e delle differenze di requisiti. Alla fine, vuoi definire abbastanza informazioni per qualcuno per sviluppare una soluzione. Una user story di livello troppo alto verrà semplicemente annullata e verrà richiesta la suddivisione in user story più piccole. Lo stesso di uno stile "il sistema deve". Probabilmente il ritiro sarà respinto perché troppo ambiguo se non ha abbastanza dettagli.

Alla fine vai con quello che i tuoi sviluppatori e stakeholder amano vedere e lavorare da quello.

Penso che ci sia molta incoerenza sul significato delle parole richieste, anche nei classici libri di testo. La stessa incoerenza si applica alle storie degli utenti. Diverse organizzazioni e libri di testo trattano questi termini in modo diverso. Ad esempio, come il classico libro di testo Software Engineering di Roger Pressman parla dei requisiti è molto diverso dal libro sui requisiti software Agile di Dean Leffingwell. Li rispetto entrambi ed entrambi possono essere validi.

I requisiti possono essere cose a cui codifichiamo che hanno una specificità straordinaria con poco lasciato 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 unico per ogni azienda e settore (non tutto lo sviluppo del software avviene nell'IT).

Mi è stato insegnato che l' elicitazione dei requisiti porta all'analisi, che porta alla progettazione, che porta all'architettura che porta all'elaborazione o alla specifica dei requisiti , 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 in anticipo. In lean and misum, l'eccitazione e l'elaborazione avvengono in varie fasi con maggiore elaborazione mentre si avvicina l'implementazione in uno sprint. Come il lavoro di progettazione emergente.

Nella nostra organizzazione, ci stiamo inclinando verso il modello di Leffingwell di Epics, Features and Stories, non come requisiti ma come suddivisione del lavoro e definizione delle priorità. I requisiti sono una cosa diversa. I requisiti sono gestiti separatamente perché siamo tenuti a farlo per le agenzie di regolamentazione. Eppure alcuni team stanno sicuramente sviluppando requisiti nelle storie degli utenti durante l'incremento del programma e la pianificazione dello sprint.

I requisiti funzionali sono generalmente una specifica formale che ti consente di sapere esattamente se il tuo software funziona o meno. La storia dell'utente è di solito un modo molto più informale per descrivere la necessità di una storia dell'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 user story (se le fai nel modo giusto) è 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 afferma specificamente che alcune cose non sono mappate alla user story e che non devi usare solo questo.

Nel mio team, utilizziamo quanto segue:

• User story : un'esigenza aziendale di un tipo di utente. L'enfasi qui è sulla necessità e perché ne ha bisogno. Come altri hanno già detto, l'importante qui non è specificare come è fatto e approfondire il reale bisogno dell'utente (es: non ha bisogno di visualizzare i dati in una tabella, deve vedere il valore esatto del dati, e ha familiarità con la tabella per fare proprio questo).
• Bug : un comportamento imprevisto del software che compromette il normale utilizzo. Di solito viene fornito un "Importanza" (indipendente dalla priorità di sviluppo) che valuta quanto influisce sul flusso di lavoro dell'utente.
• Debito tecnico. Qualcosa che non impedisce l'utilizzo dell'uso del software, ma che comprometterà noi , gli sviluppatori, in futuro. Esempio: alcune classi sono difficili da leggere, la compilazione è lenta, alcuni codici non sono testati in unità, l'IDE mostra strani avvisi ...
• Miglioramento : una modifica al software che non consente nuovi scenari, ma rende l'esperienza più piacevole. Esempio: modifica dei caratteri, riprogettazione di un modulo per renderlo più chiaro, aggiunta di impostazioni predefinite ragionevoli all'applicazione, ecc.

I requisiti funzionali non ci permetterebbero di renderci conto che una funzionalità che abbiamo implementato non risolve il bisogno di un utente, anche se il nostro test del cetriolo ha superato e abbiamo implementato ogni parola scritta. Una storia è una discussione ed è informale. Il punto è che i ragazzi dell'implementazione capiscono qual è il problema. Non sono uno strumento contrattuale. Se fai "mischia ma ... " e la tua storia è semplicemente un modo divertente per scrivere i requisiti del software, allora sì, non c'è differenza.

Il punto non è la storia dell'utente, il punto è l'enorme cambiamento di paradigma nel modo in cui approcci il lavoro da svolgere. Non stai facendo un contratto, stai aiutando alcuni dei tuoi utenti a risolvere un problema. Se non vedi le tue storie utente come strumento di discussione con un utente reale , allora non stai usando storie utente, stai usando una sintassi dei requisiti funky .

Il resto qui è la mia opinione: la user story non potrà mai avere successo in modo unilaterale. Hai bisogno che il tuo cliente ci lavori. La caduta della mischia dell'acqua è destinata a essere un bizzarro pasticcio dei requisiti ma non dei requisiti. Se hai un contratto a offerta fissa con requisiti specifici, non utilizzare iterazioni e user story, non ha senso . Usa il resto del toolkit agile: test unità / funzionale automatizzato, revisione del codice, integrazione continua, refactoring, ecc. Assicurati che il tuo software funzioni continuamente e che tu possa spedirlo in un attimo. Renderlo disponibile nella sua forma incompiuta al cliente in modo che possa fornire il maggior feedback possibile. Se lo fai amico mio, anche se non facessi "User story" e "Scrum", saresti stato più agile di molti cosiddetti negozi "Agile".

Credo che tutti implementeranno ed 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 discutere.

Tuttavia, IMO, A User Story segue l'approccio Agile di "un cliente nell'edificio o il cliente è immediatamente disponibile", in cui la documentazione non è necessariamente necessaria perché i dettagli sono nella testa dei clienti e prontamente disponibili, quindi un SRS formale può non essere richiesto. Ora un "compito" di una "User story" è il modo in cui uno sviluppatore costruirà le user story in modo digeribile.

Una user story di esempio potrebbe essere:

Come utente amministratore voglio visualizzare i dati dei miei clienti elencati in una griglia

e un "compito" potrebbe essere:

1. Crea una griglia che elenca i dati da visualizzare

2. Abilita l'ordinamento sulla griglia che ordinerà la colonna selezionata

Ora ciascuna delle attività viene stimata e completata nel rispettivo sprint.

Da una prospettiva "tradizionale", in cui "il cliente è difficile da ottenere, dobbiamo scriverlo in modo che possano confermare che l'abbiamo fatto prima di iniziare a pianificare / programmare" l'approccio, la Specifica dei requisiti software è saranno le idee che erano nella testa dei clienti e suscitate e poi scritte e formalizzate e quindi baselate e gestite.

In questo caso, un "requisito funzionale" è il dettaglio nitido di quel SRS, e una parte dell'idea più grande. Quindi, a mio avviso, una user story potrebbe essere vista come una (parte del) "Requisito" formale e il compito di tale user story è un (o uno dei tanti) requisiti funzionali.

Nella user story di esempio, il "Requisito" formale sarebbe un lungo documento con diagrammi di flusso e generalmente sarà incentrato sulla documentazione, al contrario dell'approccio più "Agile" incentrato sul cliente.

La differenza è che il "Requisito" formale sarà sulla falsariga di un documento di 10 pagine che delinea la sezione di amministrazione dell'app che indica che saranno necessari alcuni elenchi, un po 'di sicurezza basata sui ruoli, ecc. E poi alcuni dei funzionali i requisiti saranno "le griglie di quotazione devono consentire l'ordinamento", "le informazioni dell'utente devono essere elencate in una griglia", ecc.

e credo che in questi giorni i termini siano tutti mescolati e mescolati ... il che non conta affatto