Come mantenere tristi e user story triti e semplicistici?

Question

Come mantenere tristi e user story triti e semplicistici?

#1 da (4 voti)
#2 da (3 voti)

0

Sto avendo problemi a mantenere le mie user story per le operazioni di base dal suono ... basic. Ad esempio, supponiamo che sto creando un CRM per tenere traccia dei clienti:

C: Come utente, voglio creare un cliente, quindi posso ... tenere traccia dei miei clienti?
R: Come utente, voglio visualizzare i miei clienti e le loro proprietà, quindi posso ... sapere cosa sta succedendo?
U: Come utente, desidero modificare le informazioni dei miei clienti, quindi non posso ... non utilizzare informazioni obsolete?
D: Come utente, voglio eliminare un cliente, quindi non posso ... avere vecchi clienti in giro?

Sembra che ci siano molti motivi per voler eseguire operazioni CRUD sui tuoi oggetti, la ragione principale è una sorta di ovvia ragione "solo perché". Suppongo di poter scegliere una sola ragione. Ad esempio:

Come utente, voglio visualizzare i miei clienti e le loro proprietà, quindi posso sembrare esperto quando chiamano.

Ma ci sono molte, molte più ragioni per cui voglio vedere i miei clienti. Sarebbe noioso enumerare ogni motivo per cui vorrei cercare un cliente, e anche se ci provassi, probabilmente non sarei ancora in grado di pensare ad ogni motivo.

Come scrivi storie degli utenti per le operazioni di base?

agile scrum crud user-story

posta Travis 04.12.2018 - 16:42

fonte

2 risposte

Leggi altre domande sui tag agile scrum crud user-story

Dovrei scegliere di non utilizzare l'API di qualcuno? Fattori decisivi nella programmazione delle coppie

score 4 · Answer 1

Le tue ragioni ("So I can ...") sono troppo vaghe.

"Tieni traccia dei miei clienti" non è un requisito; è un desiderio. Rendi le tue ragioni più specifiche. Un vero requisito è sempre accompagnato da un test che, quando viene eseguito il test, consente una dichiarazione di successo univoca se il test ha esito positivo.

Il tedio non è una buona scusa per non scrivere requisiti e specifiche dettagliati. Dici che ci sono molte, molte ragioni per cui potresti voler tenere traccia dei tuoi clienti? L'enumerazione di questi motivi renderà il software migliore.

CRUD non è una buona user story.

Le buone applicazioni non sono solo creazione, lettura, aggiornamento e cancellazione; se fosse vero, potremmo generare automaticamente ogni nuova applicazione da uno schema di database. Le buone applicazioni eseguono operazioni aziendali riconoscibili come "fare una vendita" e "riconciliare questo account". Rappresentano processi e flussi di lavoro effettivi. Quindi dovresti usare i tuoi casi.

Lo stesso si può dire dell'architettura dell'applicazione. Molti sistemi espongono un modello CRUD al client, ma a volte è meglio esporre le operazioni aziendali effettive in un livello di servizio e lasciare che il livello di servizio effettui le chiamate CRUD necessarie.

score 3 · Answer 2

Il tuo utente non vuole queste cose. Il tuo utente desidera un sito Web in cui inserire i dettagli del cliente con i pulsanti shiney e ogni sorta di bontà dell'interfaccia utente.

Lo sviluppatore vuole implementarlo tramite un'interfaccia CRUD.

Cerca di rendere le storie degli utenti da ciò che effettivamente direbbe l'utente. vale a dire

"As a User I want a Save Button which will store the Client Details so that I can View them later"

Questo genererà un intero carico di attività secondarie

"Add save button to client detail page"
"Create Client Database table with fields..."
"Create API for Client DB with Create action"
"Add java script to savd button so that Api is called"

etc

Quando tutte le attività sono terminate, puoi guardare indietro alla storia degli utenti e dire ... OK, tutte le cose in realtà forniscono ciò che l'utente desiderava?

Per fare ciò il motivo deve fornire allo sviluppatore informazioni sufficienti in modo che possano capire quando la loro soluzione non soddisfa le esigenze degli utenti.

Ma deve anche essere abbastanza breve in modo che l'utente possa esprimerlo senza un processo di analisi aziendale esteso

Quindi "Così posso valutare i dati del cliente" non è sufficiente.

E "In modo che io possa vedere i campi X, Y e Z con i limiti di carattere a, b e C nei caratteri I, J e K" è troppo.

La giusta dimensione dipenderà dal livello di conoscenza degli sviluppatori sull'argomento