Come evitare o amalgamare minuscole storie di utenti in late project?

Question

Come evitare o amalgamare minuscole storie di utenti in late project?

#1 da (6 voti)

6

All'inizio di un progetto, scrivere le cose come storie degli utenti è un ottimo modo per ottenere un controllo sulla funzionalità di un progetto. Le storie in questa fase tendono a essere concepite e scritte in modo relativamente ampio, per coprire un secchio di funzionalità. Un paio di esempi del mio attuale progetto:

In qualità di addetto alle vendite, desidero ricevere una notifica se un lavoro supera un determinato limite la soglia di prezzo è stata creata, quindi posso offrire all'utente a sconto.
Come utente, voglio poter pagare il mio lavoro utilizzando una carta di credito.

E va bene.

Verso la fine di un progetto, tuttavia, è abbastanza comune che le omissioni siano individuate. Non sto parlando di bug ma di cose minori che nessuno ha preso in considerazione durante lo sviluppo, ma che sono venute alla luce attraverso test degli utenti o il controllo di scenari di utilizzo più complessi. Ancora una volta, un paio di esempi del mio attuale progetto:

Come utente, voglio vedere uno spinner durante i caricamenti lunghi in modo che sappia che il sito è ancora attivo.
Come utente, desidero essere portato direttamente al mio lavoro più recente quando accedo al sito tramite il link nell'e-mail "lavoro completato".

Questi sono minuscoli in termini sia di obiettivi che di sforzi rispetto alle storie originali e generiche degli utenti. Tuttavia, se il proprio manager desidera monitorare il progetto in modo completo, dovrà essere annotato e dettagliato come singoli articoli. E giustamente: se sono importanti, devono essere registrati e non dimenticati.

Questo mi irrita a diversi livelli. Queste piccole storie ingombrano un progetto e rendono più difficile il monitoraggio. Il tempo e gli sforzi necessari per scrivere queste piccole storie sembrano sproporzionatamente alti rispetto allo sforzo di limitarli a farlo.

È qualcosa che altri sviluppatori hanno trovato, o ci stiamo avvicinando al concetto di user story? Ci sono dei buoni metodi per gestire la dimensione sempre più restrittiva della storia, o è qualcosa che devi solo succhiare?

EDIT: non si tratta di evitare storie degli utenti in ritardo o di limitare lo scorrimento. Il mio obiettivo è quello di abbracciare aggiunte, obiettivi e tracciarli, ma di ridurre lo sforzo e la confusione derivanti dalla loro natura molto più granulare rispetto alle storie di progetti iniziali. All'inizio di un progetto potresti scrivere una storia e dividerla in 3-4 compiti, prendendo uno o due giorni ciascuno. Più tardi, ci troviamo a scrivere una storia con un'attività che potrebbe richiedere un'ora o due. Quindi, per studiare un lavoro di una settimana, potremmo finire per scrivere 15 storie di utenti invece di una. Questo richiede molto tempo e lascia la bacheca del progetto un pasticcio confuso.

project-management specifications user-story

posta Matt Thrower 27.04.2017 - 11:18

fonte

1 risposta

Leggi altre domande sui tag project-management specifications user-story

CQRS in domini collaborativi Quando dovresti usare le Classi locali in Java?

score 6 · Accepted Answer

Una piccola user story non dovrebbe essere un problema. Se il tuo processo aggiunge un sacco di spese generali alla gestione delle storie degli utenti, è necessario esaminare il processo o gli strumenti per renderlo più efficiente. In un moderno sistema di tracciamento dei problemi, la creazione di una user story dovrebbe essere di pochi clic.

Un sovraccarico amministrativo eccessivo potrebbe persino essere una causa del problema che vedi. Se è doloroso creare e gestire storie di utenti, incoraggi la scrittura di poche storie di utenti di grandi dimensioni piuttosto che un numero maggiore di storie utente più specifiche, il che significa che verranno trascurati altri dettagli.

The time and effort involved in writing up these tiny stories seems disproportionately high compared with the effort of just doing them.

Attenzione! Se ci vuole un sacco di tempo e sforzi per scrivere storie di utenti "piccoli", indica una delle due cose:

Le storie degli utenti non sono in realtà piccole, ma sembrano solo piccole finché non inizi a pensare agli scenari.
Non sei proprio sicuro di quali siano effettivamente i requisiti.

In entrambi i casi, scrivere la user story è un importante processo di chiarimento. Forse la modifica del codice è più semplice del chiarire i requisiti, ma se i requisiti non sono chiari, sicuramente scriverete il codice sbagliato, che comporta molti sforzi inutili e rischi aggiuntivi.