zwinne wskaźniki rozwoju oprogramowania i KPI, które pomagają zoptymalizować dostarczanie produktów

czas czytania: 13 minut

zwinne podejście do tworzenia oprogramowania od dawna jest powszechną praktyką. Według ankiety HP online, 16 procent specjalistów IT wybiera czysty zwinny, 51 procent skłania się ku it, a 24 procent stosuje zwinne podejście hybrydowe. Obecnie waterfall development jest wymieniany najczęściej jako zwinny wyróżnik, czym agile nie jest. Omówiliśmy główne różnice w naszym dokumencie dotyczącym metodologii zwinnego zarządzania projektami.

pomimo zdolności adaptacyjnych i elastyczności zwinnego zarządzania oraz szybkiego reagowania na zmiany, przepływ pracy może pozostać scentralizowany i kontrolowany. Zwinne wskaźniki KPI (key performance Indicators) zapewniają wskazówki dotyczące planowania strategicznego, oceny i poprawy procesów operacyjnych.

tradycyjne systemy zarządzania wartością koncentrują się na realizacji zadań w ramach kategorycznego harmonogramu i kosztów. Jednak dzięki agile klienci i członkowie zespołu widzą natychmiastowe wyniki i dostosowują ramy czasowe i wysiłek, aby dostarczyć produkt zgodny z wymaganiami harmonogramu. Jakich narzędzi i technik wymaga taka wiedza? Oto nasz przegląd agile development metrics performance assessment.

zwinne wskaźniki KPI rozwoju oprogramowania

w tym artykule nie zamierzamy badać wszystkich możliwych wskaźników zwinnego rozwoju i wskaźników KPI. Ponadto możesz wymyślić własne, które najlepiej pasują do twojego projektu. Opiszemy jednak najczęstsze wskaźniki KPI stosowane w wielu aspektach tworzenia oprogramowania:

• prędkość
• Sprint burndown
• Release burndown
• czas cyklu
• łączny przepływ
• wydajność przepływu
• pokrycie kodu przez testy automatyczne
• automatyzacja testu przed testowaniem ręcznym
• McCabe cyclomatic complexity (MCC)

pomiar prac w toku

prędkość

prędkość mierzy ilość pracy (wiele funkcji) wykonanej w sprincie. Chociaż nie jest to narzędzie do przewidywania ani porównywania, velocity daje zespołom wyobrażenie o tym, ile pracy można wykonać w następnym sprincie.

indeks prędkości jest unikalny dla każdego zespołu i powinien być ustawiony, aby ocenić, jak realistyczne jest zaangażowanie. Na przykład, jeśli zaległości projektu mają 200 punktów historii i średnio zespół ukończy 10 punktów historii na sprint, oznacza to, że zespół będzie potrzebował około 20 sprintów, aby ukończyć projekt.

im dłużej śledzisz prędkość, tym większa dokładność zgodności między zobowiązaniami a kosztami

dla zespołu, który właśnie przyjął metodologię agile lub nawet rozpoczął nowy produkt, szacunki prędkości pierwszych kilku sprintów będą prawdopodobnie nieregularne. Ale gdy zespoły zdobędą doświadczenie, prędkość osiągnie szczyt, a następnie osiągnie Płaskowyż przewidywalnego przepływu i oczekiwanej wydajności. Spadek spójnego przepływu wskaże problemy w rozwoju i ujawni potrzebę zmian.

Wskazówki dotyczące korzystania z metryki prędkości

niekonsekwencja walki po 3-5 sprintach. Jeśli prędkość pozostaje niespójna po długim okresie czasu, rozważ ocenę zarówno czynników zewnętrznych, jak i wewnętrznych uniemożliwiających jasne oszacowanie.

Zmień śledzenie prędkości po zmianach w zespole i zadaniach. Gdy członek zespołu opuści projekt lub więcej członków/zadań zostanie dodanych, ponownie Oblicz prędkość lub całkowicie zrestartuj obliczenia.

trzy sprinty wystarczą na wczesne prognozy. Aby przewidzieć przyszłe wyniki, użyj średniej z trzech poprzednich sprintów.

Wykres Sprint burndown

Wykres sprint burndown pokazuje ilość pracy pozostałej do wykonania przed końcem sprintu. Narzędzie jest szczególnie cenne, ponieważ wyświetla postęp w kierunku celu zamiast listy ukończonych elementów. Jest to również bardzo przydatne w odkrywaniu błędów planowania, które drużyna popełniła na początku sprintu.

na wykresie poniżej czarna linia reprezentuje prognozowaną (idealny trend) linię pokazującą, w jakim tempie zespół musi spalić punkty historii, aby ukończyć sprint na czas. Niebieska linia wskazuje całkowitą ilość pracy i jej postępy w trakcie Sprintu. Widać, że podczas piątego i szóstego dnia jednej drużynie nie udało się osiągnąć przewidywanego postępu. Jednak Siódmego Dnia problem został rozwiązany i prace wróciły na właściwe tory. Takie bieżące aktualizacje umożliwiają zespołom rozwiązywanie pojawiających się problemów podczas codziennych spotkań stand-up.

oprócz samej wydajności pracy, wykresy spalania mogą ujawniać problemy z planowaniem

Wskazówki dotyczące podejścia do spalania sprintu

punkty historii powinny być nawet w zasięgu. Jeśli obieg pracy nie jest spójny, niektóre zadania mogły zostać podzielone na nierówne części. Zakres odchylenia pomiędzy idealną tendencją a rzeczywistością wyraźnie podkreśla ten problem.

rozliczaj nieplanowane zadania. Wykres wypalenia jest przydatny do zrozumienia zakresu ukrytych i niezapisanych zadań. Jeśli ilość pracy wzrasta, a nie maleje, projekt ma wiele nieocenionych lub nieplanowanych zadań, które należy rozwiązać.

użyj wykresu wypalenia, aby ocenić zaufanie zespołu. Biorąc pod uwagę obecne stawki, zapytaj swój zespół, jak pewnie są o ukończenie sprintu na czas. Im dłużej stosujesz tę metrykę, tym dokładniejsze są szacunki sprintu.

Szacowanie Wydania za pomocą wykresu wypalenia

Wykres wypalenia wydania wskazuje ilość pracy, którą należy wykonać przed wydaniem. Wykres ilustruje przegląd postępów i pozwala na wdrożenie zmian, aby zapewnić terminową dostawę.

tradycyjna wersja wykresu jest podobna do wykresu sprintu, ale daje przegląd całego projektu, w którym oś y jest sprintem, a oś x jest miarą pozostałej pracy (dni, godziny lub punkty historii). Ale co, jeśli więcej pracy zostanie dodana do projektu lub szacowana praca nie spełnia oczekiwań?

na poniższym wykresie zespół planował ukończyć projekt w czterech sprintach i początkowo miał 45 punktów historii. Podczas pierwszego i drugiego sprintu postęp przebiegał zgodnie z planem, podczas trzeciego sprintu szacowana praca wzrosła, co znajduje odzwierciedlenie w osi y w wartościach ujemnych. Podczas trzeciego sprintu pojawiło się 5 nowych punktów. Nie ukończył ich, a czwarty sprint dopisał kolejne 5 punktów. Dlatego trzeba było dostosować postęp i czas wydania.

Wykres wypalenia wersji jest bardzo skuteczny w sytuacjach, w których zmienia się wiele wymagań i pozwala zespołowi pozostać na dobrej drodze podczas każdego sprintu

w jaki sposób Wykres wypalenia wersji może pomóc?

przewidywanie w czasie rzeczywistym dotyczące wydania. Gdy twój projekt ulegnie zmianom, co dzieje się za każdym razem, gdy iteracyjnie rozwijasz produkty, musisz zobaczyć, jak te zmiany wpływają na datę premiery. Wykres wypalenia wydania umożliwia przewidywanie daty wydania w czasie rzeczywistym zgodnie z aktualizacjami w zakresie roboczym.

przewidywania terminów. Możesz oszacować, czy zespół może ukończyć wydanie produktu na czas lub przewidzieć, że termin powinien przesunąć się dalej, biorąc pod uwagę dodane zadania.

Ocena liczby sprintów wymaganych do ukończenia pracy jest również ważnym czynnikiem, który należy wziąć pod uwagę przy wykresie wypalenia wydania.

ocena stanu procesu i znajdowanie wąskich gardeł

czas cyklu

metryka czasu cyklu opisuje, ile czasu poświęcono na zadanie, w tym za każdym razem, gdy praca musiała zostać ponownie otwarta i ponownie zakończona. Obliczanie czasu cyklu dostarcza informacji o ogólnej wydajności i pozwala oszacować zakończenie przyszłych zadań. Podczas gdy krótszy czas cyklu ilustruje lepszą wydajność, najbardziej cenione są zespoły, które dostarczają w ramach spójnego cyklu.

korzystając z poniższego wykresu możesz określić średni czas potrzebny na wykonanie zadania, narysować linię mediany lub granicy kontrolnej, której nie należy przekraczać, I zauważyć, które zadania trwały niezwykle długo.

odchylenie standardowe rysuje linię między normalną i nie zalecaną liczbą dni do wykonania zadania

Możesz również zestawiać wszystkie cykle dla określonego okresu i czerpać wgląd z porównania go z innymi danymi. Przeprowadzając dalsze dochodzenie, możesz wyciągnąć wnioski na temat jakości pracy.

tutaj możesz zobaczyć, że liczba ukończonych zadań od marca do czerwca wzrosła, podobnie jak liczba błędów

jak korzystać z czasu cyklu

Szukaj podobieństw. Dobrą praktyką jest znalezienie podobnych elementów, które wymagają nieprzewidywalnych czasów cyklu, ujawniając powtarzające się problemy, zarówno w inżynierii, jak i zarządzaniu.

Losuj prognozy. Możesz podejmować decyzje oparte na danych, przewidując czas na wykonanie nowych zadań w oparciu o podobne zadania z przeszłości.

śledź Tempo. Wykres opisuje, w jaki sposób utrzymujesz to samo tempo pracy i określa, czy istnieją wewnętrzne problemy, które zmniejszają szybkość pracy.

skumulowany wykres przepływu (CFC)

skumulowany wykres przepływu jest opisany przez obszar wykresu pokazujący liczbę różnych rodzajów zadań na każdym etapie projektu z osią x wskazującą daty i osią y pokazującą liczbę punktów historii. Jego głównym celem jest zapewnienie łatwej wizualizacji sposobu rozłożenia zadań na różnych etapach. Linie na wykresie powinny pozostać mniej więcej nawet, podczas gdy pasmo z” wykonanymi ” zadaniami powinno stale rosnąć.

Wykres ujawnia wiele krytycznych informacji, takich jak nagłe wąskie gardła lub wzrosty w którymkolwiek z pasm

CFC będzie bardzo przydatny dla zespołów Kanban jako prosta wizualizacja pracy zespołu. Wykres odpowiada również trzystopniowemu przepływowi pracy Kanban. Tutaj możesz również mapować trzy główne kategorie zadań: zadania do wykonania, w toku i zakończone.

ponadto Wykres pomaga określić, kiedy przekroczono limity WIP (work-in-progress). Będąc jednym z najcenniejszych narzędzi w zwinnym rozwoju, limity WIP mają na celu kultywowanie kultury prac wykończeniowych i eliminowanie wielozadaniowości poprzez ustawienie maksymalnej ilości pracy dla każdego statusu projektu.

na jakie kwestie zwraca uwagę CFC?

• wzrost zaległości wskazuje na nierozwiązane zadania, które są albo zbyt niskim priorytetem do rozwiązania w tej chwili lub są przestarzałe
• niespójny przepływ i nagłe wąskie gardła wskazują, które obszary powinny zostać wygładzone na późniejszych etapach
• szerokość każdego pasma pokazuje średni czas cyklu
• znaczne poszerzenie obszaru „w toku” może oznaczać, że zespół nie będzie w stanie ukończyć cały projekt na czas

sprawność przepływu

sprawność przepływu jest bardzo przydatnym wskaźnikiem w rozwoju Kanban, pomijanym głównie przez rozwój drużyn. Chociaż wydajność przepływu uzupełnia przepływ skumulowany, daje wgląd w rozkład między rzeczywistą pracą a okresem oczekiwania. Jest to rzadki przypadek, gdy deweloper pracuje nad jedną rzeczą na raz, nie czekając. Rzeczywistość jest zwykle bardziej złożona. A „work-in-progress” to nazwa, która nie zawsze pasuje do statusu.

na przykład, kod może mieć wiele zależności i nie możesz rozpocząć pracy z jakąś funkcją przed zakończeniem innej, lub zmienić swoje priorytety, lub czekasz na zatwierdzenie interesariusza. Pomiar czasu oczekiwania na pracę może być nawet bardziej przydatny niż usprawnienie procesów związanych z rzeczywistą pracą.

patrząc na najniższe wskaźniki wydajności, można zrozumieć główne wąskie gardła

jak korzystać z formuły obliczeniowej wydajności przepływu

. O ile nie zastosujesz oprogramowania do zarządzania projektami, które zawiera te wskaźniki,możesz obliczyć wydajność przepływu za pomocą tej prostej formuły: Praca / (Praca+oczekiwanie) * 100%. Następnie możesz wizualizować go cyfrowo lub nawet narysować wykres na tablicy biurowej.

Określ swoją normalną wydajność przepływu. Podobnie jak w przypadku wszystkich innych wskaźników, nie można przypisać normalnych liczb dla wszystkich projektów. Niektórzy twierdzą, że znak 15% jest w porządku dla większości projektów, co zasadniczo oznacza, że punkt historii lub inny element pracy czeka 85% wobec 15% czasu przetwarzania. David J. Anderson, ekspert zarządzania z Leankanban School of Management, sugeruje, że 40 procent i więcej powinno być celem dla większości zespołów.

rozłożyć szczegóły pracy przed ustaleniem wydajności przepływu. Wykres pozwoli na wyświetlenie dokładnych okresów czasu, kiedy wydajność była najniższa. I te dane muszą być bardzo uważnie analizowane, ponieważ prawdziwa przyczyna i jej środek zaradczy nie są ujawniane tak łatwo. Zanim rozpoczniesz intensywne działania, dokładnie zbadaj przyczyny.

zwiększenie wydajności przepływu za pomocą analizy blokerów. Dobrym sposobem na zrealizowanie poprzedniego punktu jest zwiększenie wydajności przepływu za pomocą analizy klastrów blokujących. Jeśli jakaś praca jest zablokowana, zasługuje na kolorową naklejkę lub inną formę sygnału wizualnego, aby zwrócić uwagę zespołu na te blokery, aby mogli na nie zareagować.

możesz zaznaczyć, ile dni niektóre prace są blokowane i nadać priorytet rozdzielczości

Zwykle blokery gromadzą się w klastrach, ponieważ mają wiele zależności od siebie. Lepsza analiza blokerów może być wykonana, jeśli zgrupujesz je, zaczynając od podobieństw wysokiego poziomu, takich jak wewnętrzne i zewnętrzne blokery, a następnie określając dalej przez projekt, brakującą zawartość lub inne brakujące funkcje. Analiza blockera to prosty sposób na zbadanie wydajności przepływu.

Pomiar jakości kodu

pokrycie kodu

pokrycie kodu określa, ile linii kodu lub bloków jest wykonywanych podczas uruchamiania testów automatycznych. Pokrycie kodu jest krytycznym wskaźnikiem dla praktyki test-driven development (TDD) i ciągłego dostarczania. Tradycyjnie metryka jest interpretowana w prosty sposób: im większe pokrycie kodu, tym lepiej. Aby to zmierzyć, potrzebujesz jednego z dostępnych narzędzi, takich jak kombinezony. Ale wszystkie działają prawie tak samo: podczas uruchamiania testów narzędzie wykryje, które linie kodu są wywoływane przynajmniej raz. Procent wywołanych linii to pokrycie kodu.

Kombinezony, na przykład, rozkładają pokrycie kodu do każdego pomiaru pliku i wyróżniają pokryte i odkryte linie

jak używać pokrycia kodu

skup się na niepokrytych liniach i nie przeceniaj zakrytych. Jeśli linia kodu zostanie wywołana raz lub nawet więcej, nie musi to oznaczać, że funkcja, którą obsługuje, działa doskonale, a użytkownicy pozostaną zadowoleni. Wywołanie linii kodu nie zawsze wystarcza do zamknięcia zadania testowego. Z drugiej strony, procent odkrytych linii pokazuje to, co nie zostało w ogóle pokryte i może zasługiwać na testy.

Priorytetyzuj kod i nie celuj w 100%. Chociaż wydaje się to sprzeczne z intuicją, 100 procent pokrycia nie oznacza, że poprawnie przetestowałeś kod. Twój projekt ma kod, który ma znaczenie, a reszta bazy kodu. Ponieważ automatyzacja testów jest zwykle kosztowną inicjatywą, powinna nadać priorytet funkcjom i odpowiednim fragmentom kodu.

automatyzacja testów w porównaniu z testami ręcznymi

ten pomiar określa, ile linii kodu w ramach funkcji jest już objętych testami automatycznymi w porównaniu z tymi, które są testowane ręcznie. Jest to bezpośrednio zgodne z poprzednią metryką, ale ma konkretny przypadek użycia. Proporcja automatyzacji testów w stosunku do testów ręcznych jest używana tylko wtedy, gdy krytycznie potrzebujesz automatyzacji, aby pokryć regresje. Testowanie regresji odbywa się w celu sprawdzenia, czy coś się zepsuło po aktualizacji funkcji. A jeśli twój produkt podlega ciągłym ulepszeniom-co powinno-testowanie regresji powinno być zautomatyzowane. Jeśli tak nie jest, twoi specjaliści ds. kontroli jakości będą musieli wielokrotnie powtarzać te same scenariusze testowe po każdym zatwierdzeniu aktualizacji.

możesz użyć tych samych instrumentów używanych do pokrycia kodu, aby narysować tę metrykę

opisanie automatycznego pokrycia testu na funkcję pozwoli Ci nadać priorytet funkcjom, które 1) mogą cierpieć z powodu regresji po aktualizacjach i 2) dla których automatyczne testy są krytyczne. Zazwyczaj nie masz wystarczająco dużo czasu i zasobów ludzkich, aby pokryć wszystko automatycznymi testami naraz, chyba że pracujesz w ramach test-driven development framework. Lepiej więc nadać priorytet funkcjom, które z pewnością wpłyną na wrażenia użytkownika.

McCabe Cyclomatic Complexity (MCC) kodu

pomiary złożoności kodu służą do oceny ryzyka problemów podczas testowania i konserwacji kodu. Im większa złożoność kodu, tym trudniej jest upewnić się, że ma on akceptowalną liczbę błędów i utrzymuje wysoką łatwość konserwacji. Najczęstszym podejściem do pomiaru złożoności kodu jest McCabe Cyclomatic Complexity Metric (MCC). Jedna z formuł do rysowania wyników złożoności dla MCC jest następująca:

MCC = edges-nodes + return statements

MCC na obrazku równa się 3

Dzięki tej metryce programiści nie szacują swojej złożoności kodu subiektywnie na nią patrząc. Ponieważ umiejętności inżynierów różnią się, ich oceny różnią się, co sprawia, że refaktoryzacja kodu lub naprawianie błędów jest trudniejsze w dłuższej perspektywie. Na rynku dostępnych jest wiele narzędzi pomiarowych MCC, które można łączyć z innymi metrykami złożoności kodu, takimi jak głębokość hierarchii kodu i liczba linii kodu.

zastosowanie MCC specyfiki i pułapki

równoważy ludzkie i maszynowe postrzeganie złożoności kodu. Jednym z głównych powodów korzystania z MCC jest uczynienie kodu czytelnym dla innych programistów. Czytelność kodu zmniejsza ryzyko długotrwałego wdrażania nowych programistów, którzy muszą radzić sobie ze starszym kodem. Uprości to również proces refaktoryzacji. Problem w tym, że model MCC może uznać niektóre złożone, ale czytelne metody za niedopuszczalne. A jeśli zmusisz programistę do refaktoryzacji złożonych metod na wiele pod-metod, możesz osiągnąć odwrotne wyniki: wiele metod z prostą logiką może stać się jeszcze trudniejsze do zrozumienia dla człowieka niż pojedyncza, ale złożona metoda.

nie rób z MCC restrykcyjnej metryki. Niektóre organizacje praktykują zamykanie commitów kodu, które nie przechodzą testu MCC. Chociaż może to potencjalnie zwiększyć prostotę kodu, naturalnym jest posiadanie złożonego kodu na poziomach klas, metod i funkcji. Blokowanie ich całkowicie nie zawsze jest korzystne. Dobrą praktyką jest ustawienie ogólnego KPI złożoności kodu dla programistów, co zachęci ich do bardziej świadomego podejścia do kodowania i myślenia o prostocie.

Zastosuj MCC do przeglądu kodu. Inną cenną praktyką w testach MCC jest zastosowanie go podczas przeglądów kodu, aby zawęzić zakres prac do przeglądu określonych fragmentów kodu, w których ryzyko wad jest największe.

code churn

code churn jest bardzo użyteczną wizualizacją trendów i fluktuacji, które zdarzają się bazie kodu zarówno pod względem całego procesu, jak i czasu przed wydaniem. Churn mierzy, ile linii kodu zostało dodanych, usuniętych lub zmienionych. Czasami wykresy pokazują wszystkie trzy pomiary.

ten przykład firmy Microsoft zawiera wszystkie trzy parametry, ale można ich używać selektywnie

chociaż śledzenie odejścia kodu może wydawać się nieco prymitywnym wskaźnikiem, pozwala to ocenić stabilność kodu na różnych etapach rozwoju. Należy spodziewać się najniższej stabilności podczas pierwszych sprintów i najwyższej stabilności – przy jednoczesnym NAJNIŻSZYM churn – tuż przed zwolnieniem. Jeśli twój kod jest bardzo niestabilny i zbliża się data premiery, Uruchom alarm.

przypadki użycia kodu

Szukaj prawidłowości. Regularne skoki zmian w kodzie mogą ujawnić, że podejście do generowania zadań nie jest wystarczająco skoncentrowane i produkuje wiele dużych zadań na zasadzie powtarzania.

nieregularne, ale wysokie kolce wymagają zbadania. Jeśli masz nieregularne, ale potężne skoki zmian w kodzie, możesz zbadać, które zadania spowodowały takie sejsmiczne szczyty w kodzie i ponownie rozważyć poziom zależności, zwłaszcza jeśli liczba nowych linii kodu zwiększyła liczbę zmienionych linii.

zwróć uwagę na trendy. Stabilność produktu staje się bardzo krytyczna przed wydaniem. Jak już wspomnieliśmy, wskaźnik churn powinien mieć tendencję spadkową, im bliżej Twojej drużyny do uwolnienia. Rosnący trend oznacza możliwą niestabilność produktu po wydaniu, ponieważ jest prawdopodobne, że nowy kod nie zostanie poddany wystarczającym testom.

celuj w postęp, a nie kontroluj

podobnie jak inne wskaźniki wydajności, wskaźniki zwinne nie zawsze zawierają wyraźne odpowiedzi lub przydatne wskazówki, które przypieczętują Twój sukces. Powinieneś jednak wykorzystać wiedzę, którą dostarczają, aby rozpocząć dyskusję, przeprowadzić ocenę i zaproponować własny plan radzenia sobie z problematycznymi kwestiami.

chociaż metryki zapewniają liczbowy wgląd w wydajność zespołu i ogólną satysfakcję z pracy, nie skupiaj się na nich. Biorąc pod uwagę, że wskaźniki zwinne nie są ustandaryzowane, nie ma sensu porównywać sukcesów różnych zespołów. Nie zapominaj o opiniach zespołu, inicjuj regularne dyskusje i buduj atmosferę wspólnych celów i wsparcia.