5 min czytania
W poprzednim rozdziale, Projektowanie pod kątem testowalności: przełamywanie kolejnej bariery, omówiliśmy, jak testowalność stała się głównym punktem zainteresowania po rozwiązaniu początkowych problemów z konfiguracją zespołów i testowaniem ręcznym. Rozdział ten 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 konfigurowania pulpitów nawigacyjnych w celu pomiaru naszych postępów. Mając wdrożone podstawowe praktyki i rosnącą testowalność, potrzebowaliśmy obiektywnych, opartych na danych sposobów wizualizacji przepływu, identyfikacji ograniczeń i ciągłego doskonalenia.
Dlaczego wskaźniki KPI i pulpity nawigacyjne mają znaczenie w DevOps
W miarę postępów w dążeniu do usprawnienia dostarczania usług w formule end-to-end zauważyliśmy potrzebę stworzenia wizualnego i obiektywnego mechanizmu do śledzenia pracy i wykrywania wąskich gardeł. Oznaczało to zdefiniowanie wskaźników KPI, które nie opierałyby się wyłącznie na liczbach, lecz służyłyby do wskazywania praktycznych wniosków i promowania właściwych zachowań.
Podczas konfigurowania wskaźników KPI należy pamiętać, że zespoły i organizacje mają tendencję do optymalizowania monitorowanych przez siebie miar. Jest to zgodne z prawem Goodharta, które mówi:
"Kiedy miara staje się celem, przestaje być dobrą miarą".
Zasada ta podkreśla znaczenie wyboru wskaźników KPI, które kierują zespoły ku właściwym rezultatom, zamiast zachęcać je po prostu do osiągania celów. Celem tych wskaźników KPI jest zmierzenie postępów w realizacji naszego nadrzędnego celu. Ale czym dokładnie jest ten cel?
Definiowanie celu
Jak omówiono w książce Cel, której autorem jest Eliyahu M. Goldratt, celem działalności biznesowej jest zwiększenie zysku netto przy jednoczesnej poprawie ROI oraz przepływów pieniężnych. Przekładając to na nasz kontekst tworzenia oprogramowania, w którym znajdujemy się obecnie w fazie inwestycyjnej, określiliśmy cel jako:
„Opracowanie i dostarczenie na rynek oprogramowania, które generuje stabilne 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 rynkowych szans.
- Skalowalność w przyszłości → Zapewnienie, że oprogramowanie zostało zaprojektowane tak, aby rosnąć wraz z popytem bez pogarszania wydajności.
- Optymalizacja kosztów → Równoważenie wydatków na rozwój przy jednoczesnym zmaksymalizowaniu dostarczanej wartości.
- Zwrot z inwestycji (ROI) → Zapewnienie, że produkt przynosi długoterminowe korzyści finansowe, które uzasadniają poniesione nakłady.
Warunki te posłużyły za wytyczne przy definiowaniu naszych wskaźników KPI – skupiając się nie tylko na szybkości i wydajności, ale także na budowaniu skalowalnego, opłacalnego produktu, który zapewnia długoterminową wartość biznesową.
Wizualizacja przepływu: konfigurowanie pulpitów nawigacyjnych
Zgodnie z książką Accelerate autorstwa Nicole Forsgren, Jez Humble i Gene'a Kima, naszym celem było skonfigurowanie pulpitu nawigacyjnego, który wizualizowałby i śledził cztery kluczowe metryki DevOps:
- Częstotliwość wdrażania → Jak często zespoły wdrażają kod na produkcję.
- Czas realizacji zmian → Jak szybko kod przechodzi od zatwierdzenia do wdrożenia na produkcję.
- Wskaźnik awaryjności zmian → Odsetek wdrożeń powodujących awarie.
- Średni czas przywracania sprawności (MTTR) → Jak szybko zespoły usuwają awarie.
Jednak generowanie tych wskaźników w znaczący sposób było początkowo trudne ze względu na brak systematycznego śledzenia pracy w poszczególnych zespołach. W tej sytuacji kluczowe znaczenie miało wdrożenie platformy Azure DevOps jako jednego, wspólnego rozwiązania do zarządzania pracą dla wszystkich zespołów.
Zaczęliśmy od skonfigurowania pulpitów dedykowanych poszczególnym zespołom w celu śledzenia:
- Wszystkich przypisanych zadań w podziale na zespoły.
- Prac aktualnie będących w toku.
- Ukończonych prac.
- Defektów sklasyfikowanych według etapu i priorytetu.
Pierwsze wyzwanie: Niespójne użytkowanie
Nawet przy jasnych wytycznych zespoły korzystały ze statusów i kategorii defektów w różny sposób. Ta niespójność uniemożliwiała przeprowadzenie analizy przepływu między zespołami.
Pierwszym wyzwaniem, z którym się mierzyliśmy, było niespójne stosowanie statusów zadań oraz klasyfikacji defektów, pomimo posiadania jasnych wytycznych. Poszczególne zespoły korzystały ze statusów w odmienny sposób, co utrudniało identyfikowanie problemów z przepływem pomiędzy nimi. Zapewnienie spójności w sposobie śledzenia pracy stało się kluczowe, aby pulpity mogły służyć nie tylko pojedynczym zespołom, ale także do optymalizacji przepływu w całej organizacji.
Następnie skupiliśmy się na odpowiednim zdefiniowaniu elementów pracy, aby jak najdokładniej odzwierciedlały one etap, na którym znajduje się dane zadanie w łańcuchu wartości, a jednocześnie były na tyle uniwersalne, by można je było stosować w wielu zespołach. Większość narzędzi zapewnia domyślne kategorie statusów, jednak nie zawsze były one wystarczające. Ważne było określenie kategorii statusów, które odpowiadałyby naszej strukturze zespołowej, sposobowi przepływu pracy oraz znanym nam wąskim gardłom.
Analiza przepływu pracy w celu identyfikacji wąskich gardeł
Pierwsze pulpity zostały skonfigurowane przede wszystkim w celu wizualizacji pracy będącej w toku – aby uzyskać jasny obraz sytuacji w zespołach. Obejmowało to opisy funkcji, historie użytkowników, defekty oraz plany testów. Zapewniały one pogląd na trwające prace, jednak nadal nie dawały pełnego obrazu ogólnego przepływu pracy i wartości.
Uzyskanie widoczności prac w toku było ważnym pierwszym krokiem, jednak kolejnym wyzwaniem stało się powiązanie tej widoczności ze wskaźnikami opartymi na przepływie, które mogłyby wskazać, gdzie praca utknęła i w których obszarach konieczne są ulepszenia.
Wykorzystując statusy zadań, utworzyliśmy wskaźniki pokazujące liczbę elementów pracy na każdym etapie. Początkowo dysponowaliśmy jedynie informacjami o liczbie zadań w poszczególnych stanach. Bardziej zaawansowana analiza – taka jak śledzenie czasu, przez jaki elementy pracy pozostawały w każdym stanie – wymagała dodatkowych narzędzi, które wprowadziliśmy później. Na tym początkowym etapie naszą analizę oparliśmy jednak wyłącznie na liczbach.
Nawet przy tak podstawowych danych pulpity okazały się przydatne w identyfikacji kluczowych wąskich gardeł:
- Zbyt duża liczba zadań w toku w stosunku do liczby elementów ukończonych w danym okresie.
- Rosnący zaległy stos nowych zadań, który znacznie przewyższał to, co realnie mogliśmy ukończyć w ciągu najbliższych 3 do 6 miesięcy.
- Zespoły z największą liczbą niedokończonych zadań, co wskazywało, gdzie potrzebne jest dodatkowe wsparcie i uwaga.
Każde z tych spostrzeżeń wymagało innego rozwiązania, jednak sama możliwość wizualizacji przepływu pracy była ogromnym przełomem. To ulepszenie pozwoliło pójść o krok dalej w obszarze Narzędzi w ramach naszego Trójkąta DevOps, dając impuls do rozwoju w pozostałych dwóch aspektach – Architekturze oraz Ludziach.
Wykorzystanie wskaźników KPI do napędzania ciągłego doskonalenia
Do tematu wskaźników KPI wracaliśmy na różnych etapach naszej transformacji DevOps. W miarę poprawy naszych możliwości monitorowania uzyskaliśmy dostęp do bardziej szczegółowych metryk, które pomogły nam:
- Mierzenie postępów w czasie, aby upewnić się, że zmierzamy w stronę naszego celu, jakim jest stworzenie rynkowego produktu oprogramowania.
- Zidentyfikuj zależności i przekazania, które powodowały opóźnienia w przepływie pracy.
- Wskaż obszary, w których zespoły potrzebowały dodatkowego wsparcia lub usprawnienia procesów.
- Dopasowanie naszych wskaźników KPI w większym stopniu do czterech kluczowych metryk DevOps z publikacji Accelerate, co zapewnia obiektywną miarę naszego sukcesu.
Dopasowując narzędzia, architekturę i ludzi do odpowiednich wskaźników KPI, stworzyliśmy system, który zapewnił pełną przejrzystość naszych postępów, pomógł nam identyfikować i usuwać wąskie gardła oraz zagwarantował, że skupiamy się na dostarczaniu długoterminowej wartości biznesowej.
Co dalej? Rozgałęzianie i ciągłe wdrażanie
Mając wdrożone wskaźniki KPI i pulpity nawigacyjne, jesteśmy teraz gotowi zoptymalizować przepływ kodu przez środowiska do środowiska produkcyjnego. W rozdziale 5 omówimy nasze podejście do gałęzi kodu (branchingu) i ciągłego wdrażania (Continuous Deployment) oraz zmiany kulturowe i techniczne, które umożliwiły nam szybsze i bezpieczniejsze wdrażanie.
Śledź nas na bieżąco!
