Mattia Battiston: Metryki Kanban w praktyce.
Dlaczego stosujemy metryki?
– ciągłe usprawnianie
– prognozowanie przyszłości
Metryki stosujemy w oparciu o działanie systemu. Dla poprawności danych a co za tym idzie metryk, istotna jest również stabilność systemu. Moje zdanie jest takie, że ma to znaczenie w każdym systemie – zebranie i analiza danych może pokazać jak i gdzie niestabilny jest system, dzięki czemu będzie można podjąć działania z tym związane. Poznaj metryki Kanban w praktyce.
Ważne aby patrzeć na kilka metryk, które dają różną perspektywę. Patrzenie tylko na 1 metrykę może prowadzić co lokalnej optymalizacji, która nie bierze pod uwagę działania całego systemu.
Fizyczna tablica Kanban
Stosujemy tablice fizyczne, natomiast w wersji elektronicznej są tylko 3 kolumny: do zrobienia, w trakcie i zrobione – tak by inne zespoły widziały ogólny postęp prac i była możliwa koordynacja. Na karcie zadania po prostu stemplujemy datę kiedy zadanie zmienia status. Przeniesienie tych danych do excela jest bardzo szybkie i tam gromadzimy i analizujemy nasze dane.
Zachęcam do takiego ręcznego zbierania i ustalania metryk zanim zaczniemy tą pracę automatyzować lub kupować wymyślne narzędzia. Pozwala to na zrozumienie i nauczenie się ich działania.
Metryki w moich zespołach
Używamy Cumulative Flow Diagram, na który jest dobrze patrzeć ale jest mniej wygodny w codziennym użyciu. Dlatego więcej uwagi poświęcamy mu podczas retrospekcji. Jednocześnie możemy używać go również do prognozowania postępu prac.
Delivery Time Control Chart – pozwala widzieć nam jak długo realizowane są poszczególne zadania. Dzięki temu wiemy np. że 85% zadań realizujemy w X dni lub szybciej. Jeżeli jakieś zadanie wykracza poza ustalone granice, chętnie o tym rozmawiamy co było przyczyną takiego stanu rzeczy. Możemy poszukać przyczyn i nauczyć się czegoś na tej podstawie.
Zmienia to również dyskusję z biznesem, który nie musi już pytać o estymacje. Dzięki danym wiemy, że dane zadanie możemy zrealizować w 10 dni lub szybciej z 85% prawdopodobieństwem. Rozmowa schodzi więc z pojęcia estymacji na temat rozmów o ryzyku jakie jesteśmy skłonni zaakceptować dla realizacji wymaganego przez biznes zadania.
Ponieważ system ciągle się zmienia, patrzymy na dane maksymalnie z ostatnich 4-5 miesięcy.
Patrzymy również na dystrybucję (rozkład) czasów dostarczenia. Ponownie umożliwia to rozmowę o prawdopodobieństwie dostarczenia rozwiązania oraz ryzyku jakie jesteśmy skłonni zaakceptować. Dodatkowo można zobaczyć jak przewidywalny lub nieprzewidywalny jest nasz system. Generalnie chcemy aby wartości zbliżały się do lewej strony wykresu. Jednocześnie chcemy jak najmniej wartości po prawej stronie, ponieważ tworzy do tzw. długi ogon. Im dłuższy ogon tym dłuższe czasy dostarczenia i tym mniejsza stabilność systemu.
Używamy również prawa Little’a który powinien wykazywać, że jeżeli ilość Pracy w Toku (WIP) spada, zmniejsza się czas dostarczenia w wzrasta przepustowość systemu.
Estymacja Story Points
Na początku projektu używaliśmy estymacji w Story Pointach. Jednocześnie chcieliśmy wiedzieć jaka jest relacja pomiędzy naszą estymacją o czasem realizacji, ponieważ ostatecznie to czas pozwala na planowanie realizacji zadań. Zebrane dane pokazały również u nas, że nie ma takiej korelacji. Potwierdza to relatywność estymacji w Story Pointach i jej oderwanie od jednostki czasu. Ponieważ w naszym przypadku ważne było prognozowanie w czasie, bazując na danych zrezygnowaliśmy ze Story Pointów.
Wprowadziliśmy również wizualizację jak w parkach rozrywki, dzięki czemu widać ile czasu potencjalnie zajmie dostarczenie zadania od określonego miejsca.
Stosujemy również metrykę opartą na ilości subtasków jakie zawiera w sobie zadanie. Dzięki wiedzy ile średnio zajmuje nam subtask i ile jest subtasków do wykonania, możemy podczas daily rozmawiać czy wykonanie zadania jest niezagrożone.
Metryka ilość bugów
Pod kątem metryk związanych z jakością liczymy tylko ilośc bugów w stosunku do ilości innych zadań. Dzięki temu podczas planowania czegokolwiek możemy powiedzieć, ile statystycznie może pojawić się bugów i wziąć tą wartość pod uwagę.
Miarą naszej efektywności jest efektywność przepływu zadań przez nasz system. Patrzymy tutaj jak długo zadania znajdują się w pasywnych stanach (kolejki) czekając, aż ktoś zacznie nad nimi pracować. Dzięki wizualizacji tego faktu możemy rozmawiać gdzie są najlepsze obszary do usprawnień i w jaki sposób polepszyć cały system.
Podobnie patrzymy na czas przebywania zadań w danym statusie, dzięki czemu możemy zaobserwować potencjalne miejsca, gdzie przepływ naszej pracy zwalnia.
Podsumowanie
- Na początku możesz pracować z metrykami manualnie – będzie to okazja do nauki i zrozumienia
- Nie przesadzaj z dokładnością – szukamy trendów
- System ciągle się zmienia, weź więc pod uwagę jaki zakres czasu obserwujesz
- Rozpoczęcie pracy z metrykami może nie być łatwe, ale nie poddawaj się
- Suche dane nie przemawiają do ludzi – przetłumacz je na konkretne informacje
Tutaj znajdziesz książkę Mattia: https://leanpub.com/metricsforbusinessdecisions
Przeczytaj też opracowanie Roland Cuellar: Metryki agile w służbie zwinności biznesowej
Źródła oryginalnej prezentacji https://www.youtube.com/watch?v=6zF9rZ63F28
