Quando interrompere la scrittura di storie utente e iniziare la codifica?

Devi valutare ogni storia una volta che l'hai arricchita - questo presuppone che tu stia ottenendo le tue storie in ordine di priorità e che siano sufficientemente elaborate per lo sviluppo.

Quando hai stimato abbastanza per un'iterazione, inizia a programmare.

Quando hai un backlog di prodotto completo e buone storie utente complete di tutti i casi. Quindi dividerli in iterazioni e iniziare la programmazione.

Le due attività non sono antagoniste.

La scrittura di storie riguarda la definizione delle esigenze desiderate sotto il vincolo di fornire valore aziendale.

L'avvio del codice avviene nel mezzo di uno sprint. Per iniziare uno sprint, l'unico prerequisito è un backlog di sprint definito, priorizzato dal PO (lo story writer) e selezionato dal team.

Devi smettere di scrivere storie (= interrompere il progetto), quando il beneficio marginale dell'attuazione della storia rispetto al costo dell'implementazione e del costo operativo attualizzato della funzione definita è négativo.

Dovresti iniziare a codificare nel contesto di uno sprint, quando la storia è compresa (analisi) e il testing e l'implementazione sono definiti (design) - l'approccio classico allo sviluppo del software.

quando le storie diventano abbastanza dettagliate da trasformarsi in una logica programmabile .. e quando i programmatori possono assegnare una certa quantità di punti storia che si adattano alla timeline degli sprint ...

una storia che è stimata in 50 ore / punti della storia sarebbe dura (IMO) per affrontare uno sprint di una settimana .. spezzare ulteriormente la storia permetterebbe ad altri di assumere varie parti del compito, ma se il codice non può essere sviluppato in parallelo, quindi probabilmente è il più breve possibile.

Is there any standard way for knowing when to stop writing user stories, and if so, what is the basis for this, and how does it apply to future sprints?

Non conosco personalmente un metodo standard di per sé. Si tratta davvero di una combinazione della tua metodologia e delle aspettative dei tuoi clienti.

Ho scoperto che è meglio iniziare la codifica non appena hai "abbastanza" storie da parte del tuo cliente per iniziare. Come altri hanno già detto, questo potrebbe essere per una singola iterazione, tuttavia potrebbe essere di più. La tua misura di abbastanza dovrebbe essere guidata da quanto spesso intendi rilasciare codice di lavoro al tuo cliente, e piuttosto che il tuo cliente ti fornisca una lista infinita di storie (molte delle quali probabilmente non saranno mai realizzate, o potrebbero cambiare o potrebbero non rendere la scadenza principale del rilascio), è meglio chiedere al cliente le prime 3-5 caratteristiche più importanti e più prioritarie. Quando questi vengono eseguiti e rilasciati al tuo cliente, raccogli le successive 3-5 funzionalità più importanti e così via. Chiedi più o meno in base alla durata delle tue iterazioni.

Il tuo cliente o contratto o scadenza forse ti guiderà su quando smettere di chiedere storie, ma nel frattempo hai chiesto storie e ti sei fermato tutte le volte che hai avuto iterazioni. Quando, d'accordo, tu e il cliente sentite che il prodotto è sufficientemente completo, potete decidere cosa fare con eventuali storie lasciate che il cliente potrebbe non aver ancora dato.

Il vantaggio principale di questo approccio è che finisci per offrire il massimo valore al cliente in anticipo, e mentre il progetto cresce e il tempo passa, la quantità di valore che stai offrendo al cliente diminuisce al punto in cui il cliente può prendere una decisione circa "l'ultimo 20% delle caratteristiche" che avrebbero potuto desiderare e che potrebbe non essere mai utilizzato. Riduce inoltre il tempo sprecato per articoli banali e di bassa priorità, ponendo la responsabilità (e lo stress) di prioritizzare e pianificare le iterazioni sul cliente e tutte basate esclusivamente sulle esigenze del cliente. Ciò non significa tuttavia che non si dovrebbe fornire una guida al cliente al fine di evitare complicati colli di bottiglia che potrebbero diventare evidenti quando si parla di requisiti con il cliente.

Leggi la versione Lean Software Development di Poppendeicks se desideri una descrizione più dettagliata di questo approccio in un contesto più ampio.

non smetti mai di scrivere storie .. E 'solo che quando hai abbastanza storie per lo sprint 1, farai una pianificazione sprint e il tuo team inizierà a lavorare secondo lo sprint backlog ..

Il proprietario del prodotto continuerà a governare l'arretrato del prodotto, scrivendo più storie di utenti, rompendo grandi storie, ad esempio epiche, in uno più piccolo, elaborando di più sui criteri di accettazione delle storie, prioritizzando ...