La documentazione è una User Story? [chiuso]

11

Abbiamo bisogno di fare un po 'di documentazione per l'utente per un prodotto su cui abbiamo lavorato per gli sprint precedenti. Ora stiamo iniziando un nuovo progetto nel prossimo sprint e l'OP sta facendo la documentazione per il prodotto prodotto in precedenza una User story per questo sprint.

Mi sto solo chiedendo la tua opinione su questo approccio. Personalmente, non sono d'accordo che la documentazione sia una User Story in Scrum perché non produce alcun codice.

EDIT: Grazie per le vostre opinioni ragazzi. Ho avuto nella parte posteriore della mia testa che uno sprint è stato quello di implementare un incremento del software di lavoro, ma le vostre opinioni hanno cambiato la mia prospettiva. Grazie per tutte le tue risposte.

    
posta ediblecode 06.01.2012 - 18:45
fonte

4 risposte

13

"Come utente di X, ho bisogno di sapere come funziona X" mi sembra una storia utente legittima. Ciò potrebbe comportare la documentazione scritta o l'aiuto online.

Il punto non è solo il codice: soddisfa i requisiti degli utenti.

    
risposta data 06.01.2012 - 19:07
fonte
10

Idealmente, la documentazione è parte di ogni storia di un utente e non si accumula mai. Ma, nel mondo reale, questo spesso non accade. In tal caso, dovresti creare una User story per recuperare su una specifica documentazione mancante.

Hai ragione, non produce alcun codice. Ma soddisfa un requisito dell'utente e dovrebbe avere la priorità rispetto ad altri requisiti utente.

Se ciò significa che non viene mai eseguito, poiché questa e quella funzionalità sono state elaborate, probabilmente non hai avuto bisogno della documentazione in modo errato.

    
risposta data 06.01.2012 - 18:58
fonte
2

Sono d'accordo con la valutazione della documentazione di pdr se si tratta di requisiti, documentazione tecnica o di progetto. Idealmente dovrebbe essere incorporato nel lavoro di sprint.

La documentazione del prodotto mi sembra molto diversa in quanto è un utente reale richiesto e fornisce direttamente valore all'utente. Ciò dovrebbe essere inteso naturalmente che la Documentazione del prodotto è essenzialmente non un'attività tecnica ma un'attività funzionale e può o meno essere un'attività adatta per una risorsa tecnica nel progetto.

Penso che dovrebbe essere una user story, tuttavia ritengo che una risorsa di progetto che abbia una solida comprensione dei requisiti aziendali, della prospettiva dell'utente e delle buone capacità di scrittura tecnica dovrebbero essere assegnate a questi compiti. Idealmente questo sarebbe un analista di business se disponibile, o forse un tester QA di livello superiore con una solida comprensione dei requisiti, delle user story e delle buone capacità di scrittura tecnica. Questo potrebbe anche essere uno sviluppatore, tuttavia la documentazione del prodotto scritta dagli sviluppatori tende a non essere di alta qualità o utile perché gli sviluppatori di solito sono troppo vicini ai dettagli tecnici.

    
risposta data 06.01.2012 - 19:18
fonte
1

Nella nostra organizzazione, il team di tooling, incaricato di mantenere e migliorare il nostro sistema di integrazione continua, sta utilizzando Scrum per aiutarli a gestire il proprio lavoro. Non stanno scrivendo il codice, ma stanno comunque praticando Scrum.

Per rispondere in modo specifico alla tua domanda, ti chiederei se il team ritiene che la documentazione faccia parte o meno della "Definizione di fatto".

Se il team ritiene che la documentazione sia parte della "definizione di fatto", allora non c'è bisogno di una storia aggiuntiva e la storia non può essere accettata a meno che la documentazione non sia scritta e convalidata.

Se il team ritiene che la documentazione non faccia parte della "definizione di fatto", creerei una storia separata in modo che il proprietario del prodotto possa gestire il proprio lavoro.

    
risposta data 12.01.2012 - 07:07
fonte

Leggi altre domande sui tag