Qual è la differenza tra un'User Story e una funzione nella terminologia Agile? [chiuso]

Question

Credo che una caratteristica potrebbe essere qualcosa del tipo "autorizzazione carta di credito", mentre una storia utente può essere "autorizzare la carta di credito per PayPal".

Quindi, è una storia utente un sottoinsieme di una caratteristica?

Answer 1

Sì, qualcosa di simile a un sottoinsieme. Questo articolo è una buona lettura:
Caratteristiche vs Storie

Estratto:

  

mi sono reso conto oggi che non avevo fatto   esplicita la differenza nella mia mente   tra le caratteristiche e le storie e che sia   una differenza importante. Essenzialmente,   una caratteristica è un gruppo di storie che   sono correlate e fornire un pacchetto di   funzionalità che gli utenti finali avrebbero   generalmente si aspettano di ottenere tutto in una volta.   Ad esempio, tabella integrata ridimensionamento è   una caratteristica (nota: questa è la capacità   a trascinare per ridimensionare tabelle, righe e   colonne - provano in Word). Nel   primo passaggio, si sarebbe probabilmente avete un   singola storia per la linea di ridimensionamento   tavoli, ma sarebbe troppo grande per   stima. Così si scomposizione in   tre storie, ridimensionare le colonne, ridimensionare   righe e ridimensionare la tabella stessa.

Answer 2

Kent Beck e Martin Fowler storie e caratteristiche sono sinonimi:

  

Una storia utente è un pezzo di   funzionalità (alcune persone usano il   parola caratteristica ), che è di valore per   il cliente.

Che si chiama un caratteristica è solitamente indicato come tema o epico . Temi e epopee sono utilizzati per le storie degli utenti gruppo di set di funzionalità più grandi, che hanno un senso per conto proprio.

Da un punto più di vista semantico: caratteristica è una parte del sistema che si sta tentando di costruire, user story è un modo per descrivere quella parte.

---

Correzione:

Come Pascal ha sottolineato - ho forse perso il vero significato di "funzionalità" in quella citazione ( "funzione" si riferisce ovviamente alla funzionalità) A parte questo, io continuo a pensare che si può usare queste parole (funzione e la storia utente) come sinonimi in un sacco di contesti ( "sto lavorando su questa storia" contro "sto lavorando a questa funzione"), dal momento che, come diceva Pascal, una storia utente è un modo per catturare una caratteristica. Il che significa che v'è una relazione 1: 1 tra i due. E, come si può vedere dalla mia osservazione sulla semantica, è così che ho davvero capito.

Answer 3

Non è affatto ..

Una storia utente rappresenta piccole parti di valore di business. Così è davvero difficile dire quando una storia utente è un sottoinsieme di una funzione o una funzione è un sottoinsieme di una storia utente (anche tenere a mente che le storie degli utenti sono di solito scritti dalle parti interessate, che tendono a non sapere esattamente che cosa che vogliono ... :))

Quindi, se si segue la raccomandazione di agile per mantenere le storie brevi sarebbe caduta dello scenario "migliore" che è la storia utente ne sia un sottoinsieme della funzione.

Tuttavia, se il vostro parti interessate scrivere storie lunghe, ogni storia avrebbe un paio di caratteristiche (se c'è una buona comunicazione tra la squadra e le parti interessate questo non accadrà in quanto la squadra si romperà le storie in quelle piccole)

Answer 4

Le caratteristiche sono ciò che un sistema sta facendo. le storie degli utenti sono solo un modo tra gli altri per catturare caratteristiche.

Answer 5

Ho appena imbattuto in questo argomento quando ero alla ricerca di idee diverse su "utilizzando molteplici ruoli per esigenze simili".

Credo che, una caratteristica come contenitore di storie legate aiuta a dare priorità alle esigenze, perché le parti interessate di solito raccontano le loro esigenze, come storie dipendenti. In un recente progetto, il cliente mi ha detto quanto segue

Un membro può inviare messaggi al di amministrazione L'amministratore può inviare messaggi a tutti i membri I membri possono inviare messaggi a vicenda

Quando vedo questi requisiti, lo so, dovremmo implementare un sistema per consentire alle persone di inviare un messaggio e dovremmo aggiungere controlli per consentire a chi fare che cosa.

e anche io sapere che questi requisiti possono avere alcuni altri requisiti impliciti come leggere i messaggi che sono venuti, disponendole, possono essere impostando come spam ed ecc.

Quindi provo a riformulare questi requisiti come

In qualità di membro o di amministratore, posso inviare messaggi ad altre persone. In qualità di membro o di amministratore, posso leggere i messaggi che sono stati inviati a me.

E come i criteri di accettazione, premetto in dettaglio chi può inviare a chi.

Poi chiamo tutte queste cose come funzione "Private Messaging", in modo che, in un secondo momento, se il cliente decide che è un costo aggiuntivo, si può dire "Basta inserire la cosa messaggistica privata" e posso rimuovere tutti loro dal portafoglio ordini.