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

Pomiar wskaźników DORA

Gromadzenie danych: ręczne a automatyczne

Automatyczne gromadzenie danych to najlepszy sposób na uniknięcie niedokładnych wskaźników, które mogą prowadzić do błędnych decyzji biznesowych. Jednak ze względu na pewne ograniczenia automatyzacja wszystkich parametrów branych pod uwagę przy obliczaniu wskaźnika może okazać się niemożliwa. W takich przypadkach należy uzgodnić rozsądne podejście ręczne, zgodne ze standardami branżowymi.

Czas realizacji:

Mierzy się to na podstawie czasu, jaki zajmuje danej funkcji przejście od etapu zgłoszenia biznesowego do wdrożenia produkcyjnego. Można to zmierzyć, wykorzystując różne narzędzia na każdym etapie.

• Zautomatyzuj testowanie i wdrażanie(potoki CI/CD).
• Zmniejszaj wielkość partii(mniejsze zmiany, ale częstsze).
• Usprawnij procesy weryfikacji i zatwierdzania kodu.
• Monitoruj wąskie gardła(np. długie QA , ręczne zatwierdzanie)

Metoda ręczna:

Jeśli nie są dostępne narzędzia lub wtyczki niezbędne do automatycznego obliczania czasu realizacji, można zastosować metodę ręczną. Czas realizacjimożna obliczyćręcznie w Azure DevOps (ADO) lub podobnych systemach , korzystając z wyodrębnionych danych surowych. Oto instrukcja krok po kroku:

Pobieranie danych

• Źródło: Zapytanie o zadania w systemie ADO lub interfejs API.

Zakres:

• Filtruj wedługfunkcji/historii użytkownika oznaczonychjako„Zakończone” (tj. wdrożonych do środowiska produkcyjnego).

Fragment:

• Data utworzenia(data zgłoszenia zadania).
• Data zamknięcia/zakończenia(po zaznaczeniu opcji „Zrobione”).

Wzór na obliczenie czasu realizacji funkcji/historii użytkownika:

• Czas realizacji ( na sztukę) = data zamknięcia – data utworzenia

Wzór na średnią na poziomie projektu

• Średni czas realizacji = Suma (czas realizacji na pozycję) ÷ Łączna liczba pozycji

* Uwaga: W sytuacjach, gdy planowane zadania są tworzone z wyprzedzeniem, wskaźnik czasu realizacji nie odzwierciedla rzeczywistego stanu rzeczy; w takich przypadkach jako alternatywny wskaźnik można wykorzystać czas cyklu.

Częstotliwość wdrażania:

• Zlicz liczbę wdrożeń do środowiska produkcyjnego w danym okresie (np. dziennie, tygodniowo lub miesięcznie).

Pobieranie danych:

• Wykorzystaj narzędzia CI/CD (np. GitHub Actions) do rejestrowania liczby wdrożeń.

Wzór na częstotliwość wdrażania:

• Łączna liczba wdrożeń/ Liczba miesięcy

Wzór na średnią na poziomie projektu:

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

*Uwaga: Zgodnie z definicją branżową wdrożenia poprawek nie są uwzględniane w liczbie wdrożeń.

Wskaźnik awaryjności:

Co uznaje się za „nieudane wdrożenie”?

• Cofnięcia (przywrócenie poprzedniej wersji z powodu problemów).
• Poprawki (pilne aktualizacje wprowadzane po wdrożeniu).

Metoda śledzenia:

• Zintegruj system z mechanizmami sygnalizującymi awarie w procesie wdrażaniaw ramach potoku CI/CD (np. Jenkins, GitHub Actions), aby oznaczać awarie.
• Korzystaj z narzędzi do zarządzaniaincydentami (np. ADO, Jira, ServiceNow).

 Wzór na wskaźnik niepowodzeń zmian:

• Liczba nieudanych zmian ÷ Łączna liczba zmian × 100.

Metoda ręczna:

Aby obliczyć liczbę nieudanych zmian, można wykorzystać liczbę zgłoszeń do pomocy technicznej zaklasyfikowanych jako„błąd oprogramowania”. Wynik tego dzielenia przez całkowitą liczbę wprowadzonych zmian daje nam wskaźnik CFR.

Aby wskaźnik był miarodajny, organizacje muszą regularnie klasyfikować zdarzenia.

Średni czas przywrócenia sprawności (MTTR):

Co zalicza się do „czasu regeneracji”?

• Początek:Po wykryciu awarii (uruchomieniu alarmu).
• Zakończenie:Gdy system zostanie w pełni przywrócony (np. po zakończeniu przywracania stanu poprzedniego lub wdrożeniu poprawki).

Metoda śledzenia:

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

Wzór na obliczenie MTTR:

• Suma czasów przywracania / Liczba awarii

Metoda ręczna:

Sumę czasu przywrócenia sprawności można obliczyć na podstawie zgłoszeń do pomocy technicznej sklasyfikowanych jako„błąd oprogramowania”. Jako licznik można wykorzystać różnicę w dniach między „datą utworzenia” a „datą zamknięcia”.

Jako mianownik można wykorzystać liczbę zdarzeń zaklasyfikowanych jako„błąd oprogramowania”.

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

Okresowe gromadzenie tych wskaźników i ich optymalizacja pomagają organizacjom osiągnąć większą wydajność w procesie wdrażania oprogramowania.

Dysponowanie skutecznymi narzędziami i wtyczkami oraz ich integracja pozwala zautomatyzować większość tych zadań, generować wskaźniki i podejmować właściwe decyzje.

Azure DevOps (ADO) udostępnia niezbędne metadata do gromadzenia surowych danych służących do obliczania tych wskaźników. Zespół DevOps musi dokonać starannej oceny, biorąc pod uwagę przyszłe potrzeby biznesowe.

Narzędzia do wizualizacji i pulpity nawigacyjne

Azure DevOps (ADO) oferuje funkcje pulpitu nawigacyjnego wraz z tymi metadata i widżetami do rejestrowania niektórych z tych wskaźników. Jednak zapewnienie aktualizacji metadata dla każdego elementu pracy jest niezbędne do generowania dokładnych wskaźników.

W celu zapewnienia lepszej wizualizacji i tworzenia raportów dla interesariuszy można wykorzystać alternatywne narzędzia , takie jak Power BI czy Grafana.

Wyzwania i kwestie, które organizacje powinny wziąć pod uwagę

Gromadzenie danych i korzystanie z narzędzi

Integralność danych i ograniczenia narzędzi

Wyzwania:

• Niespójne źródła danych:Potoki DevSecOps pobierają dane z różnych narzędzi (systemy CI/CD, skanery, systemy śledzenia incydentów), co prowadzi do rozbieżności w osiach czasu, fałszywych alarmów lub luk w danych.
• Błąd wynikający z ręcznego raportowania:Wskaźniki opracowywane ręcznie (np. zgłoszenia incydentów) często nie są ujednolicone, co zniekształca trendy, takie jakMTTR(średni czas przywrócenia sprawności).

Rozwiązanie:

• Zapewnij identyfikowalność:Wykorzystaj niezmienne metadata np.identyfikatory potoków w Azure DevOps, zatwierdzenia w Git) do pozyskiwania danych dotyczących zmian w kodzie.
• Weryfikacja poprzez korelację między narzędziami:połączenie danych z SonarQube (jakość kodu), ADO w celu wykrywania anomalii oraz standardów branżowych w celu weryfikacji danych metrycznych

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 do śledzenia wdrożeń) lub borykać się z problemem kosztów licencji.

Rozwiązanie:

• Skorzystaj zplatformy Azure DevOps Marketplace, aby znaleźć wtyczki (np.OWASP ZAP,SonarQube).
• W przypadku ograniczonego budżetu warto korzystać zrozwiązań open source.

Konfiguracja ADO do przechwytywania Metadata

Wyzwanie:

• Surowe dane ADO (kompilacje, wydania, elementy pracy) wymagają odpowiedniego oznaczania tagami/powiązania, aby można było generować wskaźniki, takie jakczas realizacjiczyczęstotliwość wdrażania.

Rozwiązanie:

• Wymuszanie wypełniania pól obowiązkowychw zadaniach oraz okresowych aktualizacji
• Aby uzyskać dostęp do metadata potoku, należy skorzystać zwidoków ADO Analyticslubłączników Power BI.

Skuteczne aktualizacje dotyczące zmian stanu elementów pracy

Wyzwanie:

• Ręczne zmiany statusu (np. „Zakończone” → „Zatwierdzone”) opóźniają wskaźniki takie jakczas cyklu.

Rozwiązanie:

• Zautomatyzuj procesy przejścioweza pomocąwebhookówADO lubfunkcji Azure(np. automatyczna aktualizacja po scaleniu pull requestów).
• Przyporządkuj etapy dopunktów kontrolnych DevSecOps(np. etap przeglądu bezpieczeństwa przed wdrożeniem).

Brak wystarczających danych do wygenerowania wskaźników

Wyzwanie:

• Nieliczne dane (np. rzadkie wdrożenia, mała liczba zdarzeń w ramach projektu) zniekształcają trendy.

Rozwiązanie:

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

Wskaźniki, które nie dostarczają wystarczających podstaw do podjęcia decyzji

Wyzwanie:

• Wskaźniki pozorne (np. „MTTR wynoszący 120 dni”) nie skłaniają do działania.

Rozwiązanie:

• Skup się nawskaźnikach zorientowanych na wyniki, popartych wystarczającymi danymi

Opór organizacyjny i nadużycia

Opór organizacyjny

Wyzwania:

• Obawa przed ujawnieniem:zespoły mogą niechętnie podchodzić do wskaźników, które uwidaczniają nieefektywność (np. wysokiwskaźnik niepowodzeń zmianspowodowany odrzuceniami ze względów bezpieczeństwa).
• Nadmiar narzędzi:Wprowadzenie nowych narzędzi DevSecOps, metadata gromadzenia metadata oraz wtyczek (np. skanerów SAST) może wywołać opór, jeśli zostaną one odebrane jako zakłócające pracę lub zbędne.
• Niewłaściwie ukierunkowane zachęty:kierownictwo premiuje jeden wskaźnik kosztem innych. Sam „czas realizacji” może wprowadzać w błąd

Strategie ograniczania skutków:

• Wskaźniki ramowe jako narzędzia usprawniające:
  • Należy podkreślić, w jaki sposób wskaźniki te pomagają organizacji w dłuższej perspektywie oraz umożliwiają porównywanie i mierzenie wyników
• Wskaźniki pilotażowe:
  • Zacznij od projektów o mniejszym znaczeniu, aby wykazać korzyści przed wdrożeniem w całej organizacji, i skup się na wskaźnikach, które odzwierciedlają wartość biznesową.

Długoterminowe cele organizacji a wyniki oparte na wskaźnikach

Wyzwanie:

• Rozbieżność:Krótkoterminowa optymalizacja wskaźników (np. zwiększenieczęstotliwości wdrażania) może kolidować z celami długoterminowymi (np. redukcja długu technologicznego, dojrzałość w zakresie zgodności z przepisami).
• Wskaźniki pozorne a dostarczanie wartości:Zespoły mogą przedkładać wskaźniki, które dobrze wyglądają, nad rzeczywiste wyniki.

Rozwiązanie:

Powiązanie wskaźników z tematami strategicznymi:

• Należy powiązać wskaźniki (np.czas realizacji) z celami biznesowymi (np. „Szybsze wprowadzanie na rynek produktów, w przypadku których zgodność z przepisami ma kluczowe znaczenie”).

Wyzwanie:

Pułapka związana z wskaźnikami podczas opracowywania planu działania: Nadmierne skupienie się na jednym wskaźniku (np.MTTR) może prowadzić do pominięcia problemów systemowych (np. niewystarczającej automatyzacji testów).

Rozwiązanie:

Portfele oparte na wskaźnikach ważonych:

• Należy pogodzić wskaźniki z długoterminowymi celami organizacji (np. częstotliwością wdrażania), stabilnością (wskaźnikiem niepowodzeń zmian) oraz czasem realizacji

Równowaga między wskaźnikami a kulturą zespołu

Ryzyko kulturowe związane z nadmiernym stosowaniem wskaźników

Wyzwania:

• Strach przed oceną:Zespoły mogą postrzegać wskaźniki jako formę nadzoru, co prowadzi do stresu i wypalenia zawodowego.
• Obejście systemu:Presja związana z koniecznością osiągnięcia wyznaczonych celów (np.częstotliwości wdrażania) może skłaniać do stosowania skrótów (np. pomijania skanów bezpieczeństwa).
• Tłumienie innowacji:Nadmierne skupianie się na wskaźnikach może zniechęcać do eksperymentowania (np. obawa, że nieudane wdrożenia wpłyną nawskaźnik niepowodzeń zmian).

Rozwiązanie:

• Bezpieczeństwo psychologiczne przede wszystkim:
  • Należy podkreślić, że wskaźniki sąnarzędziami diagnostycznymi, a nie służą do oceny wyników.
  • Doceniaj „uczenie się na błędach” (np. analizy po incydentach, które skracająśredni czas naprawy).
• Projektowanie wskaźników pod kierownictwem zespołu:
  • Należy zaangażować inżynierów w wybór wskaźników (np. pozwolić im wybrać, czy priorytetem będzie dla nichczas realizacjiczyczas cyklu, a nie wskaźnik niepowodzeń zmian).

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

Luki w możliwościach uniemożliwiające stosowanie wskaźników

Wyzwanie:

Zespołom brakuje umiejętności niezbędnych do poprawy kluczowych wskaźników (np. długiczas realizacji zleceniaspowodowany nieznajomością narzędzi bezpieczeństwa)

Rozwiązania:

• Segmentacja oparta na wskaźnikach umiejętności:
  • Przykład: Oddzielne śledzenieczasu realizacjidla zespołów wdrażających nowe narzędzia SAST
• Szkolenia na bieżąco:
  • Zautomatyzuj wyzwalacze szkoleń (np. jeśliwskaźnik niepowodzeń w potoku spowodowanych problemami z bezpieczeństwemprzekroczy 15%, przypisz szkolenie modułowe).
• Wskaźniki dotyczące mentoringu:
  • Zmierz odsetek sesji programowania w parach, aby zwiększyć wymianę wiedzy.

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

Wyzwanie:

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

Rozwiązania:

• Równowaga między wynikami a wskaźnikami wzrostu:
  • Porównajczęstotliwość wdrażaniaz odsetkiem członków zespołu uczestniczących w tworzeniu kodu w ramach procesu.
• Wskaźniki dotyczące ścieżki kariery:
  • Przykład: Śledź odsetek inżynierów kierujących przeglądami bezpieczeństwa, aby wzmocnić ich poczucie odpowiedzialności.

Referencje

• przyspieszyć Forsgrena, Humble’a i Kima
• Dokumentacja Azure DevOps
• Raporty z badań i oceny DevOps (DORA)