Come gestire storie che condividono funzionalità

Le User Story non sono specifiche di sistema o requisiti funzionali. Piuttosto, sono l'inizio di una conversazione che può portare a tali specifiche o requisiti.

Di conseguenza, mi aspetto che ci sia una sovrapposizione nell'implementazione del sistema. Le User Story non intendono descrivere tale sovrapposizione funzionale o eliminarla. Lo scopo delle User Story è quello di catturare le aspettative funzionali dal punto di vista dell'utente, non di descrivere i dettagli dell'implementazione.

Non: cerca e dividi le storie, fai una storia e poi l'altra.

Fai: assicurati che il team di sviluppo sia a conoscenza del secondo piano.

Il problema con il tentativo di pianificare le attività e le cose dettagliate su un modello generico in grado di gestire entrambi in modo elegante è che è difficile.

Lo scopo delle storie degli utenti è di fare le cose. L'elegante è un obiettivo secondario e dovrebbe essere lasciato al refactoring.

Ovviamente è super fastidioso se lo porti al massimo e non dire a nessuno delle altre dieci attività simili che hanno bisogno di fare, ma è anche del tutto concepibile che il secondo o il terzo compito non siano pensati fino a quando il primo non è fatto. Se vuoi pianificare tutto con la cascata.

In un violento accordo con Robert Harvey, lo scopo di una storia di un utente è capire che cosa l'utente deve essere in grado di fare. Mentre fai la tua toelettatura, il cliente capisce e si preoccupa della storia dell'utente, ma gli sviluppatori si preoccupano un po 'di più. Dopo aver chiesto abbastanza domande per comprendere e stimare il lavoro, è possibile creare attività per supportarle.

In questo caso specifico, potresti creare attività che consentano di mettere a fuoco il nucleo di entrambe le storie degli utenti insieme a qualsiasi cosa tu faccia per prima.

Le cose importanti da aggiungere alla user story sono:

• Criteri di accettazione
• Ipotesi

In senso stretto, le User Story sono la promessa di una conversazione per comprendere il risultato richiesto.

Ad esempio, prendendo la tua seconda user story

As a Credit Management User, I can receive an email containing a PDF of the current and previous payroll differences for Offices.

Pensa al seguente:

• Qual è l'utente "necessario" che sta guidando questo requisito? (Il PDF in una e-mail come soluzione viene da loro? Questo potrebbe non soddisfare le necessità e il tuo team potrebbe trovare una soluzione migliore)
• Qual è la porzione minima che può indirizzare questo utente "necessario" e convalidare la tua soluzione? Brevi cicli di feedback sono preziosi.

Quando ti avvicini alla suddivisione della storia, ricorda i tuoi criteri di INVEST, ove possibile.

1. I ndependent
2. N egotiable
3. V aluable
4. E stimatable
5. S centro commerciale
6. T estable

Va bene avere storie che hanno un ordinamento naturale. Prendilo in considerazione: solitamente la prima storia è più ampia in quanto introduce le funzionalità richieste e la seconda storia si basa su di essa.

Vorrei sfidare storie "tecniche", in quanto generalmente sono più probabili essere compiti che aiutano a supportare l'implementazione delle storie incentrate sui risultati degli utenti.

TL; DR

Supponendo che entrambe le storie utente siano incluse nell'ambito della stessa iterazione, è compito del team scomporre le storie in un piano di implementazione e nei relativi compiti. Le storie degli utenti forniscono contesto e scopo; non sono implementazioni, specifiche o elementi dell'elenco di punch.

Le storie dovrebbero essere decomposte in operazioni di iterazione

Sia che tu stia seguendo Scrum o qualche altra metodologia agile, è un errore comune saltare la fase di pianificazione di un'iterazione. In Scrum, quando si seleziona un Product Backlog Item (non è necessario che sia un utente storia, in senso stretto) viene inserito nell'attuale Sprint, il team deve quindi utilizzare parte di Sprint Planning per individuare elementi comuni tra gli elementi di lavoro, identificare le dipendenze, e quindi sviluppare uno Sprint Backlog per acquisire il lavoro a livello di attività .

Come hai sottolineato nel tuo post, non è insolito (ed è in effetti auspicabile) che una iterazione agile contenga storie utente strettamente correlate. In Scrum, questo è emerso attraverso l'uso dello Sprint Goal. Al di fuori del framework Scrum, spesso ha ancora senso inserire storie correlate perché dei loro obiettivi condivisi o dipendenze condivise. Estraendo e quindi lavorando sulle dipendenze condivise all'interno di una singola iterazione, i team possono spesso evitare la necessità di ridefinire o eseguire iterazioni sul codice per funzionalità simili ma non identiche in futuro.

Attività Implementare Storie

Ecco un altro modo di pensare alla pianificazione delle dipendenze per le storie degli utenti. In generale:

1. Un tema / epico viene utilizzato per la pianificazione o il raggruppamento a lungo termine su un backlog.
2. Una user story viene utilizzata per comunicare obiettivi, contesto e ambito.
3. La pianificazione just-in-time viene utilizzata per sviluppare un'implementazione che si adatta a una singola iterazione.
4. Le attività implementano il piano just-in-time che soddisfa la definizione di Fatto per una o più storie utente.

Trattare le storie degli utenti come un piano di implementazione o un elenco di attività è considerato dalla maggior parte dei professionisti un anti-modello agile. Qualunque cosa tu scelga di chiamarla, non saltare la fase di pianificazione just-in-time del tuo framework agile e assicurati di tenere traccia delle dipendenze e dei dettagli dell'implementazione condivisa da qualche parte all'interno del processo del tuo team.