Quanti user story per persona dovrebbero essere completati per sprint? [chiuso]

La produttività è influenzata da una serie di fattori: cultura organizzativa, esperienza con il linguaggio e gli strumenti, conoscenza del progetto, specifiche del processo utilizzato, fattori esterni come regolamenti e capacità del team come unità coesa. Questo è il motivo per cui, nella stima dei progetti, i dati più utili sono quelli del team specifico che condurrà il lavoro. Man mano che si generalizzano a livello organizzativo, industriale e quindi in tutti i progetti software, la produttività diventa un'area sfocata.

Uno dei vantaggi dello sviluppo iterativo è che si passa attraverso tutte le fasi più volte su un singolo progetto, consentendo di ottenere informazioni dettagliate sul processo e sul team. Potresti iniziare con i dati organizzativi dei progetti passati, ma molto rapidamente (2-4 iterazioni) ottenere dati specifici del team per la pianificazione del progetto.

Il numero che citi (1-1,5 user story per sprint) è il più alto livello di astrazione. Il momento migliore per utilizzare questo numero è quando non si dispone di dati specifici del settore da qualsiasi dominio in cui si trova il proprio prodotto, nessun dato organizzativo e nessun dato specifico del team - nelle prime fasi dei primi progetti che utilizzano Scrum. Probabilmente proviene da team che utilizzano tutti i tipi di varianti di Scrum, inclusa la combinazione di Scrum con altre tecniche di miglioramento dei processi (Kanban, CMMI, Lean). Mi fiderei di usare questo numero così com'è, dato che Mike Cohn e Mountain Goat Software sono consulenti agili di tutto rispetto. Tuttavia, non appena hai dati dalla tua organizzazione (o, ancora meglio, dal tuo team), utilizzalo per pianificare sprint.

Questa sarebbe una cosa povera da preoccuparsi o anche provare a misurare, questo numero cambierà molto per abilità di programmatore, complessità della storia, esperienza di programmatore e squadra, esperienza di coloro che creano storie, manutenibilità di codice- Base ...

Dovresti essere preoccupato per cose come sembra che tutti stiano contribuendo al meglio delle loro possibilità, il cliente è più felice oggi rispetto a ieri, o tutti / più pensano che questo processo funzioni meglio dell'ultimo processo che abbiamo provato?

Penso che a un livello a grana fine che dice "tutti dovrebbero completare 1,5 storie per sprint" è la rischiosa interpretazione dell'analisi. Quello che ho trovato è che nel corso del tempo, il team si accinge a specificare storie di complessità simile. Forma una linea di base grazie alla quale è possibile pianificare in modo appropriato il futuro. In altre parole velocità. Non mi piace mai misurare la velocità per numero di storie, ma piuttosto per punti storia. In generale, però, si dissolve a causa della differenza di dimensioni tra le storie (le storie più piccole compensano le storie più grandi).

È bello vedere che discute le differenze nella lunghezza dello sprint (gli sprint più lunghi tendono ad affrontare storie più grandi) e la dimensione della squadra nell'impatto qui. Anche tirare indietro il sipario (cioè avere compiti dettagliati relativi alle storie) fornisce maggiore visibilità su ciò che va a completare la storia (che è in definitiva ciò di cui tratta il post - visibilità).

Quindi, come regola generale, Cohn dice target intorno a 1-1,5 storie per sviluppatore per sprint. Molto più di questo, e si rischia di non ascoltare i progressi di una storia finché non si è in profondità in uno sprint. Lean affronta questo lasciando storie nel backlog fino a quando non sono pronte per essere coinvolte nello sviluppo. Quello che Mike sta dicendo è che il tuo work in progress effettivo per lo sviluppo dovrebbe essere limitato a 1.5X dove X è la dimensione del team di sviluppo.

Per me, dipende dallo sprint o dipende dal livello di attività da svolgere. Dalla mia attuale esperienza sto lavorando su un sistema che abbiamo creato diverse storie di utenti. per ogni settimana dovremmo fare storie che sono state assegnate per essere fatte in quella settimana, se tutte le attività sono state fatte. passiamo allo sprint successivo anche se siamo in anticipo rispetto alla pianificazione. (Supponendo che l'attività sia stata eseguita correttamente)

nel mio team ogni persona ha 3 storie che è necessario fare. e sono sorpreso che stiamo superando i nostri limiti.

dipende solo dal programmatore. ma cose come questa non dovrebbero essere un problema. il problema qui è che il cliente otterrà ciò che desidera o chiederà.

L'ultima cosa che ho sentito è che era 1,5 / 2x il numero di membri del team.

Si noti inoltre che Mike Cohn non sta dicendo che dovresti usare questi numeri, sta semplicemente dicendo che nel corso degli anni nel settore e nelle molte squadre che ha allenato, ha trovato storie da 1,5x / 2x per membro del team a funziona meglio. Ha dato questa risposta quando gli ho chiesto che cosa considerava la dimensione ideale per la user story.

La domanda Daft, ma non è la risposta scacciata attraverso una stima iniziale del team di punti storia (o qualsiasi altra cosa) da qualsiasi sessione di pianificazione sprint e poi b) velocità di sprint e / o burndown?

A volte raggiungiamo le stelle nel primo sprint e scopriamo rapidamente che non tutte le storie sono ciò che sembrano (qualcosa sempre nascosto). Quindi riaggiustiamo le nostre prossime stime di sprint per il prossimo pulldown del film dal backlog.

Uno o due piani max per dev è il tipo in cui sono finiti i progetti della maggior parte dei dispositivi mobili della mia squadra, attraverso una serie di organizzazioni, progetti e sviluppatori di piattaforme.