Grandi compiti vs una breve lista di piccoli alla riunione di pianificazione sprint

Le attività più piccole sono più facilmente valutate e implementate. Anche le attività più piccole facilitano l'identificazione quando hai "finito" con la specifica attività.

Il processo Agile ideale è altamente iterativo, quindi avere un sacco di short but incomplete lists of small tasks facilita l'iterazione e sviluppa la dimostrazione del concetto che stai cercando.

Allo stesso modo, con grandi compiti, è più difficile stimare con precisione; avere una brutta tendenza a sanguinare nel prossimo sprint; e sono orribilmente soggetti a "scope creep" in cui lo sviluppatore realizza costantemente "Oh sì, abbiamo bisogno di avere baz feature insieme a foo e bar "

Which is Scrum standard/better in terms of your experience?

Creazione di storie utente ben definite. Se necessario, ciò significa ottenere il proprietario del prodotto nella pianificazione dello sprint per rispondere alle domande. Ciò porterà a due tipi di scenari:

1. Hai risposto alle tue domande. Dolce, ora puoi creare le tue piccole storie ben definite come faresti normalmente.
2. Nessuno sa cosa sta succedendo, quindi è necessario indagare.

Mi concentrerò su quest'ultimo caso, dal momento che sembra essere quello che hai. In tal caso, quello che ho visto funziona meglio è non fare molta pianificazione sprint. "Ok Bob, dobbiamo capire come fare XYZ - cosa pensi che sarai in grado di mostrare in 2 settimane?" Bob dà qualche tentativo, tutti sono d'accordo e Bob può andare a scavare nella roba.

Bob quindi tiene tutti aggiornati sulla situazione, che offre anche l'opportunità di gestire le aspettative su questo obiettivo provvisorio. Se è in grado di definire compiti per le diverse parti dell'indagine, ottimo. Questo è davvero necessario solo se ci sono altri che hanno bisogno di lavorare sui compiti.

Avere compiti formali per questo tipo di lavoro è controproducente solo nella mia esperienza. Saranno piccoli o vaghi. Le storie minuscole aumentano semplicemente le spese generali e causano disordine. Storie vaghe fanno sì che i project manager interferiscano e non forniscano alcun valore.

La cosa principale da ricordare è che non appena Bob inizia a dire "I made ..." lo fermi e fai dei compiti. La ricerca è un affare vago e esplorativo. L'implementazione (anche i prototipi) non lo è. Una volta scoperto ciò che devi scoprire, torna al processo migliore.

Direi che qualcosa come una struttura ad albero funziona meglio. Hai a disposizione alcune enormi attività di "root", dettagliate in attività più piccole ma comunque di grandi dimensioni, suddivise in piccole attività "leaf" di meno di un giorno, facili da tracciare.

Quello che discuti per l'assunzione di sprint è attività foglia . Ma puoi sempre ricondurli a un'immagine più grande, il che aiuta a capire quali piccole attività sono più utili. Inoltre, puoi ordinare la portata e lo stato delle grandi attività.

Un esempio:

• Implementare l'autenticazione / autorizzazione dell'utente (un compito enorme)
  • ...
  • Implementare l'accesso social (un'attività di grandi dimensioni)
    • ...
    • Ottieni un esempio OpenID funzionante (un'attività foglia)
    • Ottieni un esempio di Google OAuth2 funzionante (un'attività foglia)