Gestione delle storie utente per un grande progetto [chiuso]

Question

Stiamo appena iniziando un progetto piuttosto grande con molti sottoprogetti. al momento non utilizziamo alcun tipo di processo denominato, ma spero di ottenere un tipo di processo agile / miserabile dalla porta di servizio.

L'area su cui mi concentrerò di più è avere un buon arretrato per l'intero progetto e, almeno nella mia testa, l'idea di un'iterazione in cui alcune cose sono tratte dall'arretrato, esaminato più in dettaglio e sviluppato per una scadenza ragionevole.

Mi chiedo quali tecniche le persone usano per scomporre i progetti in cose da fare nel backlog, e una volta creato il backlog come viene gestito e ordinato. anche come vengono mantenute le relazioni tra gli elementi (cioè questo deve essere fatto prima che sia possibile farlo, o questa era una storia ora è cinque)

Non sono sicuro di come mi aspetto la risposta per questa domanda. Penso che ciò che può essere più utile sia se esiste un progetto open source che mantiene il suo backlog online in qualche modo in modo da poter vedere come gli altri lo fanno.

Qualcos'altro che otterrebbe +1 da me sono esempi di storie utente reali da progetti reali (la pagina "un utente può accedere" la storia non mi aiuta a immaginare le cose nel mio progetto.

Grazie.

Answer 1

Ti consiglierei di pensare attentamente prima di adottare uno strumento, soprattutto perché sembra che il tuo processo sia inizialmente fluido quando trovi i tuoi piedi. La mia sensazione è che uno strumento potrebbe avere maggiori probabilità di vincolarti che di abilitarti in questa fase e non troverai alcun sostituto per un buon wall-card nello spazio fisico . Ti suggerirei invece di concentrare i tuoi sforzi sul compito da svolgere e di prendere uno strumento quando senti di averne davvero bisogno. A quel punto molto probabilmente avrai un'idea chiara delle tue esigenze.

Ho eseguito diversi progetti agili ora e non abbiamo mai avuto bisogno di uno strumento più complesso di un foglio di calcolo, e quello su un progetto con un budget di oltre un milione di sterline. Principalmente scopriamo che una lavagna e le schede (una per storia dell'utente) sono più che sufficienti.

Quando identifichi le tue storie, assicurati di esprimerle sempre in termini che abbiano senso per i tuoi utenti - alcune (forse solo piccole) funzionalità di superficie. Non lasciarti mai scivolare nello scrivere storie su dettagli tecnici che non potresti dimostrare a un utente.

L'abilità nel programmare le storie è cercare di dare la priorità alle cose che sai prima di tutto (pianificare ciò che vuoi imparare, piuttosto che quello che vuoi fare) mentre inizi anche con le storie che ti permetteranno di sviluppare le funzionalità principali della tua applicazione, usando le storie successive per racchiuderle funzionalità (e complessità tecnica).

Se sei sicuro di poter lasciare qualche pezzo del puzzle fino a tardi, non sudare per entrare nei dettagli di ciò - basta scrivere una singola storia che rappresenti la grande conversazione che dovrai avere in seguito e andare avanti con le cose più importanti. Se devi avere un'idea delle dimensioni di ciò che verrà, guarda una tecnica di stima delphi a banda larga chiamata pianificazione del poker .

I libri di Mike Cohn, in particolare Stima e pianificazione agili ti aiuteranno a molto in questa fase, e darti alcune tecniche utili con cui lavorare.

Buona fortuna!

Answer 2

Come DanielHonig usiamo anche RallyDev (su piccola scala) e sembra che potrebbe essere un sistema utile per almeno investigare.

Inoltre, un ottimo libro sul metodo di sviluppo della user story è User Stories Applied di Mike Cohn. Consiglierei sicuramente di leggerlo se non l'hai già fatto. Dovrebbe rispondere a molte delle tue domande.

Answer 3

Non sono sicuro se questo è quello che stai cercando, ma potrebbe essere comunque utile. Max Pool di codesqueeze ha un video che spiega il suo "muro agile". È bello vedere il suo processo, anche se potrebbe non essere necessariamente correlato alla tua domanda:

My Agile Wall (Plus A Few Tricks)

Answer 4

Quindi, ecco alcuni suggerimenti: Usiamo RallyDev.
Abbiamo creato una vista dei pacchetti in cui vivono i nostri requisiti. Le storie di grandi dimensioni sono etichettate come epiche e inserite nel backlog della versione a cui sono destinate. Le storie per bambini vengono aggiunte alle epopee. Abbiamo trovato il modo migliore per mantenere le storie molto granulari. Le storie a grana grossa rendono difficile stimare ed eseguire realisticamente la storia.

Quindi in generale:

1. Organizza per rilascio

2. Tenere iterazioni tra 2-4 settimane

3. Proprietari e progetto del prodotto i gestori aggiungono storie alla versione arretrato

4. Le stime del team di sviluppo le storie basate sulle taglie TShirt, punti, ecc ...
5. Nella pianificazione primaverile incontri il team di sviluppo seleziona il lavorare per l'iterazione dal rilascio arretrato.

Questo è ciò che abbiamo fatto negli ultimi 4 mesi e abbiamo trovato che funziona bene. Molto importante per mantenere le dimensioni delle storie piccole e granulari.

Ricorda gli acronimi Invest e Smart per la valutazione delle storie degli utenti, una buona storia dovrebbe essere: I - Indipendente N - Negoziabile V - Prezioso E - Stimabile S - Piccolo T - Testabile

Smart:

S - Specifico M - Misurabile A - Raggiungibile R - Rilevante T - Time-boxed

Answer 5

Inizierei dicendo Keep it Simple .. utilizzare un foglio di calcolo condiviso con tracciamento (e backup). Se riscontri problemi di ridimensionamento o sincronizzazione in modo tale che il mantenimento del backlog in uno stato coerente stia diventando sempre più dispendioso in termini di tempo, fai trading. Ciò convaliderà e giustificherà automaticamente le spese / i costi di riqualificazione.

Ho letto alcune cose positive su Mingle di Thoughtworks .

Answer 6

ecco la mia risposta a una domanda simile che potrebbe darti alcune idee

Aiuta un BA! Gestione delle storie utente ...

Answer 7

Molte di queste risposte sono state fornite con suggerimenti sugli strumenti da utilizzare. Tuttavia, la realtà è che il tuo processo sarà molto più importante degli strumenti che usi per implementare il processo. Stare lontano dagli strumenti che tentano di stipare una metodologia in gola. Inoltre, diffidare di implementare semplicemente un vecchio processo non agile utilizzando un nuovo strumento. Ecco alcuni fatti importanti da considerare nella determinazione degli strumenti per i processi:

1. Un cattivo processo strumentato con uno strumento software comporterà un cattivo funzionamento implementazione di strumenti software.
2. I processi cambieranno in base al gruppo che gestisci. Il la cosa importante sono le persone, non il processo. Implementa qualcosa possono lavorare con successo e il tuo progetto avrà successo.

Detto questo, ecco alcune linee guida per aiutarti:

• Inizia con una pura implementazione di un processo documentato,
• Rendi piccole le tue iterazioni,
• Dopo ogni iterazione, parla con i tuoi team e chiedi loro cosa cambierebbe, implementerebbe i cambiamenti che hanno senso.

Per le organizzazioni più grandi, se si utilizza SCRUM, utilizzare un meccanismo di stand-up a cascata. I maestri della mischia si incontrano con le loro squadre. Quindi gli Scrum Masters si incontrano in stand-up da 6 a 9, con un Super-Scrum-MAster responsabile di riportare gli oggetti dalla mischia dello Scum-Master al livello successivo ... e così via ...

Potresti scoprire che le riunioni settimanali di super scrum saranno sufficienti al massimo livello della tua gerarchia.