Przejdź do treści

Nicolas Brown: Jak wykresy kłamią?

Dane które posiadamy nie dają odpowiedzi ale pozwalają zadawać dobre pytania.

Wizualizacja danych może łatwo prowadzić do przekłamań lub wręcz pokazywania nieprawdy. W wizualizacji bardzo istotny jest również kontekst.

Wykres pokazuje tylko to co pokazuje, nic innego.

Wykres może wprowadzać w błąd poprzez:

  • zły sposób wizualizacji
  • pokazywanie wątpliwych danych
  • ukrywanie nieznanych elementów
  • pokazywanie niepełnych danych
  • sugerowanie błędnych wzorców

Nicolas pokazuje przykłady niewłaściwych wykresów ze świata Agile, które mogą w łatwy sposób wprowadzać w błąd i na których podstawie można wyciągać fałszywe wnioski.

Na przykład przy burn up charcie pokazujemy na wykresie spodziewany czas zakończenia prac bazując na średniej, czyli pomijając prawdopodobieństwo tych zdarzeń. Zgodnie ze słowami Sama L. Savage:

„Plany oparte na średniej, średnio licząc upadają”

Dlaczego deterministyczne określania zakończenia prac nie działa? Ponieważ działamy w środowisku złożonym zgodnie z modelem Cynefin.

Prognozowanie statystyczne

Powinniśmy używać innego podejścia, które mówi o pewnych zakresach możliwych wyników. To może prowadzić do zakresu 4-30 tygodni, który z kolei jest niepraktyczny ponieważ wydaje się, że rozstrzał wyników jest abstrakcyjny. Dlatego używamy narzędzia do prognozowania statystycznego Monte Carlo. W tym celu wykonujemy 1000 próbkowanie na podstawie danych historycznych co daje nam zakres możliwych wyników. To co jest ważne dla każdego wyniku możemy określić prawdopodobieństwo jego wystąpienia. Dzięki temu można rozmawiać o poziomie ryzyka jakie chcemy przyjąć.

Efektywność procesu

Naszą największą stratą nie są nieproduktywni developerzy ale zadania znajdujące się w stanie oczekiwania, w kolejce w naszym procesie. Dlatego warto mierzyć i wizualizować efektywność procesu. Tutaj trzeba jednak uważać, ponieważ taki wykres może być mylący. Bardzo często w naszym procesie nie ma stanu pasywnego. Nawet jeżeli są kolejki, statusy nie są często aktualizowane z opóźnieniem. Podobnie trudno jest zidentyfikować, że zadanie było w stanie aktywnym ale zablokowanym ponieważ przeważnie to nie jest jakoś specjalnie śledzone.

Kolejnym problemem jest fakt, że zadanie które ma wyliczoną efektywność procesu 19% niekoniecznie musi być faktycznie zrealizowane bardziej efektywnie niż zadanie z 9% wskaźnikiem. Z punktu widzenia klienta i tak taka efektywność procesu raczej nie ma znaczenia, ponieważ dla niego znaczenie ma czy dostanie jakąś funkcjonalność wcześniej.
Idąc dalej chcąc poznać efektywność całego procesu wykonujemy wyciągnięcie średniej, co jak już powiedziano wyżej nie jest dobre.

Cycle Time

Cycle Time, czyli ilość czasu jaka upłynęła od rozpoczęcia pracy nad zadaniem do jego dostarczenia, jest dobra metryką. Często można spotkać sytuację gdzie dzięki działaniom Scrum Mastera/Agile Coacha nastąpiła redukcja Cycle Time. To o czym jednak trzeba pamiętać to korelacja nie oznacza przyczynowości.

Mediana

Należy uważać również z medianą, która jest rodzajem uśrednienia. W przypadku średniego (mediana) Cycle Time, który spada może to prowadzić do mylnego wniosku że następuje jego skrócenie. Dlatego trzeba patrzeć na cały zestaw danych, cały kontekst ponieważ tak na prawdę może on rosnąć. Dlatego należy używać całego wykresu punktowego Cycle Time Scatterplot i percentyli. Wtedy można również zobaczyć pewne wzorce i o nich porozmawiać.

Metryki Leading i Lagging

Metryki wsteczne pokazują nam rzeczy które już się wydarzyły. Szukając metryk wyprzedzających trzeba uważać, aby nie patrzeć na wykresy, które mogą wprowadzić w błąd (np. wyświetlenie niewystarczających danych). Dlatego należy używać Work Item Age wykres. Gdyby Nicolas miał wybrać jeden wykres do używania – były to właśnie ten.

Źródło:

https://www.youtube.com/watch?v=sRb-H8BhGqE