Agile - User Story Definitions [chiuso]

Question

Sto scrivendo una piccola app per gli affari dei miei amici e ho pensato di cogliere l'occasione per rispolverare un po 'di formazione sull'Agile Project Management che ho fatto all'inizio dell'anno.

Io (e penso, la mia attuale organizzazione!) ho sempre lottato per raccogliere i requisiti sotto forma di User Story, che prendono la forma:

Come [tipo di utente] voglio [funzionalità] in modo che [alcuni vantaggi]

Sono sempre tentato di perdere l'inizio e la fine e di abbandonare la funzione, ma questo diventa semplicemente requisiti che si raccolgono alla vecchia maniera!

Ma non voglio solo adattarlo, in modo da poter dire "Sto agile" .... ad esempio, se so che all'utente verrà presentato un elenco di elementi, allora la ragione è evidente, non è vero?

per es.

Come [Store Manager] voglio [vedere un elenco di articoli in stock] in modo che ...?

È normale escludere la clausola [così che]?

Answer 1

Anche noi ci mancavamo. E lasciandolo fuori ci siamo persi molto. Per comprendere correttamente la funzione e non solo fare la cosa giusta, ma FARE LA COSA GIUSTA è la chiave per sapere PERCHÉ la funzione, e per questo la chiave successiva è CHI (il ruolo) In termini DDD, stakeholder. Le parti interessate possono essere diverse, chiunque si preoccupi. Da programmatori e amministratori db a tutti i tipi di utenti.

Quindi, per prima cosa capisci, chi è lo stakeholder, poi conosci il 50% del PERCHÉ se ne frega, poi il vantaggio, e quindi è quasi ovviamente COSA implementare.

Cerca di non scrivere " come utente " ;. Specificare. "come responsabile del negozio", o anche "come capo del turno responsabile della chiusura della giornata", ho bisogno di ... in modo che ....

Forse puoi implementare qualcosa di diverso che darà allo stesso stakeholder un vantaggio ancora migliore !!!

Answer 2

Prova a raggiungere [valore aziendale] Come [utente] ho bisogno di [funzione].

L'obiettivo è concentrarsi sul valore offerto dalla funzione. Ti aiuta a pensare in sezioni verticali, il che riduce le "attività tecniche" pure " che non sono visibili. Non è una transizione facile, ma quando inizi a pensare in verticale inizi davvero a ridurre gli sprechi nel tuo processo.

Un altro modo è quello di pensare ai test di accettazione che il cliente potrebbe scrivere per assicurarsi che la funzionalità funzioni. È quindi un salto in avanti usare qualcosa come FitNesse per automatizzare quei test.

Answer 3

No, in realtà non è ovvio - ci sono molti motivi per voler vedere un elenco, molte cose che potresti desiderare con esso - scansionalo per alcune informazioni, ottieni una panoramica, stampalo, copia e incolla in un documento word ecc. E che cosa esattamente ti darà preziosi suggerimenti su ragionevoli dettagli di implementazione - formattazione dell'elenco, contenuto esatto; o anche un suggerimento che una diversa funzionalità potrebbe essere un'idea migliore per soddisfare tale esigenza. Non essere sorpreso di scoprire che il motivo è in realtà " in modo da poter contare il numero di voci " ...

Ovviamente, questo potrebbe in realtà non valere per te. Il mio vero punto di fatto è che ci sono ragioni per cui le persone hanno escogitato questo modello - e ci sono anche ragioni per cui molte persone esperte non lo usano realmente. E quando sei nuovo nella pratica, non sei in una buona posizione per valutare tutti i pro e i contro di seguire una pratica, quindi consiglio vivamente di provare semplicemente a seguirla da vicino per qualche tempo. Potresti essere sorpreso dall'utilità di esso - o no, nel qual caso hai ancora imparato qualcosa e puoi lasciarlo cadere con un chiaro conciso ... :)

Answer 4

User Stories è un altro modo per dire che devi intervistare i tuoi utenti per scoprire cosa vogliono e quali problemi stanno cercando di risolvere. Che il cuore di avere questo nello sviluppo agile. Se il modulo non funziona per te, fai un passo indietro e prova un approccio diverso che ti sembra più naturale o più adatto alle tue capacità di scrittore.

In breve, non sentirti come se dovessi indossare una giacca dritta. L'importante è seguire lo spirito della metodologia.

In questo caso specifico, vuoi ottenere un elenco di quali problemi ha l'utente, perché sono problemi e cosa pensano che li aiuteranno.

Answer 5

Penso che dovresti davvero provare a definire un motivo, anche se può sembrare ovvio. Se non riesci a trovare un motivo, allora perché creare la funzionalità in primo luogo? Inoltre, il motivo potrebbe indicare altre carenze nella progettazione che potrebbero innescare miglioramenti in altri settori.

Answer 6

Spesso categorizzo le mie storie per utente / persona a cui si riferisce principalmente, quindi non inserisco l'identità dell'utente nel titolo della storia. Anche le mie storie sono più grandi di quanto suggeriscano alcune metodologie agili. Di solito, inizio con un titolo. Lo uso a fini di pianificazione. Una volta che mi sto avvicinando davvero a lavorare su quella storia, la perfeziono con alcuni dettagli - idea di base, vincoli, ipotesi, storie correlate - in modo da catturare più informazioni che conosco al riguardo. Tengo anche le mie storie in un wiki, non sulle carte per appunti. Comprendo il compromesso, vale a dire, potrei dedicare troppo tempo ai dettagli prima di averne bisogno, ma sono in grado di acquisirli e condividerli con, in genere, clienti fuori sede facilmente.

La linea di fondo per me è che Agile è una filosofia, piuttosto che una specifica. Esistono implementazioni particolari che possono (fortemente) suggerire di fare le cose in un certo modo e che potrebbero non essere negoziabili su alcuni elementi. Ad esempio, è difficile dire che stai facendo XP se non accoppi il programma. In generale, però, direi che la maggior parte degli agilisti direbbe che dovresti fare quelle cose che funzionano per te, nel modo in cui lavorano per te - fintanto che sono coerenti con i principi generali, puoi ancora chiamare agile. I principi generali includono cose come rilascio anticipato / rilascio frequente, test unitari, brevi iterazioni, riconoscimento del cambiamento, ritardo della pianificazione dettagliata fino a quando non si è pronti per l'implementazione, ...

Linea di fondo per me: se le storie funzionano per te senza l'utente e la logica - fintanto che capisci chi è l'utente e perché vogliono qualcosa - fallo nel modo che preferisci. Basta non richiedere una specifica completa prima di iniziare l'implementazione.