Modo corretto per interrompere la funzionalità nelle storie degli utenti

Un approccio più "verticale" è la guida comune sulla suddivisione delle storie. Ciò che rafforza è:

• Un team multifunzionale in grado di lavorare sull'intero prodotto
• Creazione di una strada sterrata e aggiunta di funzioni
• Mantenere la parte di una funzione aggiunta utile all'utente finale

Tuttavia, quello per cui non ho una buona risposta è che di solito c'è un lavoro di preparazione per la strada sterrata. Per rimanere "in metafora", è necessario cancellare il percorso e rendere un livello di superficie. Questo tipo di cose si fondono nella prima storia che viene costruita. Dopo di che i pezzi aggiuntivi vanno velocemente, ma il lavoro di preparazione è difficile da spiegare correttamente. Da solo non aggiunge alcun valore diretto all'utente, ma è necessario aprire la strada al nuovo set di funzionalità.

In questo esempio, potresti iniziare con la cosa più semplice:

• Visualizza 1 mese
• Evidenzia l'intervallo di date selezionato

La prossima storia sarebbe:

• Visualizza secondo mese

Infine,

• Aggiungi lo scorrimento in avanti e scorri indietro per i mesi visualizzati

Con questo esempio, l'utente ha qualcosa di minimamente utile dalla prima implementazione. La prossima storia è principalmente relativa alla UI poiché potresti dover riorganizzare i controlli per presentare i mesi fianco a fianco. Se non hai ancora creato la vista mensile, è il componente di visualizzazione, sai che devi farlo ora. Infine, la possibilità di scorrere avanti e indietro finirà per essere più di modifiche di back-end.

Questo è solo un esempio di come farlo in questo caso. Basti pensare a quale sarebbe la soluzione minima praticabile per la prima storia, e con ogni storia successiva si sta rendendo l'applicazione sempre più utile.

Non sono d'accordo sul fatto che le storie che hai presentato siano affettate orizzontalmente. Con l'affettamento orizzontale, vedi storie che sono indirizzate a diverse discipline all'interno del team o storie che non offrono nessuna funzionalità all'utente fino a quando non viene completata la funzione completa.

Se hai storie affettate verticalmente, ogni storia offre qualcosa all'utente, anche se la trama non offre abbastanza per soddisfare il bisogno dell'utente. In questo senso, le tue storie mi sembrano fette verticali, anche se potrebbero essere create fette verticali diverse (come le fette mostrate da @ Berin nella sua risposta ).

Riguardo a unirli in una singola storia, questo dovrebbe essere considerato solo se la trama per il "componente DatePicker completo" è abbastanza piccola da essere facilmente completata in un singolo sprint.

Ecco i problemi che ho con le storie degli utenti che elencherai: sembra che ci sia un'attuazione esatta in mente e qualcuno stia cercando di scrivere storie di utenti intorno a questo. Questo non è il punto o il vantaggio delle storie degli utenti. Le storie degli utenti dovrebbero essere scritte pensando all'utente. Qualcosa come:

As a meeting organizer, I'd like to be able to pick a date off a calendar because sometimes I know it's the third Saturday, but I don't know the date.

e poi su quello:

As a meeting organizer, I'd like to be able to switch months I'm looking at so that I can plan further out than this month.