Metryki zwinne to pomiary używane do śledzenia postępów i sukcesów zwinnego zespołu projektowego.
Wskaźniki, jeśli zostaną zdefiniowane we właściwy sposób, zapewniają wgląd w wydajność zespołu, jakość, wydajność testowania lub ogólną efektywność oraz jej ewolucję w czasie.
Ostatecznym celem metryk zwinnych jest pomoc zespołom w identyfikowaniu obszarów wymagających poprawy i podejmowaniu decyzji opartych na danych, które doprowadzą do lepszych produktów w miarę postępów zespołu.
W większości przypadków firmy definiują wskaźniki, które są albo wskaźnikami próżności, albo surowymi liczbami, ładnie rosnącymi od lewej do prawej. Mogą ładnie wyglądać na niektórych dashboardach, ale zazwyczaj są bezużyteczne dla samego zespołu.
Ich celem nie jest pomoc zespołowi w żaden sposób, ale raczej wypełnienie niektórych raportów dla kierownictwa, a następnie podjęcie strategicznych decyzji. Niestety, to właśnie wtedy zespół nie rozumie, dlaczego taka konkretna decyzja istnieje.
W płocie, aby spełnić takie złe wskaźniki, zespoły następnie fałszują własne procesy, aby wskaźniki wyglądały dobrze. Ale wyniki zespołu wcale się nie poprawiają.
Spis treści:
Podstawowe metryki
Istnieje wiele sposobów segregowania metryk. Być może najbardziej podstawowym jest top-down i bottom-up.
➡️ Odgórne oznacza: My, liderzy, stworzymy dla was wskaźniki, które chcemy, abyście wszyscy spełnili, a waszym ostatecznym celem jest dopasowanie się do tych zielonych obszarów. Nie mamy nic przeciwko temu, czy ty – zespół lubisz ich, czy nie; to jest to, co chcemy śledzić.
➡️ Oddolne oznacza: My – zespół musimy poprawić się w tych obszarach i w tym celu musimy się na nich skupić. Dlatego definiujemy mierniki, które pozwolą nam śledzić postępy zespołu w osiąganiu naszych celów i możemy pokazać Tobie – kierownictwu, jak dokładnie usprawniło to naszą pracę w czasie.
Definicja dobrej metryki
Co zatem powinna zawierać dobra metryka lub jak ją opisać?
Najważniejszą właściwością jest zmiana zachowania. Oznacza to, że za każdym razem, gdy spojrzysz na wynik miernika, jasne jest, co musi się zmienić w zespole, aby uzyskać poprawę.
Wtedy to musi być proste. Jeśli nie możesz tego wyjaśnić kilkoma prostymi zdaniami, tak aby wszyscy zainteresowani słuchacze mogli to zrozumieć, to coś jest nie tak.
Dobra metryka jest porównywalna w czasie. Zrób migawkę wyników w krótkim czasie, a następnie zrób to ponownie później. Umieść je obok siebie. Jeśli nie możesz porównać między sobą tych dwóch wyników, powinieneś przemyśleć tę metrykę.
Wreszcie, lepiej niż czyste liczby, jeśli to możliwe, uczyń to stosunkiem lub procentem. „10 nowych otwartych defektów podczas sprintu” niewiele powie. To zależy, czy zwykle masz jeden, czy 100.
Oto kilka przykładów wskaźników, które moim zdaniem spełniają wszystkie te kryteria definicji. Mają na myśli szczególnie zespoły Agile. Istnieją trzy główne kategorie: wydajność, jakość i morale.
Kategorie metryk
Wskaźniki wydajności
Celem jest zrozumienie, jak dobry jest zespół w doganianiu historii popełnionych w ramach sprintu. Aby ocenić, czy nadmierne zaangażowanie nie jest normalnym biznesem lub czy historie przenoszenia są standardem od sprintu do sprintu.
Z perspektywy zwinnej wydajności zespół powinien dążyć do dostarczenia zaplanowanej treści sprintu, do której zobowiązał się na początku sprintu.
Nie oznacza to, że nie będziemy elastyczni w wymianie historii podczas sprintu. Ale zawsze powinna to być negocjacja prowadząca do wymiany, a nie dodawania. Pojemność zespołu nie wzrośnie tylko dlatego, że ktoś dodał nowe historie w sprincie.
Wprowadzamy tę metrykę, aby zwracać uwagę na takie przypadki i kierować wszystkimi członkami zespołu, aby chronić ich zdolność do sprintu.
To buduje niezawodność i przewidywalność zespołu.
# 1. Wydajność sprintu a dostarczone punkty historii
Oglądaj historię pojemności sprintu w porównaniu z dostarczoną zawartością punktów opowieści (SP) w ciągu sprintów.
- Małe odchylenia od sprintu do sprintu są w porządku. Ogromne skoki w dowolnym kierunku sygnalizują, że coś jest nie tak.
- Całkowita pojemność Sprintu – dostępny dzień jednego członka zespołu dodaje jeden do całkowitej pojemności. Np. jeśli zespół liczy 10 osób i wszyscy będą dostępni w pełnym sprincie, to łączna pojemność sprintu wynosi 100.
Sprawdź wydajność sprintu w porównaniu z ukończonymi SP od sprintu do sprintu. Jeśli zespół (podczas planowania) zobowiązuje się do znacznie większej liczby SP niż zwykle może wykonać, przenieś to ryzyko na zespół.
Celem powinno być uzyskanie całkowitej planowanej SP równej lub mniejszej niż całkowita ukończona SP na sprint.
Nadal możesz mieć więcej ukończonych SP niż planowano, jeśli zespół ukończył (pod koniec sprintu) wszystkie zaplanowane historie, a zespół nadal jest w stanie zająć się dodatkową historią.
- Jeśli zespół wielokrotnie dostarcza mniej SP niż planowano, zespół musi zmienić swoje planowanie i wziąć mniej SP w następnym sprincie.
Narzędzia takie jak monday.com, Atlassian Jira czy Asana zapewniają prosty sposób zapisywania i wyodrębniania punktów historii dla każdej historii w sprintach. Mogą nawet wygenerować to dla Ciebie automatycznie po każdym planowaniu sprintu.
#2. Wykres spalania
Jest to jedna z metryk, które prawdopodobnie większość zespołów scrumowych ma gdzieś ukrytą na pulpicie nawigacyjnym. Zgadzam się, że może to nawet wyglądać na bezużyteczną rzecz. Zespół rzadko bierze to pod uwagę. Menedżer lubi raczej wskazywać, jak historie wyglądają z wysokiego poziomu i jak nie rozwijają się dobrze (ponieważ wszystkie są otwarte przez cały sprint).
Chciałbym podkreślić, że pomimo tego, jako zespół powinniście pójść i sprawdzić wykres wypalenia dla własnego dobra. Jeśli wszystkie historie są otwarte przez cały sprint i zamknięte dopiero ostatniego dnia sprintu, tworzy to niepewność wewnątrz zespołu i w kierunku realizacji celów sprintu.
- Przejrzyj swoją tablicę sprintu pod kątem ukończonych historii.
- Skontaktuj się z zespołem, aby ustalić, dlaczego małe historie są nadal otwarte, nawet jeśli zaczęły się na początku sprintu.
- Współpracuj z zespołem, aby zbudować ten sposób myślenia, a nie pozostawiać historie otwarte dłużej niż to konieczne.
- Idealny wykres wypalania jest zwykle stanem teoretycznym. Jednak im bardziej się do tego zbliżamy, tym skuteczniej prowadzimy historię.
Zwinne narzędzia do zarządzania, takie jak Asana, mogą automatycznie generować wykres wypalenia dla każdego sprintu.
źródło: asana.com
#3. Realizacja celu sprintu
Śledzi procent Celów Sprintu, które osiągnąłeś podczas każdego sprintu.
Cele Sprintu dokumentujesz osobno, np. na stronie Confluence / Jira, dla każdego sprintu. Status zostanie nadany niezależnie od tego, czy zostały spełnione w ramach sprintu.
Nawet jeśli zespół nie ukończył wszystkich historii w sprincie, nadal może osiągnąć Cel Sprintu (np. brakuje tylko historii pobocznych).
Będziemy dążyć do 100% realizacji Celów Sprintu w każdym sprincie. Jeśli tak nie jest, dowiedz się, czemu zespół zapobiega.
- Jeśli w każdym sprincie jest zbyt wiele równoległych tematów, zmniejsz ich ilość.
- Jeśli podczas sprintu dodawanych jest zbyt wiele historii ad hoc, zmniejsz to, aby nie wpłynęło to na pierwotne cele sprintu.
- Jeśli cele sprintu są zbyt duże lub zbyt trudne, uprość je. Tak czy inaczej nie ma sensu stawiać sobie wielkich celów sprinterskich i nie realizować ich do końca sprintu.
Metryki jakości kodu
Pozwoli to śledzić, jak dobry jest kod w czasie. Pomaga utrzymać zdrowe procesy rozwojowe i skraca czas poświęcany na rozwiązywanie problemów. Lub czas bezczynności programisty spowodowany oczekiwaniem na wykonanie kodu podczas działań deweloperskich i testowych.
Źródło: azuredevopslabs.com
# 1. Testy automatyczne
Twórz zautomatyzowane testy jednostkowe przez programistów dla każdej wprowadzanej przez nich zmiany.
- Mierz pokrycie kodu za pomocą testów automatycznych — użyj Azure Pipelines lub SonarCloud do uruchamiania testów. Dąż do 85% pokrycia. Powyżej 90% nie jest tak naprawdę wydajne.
- Upewnij się, że automatyczne tworzenie testów jednostkowych jest częścią definicji ukończenia dla nowych historii.
- Nadrabiaj zaległości w testach starego kodu w ramach zaległości technicznych.
#2. Złożoność kodu
Oceń niepotrzebne komplikacje, które kod staje się z biegiem czasu i aktywnie naprawiaj go za pomocą technicznych historii długów. Lub zapobiegaj ich występowaniu, jeśli to możliwe.
Zdefiniuj standardy kodu i wytyczne, aby edukować programistów, aby ich przestrzegali. Upewnij się, że przestrzegają zasad kodowania, aby zminimalizować nieuzasadniony wzrost złożoności kodu. Regularnie aktualizowałem wytyczne w oparciu o doświadczenie zespołu.
Zidentyfikuj zapachy kodu — wskaźniki potencjalnych problemów w kodzie, takich jak zduplikowany kod, długie metody i nieużywane zmienne.
Wzajemne przeglądy zapewniają zastosowanie standardów kodu do nowo utworzonego kodu.
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
Śledź, ile ręcznych czynności musi wykonać zespół, aby udostępnić kod w środowiskach testowych lub produkcyjnych.
- Naszym celem będzie osiągnięcie tutaj 0 w czasie.
- W razie potrzeby utwórz historie długów technicznych, aby dostosować potok wdrażania/wydania do planu automatyzacji. Stopniowo zmniejszaj pozostałe ręczne kroki w procesach od sprintu do sprintu.
Metryki morale
Jest to metryka służąca do śledzenia, jak zespół myśli o swojej pracy i procesach, z którymi ma do czynienia na co dzień.
# 1. Realizacja retrospektywna Sprintu
Możesz śledzić, ile elementów akcji zostało faktycznie ukończonych w następnym sprincie.
- Scrum Master gromadzi wyniki spotkań retrospektywnych na stronach zespołu, aby śledzić uzgodnione działania.
- Następnie zespół śledziłby postępy.
- Kierownictwo projektu może następnie sprawdzić, czy elementy działania postępują lub co uniemożliwia zespołowi ich ukończenie. Następnie zmodyfikuj środowisko, aby umożliwić zespołowi postęp w uzgodnionych elementach działania.
Co najmniej 33% lub 1 (w zależności od tego, co jest wyższe) działań z poprzedniego sprintu zostanie przeniesionych do kolejnych sprintów.
Jeśli jest mniej, potrzebne są zmiany, aby umożliwić zespołowi wdrożenie uzgodnionych ulepszeń.
Narzędzia do zarządzania projektami zawierają gotowe szablony dla działań retrospektywnych sprintu. Oto przykład z monday.com:
źródło: poniedziałek.com
#2. Praca drużynowa
Programowanie par ścieżek.
- Stwórz naturalną parę dla każdej historii, aby wspólnie pracować, dzieląc się obserwacjami, wiedzą i sukcesem. Twórz podzadania w historiach należących do różnych członków zespołu.
Śledź recenzje kodu z inicjatyw rówieśników.
- Rówieśnicy są proszeni lub proaktywnie podejmują działania w celu przejrzenia wyników historii innej osoby.
Metrykę można wyodrębnić z tablicy monday.com/Asana/Jira z podzadań.
Co najmniej 50% historii w sprincie musi być udostępnionych przez członków zespołu. Jeśli jest mniej, zbadaj przyczyny i podejmij działania tam, gdzie ma to sens.
W przypadku dobrowolnych recenzji koleżeńskich śledź historie za pomocą dedykowanych podzadań. Na początek 20% recenzowanych w ten sposób historii kodu to dobry początek. Stopniowo w trakcie sprintów będziesz zachęcać i motywować zespół do większej współpracy i zwiększać go do 50% historii kodu na sprint jako cel.
#3. Dług techniczny a historie nowych funkcjonalności
Źródło: atlassian.com
Danie zespołowi możliwości rozwiązania własnych historii zadłużenia zwiększy satysfakcję zespołu z jego pracy.
- Wręcz przeciwnie, nagromadzenie problemów z długiem technologicznym bez planu ich stopniowego rozwiązywania z czasem zdemotywuje zespół. A rozwiązanie stanie się bardziej niestabilne, złożone i trudne do rozwiązania bez znacznych przeróbek.
Zespół najlepiej wie, co nie działa dobrze z rozwiązaniem, nawet jeśli interesariusze lub użytkownicy końcowi tego nie widzą. Takie historie mają największy wpływ na sam zespół deweloperów. Dla interesariuszy mogą być niewidoczne. Dlatego ważne jest, aby dać zespołowi szansę pracy nad historiami, które pomogą im uporządkować działania rozwojowe.
Celem jest śledzenie, ile historii długów technicznych zostało rozwiązanych w czasie i czy zaległości w takich historiach tylko rosną, czy nie.
Zespół może oznaczyć historie jako TechDebt w backlogu i nadać im priorytet od zespołu, aby mogły znaleźć się na szczycie i zostać wybrane w sprintach.
W zależności od tego, w jakim stanie jest projekt i ile długów technologicznych zidentyfikowano w zaległościach, możesz chcieć upewnić się, że zaległości TechDebt nie rosną o więcej niż 10% od sprintu do sprintu.
Ustal priorytety dla historii zadłużenia technologicznego i uwzględnij je w sprintach, aby kontrolować wzrost zadłużenia technologicznego, tak aby zespół mógł pracować nad historiami zadłużenia technologicznego przez 10-20% czasu każdego sprintu.
Ostatnie słowa
Każdy projekt będzie w końcu wymagał pewnych wskaźników, czy to dlatego, że kierownictwo chce je mieć, czy też dlatego, że zespół decyduje się mierzyć swój własny sukces.
Najlepsze, co możesz zrobić, to zacząć budować swoją bibliotekę metryk gotowych do zbierania i używania; Im szybciej tym lepiej. A robiąc to, upewnij się, że zawsze wybierasz przede wszystkim wskaźniki zmieniające zachowanie.
Następnie sprawdź niezdrowe procesy, które mogą zrujnować Twój sprint.