Metriche Kanban in pratica a Sky UK [ITA]
•Transferir como PPTX, PDF•
11 gostaram•3,786 visualizações
Perche’ dovrei raccogliere metriche? Come possono aiutarmi? Il mio CFD e’ molto colorato ma a cosa serve? CFD, control chart, lead time distribution…Le metriche possono incutere timore ma se sai come interpretarle puoi portare il tuo processo a un nuovo livello! In questo experience report pieno di esempi pratici vi raccontero’ come il mio team a Sky (Londra) usa Kanban e metriche per: - guidare il processo di miglioramento continuo - essere prevedibili, senza bisogno di stime Downloads Powerpoint: https://goo.gl/mHg3nx PDF: https://goo.gl/WFaoW8
Recomendados
Recomendados
Mais conteúdo relacionado
Destaque
Destaque (18)
Semelhante a Metriche Kanban in pratica a Sky UK [ITA]
Semelhante a Metriche Kanban in pratica a Sky UK [ITA] (20)
Mais de Mattia Battiston
Mais de Mattia Battiston (7)
Metriche Kanban in pratica a Sky UK [ITA]
- 1. Metriche Kanban in pratica @ Sky UK GOOD CRAP AWESOME! @BattistonMattia
- 2. About me ● ~2 anni @ Sky Network Services, Londra ● software dev & continuous improvement ● Kanban “helper” Mattia Battiston @BattistonMattia mattia.battiston@gmail.com Ciao!
- 4. Kan...ché? conoscenza di base di Kanban aiuta (WIP limits, lead time, batches, etc.)
- 5. Metriche - Perché? #1: miglioramento continuo #2: prevedere il futuro
- 6. Ma le metriche non erano cattive? Problemi tipici: - si imbroglia - disfunzioni
- 7. Buone vs Cattive Metriche ● migliorare il sistema ● premiare/punire individui “95% performance attribuibile al sistema, 5% alle persone” W. Edwards Deming ● feedback ● obiettivi ● leading (guardano al presente) ● lagging (guardano al passato) ● tutte devono migliorare ● ottimizzazioni locali
- 9. Come raccogliamo i dati?
- 10. Spreadsheet Input: dettagli della storia; inizio & durata di ogni stato;
- 11. (Poca) Matematica ● Min, Max Normal: data is distributed around a central value e.g. height of UK population Skewed: data has a long tail on one side (positive or negative) e.g. income of UK population (positive skew) Lead time of stories follows skewed distribution ● Media avg(1,2,2,2,3,14) = (1+2+2+2+3+14)/6 = 4 ● Mediana: separa metà alta e metà bassa. Meno influenzata da outlier median(1,2,2,2,3,14) = 2 ● Moda: valore più frequente mode(1,2,2,2,3,14) = 2 ● Standard Deviation: misura la dispersione dalla media. Quando è alta, i valori oscillano in un largo intervallo. stdev(1,2,2,2,3,14) = 4.5; stdev(1,2,2,2,3,5) = 1.2; ● Percentile: percentuale di elementi che cadono in un intervallo 50% perc(1,2,2,3,7,8,14) = 3; 80% perc(1,2,2,3,7,8,14) = 7.8; ● Normal Distribution vs Skewed Distribution:
- 12. Cumulative Flow Diagram Descrizione: Per ogni giorno mostra quante storie sono in ogni stato no.storie giorni
- 13. Cumulative Flow Diagram ● Obiettivo: retrospettiva (con un buon facilitatore) ● Obiettivo: dimostra l’efficacia dei cambiamenti cambio WIP limit in DEV: da 3 a 2
- 14. Cumulative Flow Diagram ● Obiettivo: decidere su cosa lavorare oggi ● Obiettivo: forecasting. Approssimazione per lead time, wip, delivery date (ma è più facile se sono raccolti separatamente) WIP LEAD TIME
- 15. CFD Patterns (fonte: CFD article by Pawel Brodzinski) growing lines: indicate large WIP + context switching. action: use WIP limits stairs: indicates large batches and timeboxes action: move towards flow (lower WIP, more releases, cross-functional people) flat lines: nothing’s moving on the board action: investigate blockers, focus on finishing, split in smaller stories single flat line: testing bottleneck action: investigate blockers, pair with testers, automate more typical timeboxed iterationdropping lines: items going back action: improve policies
- 17. Control Chart Descrizione: Mostra la durata di ogni storia. Usa un limite superiore e inferiore; le storie che cadono fuori dai limiti sono storie interessanti (insolite), le analizziamo per migliorare storie cycletime(gg)
- 18. Cycle/Lead Time stats + History Descrizione: Statistiche per conoscere il tuo cycle time. Aiuta a predire “quanto impiegherà probabilmente la prossima storia?”. Visualizza trend di miglioramento
- 19. Lead Time distribution 50% 85% cycle time (gg) no.storie Descrizione: Per ogni lead time (n. giorni), quante storie hanno impiegato così a lungo. Utile mostrarlo in percentuale per conoscere la probabilità.
- 20. Story Health 50-80% >90%80-90%0-50% Descrizione: Indica se una storia è in buona salute o se dobbiamo preoccuparci. Basato su lead time distribution 0-6gg 6-10gg 10-14gg 14+gg
- 21. Cycle Time vs Release Prep. Time storie giorni Descrizione: Per ogni storia mostra quanto ha speso nell’iterazione e in release preparation. Usato per discutere il costo di rilasci poco frequenti
- 23. Iteration Throughput iterazione no.storiecompletate Descrizione: Numero di storie completate in una iterazione
- 24. WIP iterazione media(WIPgiornaliero) Descrizione: Per ogni iterazione, la media del WIP giornaliero
- 25. Little’s Law more visible here Descrizione: Lead Time = WIP / Throughput Dimostra che quando WIP scende, il Lead Time diminuisce e il Throughput cresce
- 26. Points vs Cycle Time cycletime(gg) story points Descrizione: Mostra scarsa correlazione tra punti stimati e cycle time reale
- 27. Disney Stations Descrizione: Come in coda a Disneyland. “Quanto tempo qui? Quanto tempo da qui?”
- 28. Task Time Descrizione: Mostra quanto impiega ogni task. Dà indicazione di quanto una storia impiegherà in base al n. di task
- 30. Bugs percentage Descrizione: Percentuale di bug per storia. Espresso come “1 bug ogni X storie”
- 32. Flow Efficiency Descrizione: Mostra quanto tempo le storie spendono in code - nessuno ci stava lavorando. Mostra quanto si può migliorare eliminando i tempi di attesa.
- 33. Time in status tempoinstato(gg) storie Descrizione: Per ogni storia mostra quanto ha speso in ogni stato (tempo assoluto e percentuale). Mostra trend di dove le storie spendono più tempo tempoinstato(%)
- 34. Stats per Status Descrizione: control chart, cycle time distribution e stats per ogni stato. Utile per simulazioni (forecast); dà indicazione di dove dobbiamo migliorare
- 35. Retrospettiva
- 36. Risorse Libri Presentazioni ● Troy Magennis LKUK13 LKCE13 Agile 2014 ● David Anderson Kanban's 3 Agendas LKUK13 ● Hakan Forss The Red Brick Cancer Articoli ● Cycle-time Analysis and Monte Carlo Simulation Results (Troy Magennis) ● The Seven Deadly Sins of Agile Measurement (Larry Maccherone) ● A Tool for tracking Kanban projects (Emily Webber) ● FocusedObjective@Github ● Lean Forecasting Tutorial by Troy Magennis ● Cumulative Flow Diagram (Pawel Brodzinski) ● worldofchris@github (Chris Young) Case Studies Siemens Health Services Sandvik IT Ericsson SAP Lean Kanban Case Studies series ● Dan Brown Flow Like Ketchup (LLKD14) ● Dimitar Bakardzhiev LKUK14 webinar ● Larry Maccherone LKUK14 ● Analyzing Lead Time Distribution Chart (Alexei Zheglov) ● Inside a Lead Time Distribution (Alexei Zheglov) ● Forecasting Your Oranges (Dan Brown) ● On Story Points and Distributions (Agile Pirate)
- 37. Grazie! @BattistonMattia mattia.battiston@gmail.com molto, molto apprezzato! Aiutami a migliorare
Notas do Editor
- grazie mille per aver scelto la mia sessione. Posso chiedere una rapida alzata di mano: chi sa piu’ o meno cos’e’ Kanban? chi ha mai visto o usato un CFD? Ok, siete nel posto giusto!
- Io sono Mattia Battiston, da due anni lavoro a Londra per Sky Sky e’ la stessa Sky che c’e’ in Italia, ma in UK ci occupiamo anche di internet e telefono. Io faccio funzionare internet Devo avvisarvi che dopo due anni a parlare in inglese il cervello mi e’ andato in pappa e faccio fatica a pensare ad alcuni termini in italiano. ci saranno molti inglesismi, perdonatemi! a Sky sono sviluppatore, team leader e “Kanban Helper”. Aiuto team a usare Kanban e metriche
- questa presentazione e’ una versione rivista di un workshop che tengo in azienda per gli altri team spiego l’esperienza del mio team, perche’ usiamo metriche, cosa abbiamo imparato, ecc.
- un minimo di conoscenza di Kanban aiuta, ma non e’ strettamente necessario. se sapete cosa si intende con WIP Limit dovrebbe essere abbastanza per seguire senza problemi
- Perche’ servono metriche? Quale problema stiamo cercando di risolvere? - usiamo metriche per guidare il nostro processo di miglioramento continuo. Decidiamo dove dobbiamo migliorare, introduciamo un cambiamento, e valutiamo se l’esperimento e’ stato positivo o meno - forecast. Quando ci viene chiesta una stima, invece di tirare a indovinare usiamo i dati storici che abbiamo per prevedere quanto impiegheremo. Usiamo una tecnica che si chiama Probabilistic Forecating Forecasting e’ un argomento enorme, oggi vi faccio vedere giusto un po’, ma se volete saperne di piu’ possiamo parlarne durante la pausa
- molto spesso la reazione della gente quanto si parla di metriche e’ “mmmh, no grazie” abbiamo visto un sacco di usi spaventosi (es. punti raddoppiati) e’ vero, i problemi tipici di ogni metrica sono che si puo’ imbrogliare, e causera’ disfunzioni
- Per questo noi facciamo questa distinzione tra metriche buone e cattive: buone metriche aiutano a migliorare il sistema, non sono usate per punire o premiare singoli individui usiamo metriche come feedback per sapere se stiamo migliorando, ma non sono mai un obiettivo preferiamo metriche “leading” rispetto a “lagging” solo quando tutte migliorano allora stiamo migliorando, cosi’ non si puo’ imbrogliare
- questa e’ la lavagna principale del mio team queste buste colorate rappresentano i nostri WIP limit la prima colonna si chiama NEXT e contiene le 3 storie che sono la priorita’. quando si libera uno spazio, decidiamo “qual e’ la prossima priorita’?” NEXT e’ il commitment point poi la storia va in dev e testing, fino a waiting for cut aspetta qui fino alla fine dell’iterazione (due settimane), poi facciamo un cut. il cut va in release testing e poi viene rilasciato in produzione dopo un mese applicazioni piu’ recenti vengono rilasciate on-demand, senza aspettare il cut direct va da dev a done immediatamente questi sono 3 diversi work item type. quasi tutte le metriche hanno senso solo quando consideri un singolo tipo di work item per esempio, il lead time di storie “on demand” e’ molto diverso dal lead time di storie “iteration-based”
- raccogliere i dati e’ molto semplice. quando stampiamo le storie usiamo una griglia in basso con una cella per ogni stato. ogni volta che la storia va allo stato successivo la timbriamo con la data attuale e questo e’ tutto quello che serve! e’ abbastanza per calcolare tutte le altre metriche perche’ non usiamo un tool elettronico? i dati raccolti dal tool spesso non rappresentano la realta’ (ma se ti fidi allora usali!) i tool sono molto scarsi nell’analisi di questi dati. offrono molto poco, e quel che offrono e’ molto rigido. Preferiamo spreadsheet perche’ offre massima flessibilita’
- regolarmente mettiamo i dati in uno spreadsheet l’unico input sono qualche dettaglio sulla storia (id, descrizione) e le date in cui entra in uno stato. tutto il resto e’ calcolato
- non fatevi spaventare, la matematica che serve e’ poca e probabilmente la ricordate dai tempi della scuola. comunque ci sono le formule gia’ fatte in excel
- Probabilmente e’ il grafico piu’ famoso di Kanban per ogni giorno mostra quante storie sono in ogni stato un buon CFD mostra linee che crescono in modo continuo e parallele e’ molto colorato e fa figo, ma cosa ci puoi fare in pratica?
- lo usiamo in retrospettive per parlare di un particulare periodo di tempo. lo usiamo per dimostrare l’efficacia dei cambiamenti
- lo puoi usare per decidere su cosa lavorare (es. se uno stato e’ troppo grosso) ci puoi leggere informazioni sulla prevedibilita’. WIP, Lead Time, e perfino proiettare il delivery date. Ma ci sono altri modi piu’ facili se hai i dati
- ci sono una serie di pattern che si possono identificare in un CFD
- un altro grafico molto famoso. di solito usano punti invece di colonne, ma e’ sempre lo stesso mostra storie insolite dalle quali si puo’ imparare
- calcoliamo un po’ di statistiche che ci aiutano a capire il nostro lead time mediana e’ meno influenzata da estremi rispetto alla media deviazione ci da’ una indicazione di quanta variabilita’ abbiamo un po’ di percentili sono utili per fare previsioni, e in attimo ve ne parlo meglio usiamo “all time” e “since XXX” perche’ dati troppo vecchi non dovrebbero piu’ essere rappresentativi
- se avete mai avuto problemi con stime, questa e’ la parte dove volete fare attenzione. conta quante storie hanno impiegato un certo numero di giorni la curva si chiama Weibull, ma non importa posso esprimere questi dati come percentuale, e decidere quando dovrei iniziare una storia
- ci serve una metrica leading; abbiamo inventato story hearth in base a da quanto la storia e’ gia’ in progress, sappiamo se va bene o se dobbiamo preoccuparci usiamo questo durante lo standup per decidere su cosa lavorare
- per chi di voi non rilascia in produzione molto spesso, questo e’ interessante. in blu e’ il tempo che impiega la storia per essere “pronta”. in rosa il tempo che poi impiega per arrivare in produzione abbiamo usato questo per discutere e chiedere di rilasciare piu’ spesso
- contiamo il numero di storie completate in un particolare arco di tempo. noi usiamo l’iterazione come unita’ temporale utile per sapere quante storie dovremmo pianificare per una iterazione utilissimo per fare montecarlo-simulation
- teniamo traccia di quanto WIP c’e’ ogni giorno, e facciamo la media per ogni iterazione l’obiettivo e’ tenere il WIP basso per limitare il context switching
- avendo throughput e WIP possiamo dimostrare Little’s Law
- questa slide di solito mi mette nei guai, perche’ in ambienti agili di solito criticare l’uso di story points e’ un tabu’ storie da 1 un punto impiegavano 2-10 giorni; storie da due punti impiegavano 2-20 giorni, ecc. la correlazione tra punti e quanto impiegano in effetti e’ quasi inesistente ci sono altri fattori che influenzano il lead time molto piu’ dei punti: WIP e blockers adesso usiamo semplicemente la lead time distribution per predire quanto una storia impieghera’
- come in coda a disneyland “quanto ci vuole da qui?”
- prima di iniziare development dobbiamo identificare i task per la storia in base al numero di task sappiamo quanto la storia impieghera’ in base al numero di task rimanenti decidiamo se dobbiamo aiutare su una storia o se va tutto bene
- semplicemente contiamo il numero di bug (qualsiasi cosa riportata come bug) e il numero di storie, e lo esprimiamo come percentuale lo usiamo per pianificare: se sto pianificando 10 storie, devo tenere conto che dovro’ anche lavorare su 1-2 bug
- sappiamo quali stati aggiungono valore, perche’ qualcuno sta lavorando su una storia, e quali stati invece sono semplici code, la storia sta aspettando flow efficiency e’ la percentuale di tempo spesa aggiungengo valore dimostra deming: non e’ facendo lavorare le persone di piu’ che avremo un miglioramento, ma cambiando il processo possiamo eliminare le code ed essere 50% piu’ veloci per ridurre code: abbassa WIP, cross-functional team (one piece flow)
- per ogni storia mostra quanto ha speso in ogni stato, sia in tempo assoluto che in percentuale pensato a quante volte quando un progetto e’ in ritardo viene puntato il dito sugli sviluppatori, e magari vengono aggiunti developers. questa potrebbe aiutare il blu, ma per fare la differenza dobbiamo rimuovere tutto il resto
- analizziamo anche ogni singolo stato, per decidere su cosa dobbiamo concentrarci