Qual è la differenza tra user story e feature?

Una funzionalità è un elemento distinto di funzionalità che può fornire funzionalità al business.

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 funzionalità potrebbe essere "consentire agli utenti di commentare gli articoli". Le storie associate a tale funzione potrebbero quindi essere:

• salva i commenti
• filtra i commenti per parole maleducate
• limita i commenti a 400 caratteri e ritorna agli utenti
• aggiungi i captcha per impedire ai bot di inviare spam al sito
• consente agli utenti di accedere tramite l'ID di Google

ecc.

In ogni fase possiamo quindi ottenere feedback sul fatto che la direzione che stiamo prendendo sia utile.

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

Caratteristiche == User Story.

La verbosità è dettata dalla metodologia utilizzata da Agile.

The different methodologies use different terminology to refer to features. It is up to the team to decide which methodology or terminology to use. Extreme Programming (XP) uses the terms User Stories or Stories to represent features; Scrum uses Product Backlog to describe a feature list; Feature-Driven Development uses Feature; and DSDM uses Requirement. Similarly, there are various lightweight versions of the Unified Process, or Agile UP, that use Requirement and/or Use Case to define incrementally deliverable functionality. Ultimately, the goal is the same - to deliver business value regularly in small increments, and sooner rather than later.

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

Una caratteristica del software è una caratteristica distinta del software che contribuisce al design e alla funzionalità generali del software.

Un paio di considerazioni chiave:

• Una storia può descrivere una funzione , ma una caratteristica non descrive mai una storia .
• Una storia potrebbe non descrivere direttamente una funzione .
• Una storia può implicare l'inclusione di un certo numero di Caratteristiche .
• Una funzione - singolarmente o come membro di una raccolta di Funzioni - può catturare l'intento di una storia .

Con tutto questo in mente, tendo a pensare a Storie come descrizioni. Requisiti fondamentalmente informali che mi dicono cosa vuole il cliente. Le caratteristiche, d'altra parte, tendono a pensare più come una specifica che mi dice come dovrebbe funzionare un sistema per soddisfare i requisiti dei clienti.

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

In primo luogo, 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 di software agile.

In pratica, coincidono molto spesso, in quanto una storia utente consiste nell'implementazione di una determinata funzione.

Tuttavia, in alcune situazioni possono essere diversi:

• Spesso, una caratteristica è troppo lavoro per una singola storia utente. Le storie degli utenti non devono essere troppo grandi (generalmente non più di pochi giorni, max 1-2 settimane di lavoro). Ovviamente molte funzionalità sono molto più grandi. In tal caso, una funzionalità sarà implementata in molte storie di utenti. Alcune persone usano "epiche" per raggruppare le storie degli utenti insieme, in tal caso si potrebbe dire che la caratteristica è epica.
• I requisiti non funzionali (prestazioni, sicurezza, compatibilità ecc.) possono anche essere gestiti come storie utente (sebbene questo non sia universalmente accettato). In tal caso, il risultato della user story non sarebbe normalmente chiamato feature (a meno che non si chiami "la nostra applicazione raramente blocca" una funzionalità).