Scrum i metryki – co może się przydać zespołom zwinnym?

Liczby, miary, metryki, statystyki, wyniki. Czy takie elementy mogą pasować do Zespołów Scrumowych? Przecież to takie nieludzkie 😎 Mogą i często pomagają znaleźć obszary do usprawnień, których nie dostrzegamy lub nie rozumiemy bez liczbowo-wizualnego opisu.

Poniżej znajdziesz kilka przykładowych elementów, które mogą pomóc zespołom zgodnie z myślą “mierz, wizualizuj i poprawiaj”. Pamiętajmy jednak, że:

• najlepiej, gdy dana metryka jest używana przez sam zespół, z jego inicjatywy, a nie jest narzucona odgórnie;
• gdy jednak dana metryka jest ustalona poza zespołem, to trzeba zadbać o to, aby zespół ją zrozumiał, starał się używać jak swoją (z przekonania);
• takie metryki pokazują pewien wycinek rzeczywistości i nigdy nie mogą być wykorzystywane jako narzędzie do ostatecznej oceny, szczególnie ludzi.

Uff. Dość tego wstępu. Sprawdźmy czy Scrum i metryki mogą do siebie pasować. Lecimy 🛫

 

Wykres spalania

Pokazuje ile roboty jeszcze zostało do skończenia w Sprincie. Wyznaczamy linię idealną (jak praca byłaby spalana, gdyby wszystko szło perfekcyjnie) i prowadzimy drugą linię, przez cały sprint oznaczamy, to co wykonane (nasza linia idzie w dół) i ewentualne zmiany w zakresie (np. dodanie nowego – linia do góry). Poniżej przykład, który dodatkowo opisałem, niczym Jacek Gmoch 🤩

 

Zaplanowanie vs. rzeczywiście zrobione

Prosta metryka, która mówi nam ile bierzemy do Sprintu, a ile ostatecznie realizujemy. Może być to wyrażone w Story Pointach, w liczbie historyjek czy innej jednostce, z której korzystacie.

Zbyt mało zaplanowane – będzie trzeba dobierać w trakcie sprintu. Zbyt dużo – będą “spady”. Płynne flow, stały rytm, w którym nic (albo jak najmniej 😊) nam nie zostaje na następne Sprinty, ani nie zakłóca bieżącej pracy, to zdrowa sytuacja. Im bardziej się od niej oddalasz, tym większa szansa na to, że nie pracujesz tak płynnie jak możesz. Dobre planowanie jest kluczowe.

 

Wdrożenia – zagęszczenie, liczba

Zgodzisz się z tym, że dobry zespół wdraża często i małe zmiany? Dobrze jest zatem badać liczbę wdrożeń produkcyjnych w czasie, zwrócić uwagę na ich zagęszczenie i być może rozmiar. W takim obrazku można zobaczyć m.in. flow – czy jest płynne, czy są przerwy itd.

Można też zaobserwować czy dany zespół np. omija piątki (“bo weekend, a możę się popsuć”) lub nie robi specjalnie wdrożeń po południu (“bo do domu chcę…”). Od takiej obserwacji fajnie wyjść do dalszych pytań – czemu tak jest? Może są łatwe rozwiązania, które pozwolą bezpieczniej robić te wdrożenia bez zwlekania?

 

Jak szybko dostarczasz?

W jakim czasie, to co chcesz klientowi dać, rzeczywiście do niego dociera? Można to rozpatrywać na poziomie całego projektu (jak szybko udało nam się zbudować nowy serwis) albo pojedynczych funkcjonalności (jak szybko dodaliśmy kolejną opcję płatności w sklepiku online).

Zasadniczo są dwa podejścia:

• mierzenie zupełnie całego procesu (od pomysłu “zapisanego” do realizacji lub zamówienia od klienta), czyli także ewentualna analiza, prototytpy itd.
• mierzenie fragmentu procesu – tylko od momentu rozpoczęcia pracy przez programistę.

To co lubię szczególnie w tego typu metrykach, to fakt, że kładą nacisk na klienta. Jeśli mierzymy czas dostarczania, to siłą rzeczy skupiamy się na tym, aby klient był w centrum naszego wysiłku, bo to do niego dostarczamy.

Jeśli interesują Cię tego typu metryki, a to wyżej to za mało, to poszukaj treści na temat: lead time, cycle time, time to market. Powinno się coś znaleźć 🤓

 

Czas trwania w danym etapie

Scrum przyjaźni się z leanowo-kanbanowym podejściem, więc niektóre zespoły wpadają na pomysł, aby mierzyć czasy poszczególnych etapów procesu – tak jak np. w przemyśle samochodowym. Ile czasu montowane są koła – ile czasu pisany jest kod? OK, nietrafione porównanie, ale łapiesz o co chodzi 🤣

Tak samo można mierzyć kolejne punkty podróży kodu – inspekcja, testowanie, wdrażanie. Gdy wiemy, że dany etap trwa długo możemy zacząć zastanawiać się nad optymalizacją. Jeśli Twoje wdrożenie trwa 1,5h, może jest szansa na jego przyspieszenie? Tym bardziej, że chcesz wdrażać małe zmiany i często, prawda? 🤓

Na przykład:

• Przegląd kodu trwa bardzo długo :(
• Co można zrobić, aby był szybszy?
• Dostarczać mniejsze pull requesty.
• Jak to zrobić?
• Rozwijać serwis mniejszymi częściami, pisać mniejsze historyjki.
• OK, do roboty!

 

Cele Sprintu – trafione czy nie?

Gdybym był zmuszony wybrać tylko jedną rzecz, do obserwowania z zespołem, to byłby to Cel Sprintu – czy udało się go zrealizować czy nie? Nie wyczytamy od razu wielu szczegółów, poza wynikiem: 0 czy 1, zrealizowane czy nie? Taka “metryka”, szczególnie w perspektywie historycznej (np. 5 Sprintów wstecz), może nam jednak pomóc rozpocząć dyskusje, na temat poziomu zgrania teamu, zarządzania priorytetami w Sprincie, skupienia na celach i innych aspektach. W prostym wyniku kryć się może wiele niespodziewajek 🤗

 

Liczba defektów w czasie

Bugi zjadają energię. Im więcej bugów, które musicie naprawić, im trudniej je zabić, tym mniej czasu na tworzenie nowej wartości dla klientów. Proste, prawda?

Im więcej bugów, tym więcej energii na zarządzanie nimi – zastanawianie się na temat priorytetu, opisywanie, rozmowy itd.

Jeśli jesteś podobnego zdania to co powiesz na badanie liczby tworzonych i zabijanych bugów?

Oczywiście defekt nie równy defektowi – raz okaże się, że tylko 0,5% użytkowników widzi dany błąd, który w dodatku nie blokuje konwersji czy podstawowych funkcji serwisu. Innym razem okaże się, że masz na produkcji coś, co totalnie uniemożliwia korzystanie z Twojej apki. Tu pomagają priorytety, które możesz też uwzględnić – np. ile bugów krytycznych wykryliśmy w ostatnim miesiącu i ile ubiliśmy? Rośnie? Spada? Jest tego dużo?

 

Cumulative flow diagram

Ten diagram pokazuje nam, na jednym widoku, wybrane zadania (np. w projekcie) z zaznaczonymi, za pomocą koloru, statusami. Powie nam ile pracy zostało, ile jest rozgrzebane, ile zrobiliśmy i kiedy się skończy dany zakres. Proste?

Kryje się w nim jeszcze więcej: czas między rozpoczęciem i kończeniem pracy, wąskie gardła, płynność dewelopmentu, zmiany zakresu i wiele innych.

Szczegółowo rozpisał to Paweł Brodziński – jego dobry art. przeczytasz tutaj.

 

Scrum i metryki – słowo na koniec

Ta tematyka jest jak studnia bez dna 😲 Podałem Ci tylko wybrane przykłady, które widziałem w praktyce i pomagały usprawniać pracę zespołów. Takich znaleźć możesz jeszcze wiele. Musisz wiedzieć czego potrzebujesz i nie dać się zwariować – to tylko pewne wskaźniki, które mogą pomóc, ale też potrafią wiele popsuć, gdy źle wykorzystywane.

Przykładowo – zespół chce robić więcej wdrożeń i robić je na możliwie małe? Porozmawiajcie o wizualizacji stanu obecnego i monitorowaniu postępów.

Klienci narzekają na jakość Twoich usług i wiesz, że może chodzić o błędy w Twoim serwisie? Mierz defekty i zobacz z czym masz do czynienia.

Przy okazji, mierzenie tego typu rzeczy polecałbym zespołom już raczej zaznajomionym ze zwinnym podejściem, np. ze Scrumem. Na początek ważniejsze będzie to, aby pracować w regularnych cyklach, mieć cele i przejrzysty backlog, zadbać o pętlę informacji zwrotnej (feedback loop) itd. W kolejnych krokach można dołożyć mierzenie elementów procesów, które pozwoli doszlifować pracę.

Zapraszam Cię do komentowania i podawania przykładów metryk/miar/statystyk, które Ty znasz ze swojego życia.

---

Dodatkowa lektura

• http://agilebrains.pl/scrum/metryki-w-scrum-jak-mierzyc-efektywnosc-wdrozenia-scruma/
• http://brodzinski.com/2013/07/cumulative-flow-diagram.html

---

Do ilustracji posta użyto zdjęć / grafik (częściowo zmodyfikowanych) z: Rawpixel