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
Looking for resilience, in each individual, group of people, teams, organization. Agile Teams have a noble scope: to pursue excellence in software, reacting to any turbolence, by developing their skills, optimism, trust.
We like the architecture of our applications to revolve around the business logic, not around technical details (and especially not around the database).
In my team at Sky Network Services we use the Clean Architecture and it has given us a great deal of benefits: the business logic is explicit, we are free to change our technical decisions, the app is easy to test, working on it is faster and scalable, it’s hard to do the wrong thing, and many more.
But it comes at a cost, of course. In this talk I’ll tell you the story of our experience with Clean Architecture and give you some tips to get the most out of it.
Example Project
https://github.com/mattia-battiston/clean-architecture-example
Downloads
Online: https://goo.gl/DTxftJ
PDF: https://goo.gl/ZAtdBN
Powerpoint: https://goo.gl/D54wdZ (but you need to install these fonts to see it properly: https://goo.gl/iH8SO5)
Kanban Metrics in practice for leading Continuous ImprovementMattia Battiston
Why should I bother collecting metrics? How can they help me? My CFD is pretty and colourful, but what is it actually trying to tell me?
CFD, control chart, lead time distribution, percentiles...Metrics can be daunting to start with but if you know how to interpret them they can drive continuous improvement and forecast the future and take your Kanban system to the next level! It’s much easier than you think, no need for complex maths or expensive software.
At Sky Network Services a few teams are using Kanban and metrics. In this talk I’ll share our experience: what metrics we use, how we use each one of them, what little data we collect to get a whole lot of value, what pitfalls we encountered.
Downloads
Powerpoint: https://goo.gl/4CkKJd
PDF: https://goo.gl/VDW93U
Looking for resilience, in each individual, group of people, teams, organization. Agile Teams have a noble scope: to pursue excellence in software, reacting to any turbolence, by developing their skills, optimism, trust.
We like the architecture of our applications to revolve around the business logic, not around technical details (and especially not around the database).
In my team at Sky Network Services we use the Clean Architecture and it has given us a great deal of benefits: the business logic is explicit, we are free to change our technical decisions, the app is easy to test, working on it is faster and scalable, it’s hard to do the wrong thing, and many more.
But it comes at a cost, of course. In this talk I’ll tell you the story of our experience with Clean Architecture and give you some tips to get the most out of it.
Example Project
https://github.com/mattia-battiston/clean-architecture-example
Downloads
Online: https://goo.gl/DTxftJ
PDF: https://goo.gl/ZAtdBN
Powerpoint: https://goo.gl/D54wdZ (but you need to install these fonts to see it properly: https://goo.gl/iH8SO5)
Kanban Metrics in practice for leading Continuous ImprovementMattia Battiston
Why should I bother collecting metrics? How can they help me? My CFD is pretty and colourful, but what is it actually trying to tell me?
CFD, control chart, lead time distribution, percentiles...Metrics can be daunting to start with but if you know how to interpret them they can drive continuous improvement and forecast the future and take your Kanban system to the next level! It’s much easier than you think, no need for complex maths or expensive software.
At Sky Network Services a few teams are using Kanban and metrics. In this talk I’ll share our experience: what metrics we use, how we use each one of them, what little data we collect to get a whole lot of value, what pitfalls we encountered.
Downloads
Powerpoint: https://goo.gl/4CkKJd
PDF: https://goo.gl/VDW93U
These slides have been presented in the context of a technology outlook related with the Corporate Performance Management and Enterprise Strategy track of a master in business administration for executives.
Practical Diversity at Thinking Digital Women Meri Williams
How do we build inclusive environments that can not just tolerate but positively encourage diverse teams to do their best? We'll look at some practical things you can do to make things better.
Awesome People Management with Agile at Agile North EastMeri Williams
Agile people management is two things -- applying agile principles to managing people, and also figuring out how to manage people working with agile approaches. Traditional once-a-year reviews with annual targets are hardly very agile (or useful). How do we create space for our people to be awesome? Do we even need managers at all in agile?
Brilliant People Management in an Agile SettingMeri Williams
Agile people management is two things -- applying agile principles to managing people, and also figuring out how to manage people working with agile approaches. Traditional once-a-year reviews with annual targets are hardly very agile (or useful). How do we create space for our people to be awesome? Do we even need managers at all in agile?
Creating Space to Be Awesome at QCon LondonMeri Williams
Bringing agile approaches into how we manage people and lead teams can have wonderful, far-reaching impact. How do we get the most out of these new ways of working and also ensure that we create an inclusive environment where all types of people can be successful? In this session we’ll take a closer look at the science behind great people management, to figure out how to bring these together and craft space for everyone to be awesome.
There's another talk about Clean Architecture, SOLID, and our approach at InfoJobs. If you need the slides, don't hesitate to fork https://github.com/schibsted-android-training/workshop-5
THIS IS A PRESENTATION JUST THANKING THOSE WHO HAVE ALREADY LOOKED AT SOME OF MY PREVIOUS PRESENTATIONS. PLEASE LEAVE COMMENTS EXPLAINING ANY SUBJECTS THAT YOU WANT COVERING.
5 Amazing Vine Campaigns You Need To SeeSimplify360
Ever heard of that six second video App? Well, some brands are coming up with some extremely innovative and path breaking campaigns that will leave your jaw on the floor!
Final presentation of Project Management course (Gestione Progetti Software) ...Alexander Minichino
Final presentation of the Project Management course which I've attended in first semester 2019-2020 at the University of Salerno.
My role was that of Project Manager (one of two) in a team of seven members.
The Github link is available here: https://github.com/alexminichino/trawell
User Stories - Andrea Francia @ WeDev 7 novembre 2018Andrea Francia
Titolo completo:
User Stories: cosa sono, a cosa servono, come si usano e come no - Andrea Francia @ WeDev 7 novembre 2018
Relatore: Andrea Francia
Abstract:
Come si decide quello che dovrà fare un sistema software? E poi, come comunicare la decisione alle varie persone coinvolte? È una problema difficile perché ognuna delle parti in gioco ha visioni e necessità diverse. Project manager, sviluppatori, utenti, tester e clienti hanno bisogni diversi e punti di vista diversi. Come creare un confronto produttivo tra queste persone arrivando ad una singola decisione condivisa che tutti possono supportare e mantenerne l'equilibrio per mesi o addirittura anni? In eXtreme Programming si usano le storie, un metodo per organizzare lo sviluppo semplice e efficace che però spesso viene spiegato complicato e snaturato delle caratteristiche che lo rendono utile. In questa presentazione riprendiamo la definizione originale e vediamo come usarlo come strumento per la pianificazione del lavoro e di supporto alla comunicazione e condivisione di conoscenza.
Video:
https://www.youtube.com/watch?v=dC9G4o-m5X8
Come ridurre il rischio di fallire un progetto "all fixed" (ambito, tempi e costi) senza cambiare il contratto?
Usando un approccio Agile!
In questo talk parleremo di progetti reali e sfidanti che hanno avuto successo grazie alla stretta collaborazione con il cliente.
Feedback continuo, trasparenza e sviluppo incrementale sono ingredienti alla base di questi risultati.
Sfatiamo il mito "non posso fare agile perchè il cliente e il contratto non me lo permettono"!
These slides have been presented in the context of a technology outlook related with the Corporate Performance Management and Enterprise Strategy track of a master in business administration for executives.
Practical Diversity at Thinking Digital Women Meri Williams
How do we build inclusive environments that can not just tolerate but positively encourage diverse teams to do their best? We'll look at some practical things you can do to make things better.
Awesome People Management with Agile at Agile North EastMeri Williams
Agile people management is two things -- applying agile principles to managing people, and also figuring out how to manage people working with agile approaches. Traditional once-a-year reviews with annual targets are hardly very agile (or useful). How do we create space for our people to be awesome? Do we even need managers at all in agile?
Brilliant People Management in an Agile SettingMeri Williams
Agile people management is two things -- applying agile principles to managing people, and also figuring out how to manage people working with agile approaches. Traditional once-a-year reviews with annual targets are hardly very agile (or useful). How do we create space for our people to be awesome? Do we even need managers at all in agile?
Creating Space to Be Awesome at QCon LondonMeri Williams
Bringing agile approaches into how we manage people and lead teams can have wonderful, far-reaching impact. How do we get the most out of these new ways of working and also ensure that we create an inclusive environment where all types of people can be successful? In this session we’ll take a closer look at the science behind great people management, to figure out how to bring these together and craft space for everyone to be awesome.
There's another talk about Clean Architecture, SOLID, and our approach at InfoJobs. If you need the slides, don't hesitate to fork https://github.com/schibsted-android-training/workshop-5
THIS IS A PRESENTATION JUST THANKING THOSE WHO HAVE ALREADY LOOKED AT SOME OF MY PREVIOUS PRESENTATIONS. PLEASE LEAVE COMMENTS EXPLAINING ANY SUBJECTS THAT YOU WANT COVERING.
5 Amazing Vine Campaigns You Need To SeeSimplify360
Ever heard of that six second video App? Well, some brands are coming up with some extremely innovative and path breaking campaigns that will leave your jaw on the floor!
Final presentation of Project Management course (Gestione Progetti Software) ...Alexander Minichino
Final presentation of the Project Management course which I've attended in first semester 2019-2020 at the University of Salerno.
My role was that of Project Manager (one of two) in a team of seven members.
The Github link is available here: https://github.com/alexminichino/trawell
User Stories - Andrea Francia @ WeDev 7 novembre 2018Andrea Francia
Titolo completo:
User Stories: cosa sono, a cosa servono, come si usano e come no - Andrea Francia @ WeDev 7 novembre 2018
Relatore: Andrea Francia
Abstract:
Come si decide quello che dovrà fare un sistema software? E poi, come comunicare la decisione alle varie persone coinvolte? È una problema difficile perché ognuna delle parti in gioco ha visioni e necessità diverse. Project manager, sviluppatori, utenti, tester e clienti hanno bisogni diversi e punti di vista diversi. Come creare un confronto produttivo tra queste persone arrivando ad una singola decisione condivisa che tutti possono supportare e mantenerne l'equilibrio per mesi o addirittura anni? In eXtreme Programming si usano le storie, un metodo per organizzare lo sviluppo semplice e efficace che però spesso viene spiegato complicato e snaturato delle caratteristiche che lo rendono utile. In questa presentazione riprendiamo la definizione originale e vediamo come usarlo come strumento per la pianificazione del lavoro e di supporto alla comunicazione e condivisione di conoscenza.
Video:
https://www.youtube.com/watch?v=dC9G4o-m5X8
Come ridurre il rischio di fallire un progetto "all fixed" (ambito, tempi e costi) senza cambiare il contratto?
Usando un approccio Agile!
In questo talk parleremo di progetti reali e sfidanti che hanno avuto successo grazie alla stretta collaborazione con il cliente.
Feedback continuo, trasparenza e sviluppo incrementale sono ingredienti alla base di questi risultati.
Sfatiamo il mito "non posso fare agile perchè il cliente e il contratto non me lo permettono"!
Loosely Coupled Complexity - Unleash the power of your domain modelFrancesca1980
Common software architectures are full of well-established assumptions. But some of them are flawed, no longer valid or relevant. Changing the rules of the game using DDD, CQRS and Event Sourcing can lead to systems which are more scalable, maintainable and performing. And which are fun to code as well.
[Presentation] MultiProject analysis with Critical Path MethodMichele Palumbo
This project has been developed to provide decision support to all Program managers who manage multiple projects with shared resources that are, of course, planned by the various project managers assigned. Therefore, there is a vertical communication between the Program Manager and the various reference project managers in which the latter give precisely the planning of their project to the program manager. The stage I decided to focus on is post planning. One of the most difficult problems to deal with is to manage human resources linked to multiple projects, and then shared resources. Then, you can analyse whether a given resource may be abnormally allocated across multiple projects, or if you are straddling multiple immediately subsequent critical tasks related to both the single project and the N-projects on which it is allocated. To try to solve these problems, I decided to develop a software by following the approach of data analysis through the Critical Path Method (CPM).
The tools used to develop the software are: Neo4j and PyCharm, languages: Cypher and Python, libraries: pandas and py2neo
Agile for non developer - Italian Agile Days 2019Nicole Bartolini
User Story, Kanban, Iteration Meeting, Pomodori... tutto regolare per un team di sviluppatori. Ma che succede se aggiungiamo al team degli UX Designer e magari anche un Copy Writer e un Marketer?
Vediamo come continuare ad utilizzare metodi e strumenti Agile in team cross funzionali e come i non-developers possono beneficiarne.
Scopri come una lavagna KanBan può migliorare i tuoi processi. Organizza la tua Kanban. Attraverso questa presentazione verrai introdotto alle basi di utilizzo della lavagna kanban.
Introduzione ai Big Data e alla scienza dei dati - Big DataVincenzo Manzoni
Lezione 5 del corso di analisi dati tenuto al Palazzolo Digital Hub (Palazzolo sull'Oglio, Brescia) nel 2014. In questa quinta e ultima lezione si introducono le tecnologie dei Big Data.
Real Time Monitoring and Analitycs : Customer Experience in ProductionCodemotion
"Real Time Monitoring and Analitycs : Customer Experience in Production" by Simone Cellini, Simone Gaddeo
Come aiutare un cliente a evolvere il proprio Business da "Reactive" a "Proactive" convincendolo ad utilizzare tecnologie avanzate? In questo talk vi raccontiamo su un caso reale come abbiamo fatto. Utilizzando Kafka, ElastichSearch, Kibana, Java NIO & Concurrent API siamo riusciti a monitorare lo Stack Applicativo che eroga business, ad analizzarne i comportamenti e a garantire una "Availability" 24x7. Buona Visione
Similar to Metriche Kanban in pratica a Sky UK [ITA] (20)
Most teams need to answer questions like “When will it be done? What can I get by date X?”. However, common estimation approaches often fail to give us the predictability we want, and tend to introduce bad behaviours like hard deadlines and hiding uncertainty.
In this session, I’ll show you how, step by step and with real life examples, my team uses their historical data and metrics to forecast the future and answer these questions with confidence.
Download slides at: http://bit.ly/2pD9rfQ
Book discount link: http://leanpub.com/metricsforbusinessdecisions/c/MATTIA20-BZXib2F
Most teams need to answer questions like “When will it be done? What can I get by date X?”. However, common estimation approaches often fail to give us the predictability we want, and tend to introduce bad behaviours like hard deadlines and hiding uncertainty.
In this session, I’ll show you how, step by step and with real life examples, my team uses their historical data and metrics to forecast the future and answer these questions with confidence.
Download slides at: http://bit.ly/2pD9rfQ
Book discount link: http://leanpub.com/metricsforbusinessdecisions/c/MATTIA20-BZXib2F
The science of happiness
"I'll be happy once <I get this done/I get a promotion/I change job/I buy a new car/etc >". How many times have you said something like this? We think happiness comes from success, but science has proven that it's the other way around: being happy makes us successful.
Happiness has huge benefits on most aspects of our lives, including the professional one.
So how can we be happy? Well, turns out we can quite easily "trick" our brain into being happy(er). Let me tell you how, and how I apply these concepts in my day to day work with my team
Downloads
Powerpoint: https://goo.gl/teHeis
PDF: https://goo.gl/qwV6KB
Super chickens are not safe
What makes successful teams? Let's explore some of the science behind it.
Downloads
Powerpoint: https://goo.gl/hS4nIw
PDF: https://goo.gl/p8Ht29
Most recent version: https://www.slideshare.net/secret/tvYgHqBQQvL3fB
=======================================================
The science of happiness
"I'll be happy once <I get this done/I get a promotion/I change job/I buy a new car/etc >". How many times have you said something like this? We think happiness comes from success, but science has proven that it's the other way around: being happy makes us successful.
Happiness has huge benefits on most aspects of our lives, including the professional one.
So how can we be happy? Well, turns out we can quite easily "trick" our brain into being happy(er). Let me tell you how, and how I apply these concepts in my day to day work with my team
Downloads
Powerpoint: https://goo.gl/DcZiLq
PDF: https://goo.gl/zqmABA
Kanban Metrics in practice at Sky Network ServicesMattia Battiston
Why should I bother collecting metrics? How can they help me? My CFD is pretty and colourful, but what is it actually trying to tell me?
CFD, control chart, lead time distribution, percentiles...Metrics can be daunting to start with but if you know how to interpret them they can really take your Kanban system to the next level - drive continuous improvement and forecast the future! It’s much easier than you think, no need for complex maths or expensive software.
At Sky Network Services a few teams are using Kanban and metrics. In this talk I’ll share our experience: what metrics we use, how we use each one of them, what little data we collect to get a whole lot of value, what pitfalls we encountered.
Downloads
Powerpoint: https://goo.gl/19wOjU
PDF: https://goo.gl/AM69MF
2. About me
● ~2 anni @ Sky Network Services, Londra
● software dev & continuous improvement
● Kanban “helper”
Mattia Battiston
@BattistonMattia
mattia.battiston@gmail.com
Ciao!
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
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:
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à.
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
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.
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
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)
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