Mierzenie produktywności zespołów jest z reguły czymś co każda organizacja chce robić, managerowie znając pewne wartości danych mogą na ich podstawie podejmować kroki zmierzające ku usprawnieniu pracy czy procesów. Scrum oferuje nam kilka miar/metryk do obserwacji wydajności zespołu w ujęciu kilku spintów. Zaliczają się do nich:
1) Miara „Dostarczone Wykonane” (Achieved DONE)
Miara ta jest stosunkiem sumy wszystkich story points ze wszystkich user stories jakie Product Owner zaakceptował podczas spotkania Sprint Review do sumy wszystkich story points ze wszystkich user stories jakie Scrum Master potwierdził jako wykonane podczas demo. W przypadku kiedy zespół zrobił wszystko i Product Owner zaakceptował wszystko podczas demo wówczas miara jest równa 1.
Przykład 1Zespół miał do wykonania 80 story points, na demo przygotował wszystkie, podczas demo Product Owner zaakceptował wszystkie, wobec czego stosunek 80/80 daje nam 100%
Przykład 2Zespół miał do wykonania 80 story points, na demo przygotował 60 story points, podczas demo Product Owner zaakceptował wszystkie 60 ale wobec planu stosunek 60/80 daje nam 75%
Ta miara nie koncentruje się na szybkości wykonania ale na samym wykonaniu, chodzi o to aby zespół dążył podczas każdej iteracji do wykonania 100% uzgodnionego zakresu podczas spotkania Sprint Planning. Miara poprzez swoją wartość pokazuje czy współpraca pomiędzy Product Ownerem a zespołem dobrze się układała, czy współdziałali wystarczająco blisko aby nie przeoczyć niczego istotnego oraz czy na bieżąco były rozwiązywane problemy na które zespół mógł napotkać podczas implementacji.

2) Wydajność(Velocity)
Miara ta jest liczona na końcu iteracji i porównywana zazwyczaj z swoimi odpowiednikami z kilku ostatnich sprintów. Jest sumą estymat funkcjonalności dostarczonych podczas iteracji. Miara ma za zadanie weryfikować po skończonej iteracji ilość wykonanych przez zespół story points i ukazywać te liczby w kontekście innych iteracji. Ma pokazywać czy zespół z iteracji na iterację rozkręca się i robi coraz więcej czy wręcz przeciwnie. Jeżeli z miary „Dostarczone Wykonane” wynika, że zespół zawsze dostarcza prace w 100% to kolejnym miejscem na usprawnienie powinna być właśnie wydajność. Typowym zjawiskiem jest fakt, że wydajność zespołu powinna się stabilizować podczas cyklu życia oprogramowania (stabilizacja przychodzi w okresie od 3 do 6 iteracji jeśli zespół nie wprowadza istotnych zmian). Poprawę tego wskaźnika możemy osiągnąć poprzez szkolenia zespołu, usprawnienia procesów lub zastosowanie narzędzi, które skrócą czynności wykonywane wielokrotnie.
3) Jakość (Defects&issues)
Ta metryka to całkowita liczba błędów znalezionych w oprogramowaniu zmienianym przez zespół podczas iteracji. Ta metryka jest ściśle związana z wydajnością(velocity) z tego względu aby zespół nie poprawiał wydajności kosztem utraty jakości oprogramowania. Innym podejściem do tej miary jest zliczanie wyłącznie błędów blokujących i krytycznych oprogramowania. W tym przypadku należy jednak uważać ponieważ pomijając drobniejsze błędy możemy rozmyć widok całościowy i wprowadzić organizację w błąd.
Niezależnie od wszystkiego miary tu przedstawione należy odczytywać i monitorować uważnie, nie podejmując zbyt pochopnych, szybkich kroków w oparciu o nie. Z reguły warto poczekać 3-4 iteracje, spokojnie obserwować i dojrzeć do pewnych decyzji. Jeśli miary nie wyglądają dobrze po kilku iteracjach należy podczas sprint retrospective o tym zakomunikować. W zależności od tego która miara nie działa podjąć odpowiednie kroki.
- jeśli miara Dostarczone Wykonane(Achieved DONE) jest poniżej 100%, zespół musi powziąć kroki aby poprawić komunikację z Product Ownerem, ewentualnie bardziej angażować Product Ownera w swoje prace.
- jeśli miara Wydajność(Velocity) cały czas spada wobec stanów poprzednich iteracji, zespół powinien się zastanowić i znaleźć przyczynę co jest tego powodem. Odpowiedzieć sobie na pytanie czemu ze sprintu na sprint coraz mniej story points jest realizowane, przyczyna wyjaśniona i plan poprawy powinien być wdrożony.
- jeśli miara Jakości(Defects&issues) spada, testerzy znajdują w kodzie coraz więcej bugów, trzeba sprawdzić czy zespół nie zwiększył wydajności kosztem jakości, sprawdzić przyczyny błędów i poszukać wspólnie rozwiązania problemu
Na uwadze trzeba mieć jeszcze jeden fakt, inaczej miary będą zachowywały się dla zespołu który zaczyna swoją przygodę w scrumie a inaczej dla stabilnego zespołu robiącego n-ty release….
0 komentarzy