Jakie statystyki i metryki powinien 艣ledzi膰 Scrum Master?

Po co Scrum Masterowi statystyki i metryki? Przede wszystkim po to, aby sprawdza膰, czy jego metody pracy nad przewidywalno艣ci膮 rezultat贸w i popraw膮 efektywno艣ci zespo艂u s膮 skuteczne. Lecz tak偶e po to, aby na bie偶膮co 艣ledzi膰, jak jego dzia艂ania wp艂ywaj膮 na Zesp贸艂 Developerski. Czyli jak kszta艂tuj膮 do艣wiadczenie u偶ytkownika pracownika (employees user experience, EX). Jakie zatem statystyki i metryki powinien 艣ledzi膰 Scrum Master?

Jakie statystyki i metryki powinien 艣ledzi膰 Scrum Master – om贸wione zagadnienia:

Mierzenie rezultat贸w pracy Zespo艂u Developerskiego
Monitorowanie employees user experience Developer贸w
Podumowanie

Mierzenie rezultat贸w pracy Zespo艂u Developerskiego

Najcz臋艣ciej u偶ywanymi wykresami, jakie powinien obserwowa膰 Scrum Master, s膮 te opisuj膮ce tempo i przep艂yw wykonywania zada艅. S膮 to wykres spalania, Burnup Chart, oraz Cumulative Flow Chart. S艂u偶膮 one do mierzenia zar贸wno rozwoju produktu, jak i efektywno艣ci zespo艂u. Ka偶dy z nich pozwala podej艣膰 do tych zagadnie艅 nieco inaczej, dlatego warto u偶ywa膰 ich 艂膮cznie. Mog膮 one s艂u偶y膰 do oceny post臋p贸w w r贸偶nej skali. Zar贸wno tych dokonanych podczas Sprintu, jak i ca艂ego procesu powstawania produktu.

Burndown Chart

Wykres spalania, pokazuje Scrum Masterowi i Zespo艂owi Developerskiemu, ile pracy wykonano, a ile zosta艂o jeszcze do wykonania. Na osi X przedstawiony jest czas jaki pozosta艂 na wykonanie pracy. Natomiast na o艣 Y nanoszona jest ilo艣膰 pracy pozosta艂ej do wykonania, kt贸ra zosta艂a zaplanowana w Backlogu Sprintu lub Backlogu Produktu.

Burndown chart pozwala okre艣li膰 Pr臋dko艣膰 Zespo艂u Developerskiego, kt贸rej r贸wnie偶 po艣wi臋cimy osobny artyku艂. Tutaj wspomnimy tylko, 偶e jest to u艣redniona ilo艣膰 pracy wykonywanej w czasie jednego Sprintu.

To proste narz臋dzie pozwala Scrum Masterowi nie tylko przekona膰 si臋, jak wydajnie pracuje zesp贸艂. Pomaga te偶 odpowiedzie膰 na pytania:

Jaka cz臋艣膰 pracy zosta艂a ju偶 uko艅czona?
Jak wiele zada艅 zosta艂o do wykonania?
Jak d艂ugo b臋dzie trwa艂a praca nad Produktem?

Scrum Master korzystaj膮c z Wykresu Spalania musi pami臋ta膰 o tym, 偶e nie jest to jedyne narz臋dzie pozwalaj膮ce na ocen臋 post臋p贸w pracy zespo艂u przez statystyki. Sprawdza si臋 on najlepiej w przypadku projekt贸w, w kt贸rych zakres prac jest sta艂y i znany. Gorzej sprawdzi si臋 w przypadku tworzenia bardzo innowacyjnych rozwi膮za艅 z nowym Klientem. Wtedy ilo艣膰 pracy do wykonania w ca艂ym projekcie – czyli tre艣膰 Backlogu Produktu – mo偶e znacz膮co zmienia膰 si臋 w trakcie realizacji utrudniaj膮c korzystanie z Burndown Chart.

Burnup chart

Mo偶na powiedzie膰, 偶e Burnup Chart jest odwr贸ceniem om贸wionego powy偶ej wykresu spalania (Burndown chart). Tutaj r贸wnie偶 na na osi Y zaznaczona jest ilo艣膰 pracy pozosta艂ej do wykonania. Natomiast o艣 X pokazuje czas realizacji wyra偶ony w ilo艣ci Sprint贸w albo w datach.

Scrum Master wykorzystuje jednak Burnup Chart w nieco innym celu. Pozwala on bowiem nie tylko oceni膰 post臋p prac nad produktem i post臋py Zespo艂u. Metryka ta s艂u偶y tak偶e ocenie tego, jak z up艂ywem czasu zmienia si臋 zakres prac w projekcie. Dlatego sprawdza si臋 dobrze w projektach o zmiennym zakresie.

Burnup Chart jest tak偶e narz臋dziem planowania, kt贸re staje si臋 z czasem coraz skuteczniejsze. Pozwala odpowiedzie膰 na pytanie, ile pracy szacunkowo wykona Zesp贸艂 Developerski w nast臋pnym Sprincie.

Cumulative Flow Diagram

Trzeci rodzaj wykresu bardzo przydatnego w pracy Scrum Mastera z Zespo艂em Developerskim to Cumulative Flow Diagram. Pozwala on oceni膰, jak stabilne jest tempo i wydajno艣膰 pracy Zespo艂u Developerskiego. Uk艂ad jego osi jest taki samo jak w Burnup Chart, dlatego cz臋sto okre艣lany jest jako jego bardziej z艂o偶ona wersja.

Cumulative Flow Diagram s艂u偶y jednak nie tylko do okre艣lania ilo艣ci zada艅 wykonanych w danym okresie czasu. Uwzgl臋dnia tak偶e ilo艣膰 zada艅, kt贸re oczekuj膮 w kolejce na wykonanie. Dzi臋ki temu pozwala na diagnoz臋 tzw. „w膮skich garde艂” (bottlenecks), czyli moment贸w procesu, kt贸re spowalniaj膮 powstawanie produktu.

Ta w艂a艣nie funkcja diagnostyczna czyni go jedn膮 z najbardziej przydatnych metryk w r臋kach Scrum Mastera. Pozwala bowiem przeorganizowa膰 prac臋 w taki spos贸b, aby inaczej roz艂o偶y膰 si艂y Zespo艂u Developerskiego i unikn膮膰 przestoj贸w.

Statistics and metrics the Scrum Master should track

Monitorowanie employees user experience Developer贸w

Regularne i skrupulatne prowadzenie oraz analiza statystyki jest bardzo wa偶n膮 cz臋艣ci膮 pracy skutecznego Scrum Mastera. Musi on jednak pami臋ta膰 przede wszystkim o employees user experience Developer贸w, czyli sposobie w jaki odbieraj膮 oni prac臋 w Scrum Team. O tym decyduje jednak nie jako艣膰 metryk, lecz spos贸b, w jaki Scrum Master z nich korzysta.

Je艣li statystyki s膮 prowadzone zgodnie z zasadami Scruma – s膮 przejrzyste, jawne i zrozumia艂e dla zainteresowanych Developer贸w – mog膮 by膰 sposobem na motywowanie zespo艂u do bardziej wydajnej pracy lub nagradzania go za 艣wietne rezultaty. Statystyki mog膮 by膰 jednak u偶ywane jako narz臋dzie s艂u偶膮ce do wywierania presji na Zesp贸艂 Developerski. Wtedy ich wskazania staj膮 si臋 generatorem oskar偶e艅 i pretensji. Mog膮 przyczynia膰 si臋 do pogarszania morali zespo艂u i psucia praktyki pracy zespo艂owej.

Drugim wa偶nym czynnikiem employees user experience Developer贸w, o jaki musi zadba膰 Scrum Master pracuj膮cy z narz臋dziami do analizy statystyki, jest spos贸b wykorzystania jego w艂asnego czasu. Scrum Master musi mie膰 bowiem wystarczaj膮c膮 ilo艣膰 czasu, 偶eby zaj膮膰 si臋 Zespo艂em Developerskim. Z tego powodu w przypadku du偶ego projektu, warto rozwa偶y膰 w艂膮czenie do Scrum Team dodatkowej osoby. B臋dzie ona pe艂ni艂a rol臋 menad偶era projektu i zajmowa艂a si臋 prowadzeniem metryk. Dzi臋ki temu odci膮偶y Scrum Mastera – a tak偶e do pewnego stopnia Product Ownera – z wykonywania zada艅 kt贸re odci膮gaj膮 go od pracy z Zespo艂em Developerskim.

Podsumowanie

Scrum Master powinien 艣ledzi膰 podstawowe statystyki opisuj膮ce prac臋 Zespo艂u Developerskiego. Ich umiej臋tna interpretacja zwi臋ksza szans臋 na szybkie zauwa偶anie problem贸w pojawiaj膮cych si臋 w pracy Zespo艂u i reagowanie na nie. Jednak wa偶niejsze ni偶 prowadzenie wykres贸w jest to, co robi z nimi Scrum Master. Nie powinien bowiem traktowa膰 metryk jako narz臋dzi s艂u偶膮cych do oceny Zespo艂u, a raczej traktowa膰 je jako przydatn膮 pomoc w motywowaniu Zespo艂u i diagnozowaniu w艂asnego sposobu dzia艂ania. Metryki b臋d膮 bowiem przydatnymi narz臋dziami jedynie wtedy, gdy pozwol膮 na doskonalenie pracy Zespo艂u i proces贸w doskonalenia Produktu.

Przeczytaj r贸wnie偶: Wsp贸艂praca Scrum Mastera z Product Ownerem

Je艣li podobaj膮 Ci si臋 tre艣ci, kt贸re tworzymy, sprawd藕 r贸wnie偶:

Autor: Karolina Berecka
Karolina, jako project menad偶erka jest ekspertem w poszukiwaniu nowych metod projektowania najlepszego systemu przep艂ywu pracy i optymalizacji proces贸w. Jej umiej臋tno艣ci organizacyjne i zdolno艣膰 do pracy pod presj膮 czasu sprawiaj膮, 偶e jest najlepsz膮 osob膮 do zamieniania skomplikowanych projekt贸w w rzeczywisto艣膰.

Zobacz wszystkie posty

凯发k8旗舰厅

Przerwa konserwacyjna

Scrum Guide | 11. Jakie statystyki i metryki powinien 艣ledzi膰 Scrum Master?

Jakie statystyki i metryki powinien 艣ledzi膰 Scrum Master – om贸wione zagadnienia: