Quando si disegna un backlog, ho diversi requisiti che si applicano a moltissime user story, ovvero aspetti dell'applicazione come la gestione degli errori e il feedback. Come posso includerli (senza usare una direttiva #include in ogni story utente)? Devo considerare la presentazione degli errori come una funzione, quindi avere user story per questa funzione come "il sistema rileva eccezioni e mostra le informazioni all'utente"?
Affrontare il feedback degli utenti è fondamentale per l'esperienza utente, ma si applica anche a diverse parti dell'applicazione in diversi modi.
Segui i seguenti due esempi:
Una storia potrebbe concentrarsi su un'interazione diretta dell'utente in cui si verifica un errore irreversibile. Viene utilizzata una finestra di dialogo modale per informare l'utente dell'errore e notificare che il ripristino è impossibile. La storia per questo sarebbe: "Come utente voglio essere informato su una voce non valida di alcuni dati in modo che possa tornare indietro e correggere immediatamente questo errore" . Questa storia utente implica che si tratta di un errore irreversibile di blocco che l'utente deve correggere immediatamente.
In una seconda storia l'utente dimentica di inserire dati obbligatori in un modulo. La storia sarebbe: "Come utente voglio che i campi mancanti in una voce siano evidenziati in modo da sapere quali sono i campi richiesti."
Questa sottile notifica è molto diversa e non può essere combinata con la prima storia in una storia generale di gestione degli errori. Tuttavia, entrambi possono derivare da eccezioni interne.
Ricorda che è importante comunicare il "cosa" di una storia, quindi ad esempio lo scenario di errore che dovrebbe essere trattato in una situazione specifica. Il modo in cui l'errore (ad esempio un'eccezione viene lanciata da qualche parte) è quasi irrilevante per il proprietario del prodotto in quanto non ha valore aziendale. Dal punto di vista tecnico avere un'architettura sonora è qualcosa che mi aspetterei dal mio prodotto in qualsiasi modo.
Alla fine otterrai flessibilità ed estensibilità concentrandoti sul valore aziendale e avrai storie di utenti e piccole ben separate p>
Credo che la soluzione sia una buona separazione delle preoccupazioni. Cose come la gestione degli errori, la registrazione, il feedback e simili dovrebbero essere gestiti globalmente con un solo pezzo di codice. Solo i requisiti, diversi da questo comportamento globale, devono essere annotati come parte delle storie degli utenti o in discussioni sull'implementazione di tale user story.
Quindi, dal lato della gestione del progetto, dovrebbe esserci una User story, che dice "Come utente voglio vedere l'errore in un modo simile, che mi permette di segnalarlo all'amministratore." o qualcosa di simile. E questa user story dovrebbe applicarsi come regola globale a tutti i casi d'uso.
Un'idea (presa da SCRUM): le cose che devono essere controllate per ogni storia utente sono incluse nel cosiddetto .
Di solito "definizione di fatto" include cose tecniche, come:
Ma può anche includere cose visibili all'utente:
Il team deve verificare la "definizione di fatto" per ogni storia di un utente prima che lo dichiarino.
Un'opzione consisterebbe nell'includere la gestione degli errori appropriata in questa "definizione di fatto". Tuttavia, come sottolineano le altre risposte, gli esempi che citi (errorhandling e feedback) sono in realtà non esempi davvero validi per i requisiti che si applicano "ovunque":
Corretta gestione degli errori & il feedback di solito dipende dal contesto, quindi deve essere definito separatamente per i luoghi in cui è necessario. Quindi in questo caso potrebbe essere meglio formulare la gestione degli errori come storie utente separate, come spiegato dalla risposta di malte.
Leggi altre domande sui tag project-management agile scrum