Bez wątpienia podstawową metryką postępu prac jest działające oprogramowanie. Ważne zatem jest jak często zespół dostarcza działające oprogramowanie na produkcję aby klienci mogli go używa. Zatem które metryki użyteczne dla zespołu mogą w tym pomagać?
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. Ponieważ te informacje są równie ważne, dobrze jest wiedzieć jak funkcjonuje, jak dostarcza nasz zespół. Wydaje się, że idealnie nadają się do tego metryki.
Dzięki temu, że dostarczamy często mamy szansę nauczyć się czegoś nowego o naszych klientach i ich potrzebach. W przeciwnym razie, jeżeli dostarczamy rzadziej mamy mniejsze szanse na naukę. Podobnie do nauki 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
Przeczytaj również opracowanie Daniel Vacanti: Cost of Delay – wybór kolejności pracy nad funkcjonalnościami.
Źródła pełnej prezentacji obejrzysz tutaj.
Blog Tennera: https://www.spikesandstories.com/