Monitorowanie tego, co ważne: wskaźniki KPI i pulpity nawigacyjne

W naszym poprzednim rozdziale, Projektowanie pod kątem testowalności: Przełamywanie kolejnej bariery, zbadaliśmy, jak testowalność stała się kluczowym obszarem po rozwiązaniu początkowych problemów w konfiguracji zespołu i testowaniu ręcznym. Ten rozdział stanowił punkt zwrotny w naszej transformacji DevOps, ponieważ przenieśliśmy uwagę na głębsze zasady projektowania oprogramowania, które umożliwiły płynniejsze i szybsze testowanie.

Teraz w Rozdziale 4 przechodzimy do kolejnej, kluczowej fazy: definiowania i śledzenia właściwych wskaźników KPI oraz tworzenia pulpitów nawigacyjnych do mierzenia naszych postępów. Mając już ustalone podstawowe praktyki i poprawiającą się testowalność, potrzebowaliśmy obiektywnych, opartych na danych sposobów wizualizacji przepływu, identyfikacji ograniczeń i ciągłego doskonalenia.

Dlaczego KPI i pulpity nawigacyjne mają znaczenie w DevOps

W miarę postępów w naszej podróży mającej na celu usprawnienie kompleksowej (End-to-End) realizacji, rozpoznaliśmy potrzebę wizualnego i obiektywnego mechanizmu do śledzenia pracy i wykrywania wąskich gardeł. Oznaczało to zdefiniowanie kluczowych wskaźników wydajności (KPI), które nie dotyczyły tylko liczb, ale podkreślały praktyczne wnioski i napędzały właściwe zachowania.

Przy ustalaniu wskaźników KPI należy pamiętać, że zespoły i organizacje mają tendencję do optymalizowania monitorowanych przez siebie wskaźników. Jest to zgodne z Prawem Goodharta, które mówi:

„Kiedy miara staje się celem, przestaje być dobrą miarą.”

Ta zasada podkreśla znaczenie wyboru kluczowych wskaźników efektywności (KPI), które kierują zespoły ku właściwym rezultatom, zamiast zachęcać je do jedynie osiągania celów. Celem tych KPI jest mierzenie postępu w realizacji naszego nadrzędnego celu. Ale czym dokładnie jest ten cel?

Określanie celu.

Jak omówiono w książce The Goal autorstwa Eliyahu M. Goldratta, celem biznesu jest zwiększenie zysku netto przy jednoczesnej poprawie ROI i przepływów pieniężnych. Przekładając to na nasz kontekst rozwoju oprogramowania, gdzie obecnie znajdujemy się w fazie inwestycyjnej, określiliśmy cel jako:

 „Opracować i dostarczyć oprogramowanie, które można wprowadzić na rynek i które generuje zrównoważone przychody.”

Osiągnięcie tego celu wymaga spełnienia kilku niezbędnych warunków, w tym:

• Czas wprowadzenia na rynek → Szybkie dostarczanie funkcji i produktów w celu wykorzystania możliwości rynkowych.
• Skalowalność w przyszłości → Zapewnienie, że oprogramowanie jest zaprojektowane tak, aby rozwijało się wraz z zapotrzebowaniem, bez pogarszania wydajności.
• Optymalizacja kosztów → Równoważenie kosztów rozwoju przy jednoczesnym maksymalizowaniu dostarczanej wartości.
• Zwrot z inwestycji (ROI) → Zapewnienie, że produkt przynosi długoterminowe korzyści finansowe, które uzasadniają inwestycję.

Te warunki kierowały tym, jak definiowaliśmy nasze KPI – skupiając się nie tylko na szybkości i efektywności, ale także na budowaniu skalowalnego, opłacalnego produktu, który dostarcza długoterminową wartość biznesową.

Wizualizacja przepływu: Konfiguracja pulpitów nawigacyjnych.

Zgodnie z opisem w Accelerate autorstwa Nicole Forsgren, Jeza Humble'a i Gene'a Kima, naszym celem było stworzenie panelu kontrolnego, który mógłby wizualizować i śledzić cztery kluczowe metryki DevOps:

• Częstotliwość wdrożeń → Jak często zespoły wdrażają kod do środowiska produkcyjnego.
• Czas realizacji zmian → Jak szybko kod przechodzi od zatwierdzenia do produkcji.
• Współczynnik niepowodzeń zmian → Procent wdrożeń powodujących awarie.
• Średni czas do przywrócenia (MTTR) → Jak szybko zespoły odzyskują sprawność po awariach.

Jednakże, generowanie tych wskaźników w znaczący sposób było początkowo wyzwaniem z powodu braku systematycznego śledzenia pracy w zespołach. To właśnie przyjęcie Azure DevOps jako jednego, wspólnego rozwiązania do zarządzania pracą dla wszystkich zespołów, przyniosło znaczącą różnicę.

Zaczęliśmy od utworzenia dedykowanych pulpitów nawigacyjnych dla zespołów, aby śledzić:

• Wszystkie przypisane zadania dla każdego zespołu.
• Prace w toku.
• Zakończone prace.
• Wady kategoryzowane według etapu i priorytetu.

Pierwsze wyzwanie: Niespójne użycie

Nawet przy jasnych wytycznych, zespoły różnie używały statusów i kategorii defektów. Ta niespójność sprawiła, że analiza przepływu między zespołami była prawie niemożliwa.

Pierwszym wyzwaniem, z którym się zetknęliśmy, było niekonsekwentne stosowanie stanów elementów pracy i klasyfikacji defektów, pomimo istnienia jasnych wytycznych. Różne zespoły używały statusów w różny sposób, co utrudniało identyfikację problemów z przepływem pracy między zespołami. Kluczowe stało się wprowadzenie spójności w sposobie śledzenia pracy, zapewniając, że pulpity nawigacyjne mogły być wykorzystywane nie tylko dla poszczególnych zespołów, ale także do optymalizacji przepływu pracy w całej organizacji.

Następnie skupiliśmy się na właściwym definiowaniu elementów pracy, aby dokładnie odzwierciedlały one miejsce pracy w łańcuchu wartości, jednocześnie będąc wystarczająco ogólnymi, by mogły być używane przez wiele zespołów. Większość narzędzi oferuje domyślne kategorie statusów, ale nie zawsze były one wystarczające. Ważne było zdefiniowanie kategorii statusów, które były zgodne z naszą strukturą zespołu, przepływem pracy i znanymi nam wąskimi gardłami.

Analiza przepływu pracy w celu identyfikacji wąskich gardeł

Pierwsze pulpity nawigacyjne zostały skonfigurowane głównie w celu wizualizacji pracy w toku – aby uzyskać jasny obraz tego, co działo się w zespołach. Obejmowało to historie funkcji, historie użytkowników, defekty i plany testów. Dostarczały one migawki bieżącej pracy, ale nadal nie dawały jasnego obrazu ogólnego przepływu pracy i wartości.

Posiadanie wglądu w postęp prac było ważnym pierwszym krokiem, ale kolejnym wyzwaniem było powiązanie tego wglądu z metrykami opartymi na przepływie, które mogłyby wskazać, gdzie praca się zatrzymywała i gdzie potrzebowaliśmy ulepszeń.

Na podstawie statusu elementów pracy stworzyliśmy metryki pokazujące liczbę elementów pracy w każdym stanie. Początkowo dysponowaliśmy jedynie informacjami o liczbie elementów pracy w różnych stanach. Bardziej zaawansowana analiza – taka jak śledzenie, jak długo elementy pracy pozostawały w każdym stanie – wymagała dodatkowych narzędzi, które wprowadziliśmy później. Na tym początkowym etapie rozpoczęliśmy jednak naszą analizę, opierając się wyłącznie na liczbach.

Nawet z tymi podstawowymi danymi, pulpity nawigacyjne okazały się cenne w identyfikacji kluczowych wąskich gardeł:

• Zbyt wiele zadań w toku w porównaniu do liczby zadań ukończonych w danym okresie.
• Rosnąca liczba zaległych nowych zadań, która znacznie przekraczała to, co mogliśmy realistycznie ukończyć w ciągu najbliższych 3 do 6 miesięcy.
• Zespoły z największą liczbą zaległych zadań, co wskazuje na potrzebę dodatkowego skupienia i wsparcia.

Każde z tych spostrzeżeń wymagało innego rozwiązania, ale zdolność do wizualizacji przepływu pracy była dużym przełomem. To ulepszenie posunęło dalej aspekt Narzędzi w naszym Trójkącie DevOps, dając impuls do postępu w dwóch pozostałych aspektach – Architekturze i Ludziach.

Wykorzystanie KPI do wspierania ciągłego doskonalenia

Wracaliśmy do tematu wskaźników KPI na kilku etapach naszej transformacji DevOps. W miarę poprawy naszych możliwości śledzenia byliśmy w stanie generować bardziej szczegółowe metryki, które pomogły nam:

• Mierzyć postęp w czasie, aby upewnić się, że zmierzamy do naszego celu, jakim jest opracowanie rynkowego produktu oprogramowania.
• Zidentyfikować zależności i przekazania, które powodowały opóźnienia w przepływie pracy.
• Zidentyfikuj obszary, w których zespoły potrzebowały dodatkowego wsparcia lub usprawnień procesów.
• Dostosować nasze KPI ściślej do czterech kluczowych metryk DevOps z przyspieszyć, co zapewni obiektywną miarę naszego sukcesu.

Dzięki dopasowaniu narzędzi, architektury i ludzi do odpowiednich KPI stworzyliśmy system, który zapewnił nam jasny wgląd w nasze postępy, pomógł nam identyfikować i usuwać wąskie gardła oraz zapewnił, że pozostaliśmy skoncentrowani na dostarczaniu długoterminowej wartości biznesowej.

Co dalej? Rozgałęzianie i ciągłe wdrażanie

Dzięki naszym wdrożonym wskaźnikom KPI i panelom kontrolnym jesteśmy teraz gotowi zoptymalizować przepływ kodu przez środowiska i do produkcji. W rozdziale 5 zagłębimy się w to, jak podeszliśmy do rozgałęziania i ciągłego wdrażania oraz do zmian kulturowych i technicznych, które umożliwiły nam szybsze i bezpieczniejsze wdrażanie.

Bądź na bieżąco!