Dovrebbe creare e modificare essere due storie utente separate?

La cosa fondamentale da considerare qui è se le tue storie sono pezzi di lavoro gestibili .

Per essere gestibili devono essere:

• Definito in modo univoco
• Abbastanza facile da stimare
• Completabile all'interno di uno sprint

Quindi, se trovi che la fusione di due storie compromette in qualche modo uno dei punti precedenti, allora non farlo.

Personalmente, preferisco lavorare con molte storie di piccole in quanto trovo più semplice stimare in questo modo. Il compromesso è che devi quindi essere cauto nell'ordinare storie correlate o dipendenti nello sprint (un'attività abbastanza banale).

Penso che l'opzione A, con storie utente separate, sarebbe preferibile.

Le storie degli utenti sono requisiti. Ci sono un insieme di caratteristiche di un buon requisito che tendono ad essere ben accettati. L'opzione A garantisce che le storie degli utenti siano coerenti (affronta una sola cosa), atomica (non contiene congiunzioni) e più facilmente verificabile dell'opzione B.

Da un punto di vista della stima, è probabilmente più facile stimarne uno individualmente camminando tra i flussi di lavoro e i casi d'uso. Probabilmente vedrai elementi comuni e / o dipendenze tra di loro (ad esempio, devi crearne uno prima di poterne modificare uno), ma puoi dare stime più realistiche se li dividi in parti più piccole.

Da un punto di vista dell'implementazione, tuttavia, è probabile che sia necessario fornire entrambe le funzionalità insieme per rendere un rilascio realmente utile per un utente finale. Ciò può essere gestito nella pianificazione dell'iterazione, però. A seconda del ciclo di rilascio, possono finire in una versione ma in diverse iterazioni, se una release non avviene dopo ogni iterazione. Tutto dipende dalla pianificazione e dalla gestione.

TL; DR Dovrebbero essere due requisiti separati ma correlati.

Il rischio di eseguirli come requisiti separati è che avrai un codice duplicato per l'interfaccia utente associata e i servizi sottostanti. Ma il rischio nel combinarli come un singolo requisito è che il percorso di modifica ha un setup leggermente diverso.

Un percorso create sarebbe simile a questo:

• Utente autorizzato (AU) accede al sistema, apre create user pannello
• AU accede e verifica i dettagli per il nuovo utente
• AU invia crea richiesta al sistema
• System convalida le regole aziendali relative agli account utente
• I sistemi memorizzano l'account utente (probabilmente un'istruzione di inserimento)

Un percorso edit sarebbe simile a questo:

• Utente autorizzato (AU) accede al sistema, apre edit user pannello
• AU richiede i dettagli dell'utente da recuperare
• Il sistema recupera i dettagli dell'utente e presenta le informazioni ad AU
• AU regola i dettagli per il nuovo utente
• AU invia la richiesta di modifica al sistema
• System convalida le regole aziendali relative agli account utente
• I sistemi memorizzano l'account utente (probabilmente una dichiarazione di aggiornamento)

C'è un evidente riutilizzo con i pannelli di creazione e modifica degli utenti. Allo stesso modo, è possibile riutilizzare la stessa routine per controllare le regole aziendali contro l'account utente.

Ma il percorso di creazione non ha bisogno di recuperare i dettagli utente esistenti, ed è possibile che il percorso di creazione abbia prompt leggermente diversi come con la configurazione della password.

La decisione finale su quale percorso seguire dipende da come funziona il tuo team di sviluppo. Dalla mia esperienza, avere due storie utente separate fa un lavoro migliore nel rappresentare il carico di lavoro coinvolto nella gestione del progetto. E in generale i due compiti verrebbero assegnati alla stessa persona, il che ridurrebbe la necessità di ulteriori comunicazioni / coordinamento durante il lavoro sui requisiti.

Se guardi alla prospettiva più ampia quando hai storie di utenti strettamente correlate, devi prendere un momento e abbozzare brevemente ciò che è coinvolto in ogni storia. Se c'è una differenza significativa tra le storie, allora penso che tu stia meglio usando storie separate. Questo aiuta a garantire che la differenza significativa non sia sepolta all'interno della storia combinata.

Penso che dipenda davvero dalle storie stesse, hai intenzione di differenziare il processo o l'amministrazione delle due attività?

Potrei immaginare uno scenario in cui non c'è davvero alcuna differenza al di là del fatto che tu stia creando o meno un nuovo record. Questo potrebbe essere fatto come una singola storia.

Potrei anche immaginare uno scenario quando solo alcuni amministratori possono creare un account, ma un gruppo più ampio di amministratori di applicazioni o servizi potrebbe essere in grado di aggiornare le parti dell'account utente. Questo suona come due (o più) storie di utenti.