Come raccontare storie di utenti che sono state divise da un'epica più grande

0

Ho un'epica che comporta la creazione di un'applicazione mobile che recupera i dati di un utente che hanno precedentemente creato in un'applicazione web e che agiscono localmente. Sembra logico dividere l'epica come segue:

  1. App per dispositivi mobili che agisce su dati locali e mocked up

  2. App per dispositivi mobili che scarica i dati dalla API dell'app Web ma senza autenticazione

  3. App per dispositivi mobili che scarica i dati dall'API con l'autenticazione

  4. dell'app web

Sto faticando a scrivere queste storie. 1 è uno scenario che non avverrebbe mai per l'utente finale, non avrebbe dati locali se non fosse già stato recuperato in precedenza. Come direi questo?

Se 2 è "Come utente voglio che il mio dispositivo mobile agisca sulle [entità] che ho precedentemente creato tramite l'interfaccia web", allora cosa sarebbe 3? 'Come utente voglio che il mio dispositivo mobile agisca sulle [entità] che ho precedentemente creato tramite l'interfaccia web confidando che siano state recuperate in modo sicuro ' ??

    
posta SeeNoWeevil 22.04.2013 - 11:15
fonte

1 risposta

0

Nella storia 1, vorrei solo indicare quali operazioni l'utente può / vuole fare sui dati già presenti sul dispositivo e aggiungere una nota esplicita che l'origine dei dati non rientra nell'ambito della storia (eventualmente con un riferimento alla storia che gestisce il recupero / aggiornamento dei dati)

Il tuo suggerimento per la storia 2 sembra ragionevole, e la storia 3 potrebbe essere qualcosa come ", ma non voglio che Joe Random User sia in grado di accedere a quelle [entità] ". Questo dovrebbe darti l'incentivo per aggiungere la funzione di autenticazione, in modo che l'utente reale possa provare di non essere Joe Random User.

@thecapsaicinkid ha scritto in un commento:

If I'm splitting my stories in a way which requires me to fake data, is this an indication I'm not splitting in a helpful way?

Non necessariamente. Se la storia che richiede i dati falsi e la storia che sostituisce i dati falsi con i dati reali sono nello stesso sprint, non è affatto un problema. Alla demo non dovrebbe nemmeno essere evidente che è stato utilizzato a metà strada i dati falsi sprint. Se le due storie vengono programmate per gli sprint adiacenti, sarebbe al massimo un fastidio minore che il risultato del primo sprint non possa essere implementato in modo significativo per gli utenti finali. Potrebbe diventare un problema se la storia per fornire i dati reali viene spinta più indietro nel backlog, ma non è molto probabile.

A 'thin slice' which relies on fake data has value to the business; they can see the application working. But it has practically no benefit to the end-user. Should I try and simplify my slice even further (maybe a simpler UI) so I can find the time to get some real data into the system and have an app which does at least something useful to the end user?

Dipende e dovrebbe davvero essere discusso con il rappresentante del cliente. A volte sarebbe meglio suddividere un'epica in sezioni verticali (diverse storie, in cui ogni storia contiene sia il recupero dei dati, la manipolazione e l'interfaccia utente). E a volte devi solo accettare che è impossibile dividere un'epopea in più storie che sono tutte rilevanti per l'utente finale.

Se è così, non preoccuparti troppo. Il rappresentante del cliente molto probabilmente capirà la situazione e cercherà di dare priorità alle storie in modo tale che l'intera epica venga completata nel minor numero possibile di sprint (è nel loro interesse).

    
risposta data 22.04.2013 - 11:38
fonte

Leggi altre domande sui tag