Mischia Burndown problemi [chiuso]

Question

Abbiamo utilizzato Mischia per circa 9 mesi ed è in gran parte ha avuto successo.Tuttavia il nostro burndown grafici raramente guardare come il 'modello' di grafici, invece assomiglia di più di un terrificante giro sulle montagne russe con alcuni indurre vomito sale e scende.

Per provare a combattere questo stiamo spendendo più tempo prima che la sprint di prototipazione e progettazione, ma sembriamo ancora scoprire molto di più il lavoro durante lo sprint di quanto inizialmente pensato.Nota:Con questo voglio dire che il lavoro necessario per soddisfare il backlog è più coinvolto di primo pensiero piuttosto che abbiamo individuato nuovi elementi per il portafoglio.

È questo un problema comune con la Mischia, qualcuno ha qualche consiglio per rendere più agevole il passaggio?

Tengo a precisare che la maggior parte del nostro lavoro di sviluppo non è greenfield, siamo quindi a mantenere la funzionalità esistenti in un grande e complesso applicazione.Si mischia la meno adatta a questo tipo di sviluppo, semplicemente perché non si sa quali problemi il codice esistente sta per vomitare?

Quanto tempo dovremmo spendere prima di sprint inizia a lavorare fuori i dettagli di sviluppo?

AGGIORNAMENTO:Stiamo avendo più successo e una guida più fluida ora.Questo è in gran parte perché non abbiamo preso una visione pessimista quando si stima che ci sta dando più spazio per gestire le cose quando non vanno a piano.Si potrebbe dire che ci permette di essere più "agile".Stiamo anche cercando di cambiare la percezione che il burn down chart è un qualche tipo di programma piuttosto che di un'indicazione di portata v risorse.

Answer 1

Alcuni suggerimenti su lisciando le cose.

1) Come altri hanno detto - cerca di abbattere i compiti in piccoli pezzi.Il più ovvio modo per farlo è quello di cercare di abbattere i compiti tecnici in maggiore dettaglio.Dove possibile, mi piacerebbe incoraggiare a parlare con il proprietario del prodotto e vedere se è possibile ridurre la portata o "sottile" invece la storia.Trovo la seconda più efficace.Giocoleria priorità e stime, è più facile se la squadra e il proprietario del prodotto a capire ciò che è stato discusso.

La mia regola generale è una stima più grande di mezza giornata ideale è probabilmente sbagliato :-)

2) Provare a fare un breve sprint.Se stai facendo un mese sprint - prova di due settimane.Se stai facendo per due settimane - provare uno.

• Funge da limitatore della storia di dimensione - incoraggiare il proprietario del prodotto e il team al lavoro su piccole storie che sono più facili da stimare con precisione
• Si ottiene un feedback sempre più spesso parlare di stime - e è più facile vedere le connessioni tra le decisioni che hai fatto all'inizio dello sprint e ciò che è realmente accaduto
• Il tutto viene meglio con la pratica :-)

3) Utilizzare il supporto ups e retrospettive di guardare un po ' di più le ragioni degli alti e dei bassi.È quando si passa il tempo con particolari aree della base di codice?È causato dal folk equivoco, il proprietario del prodotto?Casuale emergenze che prendere il tempo di sviluppo di distanza dalla squadra?Una volta che si dispone di più di una comprensione di dove alti e bassi sono venuta da te può spesso risolvere tali problemi in particolare.Ancora più brevi sprint può aiutare a rendere più evidente.

4) Credere che la vostra storia.Probabilmente sapete questo...ma lo dirò lo stesso :-) Se giocherellare con quella orribile eredità pacchetto Pippo ha preso 3 volte più a lungo di quanto si pensava ultimo sprint - allora sarà anche prendere 3 x come pensi lo sprint successivo.Non importa come molto più efficace pensi di essere in questo momento ;-) Fidati la storia e l'uso di cose come quelle di Ieri del Meteo per la guida delle stime nella prossima primavera.

Spero che questo aiuta!

Answer 2

Sono felice di sentire che mischia ha avuto grande successo per voi - che è più importante che avere lo sprint burndown chart look ideale.Lo sprint burndown è solo uno strumento per la squadra, per aiutare a sapere se si è sulla buona strada per la sprint obiettivi.se la squadra ha avuto un incontro con sprint obiettivi, io non preoccuparsi troppo che il grafico appare come un ottovolante.Un paio di suggerimenti

• Durante lo sprint retrospettiva di chiedere al team in cui il lavoro supplementare è venuta da
• Il lavoro supplementare può venire dal non avere buone le prove di accettazione a inizio sprint
• Il lavoro supplementare può venire dal non avere una ben curati backlog.Una buona regola empirica è quello di spendere almeno il 5% della squadra è tempo di pensare al prossimo sprint storie prima del tempo.
• Monitorare i lavori in corso - è la squadra che fa troppo in parallelo?
• Durante lo sprint planning - come fa il team di sentire circa la ripartizione delle attività che compongono le storie?

Se non avete avuto un incontro sprint obiettivi - utilizzare il consolidato team di velocità di prendere meno durante lo sprint successivo.È necessario per ottenere buoni a camminare prima di poter eseguire.

Answer 3

Nella mia esperienza, la Mischia è sicuramente più orientata verso un nuovo sviluppo, che è verso di manutenzione.Il nuovo sviluppo è molto più prevedibile di mantenimento di un vecchio, grande base di codice.

Detto questo, un possibile problema è che non stai rompendo i compiti in abbastanza piccoli pezzi.Un problema comune che le persone hanno con il software di pianificazione in generale, è che pensano: "oh, questo compito dovrebbe prendere me 2 giorni" senza pensare davvero a quello che va a fare l'attività.Spesso, troverete che se ti siedi e pensi che il compito è quello di fare A, B, C, e D e finisce con l'essere più di 2 giorni di lavoro.

Answer 4

Come altri hanno detto, mi sarei aspettato un burndown essere su e giù.Roba succede!È necessario utilizzare il "su e giù" bit come foraggio per le retrospettive.

Assicurarsi che tutti è chiaro su ciò che "essere fatto", e l'uso che il comune comprensione per aiutare a guidare il vostro sessioni di pianificazione.Spesso avere una lista di ciò che costituisce di fatto disponibili (a) aiutare a ricordare le cose che si potrebbe dimenticare e (b) sarà probabilmente innescare ulteriori idee per le attività che, altrimenti, superficie in seguito.

Un altro punto da sapere se si sta lavorando mese in mese, con un imprevedibile codebase, vorrei ancora aspettare la tua velocità di normalizzare un ragionevolmente costante.Solo traccia del vostro successo contro il lavoro pianificato e utilizzare solo gli elementi completati come massimo fase di progettazione.Quindi concentrarsi sulla vostra attività non pianificate e vedere se ci sono modelli che suggeriscono che ci sono cose che si possono fare in modo diverso per includere quelle cose nel lavoro pianificato.

Answer 5

Ho avuto problemi simili.La mia squadra precedente (su di esso per più di un anno) era grande e abbiamo mantenuto una molto grande, che cambia rapidamente codebase per la serie di lancio di nuovi prodotti.Il nostro burndowns sono stati vergognosi, cercando, ma era il massimo che poteva fare.

Una cosa che può aiutare a (rendere il vostro grafico un aspetto migliore) è il bastone per il numero di ore/punti impegnata in una costante.Se avete sottovalutato un compito, e di raddoppiare ore, tirare fuori qualcosa di sprint.Se si tira in una nuova attività, è ovviamente di priorità superiore rispetto a qualcosa che il vostro team impegnati in modo da tirare che altra cosa.

Abbiamo provato a rompere il compito in molti compiti e prima di pianificazione, e che non è mai sembrato di aiuto.Infatti, non solo ci ha dato più dannatamente biglietti da controllare durante lo sprint.Requisiti iniziato la migrazione per i biglietti e (non sorprendentemente) perso in tutte le shuffle.

Sulla mia nuova squadra, abbiamo preso un bel approccio radicale e ha iniziato a creare grandi biglietti (alcuni più di una settimana lunga) che dicono cose come "implementare v1.2 caratteristiche in ProjectX." I requisiti/funzionalità liste per ProjectX (versione 1.2 incluso), sono tenuti su un wiki, quindi il biglietto è molto pulito e solo le tracce del lavoro svolto.Questo ci ha aiutato molto - abbiamo modo un minor numero di biglietti per tenere traccia di, e sono stati in grado di finire tutti i nostri scatti, anche se abbiamo sempre tirato fuori il nostro sprint compiti per aiutare altre squadre o spegnere incendi.

Continuiamo a spingere gli oggetti, sprint, se (e solo se) siamo costretti (l'uomo) per portare nuovi elementi.

Un altro semplice suggerimento che ci hanno aiutato:aggiungere "totale ore nella sprint" per il burndown.Questa dovrebbe essere la somma di tutte le stime.Lavorare per mantenere questa linea flat può aiutare, e aumenta la visibilità dei problemi che il vostro team può essere di fronte (supponendo che non vi abbassato...)

-ab

Answer 6

Ho avuto problemi simili nel mio burndown così.Ho "risolto" da raffinazione di ciò che è stato incluso nel burndown.

SiKeep ha commentato:

Il suo progresso contro il backlog selezionati per sprint, che può o non può finire come una liberazione.

Dal momento che hai selezionato alcune cose per la sprint e che cosa è il burndown, non so che tutti i "nuovi lavori" dovrebbe apparire nel burndown.Vorrei vedere andando sul portafoglio ordini (che non influenzano il burndown), a meno che non è abbastanza importante per spostare la tua attuale sprint (che poi si mostra come una tendenza al rialzo nel burndown).

Detto questo, minori up e down sono normali, se la linea di tendenza fondamentalmente segue previsto per la velocità.Sarei preoccupato per il roller-coaster tendenza si sta menzionare.Tuttavia, l'idea di isolare il burndown da solo l'aggiunta di elementi ad alta priorità per l'attuale sprint può aiutare a smorzare queste vicende sul tuo burndown.

Come altri hanno detto, la pianificazione prima di sprint inizia dovrebbe essere breve...(non più di 4 ore).

Answer 7

Stiamo utilizzando un time-boxed incarico per attività non pianificate.Ogni volta che ad alta priorità di lavoro è in arrivo, o improvvisa bug pop-up, si può utilizzare il tempo il tempo-box (ma, non si può mai andare sotto zero).Questo metodo ha il vantaggio che si può facilmente tenere traccia delle attività che erano previste, e tenere queste cose in considerazione durante il nostro prossimo sprint planning.

Answer 8

È possibile integrare il nuovo lavoro in volata la data di inizio, di avere una grande ricerca Burndown chart.

Si può etichettare con un marcatore specifico il lavoro supplementare e valutare allo sprint finale perché non essere in grado di identificare quelle attività prima.

Answer 9

Ora stiamo utilizzando un bruciare grafico.Invece di tracciare la quantità di lavoro che abbiamo grafico di due cose:la quantità di lavoro compiuto e la quantità totale di lavoro (vale a dire.completato + in circolazione).

Questo vi dà due linee sul grafico che deve soddisfare, quando tutto il lavoro è fatto.Essa ha anche un grande vantaggio, in quanto mostra chiaramente quando il progresso è lento a causa di lavoro in più, è stato aggiunto.

Se ti piace, PO 'possiede' una riga (il lavoro totale) e gli sviluppatori/tester l'altra linea (il lavoro fatto).

Il PO e la linea andrà su e giù come aggiungere/rimuovere lavoro.

Dev/tester di linea solo andare per completare il lavoro.

Answer 10

Articolo È il vostro bruciare grafico? spiega che un determinato stato nel bruciare grafico significa.Esso fornisce anche suggerimenti su cosa fare con quello.

Alcuni esempi descritti nell'articolo:

Answer 11

Questo è come dovrebbe essere.Se il burndown chart sembra che il modello grafico, sei nei guai.Il grafico aiuta a vedere se si sarà in grado di farvi impegno e la fine di tutte le storie.

Alla scoperta di storie durante lo sprint sarà sempre accadere.Idealmente, si dovrebbe essere in grado di progettare e scoprire i compiti ma se hanno lavorato perché sarebbe un grande anticipo di design non funziona?Per rispondere all'ultima domanda, la pianificazione sprint dovrebbe prendere a più di quattro ore.