Gestione di storie utente per un grande progetto

Question

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

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

Mi chiedo quali tecniche le persone usano per suddividere i progetti in cose da inserire nel backlog e una volta creato il backlog come viene mantenuto 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 cosa mi aspetto che la risposta per questa domanda assomigli . Penso che la cosa più utile sia se esiste un progetto open source che mantiene il suo backlog online in qualche modo, così posso vedere come gli altri lo fanno.

Un'altra cosa che otterrebbe uno da me è esempi di storie di utenti reali da progetti reali (il "un utente può accedere" storia non mi aiuta le cose di immagine nel mio progetto.

Grazie.

Answer 1

Vorrei consigliarti di pensare attentamente prima di adottare uno strumento, soprattutto perché sembra che il tuo processo risulti inizialmente fluido all'inizio del tuo ritrovamento. La mia sensazione è che uno strumento potrebbe essere più propenso a costringerti piuttosto che permetterti in questa fase, e non troverai alcun sostituto per uno good card-wall in physical space. Ti suggerirei invece di concentrare i tuoi sforzi sul compito a portata di mano e prendere uno strumento quando senti di averne davvero bisogno. A quel punto avrai maggiori probabilità di avere 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 di un progetto con un budget di oltre un milione di sterline. Principalmente troviamo che una lavagna e le schede di indice (una per ogni story utente) sono più che sufficienti.

Quando identifichi le tue storie, assicurati di esprimerle sempre in termini che hanno senso per i tuoi utenti: alcune (forse solo piccole) parti di funzionalità emerse. Non permettere mai a te stesso di scrivere storie su dettagli tecnici che non potresti dimostrare a un utente.

L'abilità durante la pianificazione delle storie è quello di cercare di dare priorità alle cose che conosci almeno circa prima (piano per ciò che si vuole imparare, piuttosto che ciò che si vuole fare) mentre anche a partire dalle storie che vi permetteranno di sviluppare le funzionalità principali della tua applicazione, utilizzando le storie successive per avvolgere funzionalità (e complessità tecnica) intorno a loro.

Se sei sicuro di poter lasciare qualche pezzo del puzzle fino a un momento successivo, non preoccuparti di entrare nei dettagli di questo - basta scrivere una singola storia che rappresenti la grande conversazione di cui avrai bisogno più tardi, e andare avanti con le cose più importanti. Se hai bisogno di avere un'idea delle dimensioni di quello che verrà, guarda una tecnica di stima delphi a banda larga chiamata planning poker.

I libri di Mike Cohn, in particolare Agile Estimating and Planning, ti aiuteranno molto in questa fase e ti forniranno alcune utili tecniche con cui lavorare.

Buona fortuna!

Answer 2

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

My Agile Wall (Plus A Few Tricks)

Answer 3

Ecco alcuni suggerimenti: Utilizziamo RallyDev.
Abbiamo creato una vista dei pacchetti in cui vivono le nostre esigenze. Le storie grandi sono etichettate come epiche e inserite nel backlog di rilascio del rilascio a cui sono destinate. Le storie dei bambini vengono aggiunte agli epici. Abbiamo trovato il modo migliore per mantenere le storie molto dettagliate. Le storie a grana grossa rendono difficile stimare realisticamente ed eseguire la storia.

Quindi, in generale:

1. Organizza dal rilascio

2. Tenere iterazioni tra 2-4 settimane

3. proprietari del prodotto e del progetto manager aggiungere storie per il rilascio arretrato

4. Il team di sviluppo stima le storie basate sulle dimensioni maglietta, punti, ecc ...
5. Nella primavera pianificazione meeetings il team di sviluppo seleziona il lavoro per l'iterazione dal backlog rilascio.

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

Ricordate l'Invest e acronimi intelligenti per valutare storie di utenti, una buona storia dovrebbe essere: I - Indipendente N - Trattabili V - Valuable E - stimabile S - Piccolo T - testabile

intelligente :

S - specifici M - misurabili A - realizzabile R - Relevant T - Time-boxed

Answer 4

Avrei iniziato dicendo Keep it Simple .. usa un foglio di calcolo condiviso con tracking (e backup). Se vedi problemi di ridimensionamento o di sincronizzazione in modo tale che il mantenimento del backlog in uno stato coerente sta diventando sempre più dispendioso in termini di tempo, fai trading. Ciò convalida automaticamente e giustifica le spese/i costi di riqualificazione.

Ho letto alcune cose positive su Mingle from Thoughtworks.

Answer 5

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

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 6

qui è la mia risposta a una domanda simile che può darvi alcune idee

Help a BA! Managing User Stories ...

Answer 7

Un sacco di queste risposte sono state con suggerimenti sugli strumenti da utilizzare. Tuttavia, la realtà è che il tuo processo sarà molto più importante degli strumenti che utilizzi per implementare il processo. Stare lontano da strumenti che tentano di stipare una metodologia in gola. Ma attenzione anche a implementare semplicemente un vecchio processo non agile usando un nuovo strumento. Ecco alcuni fatti forti da prendere in considerazione al momento di determinare gli strumenti per i processi:

1. Un processo brutta strumentato con uno strumento software si tradurrà in un software cattivo strumento L'implementazione.
2. I processi cambieranno in base al gruppo che si sta gestendo. La cosa importante di è la gente, non il processo. Implementa qualcosa in cui possono lavorare con successo e il tuo progetto avrà successo.

Detto questo, qui ci sono alcune linee guida per aiutarvi a:

• Inizia con una pura implementazione di un processo documentato,
• Fai i tuoi iterazioni piccola,
• Dopo ogni iterazione parlare con i tuoi team e chiedi che cosa sono loro cambierebbe, implementare le modifiche che hanno un senso.

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

Si può trova che le riunioni settimanali di super scrum sono sufficienti al livello più alto della tua gerarchia.