Qual è la differenza tra user story e funzionalità?

25

Giocando con icescrum , mi sono reso conto che non capisco la differenza tra storie utente e caratteristiche dell'utente.

Qualcuno può spiegare la differenza?

agile scrum features

— BЈовић
fonte

23

Una caratteristica è un elemento distinto di funzionalità che può fornire capacità all'azienda.

Una storia è un piccolo aspetto di una funzione che puoi utilizzare per ottenere feedback dai tuoi stakeholder e scoprire se stai facendo qualcosa di sbagliato.

Ad esempio, una funzione potrebbe essere "consentire agli utenti di commentare gli articoli". Le storie associate a quella funzione potrebbero quindi essere:

salva commenti
filtra i commenti per le parole maleducate
limitare i commenti a 400 caratteri e rispondere agli utenti
aggiungi captcha per impedire ai robot di spamming nel sito
consentire agli utenti di accedere tramite ID Google

eccetera.

In ogni fase possiamo quindi ricevere feedback sull'utilità della direzione che stiamo prendendo.

Alcuni team non si preoccupano di suddividere le funzionalità in storie. Va bene.

— Lunivore
fonte

13

Quelle storie associate non sono in realtà attività relative alle storie utente? Direi che lo sono. Una user story sarebbe: Come utente vorrei commentare gli articoli in modo che noi come utenti possiamo migliorare il contenuto degli articoli o esprimere preoccupazioni. Questa user story sarebbe suddivisa per le attività che hai descritto ...

— Robert Koritnik,

4

Considero un compito qualcosa che deve essere fatto per ottenere feedback, ma su cui non è possibile ottenere feedback da soli, ad esempio creando una tabella di database. Ognuna di queste storie, tranne la prima, potrebbe potenzialmente essere rimossa lasciando comunque valore nella spedizione. Le attività sono di solito tagliate orizzontalmente nel mio mondo. Ma, se hai definizioni diverse, va bene. La granularità non è una cosa completamente discreta, ogni obiettivo è un sotto-oggetto di un altro e penso che dovresti fare qualsiasi cosa sia pragmatica per te. Trovo utile questa ripartizione, così come molti dei miei team.

— Lunivore,

16

Caratteristiche == Storie utente.

La verbosità è dettata dalla metodologia Agile fornita .

Le diverse metodologie utilizzano una terminologia diversa per fare riferimento alle funzionalità. Spetta al team decidere quale metodologia o terminologia utilizzare. Extreme Programming (XP) usa i termini User Story o Stories per rappresentare le funzionalità; Scrum utilizza il Product Backlog per descrivere un elenco di funzionalità; Lo sviluppo guidato da funzionalità utilizza Feature; e DSDM utilizza Requisito. Allo stesso modo, ci sono varie versioni leggere di Unified Process, o Agile UP, che usano Requisito e / o Usa caso per definire funzionalità consegnabili in modo incrementale. Alla fine, l'obiettivo è lo stesso: offrire valore commerciale regolarmente con piccoli incrementi e prima piuttosto che dopo.

— Aaron McIver
fonte

+1, questo lo spiega bene. Non direi necessariamente feature == user story, tranne quando parli di valore aziendale o valore del cliente. In altri casi, il rispettivo termine potrebbe non avere un significato.

— Murrekatt,

2

Non credo che si possa dire che sono uguali, anche se sono termini correlati. Che dire delle funzionalità che abbracciano diverse storie utente?

— sleske,

@sleske Una user story in un approccio Scrum puro dovrebbe essere un valore aggiunto per l'utente e quindi una caratteristica. Se stiamo andando a catalogare le funzionalità come Epics generali va bene, ma il risultato finale sono le storie degli utenti che offrono valore.

— Aaron McIver il

1

@AaronMcIver: Sì, è vero. Tuttavia, a volte la minima quantità di funzionalità che è veramente utile per l'utente (= funzionalità) è troppo per una user story (o anche per una iterazione). In tal caso è necessario suddividere la funzionalità in più storie.

— sleske,

BTW, domanda relativa & risposta: stackoverflow.com/questions/1714557/...

— sleske

7

Una User Story è una dichiarazione informale nella lingua del cliente che cattura l'intento di qualcosa che il cliente desidera ottenere. Puoi pensare a una User Story come a una Dichiarazione di requisiti informali.

Una caratteristica del software è una caratteristica distinta del software che contribuisce alla progettazione e alla funzionalità complessive del software.

Un paio di considerazioni chiave:

Una storia può descrivere una caratteristica , ma una caratteristica non descrive mai una storia .
Una storia potrebbe non descrivere direttamente una caratteristica .
Una storia può implicare l'inclusione di una serie di caratteristiche .
Una caratteristica - singolarmente o come membro di una raccolta di caratteristiche - può catturare l'intento di una storia .

Con tutto ciò in mente, tendo a pensare alle storie come descrizioni. Requisiti fondamentalmente informali che mi dicono ciò che il cliente desidera. D'altra parte, tendo a pensare più a una specifica che mi dice come dovrebbe funzionare un sistema per soddisfare le esigenze dei clienti.

— S.Robins
fonte

3

I due termini sono strettamente correlati, ma ci sono alcune differenze.

Innanzitutto, provengono da domini diversi. Il termine "funzionalità" è un termine abbastanza generico per alcune parti della funzionalità di un software, mentre "user story" è stato inventato per ed è realmente utilizzato solo nel contesto dello sviluppo agile del software.

In pratica, molto spesso coincidono, in quanto una storia utente consiste nell'implementare una determinata funzionalità.

Tuttavia, in alcune situazioni possono essere diversi:

Spesso, una funzione è troppo lavoro per una storia per singolo utente. Le storie degli utenti non dovrebbero essere troppo grandi (in genere non più di qualche giorno, massimo 1-2 settimane di lavoro). Ovviamente molte funzionalità sono molto più grandi. In tal caso, una funzionalità verrà implementata in molte storie utente. Alcune persone usano "epopee" per raggruppare le storie degli utenti, in tal caso si potrebbe dire che la funzionalità è un'epopea.
I requisiti non funzionali (prestazioni, sicurezza, compatibilità ecc.) Possono anche essere gestiti come user-story (sebbene ciò non sia universalmente accettato). In tal caso, il risultato della user story non verrebbe normalmente chiamato funzionalità (a meno che non si chiami "funzionalità raramente la nostra applicazione").

— sleske
fonte