W tradycyjnych projektach kamienie milowe oraz KPIs (key performance indicators) mierzą postęp projektu oraz pokazują indywidualną kontrybucję do niego. W świecie agile, a w szczególności Scrum, różne metryki mogą nam podpowiedzieć na ile zespół (a nie osoba) rozumie ten framework. Mogą nam również pokazać na ile rozumie ją biznes, z którym jako zespół scrumowy współpracujemy.
Jak zmierzyć iterację, aby uznać ją za sukces? Jak zmierzyć zadowolenie, które jest w zespole developerskim? Jak zmierzyć realizację celu? Podpowiem Wam kilka wskaźników, które mogą pomóc w powyższym.
Na początek zacząłbym od postawienia sobie podstawowych pytań:
- Jaki jest nasz time-to-market?
- Jak dużo czasu zajmuje nam dostarczenie czegoś wartościowego, kiedy zaczynamy nowy projekt?
Pytania te są mocno biznesowe, jednak uważam je za start dyskusji o pracy zespołu oraz produkcie, nad którym pracuje. Odpowiedź na pierwsze z nich pokazuje, jak szybko jesteśmy w stanie jako zespół dostarczyć to, czego oczekiwał klient. Jak efektywnie współpracujemy we wszystkich fazach opracowywania rozwiązania?
Odpowiedź na drugie z nich pokazuje, jak bardzo zespół i Product Owner skupiają się na właściwej dekompozycji wymagań tak, aby już w pierwszym sprincie wyprodukować coś, co jest wartościowe, i dostarczyć klientowi użyteczną funkcjonalność.
Powyższe są podstawowymi pytaniami, od których bym zaczął. A co dalej? Poniżej znajdziecie listę miar, które możecie użyć w swoich zespołach, wszystkie lub tylko poszczególne z nich.
Przewidywalność
Przewidywalność mówi nam, ile zadań możemy jako zespół dostarczyć na określoną datę, lub na kiedy jesteśmy w stanie zrealizować określony zakres. Przewidywalność jest określona jako procent zadań wziętych do sprintu do zadań uznanych jako skończone w danym sprincie (liczba zadań lub ich wycena). Uwaga: miary tej nie można używać samodzielnie zwłaszcza, jeśli liczymy ją wg liczby zadań, ponieważ może prowadzić do mylnych wniosków. Na przykład zespół ma do zrobienia 2 duże zadania – realizuje jedno, ma przewidywalność 50%. W drugim sprincie bierze 2 małe zadania, też robi jedno i ma tę samą przewidywalność, podczas gdy mniej się napracował, miał czas na zadania utrzymaniowe (nie wyceniane), itp.
Korzyści: Świadomość na ile prawdopodobne są aktualne plany, na ile można polegać na przewidywaniach zespołu. A dla zespołu „przewidywalność” (jej zmiana) może być miernikiem jak skuteczne są usprawnienia jakie zespół wprowadza.
Capacity (pol. pojemność zespołu)
Miara mówi nam o ‘pojemności’ zespołu. Pojemność na dany sprint mówi nam, ile z roboczodni zespołu mamy dostępnych w nadchodzącym sprincie.
Korzyści: wiemy dokładnie, ile możemy zaplanować, ponieważ staraliśmy się przewidzieć wszelkie nieobecności w zespole.
Velocity (pol. prędkość zespołu)
Pokazuje sumę wyceny zadań skończonych w danych sprincie dla danego zespołu.
Korzyści: zespół zna swoją prędkość, wie czy jest ona stabilna, jakie ma procent przewidywalności (zadania zrobione do wszystkich zadań w danym sprincie). Product Owner może ją przekazać interesariuszom, wykorzystać ją do planowania backlogu, tzn w której iteracji dana funkcjonalność powinna zostać zrobiona, kiedy możemy zrobić kolejne wdrożenie.
Yesterday’s Weather (pol. ‘wczorajsza pogoda’)
To, ile weźmiemy zadań na sprint, zależy co najmniej od dwóch wskaźników – prędkości i pojemności.
Ostatnia prędkość (velocity) oraz przewidywanej dostępności (capacity) zespołu da nam informację, ile np. story pointów możemy jako zespół wziąć na kolejny sprint.
Nazwa kalkulacji pochodzi, cytując Scrum inc., od wczorajszej pogody – najlepiej przewidzimy dzisiejszą pogodę bazując na pogodzie wczorajszej.
Korzyści – pomaga zespołowi szybko skalkulować, ile mogą wziąć elementów backloga na dany sprint. Celowo piszę “ile mogą wziąć”, ponieważ różne zespoły w różny sposób kalkulują swoją prędkość (używają różnych miar).
Retrospective Process Improvement (pol. usprawnienia procesu w trakcie retrospektyw)
Metryka pokazuje zdolność zespołu do usprawnienia procesów, w których się poruszają. Mam tu zwłaszcza na myśli: proces zgłaszania i rozwiązywania incydentów, znajdowania nowych potrzeb biznesowych oraz ich odpowiedniego przygotowania do wytworzenia (napisania kawałka kodu), organizacji pracy zespołu, naprawy błędów znalezionych w czasie testów funkcjonalnych czy też bezpieczeństwa, poprawy uwag zgłoszonych na etapie code review, itp.
Miara pokazuje sumę zidentyfikowanych na retrospekcjach problemów, ile z nich zostało zaadresowanych oraz ile rozwiązanych.
Korzyści: miara pokazuje zdolność zespołu do usprawnienia procesów.
Defects per release cycle (pol. błędy per wdrożenie)
Pokazuje liczbę zidentyfikowanych błędów per wdrożenie (release cycle) w podziale np na błędy pochodzące incydentów bezpieczeństwa, problemów na produkcji, itp.
Korzyści – metryka pokazuje jakość zadań realizowanych przez zespół.
Technical debt (pol. dług techniczny)
Dług techniczny bardzo często pojawia się we wszelkich publikacjach nt. czystego kodu (ang. clean code).
Niektóre organizacje podejmują próbę mierzenia długu technicznego na poziomie Sonara. Zespoły obserwują wyniki, cieszą sie kiedy dług spada, wymyślają i realizują strategię jego eliminacji.
Zdarza się, że część organizacji bardziej biznesowa nie zawsze do końca rozumie czym jest dług techniczny. Wydaje się, że kluczowa tutaj jest rozmowa z nimi językiem zrozumiałym. To znaczy, że jeżeli jako organizacja używamy np. Sonara (którego wdrożenie kosztowało nas wiele wysiłku organizacyjnego i finansowego), obserwujemy wyniki, obserwujemy kod i widzimy, jak wiele pracy musimy poświęcać na implementacje rozwiązań biznesowych przez stare, często już nieużywane funkcjonalności (również techniczne), powinniśmy biznesowi zwrócić na to uwagę. Powiedzieć, że np połowa czasu zespołu to zmaganie się ze starym kodem aplikacji, że gdyby podjąć odpowiednie decyzje, to np praca byłaby dwa razy szybsza.
Korzyści: Mniej długu technicznego to bardziej przyjemna praca i to zarówno po stronie zespołu, ale też przede wszystkim po stronie biznesu. To szybsze wdrażanie nowych funkcjonalności, mniej problemów dyskutowanych na retro, itp.
Team Enthusiasm (pol. zadowolenie/ entuzjazm zespołu)
Team enthusiasm lub inaczej happiness metrics. Miara pokazująca, jak bardzo nasi pracownicy są zadowoleni z organizacji, w której pracują.
Korzyści: SM, PO, zespół, organizacja wie, jakie jest aktualne zadowolenie pracowników. Z organizacji, produktów, pracy, zespołu. Na tej podstawie można w firmach zmieniać rzeczy na wielu różnych poziomach – od zmiany procesu on-boardingu poprzez instalację nowego dodatkowego środowiska testowego aż do wstawienia kanapy do pokoju zespołu.
Customer Satisfaction (pol. zadowolenie klienta)
Jak szczęśliwi / zadowoleni są nasi klienci? Aby zmierzyć satysfakcje można użyć np. NPS. Jest to prosta metoda, której użycie pomogą odpowiedzieć nam na to pytanie.
Korzyści: celem jest “złapanie” szybko informacji zwrotnej od klientów, jak bardzo są zadowoleni i odpowiednie zaadresowanie pojawiających się kwestii.
Interruptions (pol. przerywniki / przeszkadzacze)
Ile razy w ciągu sprintu zespół musiał zajmować się innymi kwestiami niż te zaplanowane w sprint backlogu? Ile razy zdarzyła się sytuacja, że ktoś przyszedł do zespołu i poprosił, aby coś zrobić, argumentując, że “przecież to zajmie tylko chwilę”?
Korzyści: kształtowanie świadomości zespołu, że takie sytuacje występują, jak często, że są one niepoprawne i jaki mamy współczynnik przerywania (np. zadania w sprincie / liczba przerwań).
Warto się także tutaj zastanowić nad mierzeniem czasu poświęconego na przerywniki w czasie jednej iteracji/ tygodnia/ miesiąca/ projektu.
Fixing work to feature work (pol. liczba błędów do liczby prac rozwojowych)
Wskaźnik pokazuje proporcje zaangażowania w rozwiązywanie błędów do rozwoju produktu / oprogramowania. Najprostszym sposobem pokazania wskaźnika jest wyliczenie procentowego udziału zadań związanych z błędami (lub szerzej z maintenancem), do liczby zadań rozwojowych.
Korzyści: uświadamia zespół i interesariuszy, ile zespół poświęca swojego czasu na rozwiązywanie problemów. Może również być miarą długu technicznego.
Cross team dependencies (pol. uzależnienia od innych zespołów)
Liczba rzeczy, które wymagają zaangażowania innego zespołu. Najprostszym przykładem może być postawienie dodatkowego środowiska testowego, co jest realizowane przez zespół infrastruktury na rzecz zespołu deweloperskiego. Wszystkie takie rzeczy spowalniają zespół deweloperski, często nie udaje się przez nie skończyć z powodzeniem sprintu.
Korzyści: miara pokazuje, ile czasu zespół stracił, czekając na rzeczy robione przez inne zespoły. Ale pokazuje również słabość zespołu, bo przecież jeżeli jest uzależniony od innych, to nie jest samowystarczalny. A powinien taki być ponieważ tylko samowystarczalny zespół może w pełni realizować zadania, od początku do końca, od wizji Product Ownera aż po jej wdrożenie na produkcję. I ponosić za nie pełną odpowiedzialność.
Pamiętajcie też o tym, co powiedział twórca Teorii ograniczeń – Eliyahu Goldratt– “Tell me how you measure me, and I will tell you how I will behave”. Innymi słowy, zawsze po jakimś czasie metryki, a przynajmniej większość z nich, pokazują dobre sytuacje oraz zachowania. Ale często jest to wynik samego mierzenia i dostosowywania się do tego procesu otoczenia, niż faktycznej poprawy.
Metryki możemy zmieniać. Jeżeli widzimy, że osiągamy bardzo dobre wyniki lub nasze wskaźniki są bezużyteczne (nikt z nich nie korzysta/ nie patrzy na nie, nie prowadzą do pogłębionych dyskusji, zespół nie usprawnia na ich podstawie swojego procesu), zmieńmy je. Wyczytałem gdzieś, że powinniśmy to robić co 3 miesiące, jednak bardziej się skłaniam ku twierdzeniu, że trzeba je zmieniać wtedy, kiedy uznamy to za stosowne
Posłuchaj nagrania podcastu Porządny Agile – Jak sensownie wykorzystać Velocity
PS. Zamiast wskaźnika time to market spotkałem się również z podejściem time to feedback. Co myślicie o tej propozycji?
PS 2. Mierzenie i pokazywanie metryk nigdy nie zastąpi obserwacji i słuchania zespołu.