E 'cattiva pratica di lavorare su più storie simultaneamente? [chiuso]

Question

In una squadra di mischia, quanto è importante per completare una singola storia, prima di passare?

Il nostro scrum master è piuttosto dogmatica di portare una singola storia fino al completamento prima di passare. Vedo che lo sviluppo sembra essere più "controllata" in questo scenario, più lo scrum master avrei un quadro molto preciso di ciò che i membri del team stavano lavorando in un dato momento ... ma sono interessati a ciò che davvero questo acquista noi?

Chiaramente lo scrum master vuole ridurre al minimo divergenza del burndown dalla realtà al fine di evitare uno shock venire la fine dello sprint - ma sicuramente se la volata è lunga due settimane, il burndown viene aggiornato costantemente e bloccanti sono comunicati in Sagome - qualsiasi tale divergenza sarà limitata dalla lunghezza sprint, ed essere reso visibile metà sprint attraverso i consueti canali (cioè la standup o parlando al master mischia singolarmente). Eventuali problemi rimanenti possono essere trattate nel quindicinale retrospettiva.

La ragione per la domanda è che mi sembra di trovare lavoro in modo più efficiente, mantenendo dire 2 (o 3 se uno è particolarmente facile) storie in corso in un dato momento, che io lavoro su come vedo in forma. Questo sembra di assistere con lo sfondo sub-conscio pensato che assiste con il completamento del compito. Mi permette anche di comprendere meglio il quadro più ampio, se un paio di storie sono legate.

Le nostre storie di solito lavorano per essere uno o due giorni vale la pena di lavoro.

Quindi, sta lavorando su un paio di storie in un momento disapprovato e se sì che cosa fa un piano-at-a-tempo si acquista?

Answer 1

penso che sia davvero al team decidere. Penso che lo ha colpito nella tua scrittura fino a circa il burndown, la cosa più importante è quello di soddisfare i vostri impegni sprint in modo coerente. come succede in realtà dovrebbe essere fino alla squadra se veramente sono auto-governo. l'im squadra adesso, la nostra norma è di lavorare su più storie contemporaneamente; la sua la natura della nostra messa a punto dato che cerchiamo di diffondere realmente la proprietà di storie attraverso la squadra. può essere una norma diversa per il vostro se avete storie più brevi e più di uno stile di proprietà individuale.

Answer 2

Personalmente penso che una storia alla volta funziona bene perché mantiene concentrati su un compito. Il costo di contesto commutazione tra più piani può essere elevato. Si tratta di una preferenza personale per me, ma persone diverse funzionano in modo diverso. Anche se penso che il tuo padrone mischia è corretto nella sua metodologia, se hai trovato ragioni molto convincenti per molteplici storie alla volta e può dimostrare che in realtà è aiutare il progresso, che sarebbe un buon caso di fare.

Answer 3

IMO, v'è una domanda di fondo qui. A volte, quando si lavora su una storia, avrò bisogno di qualcosa da un altro reparto / squadra, per es. chiarimenti su un requisito o un elemento grafico per una pagina, e questo significa che non voglio finire una storia prima di passare a un'altra storia. Mentre fate parlare di questo nel discutere i bloccanti a standup, questo può accadere in cui spetta a qualcuno al di fuori di aiutarmi a finire una storia così non ci può essere quelli più sul mio piatto. Così, posso avere più storie a causa di blocco su qualcosa e ancora voglia di essere produttivi.

In generale, non mi piace cercare di gestire più copie del codice di base o passare il mio codice molto, quindi io preferisco fare una storia alla volta, assumendo che non bloccanti. La dimensione della base di codice con cui sto lavorando è ~ 1,1 GB di dati distribuite su 82,000+ file in modo da avere più copie potrebbero essere più di un po 'doloroso mi immagino.

La mia ipotesi personale su questo è che spetta alla squadra per definire lo standard e vedere che funziona per loro. Se alcuni, come una storia alla volta e gli altri fanno multipla e tutto va bene, fresco. Se a tutti piace avere più storie in vari punti di completamento, che può funzionare anche.

Answer 4

Non intasare l'arretrato ... Nella mia esperienza, quando le storie sono tra 1 e 2 giorni in termini di dimensioni, tendono a essere implementato da un singolo sviluppatore. Se si sta lavorando a 2 o 3 piani contemporaneamente, che potrebbe ridurre la quantità di cose nel backlog che altri sviluppatori possono scegliere da e mettere a repentaglio la volata.

... ma piano per il blocco D'altra parte, lavorare 2 o 3 piani in una sola volta significa che se si è momentaneamente bloccato su una storia si può essere immediatamente produttivi, dall'altro. Trovo che ci sia un certo overhead ogni volta che inizio una nuova storia. Questo overhead rende difficile riempire un'ora a lungo "gap" nella mia giornata con una nuovo storia, mentre è molto più facile per cambio di contesto a una storia che ho già iniziato.

Linea di fondo, lascia la squadra a decidere ... e poi rivedere i risultati nel corso di una retrospettiva . Se le vostre storie, le attività e processi di lavoro supportano un ambiente in cui i membri del team possono lavorare 2 (forse 3) le storie alla volta senza sacrificare la produttività o la prevedibilità, allora il vostro SM dovrebbe rispettare questo. Ma allo stesso tempo, si dovrebbe onestamente rivedere i risultati nel corso di ogni retrospettiva ed essere pronti a cambiare se la SM non pensa il suo funzionamento.

Answer 5

Io in genere verrebbe da pensare che la decisione su come lavorare meglio dovrebbe essere fatta quasi esclusivamente dal team. Il ruolo del ScrumMaster è quello di aiutare e sostenere la squadra, non mettere in discussione il senso del gruppo di lavoro durante uno sprint.

Per essere onesti, a volte può essere una buona idea per lo ScrumMaster per evidenziare eventuali difetti o rischi - che sarebbe caduta nella "Guida e supporto tecnico" categoria. Essere dogmatica circa la vostra personale idea di come uno sprint dovrebbe essere simile internamente non è una cosa che vorrei uno ScrumMaster ad agire come. Suona un po 'come misunderstading il ruolo come il ruolo di un manager, che non è semplicemente il caso.

Per quanto riguarda il come lo facciamo: Abbiamo quasi sempre lavorare su diverse storie in una sola volta. Al momento stiamo avendo un team Scrum di quattro persone con tre sviluppatori e un tester e ci siamo quasi sempre avere almeno due o tre piani che vanno allo stesso tempo. Nell'ultimo sprint abbiamo cercato di iniziare con tutte le storie primi nello sprint per arrivare al punto in cui abbiamo un progetto di base e una buona idea di ciò che i potenziali problemi potrebbero essere. Naturalmente non stavamo lavorando su tutte le storie allo stesso tempo dopo.

Capisco che in termini di gestione dei rischi che si potrebbe desiderare di fare in modo che tutto sia fatto per una storia prima di affrontare il prossimo. Tuttavia, lo svantaggio è che quando si esegue in problemi imprevisti lateron, si potrebbe non avere abbastanza tempo per risolvere quelli. Di solito i problemi mostrano i loro brutte facce durante la fase di attuazione e abbastanza spesso abbastanza presto. Quindi, che, fondamentalmente, scambiare un rischio per un altro.

Quale rischio è più facile da gestire shoud essere fino alla squadra. E 'il loro sprint, dopo tutto e mentre penso che sia perfettamente equo per la ScrumMaster parlare preoccupazioni circa il modo in cui lo sprint sta andando, non dovrebbe forzare la sua idea del modo migliore per lavorare sulla squadra.

Alla fine, penso che si riduce a queste due cose:

1. Sì, facciamo lavorare su più piani in una sola volta e ha funzionato bene finora.

2. Ricordate che lo ScrumMaster è lavorare per la squadra, non il contrario viceversa.

Si prega di notare che io sto per lo più parlando di tutta la squadra a lavorare su diverse storie in una sola volta, non uno sviluppatore. Il problema mi piacerebbe vedere non v'è che è necessario fare in modo che non bloccare nessuna storia da tenerli aperti, in modo che nessun altro può continuare il lavoro. Ancora una volta, questa è una questione di circostanza e la preferenza. Quando si tratta di test, il nostro tester ha spesso un paio di compiti di prova per storie diverse, in modo che possa facilmente passare ad un compito diverso, se alcuni lo blocchi di bug da continuare testare una caratteristica.