Confuso riguardo alla modifica dello sprint backlog durante uno sprint

11

Ultimamente ho letto molto sulla mischia, e ho trovato quelle che mi sembrano informazioni contrastanti sull'opportunità o meno di cambiare lo sprint backlog durante uno sprint. L' articolo di Wikipedia su scrum dice che non è ok, e vari altri articoli dicono anche questo. Anche il mio professore di sviluppo software ha insegnato la stessa cosa durante una panoramica della mischia.

Tuttavia, ho letto Scrum e XP dalle trincee e che descrive una sezione per gli elementi non pianificati sulla bacheca. Quindi ho cercato la Guida Scrum e ho detto che durante lo sprint "Non sono state apportate modifiche che influenzare l'obiettivo di Sprint "e nella discussione dello Sprint Goal" Se il lavoro risulta essere diverso dal Si prevede che il team di sviluppo collaborerà con il proprietario del prodotto per negoziare ambito di Sprint Backlog all'interno dello Sprint. "Continua nella discussione dello Sprint Backlog:

The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily Scrum. The Development Team modifies Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal.

As new work is required, the Development Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. Only the Development Team can change its Sprint Backlog during a Sprint. The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team.

Quindi a questo punto sono del tutto confuso. Pensandoci, ha più senso per me prendere il secondo approccio. I singoli elementi specifici del backlog non mi sembrano la cosa più importante, ma piuttosto l'obiettivo dello sprint, quindi non cambiare l'obiettivo dello sprint, ma avere la possibilità di cambiare il backlog ha senso. Ad esempio, se sia il proprietario del prodotto che il team pensavano di essere sulla stessa pagina di una storia, ma con lo sprint avanzato hanno capito che c'era un equivoco, sembra che abbia senso modificare i compiti che compongono quella storia di conseguenza . O se ci fosse qualche storia o compito che è stato dimenticato, ma è necessario per raggiungere l'obiettivo di sprint, penso che sarebbe meglio aggiungere la storia o l'attività al backlog durante lo sprint.

Tuttavia, ci sono molte persone che sembrano piuttosto irremovibili sul fatto che qualsiasi modifica allo sprint backlog non sia ok. Sto fraintendendo quella posizione in qualche modo? Quelle persone definiscono lo sprint di sprint in qualche modo in qualche modo? La mia comprensione dello sprint backlog è che consiste sia delle storie che dei compiti in cui sono suddivise.

Comunque apprezzerei molto l'input su questo problema. Sto cercando di capire sia l'approccio idealistico di scrum che quello di cambiare lo sprint backlog durante uno sprint, e se le persone che usano scrum con successo per lo sviluppo permettono di cambiare lo sprint backlog durante uno sprint.

    
posta Maltiriel 23.05.2012 - 18:38
fonte

4 risposte

9

Per prima cosa non avrei regole severe su di esso; l'intero punto di mischia è quello di permetterti di adattarti alla situazione. Quindi dovresti essere in grado di modificare lo sprint backlog durante lo sprint se devi assolutamente (come se avessi dimenticato qualcosa di critico).

Dire che questa modifica allo sprint backlog durante lo sprint dovrebbe essere contrastata. L'intero punto in cui lo sprint è breve è che il nuovo lavoro può essere aggiunto allo sprint successivo (dopo che è stato correttamente assegnato la priorità) senza influire sulla timeline del progetto (più sprint).

Ma se il lavoro è fondamentale per una delle attività in questo sprint hai due opzioni.

  1. Aggiungi un nuovo elemento allo sprint.
    MA rimuovi un oggetto di dimensioni equivalenti dallo sprint.
  2. Elimina l'elemento che è stato pianificato male da questo sprint (in modo da poterlo pianificare correttamente nel prossimo sprint).
    • Aggiunta in un'alternativa (di dimensioni appropriate) dalla parte superiore del backlog del prodotto (che dovrebbe essere in ordine di priorità dalla riunione di pianificazione sprint).
    • Oppure, quando tutti gli elementi sprint sono finiti, consente a dev's di recuperare il gioco dal backlog del prodotto.

Quindi sono nel campo che probabilmente non dovresti modificare lo sprint backlog. Ma devi tener conto della situazione che potrebbe esserci una circostanza eccezionale. Nella maggior parte dei casi vorrei andare con le opzioni 2 e lasciare che gli sviluppatori prendessero il gioco con le attività del backlog.

Quindi nella prossima riunione di pianificazione la nuova attività verrà analizzata in modo appropriato e aggiunta allo sprint (come appropriato).

Ricorda che lo sprint è breve e solo il segno della prossima caduta, non la fine del ciclo di sviluppo. Il proprietario del prodotto dovrebbe essere molto disperato per una funzionalità che non potevano aspettare la fine del prossimo sprint.

    
risposta data 23.05.2012 - 20:05
fonte
9

La confusione è dovuta al linguaggio ambiguo.

Lo Sprint Backlog ha due livelli di dettaglio. Innanzitutto, è una lista di Articoli (User Story) che il Team si è impegnato a consegnare. Secondo, sono tutti i COMPITI che il team intende fare per consegnare ognuna di queste storie.

Quindi quando le persone parlano dello Sprint Backlog, dovrebbero essere davvero chiari su cosa significano. Quando leggi la Guida di Scrum vedrai che afferma: Lo Sprint Backlog è l'insieme di articoli del Product Backlog selezionati per lo Sprint, più un piano per la consegna dell'incremento del prodotto e la realizzazione dello Sprint Goal.

Quindi è ENTRAMBI la lista degli articoli del Product Backlog AND the Plan (Tasks) per consegnarli.

Ora, a molti team piace aggiungere tutte le attività proposte (piano) all'inizio dello Sprint in modo che possano tracciare un grafico di burndown in base alle ore rimanenti. Altri team hanno lasciato emergere i compiti come richiesto. QUESTO è quando è OK aggiungere allo "Sprint Backlog", dal momento che il team deve farlo per ispezionarlo e adattarlo al fine di consegnare gli Oggetti e raggiungere l'Obiettivo di Sprint.

In determinate circostanze, una squadra potrebbe essere in anticipo sui tempi e (dopo aver eliminato tutte le altre attività utili che potrebbero migliorare le capacità della squadra) potrebbe decidere di lavorare con il proprietario del prodotto per selezionare un'altra storia (dovrebbe già essere stata data la priorità e dimensionato) dal Product Backlog ... ma solo se hanno la certezza che sarà completato all'interno di quello Sprint e che si allinea con lo Sprint Goal.

Quindi, ce l'abbiamo; SÌ ... i team DO aggiungono compiti al piano di Sprint Backlog come richiesto. NO, in genere non aggiungono all'elenco degli elementi del backlog che definiscono l'ambito dello sprint.

Spero che questo chiarisca la situazione.

    
risposta data 19.12.2013 - 03:37
fonte
2

Dipende dalle tue situazioni. Se alcune informazioni vengono saltate fuori durante la pianificazione, e in seguito capisci che devi modificare o aggiungere alcuni punti a poche storie, allora penso che vada bene. Ma sì, se l'ambito di una funzionalità cambia completamente, allora questa è una situazione estrema e deve essere gestita in modo diverso.

Ma ovviamente, durante la pianificazione, si presume che tutti sappiano e discutano chiaramente su ciascuna delle funzionalità su cui avrebbero lavorato. Se le discussioni e la pianificazione sono buone, in quasi tutti i casi non hai davvero bisogno di alcuna modifica.

    
risposta data 23.05.2012 - 20:12
fonte
0

Sono d'accordo con le risposte, sottolineerei che se la storia ha iniziato lo sviluppo, allora non può essere fermato fino a quando non è finito.

Scava i talloni all'inizio. Coloro che chiedono il cambiamento dovranno imparare nel modo più duro, altrimenti si finirà con la pianificazione di essere inutili se le persone imparano che puoi fare ciò che ti piace comunque.

Cita che la qualità proviene dal focus e gli errori nascono dal lasciare cadere un filo di pensieri. Cita il costo del cambio di contesto. Monitorare il debito e la gestione della scrittura e della discussione e del gioco in una storia per affrontare il lavoro a metà è costoso. Non iniziare da questa rotta.

Idea: concedere alla gestione 3 crediti di conversione da spendere ogni trimestre come compromesso.

    
risposta data 18.07.2018 - 17:41
fonte

Leggi altre domande sui tag