Come finiamo tutte le nostre storie entro la fine dello sprint e non dopo e perché è così importante?

1

Stiamo facendo scatti di 2 settimane in cui il team terminerà appena lo sviluppo entro l'ultimo giorno dello sprint, ma le carte non sono complete perché i test non sono terminati. La definizione di fatto è veramente "quando lo sviluppo è completo" piuttosto che "quando le storie sono complete". Abbiamo un ritardo di 1 settimana tra l'ultimo giorno dello sprint e la data di rilascio. La squadra finisce lo sprint entro la data di rilascio, ma sembra che non sia proprio l'obiettivo della mischia. Il team inizia lo sprint successivo il giorno dopo lo sprint precedente.

Vedo i seguenti problemi:

    Il team
  1. non sta utilizzando test di team completi
  2. Il team
  3. non è troppo interessato alla programmazione di coppie o all'accatastamento su una carta alla volta.
  4. Forse le storie sono troppo grandi e dovremmo romperle di più in modo da finire con un ritmo più costante durante lo sprint?

Qualche suggerimento su come la squadra viene comprata per finire lo sprint entro la data di fine? O altre idee?

Perché pensiamo che sia importante finire l'ultimo giorno? Perché è importante se la squadra sta ancora finendo entro la data di rilascio? (Ho le mie risposte ma sono curioso di sapere cosa pensano gli altri qui.)

    
posta ChrisF 19.04.2012 - 00:24
fonte

3 risposte

5

Il bisogno di Scrum non è quello di completare ogni storia alla fine di ogni sprint. In realtà, ciò potrebbe non accadere, specialmente all'inizio di un progetto quando si sta ancora stabilendo una velocità. L'idea è di avere un prodotto potenzialmente spedibile (funzionante, testato e documentato) che aggiunge valore commerciale al cliente alla fine di ogni iterazione.

La prima cosa da fare è migliorare la tua definizione di fatto. Fatto dovrebbe significare che la storia è completa. Ciò significa che è stato progettato, implementato, testato unitamente, integrato e superato i test di sistema e di accettazione. Quando una storia è finita, ciò significa che la caratteristica o la capacità che il negozio rappresenta è pronta per essere consegnata al cliente. The Scrum Alliance ha alcuni articoli su che aspetto ha una buona definizione di fatto , come sapere quando hai finito con una storia , e una metodologia per creare una buona definizione di fatto .

Successivamente, probabilmente dovresti iniziare a lavorare sulla tua stima e pianificazione. Non dovrebbe essere una lotta continua per incorporare le storie in ogni uscita. Inizia con stime appropriate e accurate sulla dimensione della storia, che spesso utilizza i punti storia per fornire una stima del sforzo relativo richiesto per completare la storia . Una volta che hai delle stime, devi usare queste stime per pianificare. Se ti ritrovi a finire 10 punti storia ad ogni sprint, non tirare più di 10 punti storia nel prossimo sprint. Se hai tirato 10 punti storia in uno sprint, ma ne hai terminati solo 8, includi solo 8 nel prossimo sprint. Se finisci presto, puoi inserire più punti storia o utilizzare il tempo addizionale per ridurre il debito tecnico rifattorizzando, scrivendo nuovi test automatici o migliorando i test esistenti (come alcuni esempi).

Invece di iniziare immediatamente il prossimo sprint, assicurati di avere tempo per le tue riunioni retrospettive e di pianificazione. Utilizzalo come un'opportunità per determinare quali sono stati i problemi o ha bisogno di miglioramenti, quindi implementare le correzioni per il processo negli sprint futuri.

Penso che fare questo risolva alcuni dei tuoi problemi, e rendere gli altri più facili da risolvere, o almeno portare più informazioni. Alcuni dei problemi sono anche legati alla cultura organizzativa, come l'intero team che partecipa al test o che non usa la programmazione della coppia. Alla fine, vorrai portare l'intero team in test (e altre attività), dal momento che Scrum è incentrato su un team con competenze interfunzionali. Una stima migliore ti aiuterà anche a identificare se le tue storie sono troppo grandi. Per quanto riguarda la programmazione di coppie, è un non-problema, dal momento che non è richiesto per Scrum e potrebbe non essere utile alla tua squadra.

    
risposta data 19.04.2012 - 19:11
fonte
0

Dove lavoravo, avevamo un blocco del codice per consentire il tempo di test nello sprint. Ciò avrebbe anche dato agli sviluppatori il tempo di fare refactoring e altre piccole modifiche mentre il controllo qualità esaminava il lavoro svolto per vedere ciò che è e non è pronto per la produzione, poiché il lavoro di refactoring non sarebbe stato fuso solo dopo che il rilascio fosse stato taggato / ramificato. p>

Mi chiedo quanto bene il team comprenda l'idea di velocità in cui i punti X del lavoro di una storia sono fatti in uno sprint e non sanguinano in un'altra sprint con correzioni di bug o altri lavori che potrebbero avere un impatto sul lavoro successivo dello sprint.

    
risposta data 19.04.2012 - 18:22
fonte
0

Any suggestions on how we get the team bought in to finishing the sprint by the end date?

In senso stretto, lo Sprint è completato entro la data di fine, indipendentemente dal fatto che Sprint Team abbia completato tutti gli elementi di Sprint Backlog o meno. Non hai bisogno di "buy-in" per finire lo Sprint in tempo ... Hai bisogno di "buy-in" per seguire effettivamente Scrum.

Why do we think it is important to finish by the last day?

Why does it matter if the team is still finishing by the release date?

Un'altra parte di Scrum è la tua "definizione di 'fatto" ". La definizione di "fatto" che hai scelto (sviluppo completo, ma non testing, ecc.) Non ti consente di raggiungere l'obiettivo principale di Scrum ... "un incremento di alta qualità di un prodotto deliverable ".

    
risposta data 09.07.2015 - 05:58
fonte

Leggi altre domande sui tag