Il burndown soffre a causa della dipendenza "tecnica" tra le attività: dovremmo concentrarci maggiormente su ogni attività e accettare un sovraccarico aggiuntivo?

La cosa migliore da fare sarebbe attenersi alla natura atomica, cioè lavorare su una sola storia utente al posto di tutto alla fine.

Fare diverse storie correlate ma atomiche contemporaneamente può avere diversi problemi. Rende i test più difficili e richiede più tempo, in quanto possono esserci un tuffo nelle storie da testare, quindi un alluvione improvviso, che porta a carichi di lavoro di test irregolari. Significa anche che trovare la storia a cui si riferisce un bug diventa più difficile.

Nel tuo esempio, tuttavia, questo non è sempre possibile. La storia per aggiungere un utente dovrebbe molto probabilmente essere completata prima delle altre due storie, poiché sarebbe difficile eseguire il debug della modifica / eliminazione di un utente senza poterne aggiungere uno.

Il significato delle storie atomiche è che la tua applicazione dovrebbe trovarsi in uno stato che può essere distribuito dopo che una storia è stata completata: la costruzione non è interrotta, tutti i test superano, ecc. Ciò non significa che l'applicazione a quel punto sia < em> funzione completa , significa solo che una singola storia è terminata, ma la funzionalità nel suo insieme non funziona necessariamente ancora. Vorresti davvero implementare l'add senza la modifica o la rimozione? Probabilmente no ... Si schiera quando una FEATURE (che può essere composta da più STORIE) è completata. A volte 1 funzione = 1 trama, a volte 1 funzione = 12 storie.

Le storie atomiche implicano anche la possibilità di lavorare su più storie contemporaneamente, il che è importante nei team più grandi. In questo senso, aggiungi e modifica non possono essere considerate atomiche perché dipendono l'una dall'altra. Niente di male in questo, e anche niente di sbagliato nello scrivere il codice per la tua prima storia "aggiungi" tenendo conto del fatto che devi fare una storia di "modifica" successiva.

Per questo tipo di funzionalità, spesso abbiamo delle stime che sono pesanti nella storia di "aggiungi". In questa storia, creiamo tabelle di database, creiamo nuovi oggetti di dominio, nuove pagine e così via. La storia di 'modifica' è molto meno punti di storia perché abbiamo già tabelle, oggetti, pagine e così via. Consideriamo questo fattore quando valutiamo.

Riguardo al burndown: non si disegna un burndown basato su punti memoria. A meno che tu non stia facendo centinaia di storie in uno sprint, ha più senso bruciare in base a attività . Le storie sono stimate in punti storia per indicare la quantità di lavoro che una squadra pensa che prenderà, che consente una certa pianificazione ("quante storie possiamo inserire in uno sprint"). Le squadre quindi dividono le storie per uno sprint in compiti e il burndown su quelle. Puoi bruciare i punti storia quando fai cose come un rapporto sullo stato annuale.