Opanowanie wskaźników DORA: praktyczny przewodnik po pomiarze i doskonaleniu dostarczania oprogramowania

Pomiar wskaźników DORA

Gromadzenie danych: ręczne kontra zautomatyzowane

Zautomatyzowane gromadzenie danych to najlepszy sposób na uniknięcie niedokładnych wskaźników, które prowadzą do błędnych decyzji biznesowych. Jednak automatyzacja każdego parametru zaangażowanego w obliczanie wskaźnika może nie być możliwa ze względu na ograniczenia. W takich przypadkach uzgodnij podejście ręczne, które jest rozsądne i zgodne ze standardami branżowymi.

Czas realizacji:

Mierzony na podstawie czasu potrzebnego na przejście funkcji od zgłoszenia biznesowego do wdrożenia na produkcję. Można to zmierzyć za pomocą wielu narzędzi na każdym etapie.

• Automatyzacja testów i wdrożeń (pakiety CI/CD).
• Zmniejszenie rozmiarów partii (mniejsze, częstsze zmiany).
• Usprawnienie procesów przeglądu kodu i zatwierdzania.
• Monitorowanie wąskich gardeł (np. długie cykle QA, ręczne zatwierdzania).

Metoda ręczna:

Gdy wymagane narzędzia/wtyczki nie są dostępne do automatycznego obliczania czasu realizacji, można zastosować ręczne podejście. Możesz ręcznie obliczyć czas realizacji w systemie Azure DevOps (ADO) lub podobnych systemach, używając surowych danych źródłowych. Oto podejście krok po kroku:

Pobieranie danych

• Źródło: zapytanie o elementy pracy w ADO lub interfejs API.

Zakres:

• Filtruj według funkcji/zadań użytkownika oznaczonych jako Ukończone (tj. wdrożone na produkcję).

Wyodrębnij:

• Datę utworzenia (kiedy element pracy został zgłoszony).
• Datę zamknięcia/ukończenia (kiedy oznaczono jako „Ukończone”).

Formuła dla czasu realizacji funkcji lub zadania użytkownika:

• Czas realizacji (dla każdego elementu) = data zamknięcia - data utworzenia

Formuła dla średniej na poziomie projektu

• Średni czas realizacji = suma czasu realizacji dla każdego elementu ÷ całkowita liczba elementów

* Uwaga: w przypadkach, gdy planowane funkcje są tworzone z wyprzedzeniem, wskaźnik czasu realizacji może nie odzwierciedlać rzeczywistości i w takich sytuacjach jako alternatywny wskaźnik można wykorzystać czas cyklu.

Częstotliwość wdrożeń:

• Policz liczbę wdrożeń na produkcję w danym okresie (np. dziennie, tygodniowo lub miesięcznie).

Pobieranie danych:

• Użyj narzędzi CI/CD (np. GitHub Actions), aby rejestrować liczbę wdrożeń.

Formuła dla częstotliwości wdrożeń:

• Całkowita liczba wdrożeń / Liczba miesięcy

Wzór dla średniej na poziomie projektu:

• Liczba wdrożeń projektu / Liczba miesięcy

*Uwaga: Zgodnie z definicją branżową wdrożenia poprawek awaryjnych (Hotfix) są wykluczone z liczby wdrożeń.

Wskaźnik awaryjności zmian (CFR):

Co jest uważane za „nieudane wdrożenie”?

• Wycofania (cofnięcie wydania z powodu problemów).
• Poprawki awaryjne (pilne łatki po wdrożeniu).

Metoda śledzenia:

• Integruj z awariami wdrożeń w piplejnie CI/CD (np. Jenkins, GitHub Actions), aby oznaczać błędy.
• Korzystaj z narzędzi do zarządzania incydentami (np. ADO, Jira, ServiceNow).

 Wzór na wskaźnik awaryjności zmian:

• Liczba nieudanych zmian ÷ Całkowita liczba zmian × 100.

Metoda ręczna:

Do obliczenia liczby nieudanych zmian można wykorzystać liczbę zgłoszeń wsparcia sklasyfikowanych jako „Błąd oprogramowania”. Wartość ta podzielona przez całkowitą liczbę wypuszczonych zmian daje wskaźnik CFR.

Organizacje muszą okresowo klasyfikować incydenty, aby wskaźnik był dokładny.

Średni czas przywracania sprawności (MTTR):

Co jest uważane za „czas odzyskiwania sprawności”?

• Początek: Kiedy wykryto awarię (wyzwolono alert).
• Koniec: Kiedy system zostanie w pełni przywrócony (np. ukończono wycofywanie, wdrożono poprawkę awaryjną).

Metoda śledzenia:

• Narzędzia do zarządzania incydentami (np. ADO, Jira).
• Systemy monitorowania (np. CloudWatch, Prometheus) do rejestrowania czasu rozwiązywania problemów.

Wzór do obliczenia MTTR:

• Suma czasów przywracania ÷ Liczba awarii

Metoda ręczna:

Sumę czasów przywracania można uzyskać na podstawie zgłoszeń wsparcia sklasyfikowanych jako „Błąd oprogramowania”. Jako licznik można wykorzystać różnicę między „Datą utworzenia” a „Datą zamknięcia” w dniach.

Jako mianownik można wykorzystać liczbę incydentów sklasyfikowanych jako „Błąd oprogramowania”.

Łączenie systemów ADO, CI/CD oraz monitorowania

Regularne gromadzenie tych wskaźników i ich optymalizacja pomagają organizacjom osiągnąć wydajność w sposobie, w jaki wdrażają oprogramowanie.

Posiadanie skutecznych narzędzi, wtyczek oraz ich integracja pomagają w automatyzacji większości tych zadań, generowaniu wskaźników i podejmowaniu odpowiednich decyzji.

Azure DevOps (ADO) dostarcza wymagane Metadata do rejestrowania surowych danych na potrzeby obliczania tych wskaźników. Zespół DevOps musi przeprowadzić dokładną ocenę, uwzględniając przyszłe potrzeby biznesowe.

Narzędzia do wizualizacji i pulpity nawigacyjne

Azure DevOps (ADO) oferuje funkcje pulpitów nawigacyjnych wykorzystujące te Metadata oraz widżety do rejestrowania wybranych wskaźników. Jednak dbanie o to, aby dane te były aktualizowane dla każdego elementu pracy, jest niezbędne do generowania dokładnych wskaźników.

Alternatywne narzędzia, takie jak Power BI czy Grafana, mogą być stosowane w celu uzyskania lepszej wizualizacji i raportów dla interesariuszy.

Wyzwania i kwestie do rozważenia dla organizacji

Gromadzenie danych i korzystanie z narzędzi

Integralność danych i ograniczenia narzędzi

Wyzwania:

• Niespójne źródła danych: Pipelines DevSecOps pobierają dane z różnych narzędzi (systemów CI/CD, skanerów, rejestratorów incydentów), co prowadzi do niedopasowanych harmonogramów, fałszywych alarmów lub luk.
• Błąd raportowania ręcznego: Wskaźniki tworzone przez ludzi (np. raporty dotyczące incydentów) często nie są standaryzowane, co zniekształca trendy takie jak MTTR (średni czas naprawy).

Rozwiązanie:

• Wymuszanie śledzenia pochodzenia: Używaj niezmiennych danych Metadata (np. identyfikatorów pipeline'ów w Azure DevOps, zatwierdzeń w systemie Git) do wyodrębniania danych powiązanych ze zmianami w kodzie.
• Weryfikacja za pomocą korelacji między narzędziami: Łączenie danych z narzędzia SonarQube (jakość kodu), ADO w celu oznaczania anomalii oraz standardów branżowych w celu weryfikacji danych o wskaźnikach.

Dostępność narzędzi i wtyczek

Wyzwanie:

• Organizacje mogą nie mieć dostępu do zintegrowanych narzędzi DevSecOps (np. skanerów SAST/DAST, narzędzi śledzących wdrażanie) lub mogą borykać się z wysokimi kosztami licencji.

Rozwiązanie:

• Korzystaj z Azure DevOps Marketplace, aby wyszukiwać wtyczki (np. OWASP ZAP, SonarQube).
• W przypadku ograniczonego budżetu korzystaj z alternatyw o otwartym kodzie źródłowym.

Konfiguracja ADO w celu rejestrowania danych Metadata

Wyzwanie:

• Surowe dane z ADO (kompilacje, wydania, elementy pracy) wymagają odpowiedniego tagowania i łączenia, aby generować wskaźniki takie jak czas realizacji (Lead Time) lub częstotliwość wdrażania.

Rozwiązanie:

• Wymuszaj obowiązkowe pola w elementach pracy oraz okresowe aktualizacje.
• Użyj widoków analitycznych ADO lub łączników Power BI, aby wyszukiwać zapytania w danych Metadata pipeline'u.

Skuteczne aktualizacje w przypadku zmian statusu elementów pracy

Wyzwanie:

• Ręczne aktualizacje statusu (np. z Wykonane na Zatwierdzone) opóźniają wskaźniki takie jak czas cyklu (Cycle Time).

Rozwiązanie:

• Automatyzuj przejścia za pomocą ADO webhooks lub Azure Functions (np. automatyczna aktualizacja po scaleniu PR).
• Przypisz stany do bram DevSecOps (np. stan przeglądu bezpieczeństwa przed wdrożeniem).

Niewystarczająca ilość danych do wygenerowania wskaźników

Wyzwanie:

• Niewielka ilość danych (np. rzadkie wdrożenia, mała liczba incydentów na projekt) wypaczająca trendy.

Rozwiązanie:

• Określ minimalne progi (np. „Śledź tylko wtedy, gdy liczba incydentów w kategorii błędów oprogramowania przekracza 5”).

Wskaźniki, które nie pozwalają na podjęcie decyzji

Wyzwanie:

• Wskaźniki próżności (np. „MTTR wynoszący 120 dni”) nie skłaniają do działania.

Rozwiązanie:

• Skup się na wskaźnikach zorientowanych na rezultaty, popartych wystarczającymi danymi

Opór organizacyjny i niewłaściwe użytkowanie

Opór organizacyjny

Wyzwania:

• Obawa przed ujawnieniem: Zespoły mogą opierać się wskaźnikom, które obnażają nieefektywność (np. wysoki wskaźnik błędów zmian z powodu odrzuceń związanych z bezpieczeństwem).
• Przeładowanie narzędziami: Wprowadzanie nowych narzędzi DevSecOps, zbieranie Metadata oraz wtyczek (np. skanerów SAST) może wywołać sprzeciw, jeśli zostanie uznane za uciążliwe lub niepotrzebne.
• Niezgodne zachęty: Kierownictwo nagradza jeden wskaźnik kosztem innych. Sam „czas realizacji” może wprowadzać w błąd

Strategie mitygacji:

• Traktuj wskaźniki jako narzędzia doskonalenia:
  • Podkreśl, w jaki sposób te wskaźniki pomagają organizacji w dłuższej perspektywie oraz w porównywaniu lub mierzeniu wydajności
• Wskaźniki pilotażowe:
  • Zacznij od projektów o mniejszym znaczeniu krytycznym, aby pokazać wartość przed wdrożeniem w całej organizacji, i skup się na wskaźnikach oferujących wartość biznesową.

Długoterminowe cele organizacji a wyniki wynikające ze wskaźników

Wyzwanie:

• Brak dopasowania: Krótkoterminowa optymalizacja wskaźników (np. poprawa częstotliwości wdrażania) może być sprzeczna z celami długoterminowymi (np. redukcja długu technologicznego, dojrzałość w zakresie zgodności z przepisami).
• Wskaźniki próżności a dostarczanie wartości: Zespoły mogą przedkładać wskaźniki, które dobrze wyglądają, nad znaczące rezultaty.

Rozwiązanie:

Powiąż wskaźniki z tematami strategicznymi:

• Przypisz wskaźniki (np. czas realizacji) do celów biznesowych (np. „Szybsze wprowadzanie na rynek produktów krytycznych pod względem zgodności z przepisami”).

Wyzwanie:

Pułapka wskaźników podczas definiowania mapy drogowej: Zbytnie skupianie się na jednym wskaźniku (np. MTTR) może prowadzić do ignorowania problemów systemowych (np. niewystarczającej automatyzacji testów).

Rozwiązanie:

Zważone portfele wskaźników:

• Zrównoważ wskaźniki z długoterminowymi celami organizacji (np. częstotliwością wdrażania) i stabilnością (wskaźnikiem błędów zmian) kosztem czasu realizacji

Równoważenie wskaźników z kulturą zespołu

Kulturowe ryzyka nadmiernego pomiaru

Wyzwania:

• Strach przed pomiarem: Zespoły mogą postrzegać wskaźniki jako formę inwigilacji, co prowadzi do stresu i wypalenia zawodowego.
• Naginanie systemu: Presja na osiąganie celów (np. częstotliwości wdrażania) może skłaniać do pójścia na skróty (np. pomijania skanów bezpieczeństwa).
• Tłumienie innowacji: Nadmierne skupienie się na wskaźnikach może zniechęcać do eksperymentowania (np. obawa przed nieudanymi wdrożeniami wpływającymi na wskaźnik błędów zmian).

Rozwiązanie:

• Bezpieczeństwo psychologiczne przede wszystkim:
  • Podkreśl, że wskaźniki są narzędziami diagnostycznymi, a nie ocenami wyników.
  • Doceniaj „wyciąganie wniosków z błędów” (np. przeglądy po incydentach, które skracają MTTR).
• Projektowanie wskaźników przez zespół:
  • Zaangażuj inżynierów w wybór wskaźników (np. pozwól im wybrać między czasem realizacji a czasem cyklu jako priorytetem zamiast wskaźnika awaryjności zmian).

Wskaźniki a możliwości zespołu i potrzeby szkoleniowe

Luki w umiejętnościach blokujące wskaźniki

Wyzwanie:

Zespoły nie mają umiejętności poprawy kluczowych wskaźników (np. wolny czas realizacji z powodu nieznajomości narzędzi bezpieczeństwa)

Rozwiązania:

• Segmentacja wskaźników oparta na umiejętnościach:
  • Przykład: Śledź czas realizacji osobno dla zespołów wdrażających nowe narzędzia SAST
• Szkolenia w odpowiednim czasie (Just-in-Time):
  • Automatyzuj wyzwalacze szkoleń (np. jeśli odsetek nieudanych potoków z przyczyn bezpieczeństwa przekracza 15%, przypisz szkolenie modułowe).
• Wskaźniki mentorskie:
  • Mierz odsetek sesji programowania w parach, aby zwiększyć wymianę wiedzy.

Wskaźniki ignorujące rozwój zespołu

Wyzwanie:

• Nadmierny nacisk na wskaźniki wyników (np. częstotliwość wdrażania) nie docenia budowania potencjału.

Rozwiązania:

• Zrównoważenie wskaźników wyników i rozwoju:
  • Połącz częstotliwość wdrażania z odsetkiem zespołu przyczyniającym się do kodu potoku.
• Wskaźniki ścieżki kariery:
  • Przykład: Śledź odsetek inżynierów prowadzących przeglądy bezpieczeństwa, aby zachęcić do poczucia odpowiedzialności.

Piśmiennictwo

• przyspieszyć przez Forsgren, Humble & Kim
• Dokumentacja Azure DevOps
• Raporty z badań i oceny DevOps (DORA)