Właściwy sposób definiowania metryk zwinnych

Metryki zwinne stanowią zbiór mierników, które pozwalają monitorować postępy i osiągnięcia zespołów projektowych pracujących w metodyce Agile.

Właściwie zdefiniowane wskaźniki dostarczają cennych informacji na temat efektywności zespołu, jakości wytwarzanego oprogramowania, skuteczności testów oraz ogólnej produktywności i jej ewolucji w czasie.

Nadrzędnym celem stosowania metryk zwinnych jest wspieranie zespołów w identyfikacji obszarów wymagających doskonalenia oraz umożliwienie podejmowania decyzji opartych na faktach, które prowadzą do tworzenia lepszych produktów w miarę rozwoju zespołu.

Niestety, w wielu firmach wskaźniki sprowadzają się do mierzenia powierzchownych danych, które ładnie wyglądają na wykresach, ale nie wnoszą realnej wartości dla zespołu. Zwykle są to dane, których celem jest jedynie zaspokojenie potrzeb raportowania dla kierownictwa i podejmowania decyzji strategicznych.

W efekcie, zespoły nie rozumieją celu istnienia takich wskaźników. Zaczynają więc manipulować własnymi procesami, aby prezentować wyniki, które dobrze wyglądają na wykresach, zamiast skupiać się na rzeczywistej poprawie jakości swojej pracy.

Paradoksalnie, takie działania nie prowadzą do poprawy wyników zespołu, a jedynie do zniekształcenia obrazu rzeczywistości.

Podział metryk

Istnieje wiele podejść do klasyfikacji metryk. Najbardziej fundamentalny podział to podejście „odgórne” i „oddolne”.

➡️ Podejście odgórne: W tym podejściu to liderzy definiują wskaźniki, które zespół ma osiągnąć, a głównym celem staje się dopasowanie się do wyznaczonych założeń. Zespół nie ma wpływu na wybór tych wskaźników, ani nie ma znaczenia jego opinia na ich temat.

➡️ Podejście oddolne: W tym podejściu to sam zespół identyfikuje obszary wymagające poprawy i definiuje wskaźniki, które pozwalają śledzić postępy w realizacji założonych celów. W ten sposób, zespół może udokumentować, jak jego działania wpłynęły na usprawnienie pracy.

Kryteria dobrej metryki

Jakie cechy powinna posiadać dobra metryka? Jak ją zdefiniować?

Najważniejszą cechą dobrej metryki jest to, że powinna ona skłaniać do zmiany zachowań. Oznacza to, że patrząc na wynik metryki, powinno być jasne, jakie zmiany musi wprowadzić zespół, aby osiągnąć poprawę.

Ponadto, metryka powinna być prosta. Jeśli nie da się jej wytłumaczyć w kilku prostych zdaniach, tak aby wszyscy zainteresowani mogli ją zrozumieć, to znaczy, że coś jest nie tak.

Kolejnym aspektem jest porównywalność w czasie. Wyniki metryki powinny być mierzalne w różnych momentach czasowych, tak, aby można było je ze sobą porównać. Jeśli nie można porównać ze sobą wyników z różnych okresów, należy przemyśleć daną metrykę.

Warto również, aby metryka była przedstawiona jako wskaźnik lub procent, a nie jako surowa liczba. Na przykład, informacja o 10 nowych defektach w sprincie nie jest zbyt użyteczna, jeśli nie znamy kontekstu, tj. czy normalnie mamy jeden, czy 100 defektów.

Poniżej przedstawiono przykłady metryk, które spełniają powyższe kryteria. Są one szczególnie przydatne dla zespołów pracujących w metodyce Agile i zostały podzielone na trzy kategorie: wydajność, jakość i morale.

Kategorie metryk

Wskaźniki wydajności

Te wskaźniki pozwalają zrozumieć, jak skuteczny jest zespół w realizacji zadań zaplanowanych na dany sprint. Pomagają ocenić, czy zespół nie podejmuje się zbyt wielu zadań, oraz czy przenoszenie zadań między sprintami nie stało się standardem.

Zgodnie z filozofią Agile, zespół powinien dążyć do dostarczenia zaplanowanej ilości pracy, którą zadeklarował na początku sprintu.

Nie oznacza to, że zespół nie powinien być elastyczny. Jednak zmiany w zakresie sprintu powinny być wynikiem negocjacji, a nie dodawania nowych zadań bez usuwania innych. Zdolności zespołu do realizacji zadań nie wzrosną tylko dlatego, że dodano nowe historie w trakcie sprintu.

Wprowadzenie tych metryk ma na celu zwrócenie uwagi na sytuacje, w których zakres sprintu jest zmieniany w sposób niekontrolowany i pomaga zespołowi chronić jego zdolność do dostarczania wartości.

Poprawia to niezawodność i przewidywalność zespołu.

#1. Wydajność sprintu vs. dostarczone punkty historii

Monitoruj relację pomiędzy planowaną pojemnością sprintu, a liczbą dostarczonych punktów historii (Story Points – SP) w kolejnych sprintach.

• Niewielkie odchylenia pomiędzy sprintami są naturalne, jednak duże skoki w dowolnym kierunku mogą sygnalizować potencjalne problemy.
• Całkowita pojemność sprintu – dostępność każdego członka zespołu w ciągu dnia pracy przekłada się na pojemność. Na przykład, jeśli zespół liczy 10 osób, a wszyscy są dostępni przez cały sprint, to całkowita pojemność sprintu wynosi 100.

Porównuj zaplanowaną pojemność sprintu z liczbą ukończonych SP. Jeśli zespół (podczas planowania) zadeklaruje znacznie większą liczbę SP, niż zazwyczaj jest w stanie dostarczyć, może to sygnalizować potencjalne ryzyko.

Celem powinno być osiągnięcie sytuacji, w której całkowita planowana liczba SP jest równa lub mniejsza od całkowitej liczby ukończonych SP.

Możliwe jest ukończenie większej liczby SP niż planowano, jeśli zespół zrealizuje wszystkie zaplanowane historie, a następnie podejmie się realizacji kolejnych.

• Jeśli zespół regularnie dostarcza mniej SP, niż zaplanował, powinien zweryfikować proces planowania i uwzględnić mniejszą liczbę SP w następnym sprincie.

Narzędzia takie jak monday.com, Atlassian Jira czy Asana umożliwiają rejestrowanie i wyodrębnianie punktów historii dla każdego zadania w sprincie, a nawet mogą automatycznie generować te informacje po każdym planowaniu.

#2. Wykres spalania

Wykres spalania (Burndown Chart) jest metryką, która często jest obecna na pulpitach nawigacyjnych zespołów Scrum. Niestety, zespoły rzadko z niej korzystają, a menedżerowie często wykorzystują ją do oceny, czy prace postępują zgodnie z planem.

Jednakże, jako zespół, warto regularnie analizować wykres spalania. Jeśli wszystkie historie są otwarte przez większość sprintu, a zamknięte dopiero ostatniego dnia, może to prowadzić do niepewności w zespole i obniżyć morale.

• Przeanalizuj tablicę sprintu pod kątem ukończonych zadań.
• Porozmawiaj z zespołem, aby zrozumieć, dlaczego mniejsze zadania pozostają otwarte, mimo że rozpoczęły się na początku sprintu.
• Wspólnie z zespołem wypracuj nawyk zamykania zadań w miarę postępów, a nie pozostawiania ich otwartych aż do końca sprintu.
• Idealny wykres spalania jest raczej stanem teoretycznym. Im bardziej zbliżamy się do tego ideału, tym efektywniej zarządzamy przepływem pracy.

Narzędzia do zarządzania projektami, takie jak Asana, automatycznie generują wykres spalania dla każdego sprintu.

źródło: asana.com

#3. Realizacja celu sprintu

Monitoruj procent zrealizowanych Celów Sprintu w każdym sprincie.

Cele sprintu powinny być dokumentowane osobno, np. na stronie Confluence lub Jira. Należy określić, czy zostały one osiągnięte w danym sprincie.

Nawet jeśli zespół nie ukończy wszystkich historii w sprincie, może nadal osiągnąć Cel Sprintu (np. jeśli brakuje tylko zadań o mniejszym znaczeniu).

Powinniśmy dążyć do 100% realizacji Celów Sprintu w każdym sprincie. Jeśli cel nie został osiągnięty, należy zrozumieć przyczynę tego stanu rzeczy.

• Jeśli w każdym sprincie występuje zbyt wiele równoległych tematów, należy zmniejszyć ich liczbę.
• Jeśli w trakcie sprintu dodawane jest zbyt wiele zadań ad hoc, należy to ograniczyć, aby nie wpływało to negatywnie na pierwotne cele sprintu.
• Jeśli cele sprintu są zbyt ambitne lub trudne do osiągnięcia, należy je uprościć. Nie ma sensu wyznaczać nierealnych celów.

Metryki jakości kodu

Te metryki pozwalają monitorować jakość kodu w czasie. Pomagają one utrzymać zdrowe procesy rozwoju oprogramowania oraz skracają czas potrzebny na rozwiązywanie problemów. Ponadto, redukują czas przestoju programisty, wynikający z oczekiwania na wykonanie kodu podczas działań deweloperskich i testowych.

Źródło: azuredevopslabs.com

#1. Testy automatyczne

Twórz automatyczne testy jednostkowe dla każdej wprowadzonej zmiany w kodzie.

• Mierz pokrycie kodu za pomocą testów automatycznych – użyj Azure Pipelines lub SonarCloud do uruchamiania testów. Dąż do osiągnięcia pokrycia na poziomie 85%. Poziom powyżej 90% nie jest już tak efektywny.
• Upewnij się, że tworzenie testów jednostkowych jest częścią definicji „ukończenia” zadania.
• Uzupełniaj braki w testach starszego kodu w ramach zaległości technicznych.

#2. Złożoność kodu

Monitoruj niepotrzebne komplikacje w kodzie i aktywnie usuwaj je za pomocą zadań technicznych. Staraj się zapobiegać powstawaniu tych problemów.

Zdefiniuj standardy i wytyczne dotyczące pisania kodu. Regularnie aktualizuj wytyczne na podstawie doświadczeń zespołu.

Zidentyfikuj „zapachy kodu” – wskaźniki potencjalnych problemów, takie jak duplikacja kodu, zbyt długie metody i nieużywane zmienne.

Wzajemne przeglądy kodu (code review) zapewniają stosowanie standardów kodowania.

Używaj narzędzi takich jak pulpity nawigacyjne i raporty Azure Ado lub SonarCloud, aby wykrywać problemy z kodem.

#3. Ręczne kroki wdrażania

Monitoruj liczbę ręcznych czynności, które musi wykonać zespół, aby wdrożyć kod w środowiskach testowych i produkcyjnych.

• Celem jest osiągnięcie 0 ręcznych czynności.
• W razie potrzeby utwórz zadania techniczne, aby dostosować potok wdrażania/wydania do automatyzacji. Stopniowo ograniczaj liczbę ręcznych kroków w każdym sprincie.

Metryki morale

Te metryki pozwalają ocenić, jak zespół ocenia swoją pracę i procesy, z którymi ma do czynienia na co dzień.

#1. Realizacja działań z retrospektywy sprintu

Śledź, ile działań z retrospektywy zostało zrealizowanych w następnym sprincie.

• Scrum Master gromadzi wyniki spotkań retrospektywnych, aby śledzić uzgodnione działania.
• Zespół monitoruje postępy w realizacji tych zadań.
• Kierownictwo projektu monitoruje postępy, identyfikuje problemy i modyfikuje środowisko pracy, tak aby umożliwić zespołowi realizację uzgodnionych działań.

Co najmniej 33% lub 1 (w zależności od tego, co jest wyższe) działań z poprzedniego sprintu powinno być przeniesione do kolejnych sprintów.

Jeśli ten wskaźnik jest niższy, należy wprowadzić zmiany, które umożliwią zespołowi wdrażanie uzgodnionych usprawnień.

Narzędzia do zarządzania projektami oferują szablony do tworzenia dokumentacji z działań retrospektywnych. Przykład szablonu z monday.com:

źródło: poniedziałek.com

#2. Praca zespołowa

Promuj pracę w parach (pair programming).

• Twórz pary programistów dla każdego zadania, aby wspólnie pracowali, dzieląc się wiedzą, obserwacjami i sukcesami. Dziel zadania na mniejsze podzadania, które będą przydzielone różnym członkom zespołu.

Monitoruj liczbę przeglądów kodu (code review).

• Zachęcaj członków zespołu do aktywnego przeglądania kodu innych osób.

Metrykę tę można wyodrębnić z tablicy w monday.com/Asana/Jira, analizując podzadania.

Co najmniej 50% historii w sprincie powinno być realizowanych we współpracy z innym członkiem zespołu. Jeśli wskaźnik ten jest niższy, należy przeanalizować przyczyny i podjąć odpowiednie działania.

W przypadku dobrowolnych recenzji kodu, śledź je za pomocą dedykowanych podzadań. Na początek 20% kodu poddawanego recenzji to dobry wynik. Stopniowo zachęcaj zespół do większej współpracy i dąż do osiągnięcia celu 50% kodu recenzowanego w każdym sprincie.

#3. Dług techniczny vs. nowe funkcjonalności

Źródło: atlassian.com

Umożliwienie zespołowi rozwiązywania problemów związanych z długiem technicznym zwiększy satysfakcję zespołu z pracy.

• Z drugiej strony, narastanie problemów związanych z długiem technicznym, bez planu jego stopniowego rozwiązywania, zdemotywuje zespół. W takim przypadku rozwiązanie stanie się bardziej niestabilne i trudne do utrzymania bez znacznych przeróbek.

Zespół najlepiej wie, które elementy rozwiązania nie działają prawidłowo. Zazwyczaj problemy te są niewidoczne dla interesariuszy i użytkowników końcowych. Dlatego ważne jest, aby umożliwić zespołowi pracę nad zadaniami, które pomogą mu uporządkować działania związane z rozwojem oprogramowania.

Celem jest monitorowanie, ile zadań związanych z długiem technicznym jest rozwiązywanych w czasie i czy zaległości w tych zadaniach rosną, czy nie.

Zespół może oznaczać zadania jako „TechDebt” w backlogu i nadać im priorytet, aby mogły być realizowane w kolejnych sprintach.

W zależności od stanu projektu i wielkości zidentyfikowanego długu technicznego, staraj się, aby zaległości w tej kategorii zadań nie rosły o więcej niż 10% z sprintu na sprint.

Ustal priorytety dla zadań związanych z długiem technicznym i uwzględnij je w sprintach. Celem jest, aby zespół mógł poświęcić 10-20% czasu w każdym sprincie na pracę nad tego typu zadaniami.

Podsumowanie

W każdym projekcie konieczne jest korzystanie z metryk, niezależnie od tego, czy są one wymagane przez kierownictwo, czy też są to metryki definiowane przez zespół.

Najlepszym rozwiązaniem jest rozpoczęcie budowania własnej biblioteki metryk, które można gromadzić i wykorzystywać. Im szybciej to zrobimy, tym lepiej. Podczas wyboru metryk należy kierować się zasadą, że wskaźnik powinien przede wszystkim skłaniać do zmiany zachowań.

Na koniec, należy przyjrzeć się procesom, które mogą zakłócać pracę zespołu i negatywnie wpływać na efektywność sprintu.