5 min read
W naszym poprzednim rozdziale, Projektowanie pod kątem testowalności: Przełamywanie kolejnej barieryzbadaliśmy, w jaki sposób testowalność stała się kluczowym celem po rozwiązaniu początkowych wąskich gardeł w konfiguracji zespołu i testowaniu ręcznym. Rozdział ten stanowił punkt zwrotny w naszej transformacji DevOps, ponieważ zwróciliśmy uwagę na głębsze zasady projektowania oprogramowania, które umożliwiły płynniejsze i szybsze testowanie.
Teraz, w rozdziale 4, przechodzimy do krytycznej kolejnej fazy: definiowania i śledzenia właściwych wskaźników KPI oraz konfigurowania pulpitów nawigacyjnych do pomiaru naszych postępów. Po wprowadzeniu podstawowych praktyk i poprawie testowalności 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 naszej podróży do usprawnienia kompleksowej dostawy, zdaliśmy sobie sprawę z potrzeby wizualnego i obiektywnego mechanizmu śledzenia pracy i odkrywania wąskich gardeł. Oznaczało to zdefiniowanie wskaźników KPI, które nie dotyczyły tylko liczb, ale podkreślały przydatne spostrzeżenia i kierowały właściwymi zachowaniami.
Podczas konfigurowania wskaźników KPI należy pamiętać, że zespoły i organizacje mają tendencję do optymalizacji wskaźników, które monitorują. Jest to zgodne z prawem Goodharta, które mówi:
"Kiedy środek staje się celem, przestaje być dobrym środkiem".
Zasada ta podkreśla znaczenie wyboru wskaźników KPI, które prowadzą zespoły w kierunku właściwych wyników, a nie zachęcają ich do osiągania celów. Celem tych wskaźników KPI jest mierzenie postępów w realizacji naszego nadrzędnego celu. Ale co dokładnie jest tym celem?
Definiowanie celu
Jak omówiono w książce „Cel” autorstwa Eliyahu M. Goldratta, celem działalności gospodarczej jest zwiększenie zysku netto przy jednoczesnej poprawie ROI i przepływów pieniężnych. Przekładając to na kontekst tworzenia oprogramowania, w którym obecnie znajdujemy się w fazie inwestycji, zidentyfikowaliśmy następujący cel:
"Opracowanie i dostarczenie rynkowego oprogramowania, które generuje trwałe przychody".
Osiągnięcie tego celu wymaga spełnienia kilku niezbędnych warunków, w tym
- Time to Market → Szybkie dostarczanie funkcji i produktów w celu wykorzystania szans rynkowych.
- Przyszła skalowalność → Zapewnienie, że oprogramowanie jest zaprojektowane tak, aby rosło wraz z popytem bez uszczerbku dla wydajności.
- Optymalizacja kosztów → Równoważenie wydatków na rozwój przy jednoczesnej maksymalizacji dostarczanej wartości.
- Zwrot z inwestycji (ROI) → Zapewnienie, że produkt przynosi długoterminowe korzyści finansowe, które uzasadniają inwestycję.
Warunki te ukierunkowały sposób, w jaki zdefiniowaliśmy nasze KPI - koncentrują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: konfiguracja pulpitów nawigacyjnych
Jak opisano w Accelerate autorstwa Nicole Forsgren, Jez Humble i Gene Kim, naszym celem było skonfigurowanie pulpitu nawig acyjnego, który mógłby wizualizować i śledzić cztery kluczowe wskaźniki DevOps:
- Częstotliwość wdrażania → Jak często zespoły wdrażają kod do produkcji.
- Czas oczekiwania na zmiany → Jak szybko kod przechodzi od zatwierdzenia do produkcji.
- Change Failure Rate → Procent wdrożeń powodujących awarie.
- Średni czas przywracania (MTTR) → Jak szybko zespoły odzyskują sprawność po awarii.
Jednak generowanie tych metryk w znaczący sposób było początkowo trudne ze względu na brak systematycznego śledzenia pracy między zespołami. W tym miejscu przyjęcie Azure DevOps jako pojedynczego, wspólnego rozwiązania do zarządzania pracą dla wszystkich zespołów stanowiło znaczącą różnicę.
Zaczęliśmy od skonfigurowania pulpitów nawigacyjnych dla poszczególnych zespołów:
- Wszystkie przypisane elementy pracy na zespół.
- Prace są obecnie w toku.
- Praca zakończona.
- Usterki skategoryzowane według etapu i priorytetu.
Pierwsze wyzwanie: Niespójne użycie
Nawet przy jasnych wytycznych, zespoły używały różnych statusów i kategorii defektów. Ta niespójność sprawiała, że analiza przepływu między zespołami była prawie niemożliwa.
Pierwszym wyzwaniem, jakie napotkaliśmy, było niespójne wykorzystanie stanów elementów pracy i klasyfikacji defektów, pomimo posiadania jasnych wytycznych. Różne zespoły używały różnych statusów, co utrudniało identyfikację problemów związanych z przepływem między zespołami. Zapewnienie spójności w sposobie śledzenia pracy stało się krytyczne, zapewniając, że pulpity nawigacyjne mogą być używane nie tylko dla poszczególnych zespołów, ale także do optymalizacji przepływu w całej organizacji.
Następnie skupiliśmy się na prawidłowym zdefiniowaniu elementów pracy, upewniając się, że mogą one dokładnie odzwierciedlać miejsce pracy w łańcuchu wartości, a jednocześnie są wystarczająco ogólne, aby można je było stosować w wielu zespołach. Większość narzędzi zapewnia domyślne kategorie statusu, ale nie zawsze były one wystarczające. Ważne było zdefiniowanie kategorii statusu, które byłyby zgodne ze strukturą naszego zespołu, sposobem przepływu pracy i znanymi 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 prac w toku - aby uzyskać jasny obraz tego, co dzieje się w zespołach. Obejmowało to historie funkcji, historie użytkowników, defekty i plany testów. Zapewniały one migawkę trwających prac, ale nadal nie zapewniały jasnego obrazu ogólnego przepływu pracy i wartości.
Posiadanie widoczności prac w toku było ważnym pierwszym krokiem, ale kolejnym wyzwaniem było połączenie tej widoczności z metrykami opartymi na przepływie, które mogłyby wskazać, gdzie praca utknęła i gdzie musimy ją poprawić.
Korzystając ze statusu elementów pracy, stworzyliśmy metryki pokazujące liczbę elementów pracy w każdym stanie. Początkowo dysponowaliśmy jedynie informacjami na temat liczby elementów roboczych 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ę, wykorzystując jedynie liczbę elementów.
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ące zaległości w nowych elementach pracy, które znacznie przekraczały to, co mogliśmy realistycznie ukończyć w ciągu najbliższych 3 do 6 miesięcy.
- Zespoły z największą liczbą niedokończonych zadań, wskazujące obszary wymagające dodatkowego wsparcia.
Każde z tych spostrzeżeń wymagało innego rozwiązania, ale możliwość wizualizacji przepływu pracy była głównym przełomem. To ulepszenie posunęło aspekt narzędziowy naszego trójkąta DevOps dalej, zapewniając impuls do postępu w pozostałych dwóch aspektach - architekturze i ludziach.
Wykorzystanie wskaźników KPI do ciągłego doskonalenia
W trakcie transformacji DevOps wielokrotnie powracaliśmy do tematu w skaźników KPI. Wraz z poprawą naszych możliwości śledzenia, byliśmy w stanie generować bardziej szczegółowe dane, które pomogły us:
- Mierzenie postępów w czasie, aby upewnić się, że zmierzamy w kierunku naszego celu, jakim jest opracowanie oprogramowania nadającego się do sprzedaży.
- Identyfikacja zależności i przekazań, które powodowały opóźnienia w przepływie pracy.
- Wskazanie obszarów, w których zespoły potrzebują dodatkowego wsparcia lub usprawnienia procesów.
- Ściślejsze dostosowanie naszych wskaźników KPI do czterech kluczowych wskaźników DevOps z Accelerate, zapewniając obiektywną miarę naszego sukcesu.
Dzięki dostosowaniu narzędzi, architektury i pracowników do odpowiednich wskaźników KPI stworzyliśmy system, który zapewnił nam jasny wgląd w nasze postępy, pomógł us zidentyfikować i usunąć przeszkody oraz zapewnił, że pozostajemy skupieni na dostarczaniu długoterminowej wartości biznesowej.
Co dalej? Rozgałęzianie i ciągłe wdrażanie
Dzięki wdrożonym wskaźnikom KPI i pulpitom nawigacyjnym jesteśmy teraz gotowi do optymalizacji przepływu kodu przez środowiska i do produkcji. W rozdziale 5 omówimy nasze podejście do rozgałęziania i ciągłego wdrażania oraz zmiany kulturowe i techniczne, które umożliwiły us szybsze i bezpieczniejsze us .
Bądź na bieżąco!
