Streszczenie: Wskaźniki Agile zapewniają wgląd w produktywność na różnych etapach cyklu tworzenia oprogramowania. Pozwala to ocenić jakość produktu i śledzić wydajność zespołu.
Wskaźniki to drażliwy temat.
Z jednej strony każdy z nas brał udział w projekcie, w którym nie śledziło się żadnych danych, przez co trudno było powiedzieć, czy wydanie idzie zgodnie z planem albo czy wydajność zespołu zwiększa się z czasem. Z drugiej strony wielu z nas miało wątpliwą przyjemność uczestniczenia w projektach, w których statystyki były używane jako broń, nastawiając jeden zespół przeciwko drugiemu lub uzasadniając obowiązkową pracę w weekendy. Nie dziwi zatem fakt, że większość zespołów balansuje na cienkiej granicy między miłością i nienawiścią do wskaźników.
Ale wcale nie musi tak być. Śledzenie i udostępnianie rzetelnych wskaźników Agile ułatwia ograniczenie zamieszania i pozwala rzucić światło na postępy (i niepowodzenia) zespołu w całym cyklu programowania. Oto, jak to zrobić.
Poznaj swoją firmę
Status „Gotowe” to jedynie połowa historii. Chodzi o opracowanie właściwego produktu, w odpowiednim czasie i na właściwy rynek. Aby podążać w zaplanowanym kierunku w trakcie całego programu, trzeba na bieżąco zbierać i analizować odpowiednie dane. W każdym programie Agile ważne jest monitorowanie zarówno wskaźników biznesowych, jak i Agile. Wskaźniki biznesowe koncentrują się na tym, czy rozwiązanie zaspokaja potrzeby rynku, natomiast wskaźniki Agile odnoszą się do różnych aspektów procesu programistycznego.
„Wskaźniki biznesowe programu powinny być osadzone w jego harmonogramie”.
Dla każdej inicjatywy uwzględnij w harmonogramie kilka kluczowych wskaźników wydajności (KPI) odpowiadających celom programu. Ponadto dodaj kryteria sukcesu dla każdego wymagania dotyczącego produktu, takie jak wskaźnik przyjęcia przez użytkowników końcowych czy procent kodu objęty zautomatyzowanymi testami. Te kryteria sukcesu będą źródłem danych dla wskaźników Agile programu. A im więcej zespoły będą się uczyć, tym sprawniej będą w stanie się dostosowywać i rozwijać.
Optymalizacja dostarczania z wykorzystaniem wskaźników KPI w metodyce Agile
Wykres spalania sprintu
Zespoły Scrum organizują proces programistyczny w formie ograniczonych czasowo sprintów. Na początku sprintu zespół prognozuje, ile pracy jest w stanie wykonać w trakcie jego trwania. Następnie raport spalania sprintu pozwala monitorować realizację prac w trakcie sprintu. Oś X oznacza czas, a oś Y ilość prac, które jeszcze trzeba ukończyć, wyrażoną w punktach historyjek lub godzinach. Celem jest zrealizowanie wszystkich prognozowanych prac przed końcem sprintu.
Zespół, który konsekwentnie realizuje swoje prognozy, stanowi atrakcyjną reklamę metodyki Agile w swojej organizacji. Pamiętaj jednak, aby nie ulegać pokusie fałszowania liczb i deklarowania, że coś zostało ukończone, zanim faktycznie do tego dojdzie. Na krótką metę wygląda to dobrze, ale w dłuższej perspektywie jedynie utrudnia wyciąganie wniosków i doskonalenie.
- Przedwczesne kończenie kolejnych sprintów przez zespół w związku z podejmowaniem się zbyt małej ilości prac.
- Prognozy nierealizowane przez zespół w kolejnych sprintach w związku z podejmowaniem się zbyt dużej ilości prac.
- Linia spalania zawiera gwałtowne spadki, zamiast przedstawiać bardziej stopniowe spalanie, ponieważ praca nie została podzielona na mniejsze fragmenty.
- Product owner rozszerza lub zmienia zakres w trakcie trwania sprintu.
Spalanie epików i wydań
Wykresy spalania epików i wydań (lub wersji) pozwalają śledzić postęp większego wycinka prac niż ten, którego dotyczy wykres spalania sprintu, i wyznaczają kierunek prac programistycznych zarówno zespołów Scrum, jak i Kanban. Sprint (w przypadku zespołów Scrum) może zawierać prace pochodzące z kilku epików i wersji, dlatego ważne jest śledzenie zarówno postępu poszczególnych sprintów, jak i całych epików oraz wersji.
„Pełzający zakres” to rozszerzanie wymagań uprzednio zdefiniowanego projektu. Jeśli na przykład zespół dostarcza nową witrynę internetową dla firmy, to pełzający zakres będzie występował w przypadku dodawania próśb o nowe funkcje po nakreśleniu wstępnych wymagań. Choć tolerowanie pełzającego zakresu w trakcie sprintu jest złą praktyką, modyfikowanie zakresu w obrębie epików oraz wersji jest naturalną konsekwencją procesu programistycznego Agile. W miarę postępów w realizacji projektu przez zespół product owner może podjąć decyzję o dołożeniu lub odebraniu prac w oparciu o zebrane informacje. Wykresy spalania epików i wydań informują wszystkich o wahaniach postępu prac w obrębie epików oraz wersji.
- Brak aktualizacji prognoz dotyczących epików lub wydań w miarę realizacji prac przez zespół.
- Brak postępów w okresie kilku iteracji.
- Stale pełzający zakres, co może być oznaką, że product owner nie w pełni rozumie problem rozwiązywany w ramach prowadzonych prac.
- Zwiększanie zakresu w tempie większym niż zespół jest w stanie przyswoić.
- Niedostarczanie przez zespół przyrostowych wydań w trakcie prac nad epikiem.
Prędkość
Prędkość oznacza średnią ilość prac, którą zespół Scrum wykonuje w trakcie sprintu, wyrażoną w punktach historyjek lub godzinach. Jest to wskaźnik bardzo przydatny przy prognozowaniu. Na podstawie prędkości product owner może przewidywać, jak szybko zespół może wykonać zadania zawarte w backlogu, ponieważ raport śledzi prognozowane i ukończone prace na przestrzeni kilku iteracji. Im więcej iteracji, tym dokładniejsza jest prognoza.
Załóżmy, że product owner chce ukończyć 500 punktów historyjek z backlogu. Wiemy, że zespół programistyczny zwykle realizuje 50 punktów historyjek w trakcie jednej iteracji. Product owner może rozsądnie założyć, że do ukończenia wymaganej pracy konieczne będzie przeprowadzenie (mniej więcej) 10 iteracji.
Ważne jest monitorowanie zmian prędkości w czasie. Można się spodziewać, że prędkość nowych zespołów będzie się zwiększać w miarę optymalizowania relacji i procesu roboczego. Istniejące zespoły mogą monitorować swoją prędkość, aby mieć pewność, że ich wydajność nie zmienia się z czasem, i sprawdzać, czy konkretne zmiany wprowadzone w procesie doprowadziły do poprawy. Spadek średniej prędkości jest zazwyczaj oznaką, że jakaś część procesu programistycznego zespołu stała się nieefektywna, i należy się nad tym zastanowić w trakcie kolejnej retrospektywy.
Jeśli prędkość waha się w dłuższym okresie, zawsze należy ponownie przyjrzeć się praktykom szacowania stosowanym w zespole. W trakcie retrospektywy zespołu należy postawić następujące pytania:
- Czy wystąpiły nieprzewidziane trudności w procesie programistycznym, których nie wzięliśmy pod uwagę w trakcie szacowania pracy? Jak możemy usprawnić podział pracy, aby ujawnić niektóre z tych trudności?
- Czy występują naciski zewnętrzne ze strony firmy, które zmuszają zespół do pracy ponad miarę? Czy w związku z tym pogarsza się przestrzeganie najlepszych praktyk programistycznych?
- Czy jako zespół nie jesteśmy nadgorliwi przy prognozowaniu sprintu?
Prędkość jest cechą unikatową każdego zespołu. Jeśli zespół A ma prędkość 50, a zespół B ma prędkość 75, nie oznacza to, że zespół B ma większą produktywność. Kultura szacowania jest tak samo unikatowa dla każdego jak jego prędkość. Nie wolno ulegać pokusie porównywania prędkości różnych zespołów. Poziom wysiłku i efekty pracy należy mierzyć w oparciu o unikatową dla każdego zespołu interpretację punktów historyjek.
Karta kontrolna
Karty kontrolne koncentrują się na czasie cyklu poszczególnych zgłoszeń, czyli łącznym czasie przejścia zgłoszenia od stanu „W toku” do „Gotowe”. Zespoły, w których czasy cykli są krótsze, mają większą produktywność, natomiast zespoły, w których czasy cykli są podobne w przypadku wielu zgłoszeń, są bardziej przewidywalne pod względem dostarczania prac. Choć czas cyklu jest głównym wskaźnikiem dla zespołów Kanban, zespoły Scrum również mogą czerpać korzyści z jego optymalizacji.
Pomiar czas cyklu jest skutecznym i elastycznym sposobem na usprawnienie procesów zespołu, ponieważ efekty zmian są dostrzegalne niemal natychmiast, co pozwala na błyskawiczne dokonanie dalszych korekt. Ostatecznym celem jest wypracowanie stabilnego i krótkiego czasu cyklu, niezależnie od typu pracy (nowa funkcja, dług techniczny itp.).
Na początku karty kontrolne mogą sprawiać wrażenie nieprzewidywalnych. Nie przywiązuj szczególnej wagi do każdego odstępstwa. Szukaj trendów. Zwracaj przy tym uwagę na dwa istotne obszary:
- Wydłużenie czasu cyklu — wydłużenie czasu cyklu odbiera zespołowi zwinność, którą z takim trudem sobie wypracował. Poświęć czas w trakcie retrospektywy zespołu, aby przeanalizować ten wzrost. Jeden wyjątek: jeśli definicja ukończenia w zespole została rozszerzona, czas cyklu najprawdopodobniej również się wydłuży.
- Nieregularność czasu cyklu — celem jest wypracowanie spójnego czasu cyklu przy jednostkach pracy o podobnej liczbie punktów historyjek. Przefiltruj kartę kontrolną pod kątem każdej wartości punktów historyjek, aby sprawdzić spójność. Jeśli czas cyklu jest nieregularny w przypadku mniejszych i większych wartości punktów historyjek, w trakcie retrospektywy przyjrzyjcie się niedociągnięciom i możliwościom poprawy szacunków w przyszłości.
Kumulacyjny diagram przepływu
Kumulacyjny diagram przepływu powinien przebiegać w miarę płynnie od lewej do prawej. Bąbelki lub luki w dowolnym kolorze wskazują na braki i wąskie gardła, jeśli więc się pojawią, poszukaj sposobów na wygładzenie pasków kolorów na wykresie.
- Powstawanie, w wyniku istnienia blokujących zgłoszeń, dużych zaległości w niektórych częściach procesu i braków w innych.
- Niekontrolowany rozrost backlogu z czasem. Takie zjawisko pojawia się, gdy product ownerzy nie zamykają zgłoszeń przestarzałych lub o priorytecie zbyt niskim, aby zostały wybrane.
Jeszcze więcej wskaźników
Dobre wskaźniki nie ograniczają się do wymienionych powyżej raportów. Przykładowo jakość jest ważnym wskaźnikiem dla zespołów Agile, a w procesie programistycznym Agile można zastosować również szereg wskaźników tradycyjnych:
- Ile defektów znaleziono?
- w trakcie procesu programistycznego?
- po udostępnieniu wydania klientom?
- przez osoby spoza zespołu?
- Ile defektów odroczono do przyszłego wydania?
- Ile wniosków wpływa do działu obsługi klienta?
- Jaki jest procentowy zasięg testów zautomatyzowanych?
Zespoły Agile powinny również zwracać uwagę na częstotliwość wydawania i prędkość dostarczania. Na końcu każdego sprintu zespół powinien wydawać oprogramowanie w środowisku produkcyjnym. Jak często faktycznie do tego dochodzi? Czy dostarczana jest większość kompilacji wydań? Idąc dalej tym tropem, ile czasu zajmuje zespołowi wydanie awaryjnej poprawki w środowisku produkcyjnym? Czy wydanie przychodzi zespołowi z łatwością czy też wymaga heroicznej walki?
Analizy na podstawie kontekstu
Analizy są dla zespołów doskonałym narzędziem oceny wskaźników, gdy zachodzi taka potrzeba: w trakcie planowania sprintów, raportowania postępów podczas codziennych spotkań stand-up lub podczas optymalizacji dostarczania. Analizy można znaleźć w prawym górnym rogu widoków tablicy, backlogu oraz wdrożeń w systemie Jira.
Analizy zapewniają wizualną prezentację następujących wskaźników:
- Postęp sprintu
- Podział według typów zgłoszeń
- Zaangażowanie w ramach sprintu
- Częstotliwość wdrażania
- Czas cyklu
Te wskaźniki pozwalają w ciągły sposób optymalizować wydajność zespołu. Dowiedz się więcej o analizach.
Podsumowując…
Wskaźniki Agile i KPI to tylko jeden z elementów budowania kultury zespołu. Zapewniają ilościowy wgląd w wydajność zespołu i pełnią funkcję wymiernych celów dla jego członków. Choć są ważne, nie należy trzymać się ich obsesyjnie. Wysłuchanie opinii członków zespołu w trakcie retrospektyw jest równie ważne dla budowania zaufania w zespole, zapewniania jakości produktu i utrzymania tempa prac programistycznych w procesie wydawania. Zadbaj o to, aby motorem zmian były zarówno ilościowe, jak i jakościowe informacje zwrotne.
Powiązane zasoby
