Immagino che una funzionalità potrebbe essere qualcosa come "autorizzazione della carta di credito", mentre una storia utente potrebbe essere "autorizzi la carta di credito per paypal".Qual è la differenza tra una User story e una feature nella terminologia Agile?
Quindi, la trama di un utente è un sottoinsieme di una funzione?
Sì, qualcosa come un sottoinsieme. Questo articolo è una buona lettura:
Features vs Stories
Estratto:
mi sono reso conto oggi che non avevo fatto esplicita la differenza nella mia mente tra le caratteristiche e storie ed è un importante differenza. Essenzialmente, una funzionalità è un gruppo di storie che sono correlate e offrono un pacchetto di funzionalità che gli utenti finali sarebbero generalmente si aspettano di ottenere tutto in una volta. Ad esempio, il ridimensionamento in linea è una funzione (nota: questa è l'abilità da trascinare per ridimensionare tabelle, righe e colonne - provarlo in Word). Nel primo passaggio , probabilmente si dispone di un singolo articolo per il ridimensionamento in linea delle tabelle , ma sarebbe troppo grande per la stima . Quindi lo suddivido in tre piani, ridimensiona colonne, ridimensiona le righe e ridimensiona la tabella stessa.
Dai un'occhiata al post di 'Diego's 'in questa pagina, una prospettiva rinfrescante. –
Grazie ... Questo è un buon link che hai postato anche tu. Ogni volta che leggo l'esperienza di qualcuno che sta ripensando a quello che sta facendo, mi viene in mente l'argomento in un modo diverso. Questo è uno dei motivi per cui penso che questo sito sia fantastico .. tu continui sempre ad imparare –
Espressioni esatte qui :) –
Non a tutti ..
Una storia utente rappresenta piccole parti di valore di business. Quindi è davvero difficile dire quando una user story è un sottoinsieme di una feature o una feature è un sottoinsieme di una user story (tenere presente che le user story sono solitamente scritte dagli stakeholder, che tendono a non sapere esattamente quello che vogliono ... :))
Quindi, se si segue la raccomandazione di agile per mantenere le storie brevi si cade sullo scenario "migliore" che è la storia utente che è un sottoinsieme della funzionalità.
Tuttavia se il vostro stakeholder scrive storie lunghe, ogni storia avrà un paio di funzioni (se c'è una buona comunicazione tra il team e gli stakeholder ciò non accadrà dato che il team infrangerà le storie in piccoli)
Secondo Kent Beck and Martin Fowlerstorie e caratteristiche sono sinonimi:
una storia utente è un pezzo di funzionalità (alcune persone usano la parola funzione) che è di valore per il cliente.
Che si chiama una funzione è solitamente indicato come tema o epico. Temi ed epop sono usati per raggruppare le storie degli utenti a set di funzionalità più grandi, che hanno senso da soli.
Da un punto di vista più semantico: la funzionalità è una parte del sistema che si sta tentando di costruire, la 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 uno può usare queste parole (feature e user story) come sinonimi in molti contesti ("Sto lavorando su questa storia" vs. "Sto lavorando su questa caratteristica"), poiché, come ha detto Pascal, una user story è un modo per catturare una funzionalità. Il che significa che esiste una relazione 1: 1 tra questi due. E, come si può vedere dal mio commento sulla semantica, questo è il modo in cui lo capisco davvero.
"Quello che chiami una funzione viene solitamente definito tema o epico", mi piace questa analogia. :) –
Ho cancellato il mio commento per sbaglio, quindi lo sto rimettendo per chiarezza: sei sicuro che alcune persone usano la parola funzione non si applica alla funzionalità? –
BTW, mi piace molto l'addendum anche se ho un altro punto di vista (personalmente, vedo la relazione come * user story => feature * senza un'equivalenza rigorosa). –
Le funzionalità sono ciò che sta facendo un sistema. Le storie degli utenti sono solo uno dei modi per catturare le funzionalità.
Il mio punto, Pascal;) –
Mi sono imbattuto in questo argomento quando cercavo idee diverse su "utilizzo di più ruoli per requisiti simili".
Penso che una funzionalità come contenitore di storie correlate aiuti a dare priorità ai requisiti perché gli stakeholder solitamente raccontano le loro esigenze come storie dipendenti. In un recente progetto, il cliente mi ha detto quanto segue
Un membro può inviare messaggi con l'amministratore Admin possono inviare messaggi a tutti i membri I membri possono inviare messaggi a vicenda
Quando vedo questi requisiti, i sappi che dovremmo implementare un sistema per consentire alle persone di inviare un messaggio e dovremmo aggiungere controlli per consentire a chi fare cosa.
e anche io sapere che questi requisiti possono avere alcuni altri requisiti impliciti come leggere i messaggi che sono venuti, disponendole, possono essere impostazione come spam e ecc
così cerco di riformulare questi requisiti come
Come membro o amministratore, posso inviare messaggi ad altre persone. Come membro o amministratore, posso leggere i messaggi che mi sono stati inviati.
E come criterio di accettazione, dichiaro in dettaglio chi può inviare a chi.
Quindi chiamo tutte queste cose come funzionalità "Messaggistica privata", in modo che, in un momento successivo, se il cliente decide che si tratta di un costo aggiuntivo, può dire "Basta trascinare la cosa di messaggistica privata" e io posso rimuoverli tutti dal backlog.
Un archivio utente agile deve essere incentrato sulla persona. Ad esempio: "Come proprietario di un account, posso autorizzare la mia carta di credito per Paypal." Dopo ciò, vorrai ottenere criteri di successo dettagliati. – Jay
Esistono modelli UML per spiegare relazioni di storie, backlog, ecc. In http://scalingsoftwareagility.files.wordpress.com/2007/03/a-lean-and-scalable-requirements-information-model-for-agile- enterprises-pdf.pdf – Fuhrmanator