L'accettazione a metà sprint è un concetto valido in Agile/SCRUM?[Chiuso]

Question

Chiuso.Questa domanda è basato sull'opinione.Al momento non accetta risposte.

---

Vuoi migliorare questa domanda? Aggiorna la domanda in modo che sia possibile rispondere con fatti e citazioni modificando questo post.

Chiuso 2 anni fa.

Faccio parte di un team Agile Scrum che lavora al rilascio di un prodotto software.La durata dello sprint è di 2 settimane (~10 giorni).

Qui viene utilizzata una metrica peculiare, chiamata 'accettazione a metà sprint'.In sostanza, l'aspettativa è che la metà dei punti della user story impegnati e pianificati da un team di mischia in uno sprint debbano essere completati entro la metà di quello sprint.Questo, dicono, si traduce in un burndown lineare di punti che è un forte indicatore del fatto che lo sprint sta andando bene.

Come squadra, le nostre accettazioni a metà sprint sono generalmente negative, ma siamo noti per completare tutti i punti impegnati nella storia dell'utente entro la fine dello sprint.

Ho le seguenti domande:

1) L'accettazione a metà sprint è una pratica Agile/SCRUM valida?Viene utilizzato altrove?

2) Aspettarsi che metà del lavoro venga completato nella metà del tempo è come trattarlo come un lavoro di "fabbrica", dove la natura e la complessità del lavoro da svolgere sono completamente deterministiche.Poiché lo sviluppo del software è un processo “creativo”, parametri così rigidi in una metodologia altamente flessibile come Agile sono irrilevanti.Cosa ne pensi?

3) Sebbene il mio team di mischia completi tutti i nostri impegni giusto in tempo per lo sprint, veniamo interrogati per i nostri pessimi parametri di accettazione a metà sprint.È del tutto normale che i team di mischia di qualsiasi altro posto rispettino i propri impegni solo verso la fine degli sprint?

Molte grazie in anticipo.

Answer 1

1) Is mid-sprint acceptance a valid Agile/SCRUM practice? Is it being used anywhere else?

Non ho mai sentito parlare di accettazione a metà sprint prima.Non credo che sia una pratica Agile/Scrum valida. Questo sito sembrerebbe essere d'accordo "Una volta che il team si è impegnato nel lavoro, il Product Owner non può aggiungere altro lavoro, modificare il percorso a metà dello sprint o microgestione."

2) Expecting half of the work to be completed in half the time is akin to treating it as a 'factory-floor' job, where the nature and complexity of the work at hand is completely deterministic. Since software development is a 'creative' process, such rigid metrics in a highly flexible methodology such as Agile is irrelevant. What do you think?

Qualsiasi metrica rigida generalmente non è una buona idea da utilizzare con gli sviluppatori per i motivi che hai menzionato.Inoltre, è probabile che gli sviluppatori saranno più interessati a ottenere un punteggio minimo in qualunque cosa venga misurata e non a produrre un prodotto di qualità.Questo è uno degli orsetti di Joel Spolsky - Qui, Qui E Qui

3) Although my scrum team completes all our commitments just in time for the sprint, we are being questioned for our bad mid-sprint acceptance metrics. Is it completely normal in scrum teams everywhere else to meet their commitments only towards the end of their sprints?

Un team Scrum di successo dovrebbe completare tutto ciò che si è impegnato a fare entro la fine dello sprint.Il grafico di burndown dovrebbe essere visibile per guidare i progressi verso questo obiettivo e certamente nella seconda metà dello sprint indicherà se è probabile che lo sprint abbia successo.Negli sprint di successo in cui sono stato coinvolto è normale fare progressi costanti verso il completamento delle user story, ma questo non può riflettersi nel completare metà delle user story nella metà del tempo e sconsiglierei una metrica di questo tipo.

Answer 2

Hai provato a limitare la quantità di lavoro che hai in corso.Se convinci tutto il team a concentrarsi su un paio di storie e non vai avanti finché quelle storie non sono finite, dovresti vedere il tuo burndown diventare molto più lineare.

Potrebbe anche valere la pena considerare la dimensione delle storie.Personalmente non mi piace vedere una storia che richiede più di un paio di giorni per essere completata dall'inizio alla fine.

Answer 3

Non è una pratica Scrum.Potrebbe essere interpretato come una metrica, ma sbagliata.Per quanto riguarda i tuoi dubbi, hai ragione.

Scrum dispone di uno strumento perfetto per seguire la progressione: il grafico di burn-down.Non è necessario aggiungere alcun traguardo arbitrario.

Sembra che il tuo management non comprenda il concetto di base di uno sprint, dovrebbe ricevere consulenza o seguire una formazione di base.Se per il tuo management è ancora importante ciò che viene fatto entro una settimana, prova invece a suggerire di dimezzare la durata dello sprint.

Answer 4

1) Is mid-sprint acceptance a valid Agile/SCRUM practice? Is it being used anywhere else?

Sì.

2) Expecting half of the work to be completed in half the time is akin to treating it as a 'factory-floor' job, where the nature and complexity of the work at hand is completely deterministic. Since software development is a 'creative' process, such rigid metrics in a highly flexible methodology such as Agile is irrelevant. What do you think?

Se suddividi i compiti in compiti veramente piccoli puoi ottenere una buona metrica dell’evoluzione del lavoro.Pertanto, progetta le attività da completare in un giorno lavorativo ed è possibile ottenere un buon utilizzo della metrica di burndown.Se hai attività lunghe e di durata imprevedibile, la metrica del burndown è irrilevante, come hai detto.

3) Although my scrum team completes all our commitments just in time for the sprint, we are being questioned for our bad mid-sprint acceptance metrics. Is it completely normal in scrum teams everywhere else to meet their commitments only towards the end of their sprints?

Il problema non è il team, ma la progettazione dei compiti.Il problema riguarda la granularità dei compiti.Il tuo team può portare a termine il lavoro nella metrica del tempo di sprint, ma ora devi perfezionare le attività in modo che il 50% di esse venga completato nella metrica del tempo di metà sprint.Suddividi le attività in attività più piccole e potrai ottenere il grafico di burndown (lineare) desiderato.

Answer 5

È una terminologia non standard, ma c'è qualcosa in quello che dice il tuo manager.

Un grafico burndown che è pesante (vale a dire, rimane alto per un'ampia porzione del grafico, poi diminuisce improvvisamente alla fine) è indicativo di una pratica in cui le attività sono a grana grossa, ovvero un'attività probabilmente sarà richiede un intero sprint per essere completato e realizzato dai singoli sviluppatori.Con questo schema, tutte le attività rimangono incomplete fino a poco prima della fine dello sprint.

Non è proprio così che dovrebbe funzionare:se il backlog è in ordine di priorità, allora perché si stanno lavorando su problemi che non hanno la priorità più alta?Inoltre, questo imposta il "numero del bus" per ciascuna attività molto basso, il che può aumentare significativamente il rischio che le attività rimangano incomplete entro la fine dello sprint.

Per risolvere questo problema, le attività dovrebbero essere suddivise in parti molto più piccole.Se stai pianificando il poker e un'attività è stimata in 8 punti o più, è probabile che l'attività sia sottospecificata.Deve essere scomposto.Prova a mantenerlo a 2 e 3 (o meno!), se possibile.In questo modo, puoi avere diversi sviluppatori che lavorano in modo indipendente sullo stesso obiettivo generale e il tuo grafico di burndown dovrebbe iniziare ad apparire più fluido e meno rischioso, anche se viene svolto lo stesso lavoro.

Answer 6

L'accettazione del Mid Sprint non è una pratica agile o non funziona nella realtà.Se hai una stima corretta per ogni storia utente e attività (ad esempio nel Rally), il grafico di burndown mostra chiaramente se il lavoro dello sprint è in linea con il piano e può essere completato in tempo o meno.L'accettazione viene effettuata solo al termine dello sviluppo e del test della storia dell'utente, non delle attività.