Ciągłe dostarczanie: wartość biznesowa, korzyści, wyzwania i wskaźniki

1. Prędkość

Zautomatyzowane pipeline'y dostarczania oprogramowania pomagają organizacjom lepiej reagować na zmiany rynkowe. Potrzeba szybkości ma ogromne znaczenie dla skrócenia czasu opóźniania wysyłki nowych funkcji. Skracając czas wprowadzania na rynek, organizacje mają większą szansę na wyprzedzenie konkurencji i pozostanie w interesie.

Pamiętaj, że prędkość sama w sobie nie jest wskaźnikiem sukcesu. Bez jakości prędkość jest nie ma znaczenia. Pipeline'y ciągłego dostarczania pozwalające na błyskawiczne wysyłanie do produkcji błędnego kodu są bezwartościowe.

2. Produktywność

Produktywność przekłada się na zadowolenie, a zadowolone zespoły są bardziej zaangażowane.

Produktywność wzrasta, gdy żmudne i powtarzalne zadania, takie jak wypełnianie raportu o błędzie dla każdej wykrytej usterki, mogą być wykonywane przez pipeline'y zamiast przez ludzi. Pozwala to zespołom skupić się na wizji, podczas gdy pipeline'y zajmują się realizacją. A kto nie chce delegować dużych obciążeń na narzędzia?

Zespoły analizują problemy zgłaszane przez ich pipeline'y, a po zatwierdzeniu poprawki pipeline'y te są uruchamiane ponownie w celu sprawdzenia, czy problem został rozwiązany oraz czy przypadkowo nie wprowadzono nowych problemów.

3. Zrównoważony rozwój

Firmy chcą wygrywać maratony, nie tylko sprinty. Wiemy, że wyjście przed szereg wymaga odwagi. Jeszcze trudniej jest utrzymać swoją pozycję przed tym szeregiem. Wymaga to dyscypliny i rygoru. Ciężka praca 24/7 doprowadzi do przedwczesnego wypalenia. Zamiast tego pracuj mądrze i deleguj powtarzalne prace maszynom, które, nawiasem mówiąc, nie potrzebują przerw na kawę i nie pyskują!

Każda organizacja, niekoniecznie o profilu technologicznym, wykorzystuje technologię, aby wyróżnić się na rynku. Zautomatyzowane pipeline'y ograniczają liczbę ręcznie wykonywanych prac, a ostatecznie prowadzą do oszczędności, ponieważ zatrudnianie personelu jest droższe od narzędzi. Znaczna inwestycja na początku może budzić wątpliwości u niedoświadczonego kierownictwa, jednak dobrze zaprojektowane pipeline'y dają organizacjom możliwość lepszego i szybszego tworzenia innowacji zaspokajających potrzeby ich klientów. Ciągłe dostarczanie zapewnia firmie większą elastyczność w dostarczaniu funkcji i poprawek. Określone zestawy funkcji mogą być udostępniane konkretnym klientom lub konkretnej grupie klientów, aby zyskać pewność, że będą one działały i skalowały się zgodnie z przewidywaniami. Funkcje można testować i rozwijać bez aktywowania ich w produkcie przez wiele wydań. Twój dział marketingu chce zaskoczyć odbiorców na dorocznym konwencie branżowym czymś spektakularnym? Z modelem ciągłego dostarczania jest to nie tylko możliwe, ale wręcz proste.

Budżet: czy Twój jest zbyt niski?

Tworzenie pipeline'ów ciągłego dostarczania zajmuje najlepszych ludzi. Nie jest to projekt poboczny, którego koszt można zamieść pod dywan. Zawsze zaskakiwało mnie, w jaki sposób niektóre organizacje zaczynają od przydzielania młodszych członków zespołu oraz szukania oszczędności na zakupie nowoczesnych narzędzi. Na pewnym etapie korygują swój tok postępowania i przydzielają starszych architektów do inwestycji w rozdzielenie architektury i opracowanie solidnych pipeline'ów ciągłego dostarczania.

Nie zaczynaj od obniżania poprzeczki. Bazując na swojej wizji, odłóż odpowiednią kwotę, aby mieć pewność, że inwestycja zostanie zrealizowana bez problemów. Udostępnij produkt o minimalnej wymaganej funkcjonalności (MVP) w ramach pipeline'u ciągłego dostarczania, a następnie przeskaluj go na całą organizację.

Czy masz osoby, które myślą przyszłościowo?

Nawet jeśli będziesz dysponować budżetem, ostatecznie może okazać się, że problemem w realizacji będą ludzie.

Zespoły powinny nieustraszenie dążyć do automatyzacji swoich zadań, a następnie przechodzić do nowych projektów. Jeśli Twoi ludzie obawiają się powierzać zautomatyzowanym agentom zadania, które w innym przypadku musieliby wykonywać ręcznie, zatrudniasz niewłaściwe osoby.

Jeśli czujesz, że nie dasz rady ruszyć dalej, zmień bieg. Naucz się dawać zespołowi samochód tam, gdzie proszą jedynie o szybszego konia. Na początku skorzystaj z pomocy doświadczonych specjalistów, którzy pomogą Ci uporać się z tymi wstępnymi trudnościami. W końcu to ludzie są Twoim najcenniejszym zasobem i zapewnij im szkolenie, które umożliwi im podjęcie właściwych działań. Ułatw podejmowanie właściwych kroków i utrudnij działanie w sposób niewłaściwy, a wyniki będą dla Ciebie miłym zaskoczeniem.

Brak priorytetów

„Zatrzymajmy prace i opracujmy pipeline'y ciągłego dostarczania!” — nie powiedział nigdy żaden product owner.

Na ich obronę można powiedzieć, że są skoncentrowani na wyprzedzaniu konkurencji w tworzeniu nowych funkcji, które zachwycą odbiorców na całym świecie. Jednocześnie zdajesz sobie sprawę, że masz problem, jeśli w każdym planowaniu sprintu wartość pipeline'ów ocenia się przez porównanie z funkcjami produktów, a w konsekwencji się je odrzuca.

W backlogach niektórych produktów pipeline'y, jeśli w ogóle się pojawiają, dożywotnio okupują pozycje najbliższe dolnej kreski. Krótkowzroczne kierownictwo klasyfikuje prace związane z pipeline'ami jako wydatki, a nie inwestycje, które zapewnią zespołom lepszą pozycję. Wypierają oni długoterminowe szkody, jakie generują, i niestety często uchodzi im to na sucho.

Pipeline'y są jak higiena. Jeśli chcesz się utrzymać na rynku, zadaj sobie pytanie „czy higiena jest ważna”. Założę się, że odpowiesz twierdząco.

W Pipeline'ach znajduje się ogrom danych transakcyjnych

Wyobraź sobie typowy dzień z życia zespołu programistycznego. Zespół zatwierdza funkcję, którą firma uznała za priorytetową, następnie zatwierdza testy dla tej funkcji i integruje wdrożenia z pipelinem ciągłego dostarczania, aby każda zmiana była wdrażana automatycznie. Zespół uzmysławia sobie, że po dodaniu nowej funkcji, aplikacja zaczęła działać powoli, i zatwierdza poprawkę problemu z wydajnością. Zespół dodaje również testy wydajności, aby się upewnić, że niewłaściwe czasy reakcji zostaną wychwycone przed przeniesieniem aplikacji ze środowiska testowego do przejściowego.

Wyobraź sobie, że każdy taki commit jest transakcją. W ten sposób zespoły tworzące oprogramowanie idą naprzód — transakcja za transakcją — aż powstanie produkt, który zachwyci świat. A potem znów ruszają. Pomnóż te transakcje przez wszystkich inżynierów i wszystkie zespoły w Twojej organizacji, a okaże się, że masz do dyspozycji ogrom danych transakcyjnych.

Przeanalizujmy dane transakcyjne pipeline'u

Czy moglibyśmy przeanalizować dane transakcyjne, aby wydobyć z nich pęczki informacji? Pewnie, że tak!

Podobnie jak w przypadku wszystkich danych transakcyjnych, ilość danych sprawia, że same w sobie nie wnoszą zbyt wiele. Dlatego powinniśmy agregować dane i przeprowadzać analizy, aby uzyskać lepszy wgląd w naszą organizację. Analizy pomagają nam dostrzec całość obrazu, jaki tworzą części układanki. Poniżej przedstawiliśmy trzy przykłady ulepszenia naszych praktyk dzięki analizom pipeline'ów i wyciąganiu z nich wniosków.

Na podstawie setek wdrożeń realizowanych każdego tygodnia wywnioskowaliśmy, że liczba nieudanych wdrożeń aplikacji A jest trzy razy większa niż w przypadku aplikacji B. To odkrycie skłoniło nas do przyjrzenia się decyzjom projektowym w zakresie stabilności środowiska i zarządzaniu konfiguracjami w kontekście aplikacji A. Okazało się, że zespół używał do wdrażania w swoim centrum danych niespójnych maszyn wirtualnych, podczas gdy aplikacja B była skonteneryzowana. Potraktowaliśmy zatem priorytetowo inwestycję w niezmienną infrastrukturę, a po miesiącu przeprowadziliśmy kontrolę, aby się upewnić, że zwrot z tej inwestycji był dobry. I faktycznie taki był. To, co da się zmierzyć, można naprawić.

Kolejnym przykładem jest sytuacja, gdy dowiedzieliśmy się, że w ostatnich kilku kwartałach liczba błędów statycznej analizy kodu aplikacji B wykazuje tendencję wzrostową. Mogło to oznaczać, że zespół odpowiedzialny za aplikację B wymaga doszkolenia celem poprawy jakości pisanego kodu. Odkryliśmy również, że narzędzia do statycznej analizy kodu zgłaszały fałszywe błędy, co oznacza, że dodawały flagi naruszenia zasad kodu, podczas gdy takie naruszenia nie występowały. Zamieniliśmy narzędzie analityczne tego zespołu na dobrze znane standardowe narzędzie branżowe i w pewnym stopniu udało się ograniczyć liczbę fałszywych błędów. Zorganizowaliśmy warsztaty pisania kodu, w trakcie których omówiono i rozwiązano istotne błędy analizy statycznej. Ostatecznie zespół znów zaczął pracować bardzo sprawnie.

Innym ciekawym wnioskiem z analizy było stwierdzenie, że testy jednostkowe aplikacji A obejmują mniej testów pokrycia niż testy aplikacji B i C, a mimo to w zeszłym roku liczba błędów produkcyjnych tej aplikacji była mniejsza. Pisanie testów jednostkowych i przeprowadzanie testów pokrycia jest w porządku. Jednak przywiązywanie nadmiernej wagi do tej aktywności jest mało produktywne z punktu widzenia zespołu i nieprzydatne dla klientów. Wyciągnęliśmy odpowiednie wnioski.

Kluczowe wskaźniki wydajności (KPI)

W kwestii naprowadzania organizacji na właściwy kierunek nie można polegać na opiniach. Najpierw musimy zdefiniować wskaźniki KPI na podstawie naszej wizji sukcesu. Następnie musimy podejmować decyzje oparte na danych, analizując wskaźniki KPI na przestrzeni miesięcy, kwartałów i lat.

Organizacyjne i wydziałowe wskaźniki KPI

Wielokrotnie obserwowaliśmy, jak poszczególne działy definiują własne wskaźniki sukcesu. Dobrze, jeśli działy są świadome oblicza swojego sukcesu, pod warunkiem że przyjęte wskaźniki odpowiadają celom organizacji.

Błędy w testach, środowisku przejściowym i produkcji

Niektóre organizacje wymagają od programistów posiadania środowiska testowego, od działu zapewniania jakości — własnego środowiska przejściowego, a od zespołu odpowiedzialnego za eksploatację systemów informatycznych — własnego środowiska produkcyjnego. Zamiast zasypywania programistów raportami z testów pokrycia przeprowadzanych w ramach testów jednostkowych wykonywanych w środowisku testowym, ważne, aby zapewnić im możliwość cofnięcia się o krok i spojrzenia z szerszej perspektywy na wszystkie środowiska, bez względu na to, czy są ich właścicielami.

Odsetek błędów w środowisku przejściowym wynikających z przeprowadzanych testów wydajności może być wysoki, co może wynikać z niewłaściwych wartości referencyjnych lub powolnego działania kodu. Analiza porównawcza może wykazać, że pipeline'y wykazują błędy przede wszystkim w integracyjnych testach smoke w środowisku produkcyjnym, a to uzasadniałoby przeprowadzenie bliższej analizy. Główną przyczyną mogą być autentyczne błędy w produkcie lub błędy w kodzie testów, niedokładne dane testowe, niepoprawna konfiguracja testowa, nieporozumienia między zespołem produktowym a technicznym itp.

Dalsza analiza może ujawnić powszechne stosowanie nieprawidłowych konfiguracji testów, skłaniając do priorytetowego potraktowania usunięcia tych problemów w celu wyeliminowania częstych błędów przy integracji. Poza tym przyznanie programistom własności kodu w całym procesie, aż do produkcji, jest również zgodne z paradygmatem DevOps.

Wskaźnik stabilności

Po zdefiniowaniu wskaźników KPI bardzo ważne jest dla nas ustalenie, czy pojedynczy wskaźnik wykazuje jakiś trend i skłania się w jednym konkretnym kierunku. Jeśli tak, musimy zrównoważyć go innymi wskaźnikami KPI, które pozwolą przesunąć punkt ciężkości w kierunku środka. Jednym z takich wskaźników KPI jest stabilność.

Do pomiaru stabilności programiści wykorzystują wskaźnik „Czas wdrożenia funkcji”, który oznacza czas potrzebny na aktywne wdrożenie jednej funkcji w środowisku produkcyjnym. Funkcja składa się z wielu commitów, dlatego stosuje się również bardziej szczegółowy wskaźnik „Zaewidencjonowanie do wdrożenia”, który oznacza czas do zaewidencjonowania do aktywnego wdrożenia w środowisku produkcyjnym.

Wskaźnik „Zaewidencjonowanie do wdrożenia” warto mierzyć z wykorzystaniem pipeline'u, ponieważ w przybliżeniu odnosi się on do czasu, jaki w pipelinie zajmuje przepuszczenie kodu od środowiska testowego, poprzez przejściowe, aż do produkcyjnego. Ponadto wskaźnik „Zaewidencjonowanie do wdrożenia” wskazuje również na problemy ze średnim czasem rozstrzygania (MTTR), ponieważ poprawka błędu przechodzi przez ten sam pipeline — od środowiska testowego, poprzez przejściowe, aż po produkcję.

Co ciekawe, w rozmowach z członkami zespołu ds. eksploatacji systemów informatycznych szybkość często budziła negatywne skojarzenia, ponieważ ludzi zachęca się do unikania ryzyka. Zespół mierzy liczbę wad, jakie umknęły uwadze, co stanowi wskaźnik awaryjności, a następnie definiuje stabilność na podstawie odsetka wad wychwyconych przez pipeline, w odróżnieniu od wad, które przemknęły niezauważone.

Firma definiuje stabilność na podstawie zadowolenia klientów lub liczby stałych klientów. Choć brzmi to subiektywnie wartość tego wskaźnika można oszacować w przybliżeniu na podstawie liczby problemów zgłaszanych przez klientów lub ankiet opinii klientów.

Wskaźnik stabilności jest klasycznym przykładem opiniowania zespołów programistycznych, eksploatacyjnych i biznesowych z ich własnej perspektywy, jednak dla organizacji lepiej jest opracować zestaw wskaźników niż polegać na jednym. W związku z tym trzeba opracować bezstronny wskaźnik stabilności dla organizacji.

Wskaźnik jakości kodu

Innym przykładem, w którym należy uwzględnić różne punkty widzenia, jest jakość kodu. Niektórzy twierdzą, że jakość naszego kodu znajduje odzwierciedlenie w testach pokrycia wykonywanych w ramach testów jednostkowych, podczas gdy inni twierdzą, że mamy tu do czynienia ze złożonością cykliczną. Standardowe analizatory statyczne zgłaszają przypadki powielenia kodu, luki w zabezpieczeniach i potencjalne wycieki z pamięci. Wszystkie te dane są autentyczną miarą jakości kodu, dlatego trzeba opracować wskaźnik, w którym te, a być może także inne dane będą uwzględniane.

Biznesowe wskaźniki KPI a techniczne wskaźniki KPI

Innym popularnym wskaźnikiem KPI, który organizacje lubią śledzić, jest wartość dostarczana w trakcie sprintu. Często spotykaną złą praktyką jest rejestrowanie wielu wydań, które same w sobie nie dodają wartości. Można przenosić bity z punktu A do punktu B tak, że wskazówka rozwoju firmy ani drgnie, ale to nie wystarczy. Niektóre organizacje mierzą liczbę nowo dodanych testów w danym sprincie lub całkowitą liczbę wykonanych testów, a to nie odzwierciedla wyników biznesowych, a jedynie nakład prac technicznych. Wartość dostarczana w ramach sprintu musi być adekwatna do działalności.

Do przykładów biznesowych wskaźników KPI można zaliczyć przykładowo liczbę klientów pozyskanych w ostatnim kwartale oraz liczbę reklam klikniętych w zeszłym miesiącu. Pipeline'y nie wpływają bezpośrednio na te wskaźniki biznesowe. Jedynym powodem, dla którego podejmujemy próbę odwzorowania biznesowych wskaźników KPI w technicznych wskaźnikach KPI, jest zrozumienie relacji między rzemieślniczą pracą techniczną a celami biznesowymi.

Odwzorowanie biznesowych wskaźników KPI w pipeline'ach pomaga również w obliczaniu zwrotu z inwestycji dla pipeline'ów. Zespoły kierownicze wykorzystują te wskaźniki, aby poznać możliwe obszary doskonalenia i zaplanować budżet.

Zacznij swoją podróż