Podstawową metryką postępu prac jest działające oprogramowanie. (jak często zespół dostarcza działające oprogramowanie na produkcję).
Zwykle wiemy sporo o klientach a stosunkowo niewiele o zespołach i ich współdziałaniu, procesach i samych ludziach, którzy pracują nad oprogramowaniem.
Dzięki temu mamy szansę nauczyć się czegoś nowego o naszych klientach i ich potrzebach. Im rzadziej dostarczamy tym mniejsze szanse na naukę. Historia o nauce gry na pianinie. Jeżeli po uderzeniu w klawisz, dźwięk usłyszałbyś dopiero po 15 sekundach – nauka byłaby dużo trudniejsza, dłuższa i kosztowna. Szybkość informacji o reakcji na nasze działania ma ogromne znaczenie.
Czy metryki mogą pomóc Twojemu zespołowi ulepszać sposób pracy? Jeżeli tak to jakie metryki?
W jaki sposób odpowiedzialnie wykorzystywać metryki?
Czy metryki mogą pomóc naszym zespołom i organizacji w tworzeniu kultury eksperymentów?
Czyste metryki to nie wszystko. Jak powiązać je z motywacjami i pasją członków naszych zespołów?
- Dobre praktyki dla metryk:
- metryki w zasięgu działania zespołu
- metryki parte na trendach
- metryki wskazują kierunek zmian
- metryki są prawdziwe – oddają rzeczywisty stan rzeczy
- metryki są dla zespołu
- Złe praktyki
- metryki wygodne do zbierania ale nie dające wartości
- metryki oceniające ludzi
- wskaźniki końcowe, bez możliwości zmian
- metryki nieprawdziwe, przekłamane
Cel
- wzbogacenie rozmów zespołu
- przestrzeń do eksperymentów
- chcemy wiedzieć co zyskujemy i co tracimy
- metryki pokazujące wiele różnych wymiarów projektu
Dane zwykle nie odpowiadają na pytania ale inspirują do ich zadawani. Ich celem powinno być wzbudzenie ciekawości dlaczego dane pokazują to co pokazują
Przykładowe metryki
Przewidywalność = dostarczone Story Points/Zaplanowane Story Points
Szybkość = velocity/capacity
Jakość = ilość napisanych unit testów w Sprincie
Zaangażowanie = NPS
Źródła:
Blog Tennera: https://www.spikesandstories.com/