User story come modo per documentare le specifiche point-in-time del prodotto

Question

User story come modo per documentare le specifiche point-in-time del prodotto

#1 da (1 voti)
#2 da (0 voti)

5

Abbiamo un prodotto software esistente che viene trasferito su un processo agile.

I nuovi requisiti verranno catturati come storie utente, ma questo ha ispirato la domanda su cosa fare con i requisiti esistenti e quale sia la relazione tra le storie degli utenti e le specifiche / documentazione del prodotto.

Riesco a vedere il valore nel catturare tutti gli attualmente implementati e nuovi requisiti come storie degli utenti come un modo per rispondere alla domanda: "Cosa possono fare esattamente gli utenti con il prodotto in questo momento?" .

Al momento non ho bisogno di questo, ma posso vedere che è utile essere in grado di mostrare un cliente: "Ecco: questo è esattamente ciò che fa il prodotto". Questo può essere un buon modo per monitorare i nostri impegni contrattuali, o anche una checklist per l'acquisto.

In generale, tuttavia, le user story sono utilizzate come strumento per acquisire e implementare i nuovi requisiti e, per quanto ne so, le persone raramente eliminano una user story quando il requisito diventa obsoleto o non è necessario più. E senza fare questa "potatura" non hai più una specifica completa delle funzionalità del tuo prodotto in un momento specifico.

Suppongo che l'altro modo per acquisire questa specifica sia tramite test di accettazione ( Specifiche eseguibili ). Con qualcosa come il cetriolino hai un legame stretto tra storia, test di accettazione e specifiche.

TL; DR: Se volessi un modo per acquisire un elenco di funzionalità point-in-time o "specifiche" del mio prodotto software, come faresti? Le storie degli utenti tramite uno strumento di monitoraggio appropriato sembrano darci il potere di farlo ma non le ho mai viste per questo.

Nota: il team ha già una certa familiarità con l'agile, quindi questa domanda non riguarda la familiarizzazione con il processo.

agile

posta Schneider 22.02.2017 - 01:43

fonte

2 risposte

Leggi altre domande sui tag agile

Esegue il trigger sulla chiave primaria anziché sull'identità Progettazione di un'API flessibile con supporto per le callback

score 1 · Answer 1

Personalmente, non assegnerei risorse per reingegnerizzare le storie degli utenti su un'applicazione esistente tutto in una volta.

Inizia con le nuove richieste per sviluppare buone pratiche con questo processo (ottenere feedback dai clienti, generare storie sugli utenti, utilizzarle per lo sviluppo e infine avere funzionalità testate e approvate). Tutti dovrebbero diventare fluenti ed efficienti.

Una volta che tutte le persone coinvolte sono abili nel processo della storia dell'utente, raccolgono ulteriori storie su funzioni o sezioni dell'app relative alle nuove funzionalità. L'obiettivo qui è quello di identificare ciò che gli utenti desiderano veramente (forse una funzionalità può essere rimossa?), Quindi nessuno accidentalmente toglie qualcosa di necessario. Penso che questo sia un metodo più efficiente perché lo sviluppatore si sta familiarizzando con una certa parte della base di codice già. Usa quella conoscenza per sviluppare più specifiche.

Ricorda che le storie degli utenti sono ciò che l'utente desidera dalla loro prospettiva. Non c'è nulla su come questo viene realizzato. Una suite di test potrebbe aiutare a completare questa o la documentazione aggiuntiva sui requisiti, ma è necessario avere un team con una certa scioltezza in quest'area. Le squadre che lottano con i test di scrittura, proprio come scrivere storie di utenti non saranno in grado di creare qualcosa di molto utile. Stanno lottando per farlo funzionare.

La chiave è assicurarsi che l'adozione di questi nuovi processi (user story e test) abbia successo. Richiede tempo. Se continui a praticare queste cose, è improbabile che ne ricaverai tanto da loro quanto potresti pensare. Tutti saranno frustrati dal processo e questo finirà per essere uno spreco.

score 0 · Answer 2

Le storie degli utenti possono anche aiutare a definire le aspettative su ciò che ci aspettiamo che gli utenti e su come dovrebbero comportarsi con i limiti / gli stati di errore del sistema. [1]

Se disponi di specifiche di sistema (le considero più come pre-concordate limitazioni) che non possono essere descritte direttamente nelle storie degli utenti, prova a descrivere cosa accadrà quando l'utente è al limite del sistema e cosa succede quando vanno oltre a ciò.

[1]: questa è solo documentazione. Non costringere gli utenti a seguire le storie degli utenti. Se c'è un divario tra ciò che gli utenti stanno facendo e quello che ti aspetti che facciano, allora i requisiti non erano abbastanza buoni la prima volta e hanno bisogno di essere rivisitati.