Szablon danych cyklu wytwarzania oprogramowania

Azure DevOps
Szablon danych cyklu wytwarzania oprogramowania

Szablon danych cyklu wytwarzania oprogramowania

Ten szablon pokazuje, jak przygotować dane dotyczące cyklu wytwarzania oprogramowania do analizy process mining. Zawiera listę potrzebnych atrybutów, najważniejszych działań do śledzenia oraz praktyczne wskazówki dotyczące pobierania danych z Azure DevOps. Dzięki niemu można odpowiednio uporządkować dane przed analizą i usprawnianiem procesu.
  • Zalecane atrybuty do zebrania
  • Najważniejsze działania do śledzenia w SDLC
  • Szczegółowe wskazówki dotyczące pobierania danych z Azure DevOps
Pierwszy raz spotykają się Państwo z dziennikiem zdarzeń? Dowiedz się jak utworzyć dziennik zdarzeń na potrzeby process mining.

Atrybuty cyklu wytwarzania oprogramowania

To zalecane pola danych, które warto uwzględnić w dzienniku zdarzeń, aby analizować i usprawniać cykl wytwarzania oprogramowania.
5 Wymagane 7 Zalecane 6 Opcjonalne
Nazwa Opis
Czas zdarzenia
EventTime
Dokładny znacznik czasu wskazujący, kiedy wystąpiło dane działanie lub zdarzenie dotyczące elementu prac programistycznych.
Opis

Czas zdarzenia określa datę i godzinę każdego działania w cyklu życia prac programistycznych. Ten znacznik czasu pozwala uporządkować zdarzenia chronologicznie i obliczyć odstępy między nimi.

Atrybut ten służy do obliczania wszystkich wskaźników opartych na czasie, w tym czasu cyklu, czasu realizacji i czasu oczekiwania. Umożliwia utworzenie uporządkowanego chronologicznie dziennika zdarzeń, który jest niezbędnym źródłem danych dla każdej analizy process mining. Pomaga wykrywać opóźnienia, mierzyć wyniki względem SLA i śledzić zmiany w czasie.

Dlaczego to ważne

Znacznik czasu określa kolejność zdarzeń, co jest niezbędne do obliczania wszystkich wskaźników KPI opartych na czasie oraz analizy przebiegu procesu i wąskich gardeł.

Skąd pobrać

To wartość „Changed Date” przypisana do każdej aktualizacji w historii elementu pracy. W przypadku zdarzeń zewnętrznych, takich jak kompilacje lub wdrożenia, jest to znacznik czasu ich zakończenia.

Przykłady
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-10-28T09:00:00Z
Element prac programistycznych
DevelopmentItem
Unikatowy identyfikator pojedynczej jednostki pracy, takiej jak funkcja, błąd lub historyjka użytkownika. Pełni rolę identyfikatora case w procesie.
Opis

Element prac programistycznych to odrębna jednostka pracy śledzona w Azure DevOps. Każdy element ma unikatowy identyfikator i stanowi główny obiekt, wokół którego przebiegają wszystkie działania w procesie: od utworzenia i planowania, przez programowanie i testowanie, po wdrożenie.

W analizie process mining ten atrybut służy do łączenia powiązanych zdarzeń w jeden przebieg case. Pozwala odtworzyć pełny cykl życia każdego elementu pracy oraz analizować czas cyklu, odstępstwa od procesu i pętle poprawek dla poszczególnych elementów.

Dlaczego to ważne

To podstawowy identyfikator, który łączy wszystkie etapy procesu w jeden spójny case i umożliwia analizę całego cyklu życia oprogramowania.

Skąd pobrać

Odpowiada polu „ID” elementu pracy w Azure DevOps Boards. Można go pobrać za pomocą Azure DevOps REST API dla Work Item Tracking.

Przykłady
10234102351023610237
Nazwa działania
ActivityName
Nazwa konkretnego zdarzenia lub zadania, które wystąpiło w danym momencie cyklu życia elementu pracy.
Opis

Nazwa działania określa konkretny krok lub etap procesu, na przykład „Rozpoczęcie prac programistycznych”, „Utworzenie pull request” lub „Wdrożenie na produkcję”. Działania ustala się na podstawie zmian stanu elementu pracy, powiązanych zdarzeń, takich jak kompilacje lub pull request, oraz zdarzeń niestandardowych.

Ten atrybut jest niezbędny do utworzenia mapy procesu, która przedstawia przebieg workflow. Analitycy mogą dzięki niej poznać kolejność zdarzeń, wskazać typowe ścieżki, wykryć wąskie gardła między działaniami i sprawdzić, jak często występuje każdy krok.

Dlaczego to ważne

Określa kroki procesu i stanowi podstawę mapy procesu. Umożliwia analizę workflow, wąskich gardeł i odstępstw.

Skąd pobrać

Zazwyczaj atrybut ustala się na podstawie zmian pola „State” elementu pracy lub powiązanych zdarzeń, takich jak kompilacje, commity i pull request. Surowe dane o tych zdarzeniach znajdują się w historii elementu pracy.

Przykłady
Rozpoczęcie prac programistycznychZakończenie pull requestNiepowodzenie testów QAWdrożenie na produkcjęZamknięcie elementu pracy
Data ostatniej aktualizacji danych
LastDataUpdate
Znacznik czasu wskazujący, kiedy ostatnio odświeżono dane procesu z systemu źródłowego.
Opis

Ten atrybut zapisuje datę ostatniego pobrania i aktualizacji zbioru danych z Azure DevOps. Informuje, jak aktualne są dane i jaki okres obejmuje analiza.

Przy podejmowaniu decyzji na podstawie analizy procesu ważne jest, by wiedzieć, jak świeże są dane. Znacznik czasu pozwala ustalić, czy analizowane są informacje bieżące, czy historyczne, co wpływa na aktualność wniosków.

Dlaczego to ważne

Informuje o aktualności danych, dzięki czemu wiadomo, jakiego okresu dotyczą analizy i podejmowane na ich podstawie decyzje.

Skąd pobrać

To znacznik czasu metadanych generowany i zapisywany podczas procesu pobierania, przekształcania i ładowania danych (ETL).

Przykłady
2024-05-20T08:00:00Z
System źródłowy
SourceSystem
System, z którego pobrano dane o procesie, w tym przypadku Azure DevOps.
Opis

Ten atrybut wskazuje system źródłowy danych. Jest szczególnie przydatny, gdy w celu uzyskania szerszego obrazu procesu łączy się dane z wielu systemów. W tym modelu jego wartością jest zawsze Azure DevOps.

W analizie obejmującej jeden system może wydawać się niezmienny, ale dostarcza ważnych informacji o pochodzeniu danych. Ma to znaczenie dla zarządzania danymi, rozwiązywania problemów i przyszłej integracji z innymi systemami, takimi jak ServiceNow lub SAP.

Dlaczego to ważne

Informuje o pochodzeniu danych, co ma znaczenie dla zarządzania danymi, ich weryfikacji i analizy procesów obejmującej wiele systemów.

Skąd pobrać

To stała wartość dodawana podczas pobierania i przekształcania danych, aby oznaczyć zbiór danych.

Przykłady
Azure DevOps
Czas zakończenia
EndTime
Znacznik czasu wskazujący, kiedy zakończono działanie. Służy do obliczania czasu jego realizacji.
Opis

Czas zakończenia wyznacza koniec działania. W wielu dziennikach zdarzeń za czas zakończenia poprzedniego działania przyjmuje się czas rozpoczęcia kolejnego. Osobny znacznik czasu zakończenia pozwala jednak dokładniej obliczyć zarówno czas realizacji działania, jak i przestój między działaniami.

Ten atrybut jest niezbędny do obliczania KPI ProcessingTime i szczegółowej analizy wąskich gardeł. Pozwala odróżnić czas aktywnej pracy nad zadaniem od czasu oczekiwania na rozpoczęcie kolejnego kroku. To ważne w dashboardzie Stage Handoff Analysis.

Dlaczego to ważne

Pozwala dokładnie obliczyć czas realizacji działań i przestoje, co jest podstawą analizy wąskich gardeł i poprawy efektywności.

Skąd pobrać

Często wartość jest wyliczana. Może nią być czas rozpoczęcia kolejnego zdarzenia w tym samym case albo jawnie zapisany czas, jeśli system źródłowy rejestruje zarówno początek, jak i koniec zadania.

Przykłady
2023-10-26T18:00:00Z2023-10-27T15:00:00Z2023-10-28T11:00:00Z
Czy ponownie wykonano pracę
IsRework
Wartość logiczna określająca, czy element pracy wrócił na wcześniejszy etap cyklu życia.
Opis

Wartość tego atrybutu jest ustawiana na true, jeśli element pracy wraca do wcześniejszego etapu, na przykład ze stanu „Testy QA zakończone” do „Rozpoczęto prace programistyczne”. Atrybut jest obliczany na podstawie kolejności działań w danym case i wykrytych odstępstw od liniowego przebiegu.

Ten atrybut jest niezbędny w dashboardzie częstotliwości poprawek i ponownych testów oraz w KPI częstotliwości powrotów do wcześniejszych etapów. Ułatwia filtrowanie i mierzenie poprawek, a także wskazywanie problemów z jakością, komunikacją lub testowaniem, które obniżają wydajność.

Dlaczego to ważne

Bezpośrednio wskazuje i mierzy poprawki, pomagając wykrywać problemy z jakością i nieefektywne elementy procesu, które wydłużają czas cyklu.

Skąd pobrać

To obliczany atrybut, wyznaczany na podstawie kolejności działań w dzienniku zdarzeń dla każdego case.

Przykłady
truefalse
Nazwa zespołu
TeamName
Nazwa zespołu programistycznego odpowiedzialnego za dany element pracy.
Opis

Nazwa zespołu wskazuje, do którego zespołu przypisano dany element pracy. W Azure DevOps prace często są podzielone między zespoły, które mogą stanowić część większego projektu.

Dzięki temu atrybutowi można analizować procesy osobno dla każdego zespołu. Ułatwia porównywanie przebiegu pracy i wyników zespołów, znajdowanie dobrych praktyk w zespołach osiągających lepsze wyniki oraz wskazywanie zespołów, które potrzebują wsparcia lub zmian w procesie.

Dlaczego to ważne

Umożliwia porównywanie zespołów, wykrywanie różnic w wynikach i dzielenie się dobrymi praktykami w całej organizacji.

Skąd pobrać

Często jest ustalana na podstawie pola „Area Path” elementu pracy, ponieważ w Azure DevOps zespoły są zwykle przypisane do określonych ścieżek obszaru.

Przykłady
Zespół PhoenixDrużyna OmegaZespół Platform CoreZespół Frontend
Priorytet
Priority
Liczbowa lub opisowa ocena ważności elementu pracy w porównaniu z innymi elementami.
Opis

Priorytet określa, jak pilnie należy zaplanować realizację elementu pracy. Elementy o wyższym priorytecie powinny być obsługiwane szybciej niż te o niższym. Często stosuje się wartości liczbowe, na przykład 1, 2, 3 i 4, gdzie 1 oznacza najwyższy priorytet.

Ten atrybut jest niezbędny w dashboardzie przepustowości i czasu cyklu według priorytetu. Analiza tych danych pozwala ocenić, czy system priorytetyzacji działa: czy elementy o wysokim priorytecie rzeczywiście przechodzą przez proces szybciej niż pozostałe.

Dlaczego to ważne

Pozwala sprawdzić, czy proces przyspiesza obsługę elementów o wysokim priorytecie. To ważny sposób oceny skuteczności przyjętych zasad priorytetyzacji.

Skąd pobrać

Odpowiada polu „Priority” elementu pracy w Azure DevOps.

Przykłady
1234
Przypisano do
AssignedTo
Użytkownik lub członek zespołu, do którego obecnie przypisano element prac programistycznych.
Opis

Ten atrybut wskazuje osobę odpowiedzialną za element pracy na danym etapie procesu. Przypisanie może się zmieniać w trakcie cyklu życia elementu, na przykład z programisty na testera, a następnie na menedżera wydań.

Analiza według pola „Assigned To” jest niezbędna w dashboardzie Developer and Tester Workload Overview. Pomaga zrozumieć przydział zasobów, wykryć przeciążonych członków zespołu i porównać wyniki poszczególnych osób lub zespołów.

Dlaczego to ważne

Umożliwia analizę wykorzystania zasobów, pomaga zrozumieć rozkład obciążenia, wykryć wąskie gardła związane z konkretnymi zasobami i zarządzać możliwościami zespołu.

Skąd pobrać

Odpowiada polu „Assigned To” elementu pracy w Azure DevOps. Wartość dla każdego zdarzenia odczytuje się z historii elementu pracy.

Przykłady
jane.doe@example.comjohn.smith@example.comnieprzypisany
Stan
State
Bieżący status elementu pracy w workflow, na przykład „Nowy”, „Aktywny”, „Rozwiązany” lub „Zamknięty”.
Opis

Atrybut State określa formalny status elementu pracy w danym momencie, zgodnie z szablonem procesu projektu. Zmiany stanu są głównym źródłem działań rejestrowanych w dzienniku zdarzeń.

Atrybut Activity często opisuje zmianę stanu dokładniej, ale surowy atrybut State przydaje się do filtrowania i analizy. Pozwala sprawdzić, ile czasu elementy pracy spędzają w poszczególnych stanach. Jest też podstawą dashboardu czasu trwania etapów i analizy przekazywania pracy.

Dlaczego to ważne

Określa status elementu pracy w cyklu życia. To ważna informacja przy analizie przepływu procesu i obliczaniu czasu spędzonego na poszczególnych etapach.

Skąd pobrać

Odpowiada polu „State” elementu pracy w Azure DevOps.

Przykłady
NowyAktywnyW testach QARozwiązanyZamknięty
Typ elementu pracy
WorkItemType
Klasyfikacja elementu prac programistycznych, na przykład błąd, funkcja, historyjka użytkownika lub zadanie.
Opis

Typ elementu pracy określa charakter realizowanych prac. Różne typy elementów często przebiegają innymi ścieżkami procesu i podlegają innym oczekiwaniom dotyczącym wyników lub SLA. Na przykład błąd może być obsługiwany szybciej niż funkcja.

Ten atrybut jest niezbędny do porównań. Pozwala filtrować mapę procesu lub wskaźniki KPI według typu pracy i sprawdzić, czy obsługa błędów jest sprawniejsza niż realizacja funkcji. Umożliwia też śledzenie historycznych zmian czasu cyklu dla różnych kategorii prac.

Dlaczego to ważne

Pozwala podzielić analizę procesu na kategorie i porównać przebieg workflow oraz wyniki dla różnych rodzajów prac, takich jak błędy i funkcje.

Skąd pobrać

Odpowiada polu „Work Item Type” elementu pracy w Azure DevOps.

Przykłady
BłądFunkcjaHistoryjka użytkownikaZadanie
Czas oczekiwania na akceptację
ApprovalWaitingTime
Czas, przez jaki element pracy czeka na akceptację po złożeniu wniosku.
Opis

Ten wskaźnik mierzy czas oczekiwania na akceptację. Przykładem jest okres od „Rozpoczęto UAT” do „Zatwierdzono UAT”. Dla danego case oblicza się go, mierząc czas między tymi dwoma działaniami.

Ten obliczany atrybut bezpośrednio zasila dashboard analizy czasu oczekiwania na akceptację i powiązany z nim KPI. Wyodrębnienie tych opóźnień pozwala zespołom usprawniać komunikację i podejmowanie decyzji, skracać czas bezczynności i przyspieszać cały cykl.

Dlaczego to ważne

Mierzy opóźnienia wynikające z oczekiwania na decyzje lub akceptację, wskazując możliwości usprawnienia komunikacji i podejmowania decyzji.

Skąd pobrać

Oblicza się go, wyszukując w dzienniku zdarzeń określone działania rozpoczynające i kończące oczekiwanie na akceptację, na przykład „Rozpoczęto UAT” i „Zatwierdzono UAT”, a następnie mierząc różnicę czasu.

Przykłady
3 dni 2 godziny1 dzień 8 godzin 30 minut4 godziny
Czas przekazania między etapami
StageHandoffTime
Czas bezczynności między zakończeniem jednego głównego etapu a rozpoczęciem kolejnego.
Opis

Czas przekazania między etapami mierzy oczekiwanie między kolejnymi etapami procesu, na przykład od „Zakończono prace programistyczne” do „Rozpoczęto testy QA”. Oblicza się go, identyfikując te przejścia i mierząc odstęp między zakończeniem pierwszego działania a rozpoczęciem drugiego.

Ten wskaźnik jest podstawą dashboardu czasu trwania etapów i analizy przekazywania pracy. Pomiar czasu przekazania pozwala wykrywać ukryte wąskie gardła, w których praca czeka bezczynnie, często z powodu braku dostępnych zasobów, opóźnień w komunikacji lub nieefektywnego procesu.

Dlaczego to ważne

Mierzy czas oczekiwania między etapami procesu, ujawniając ukryte wąskie gardła i opóźnienia niezwiązane z aktywną pracą.

Skąd pobrać

To obliczany atrybut. Wymaga wskazania par kolejnych działań oznaczających przekazanie pracy, a następnie obliczenia różnicy czasu między nimi.

Przykłady
2 godziny 15 minut1 dzień 4 godziny30 minut
Identyfikator pull requestu
PullRequestId
Identyfikator pull requestu powiązanego z elementem pracy.
Opis

Ten atrybut łączy element pracy z konkretnym pull requestem, który służy do zgłaszania i przeglądania zmian w kodzie. Jeden element pracy może być powiązany z kilkoma pull requestami.

Identyfikator pull requestu pozwala szczegółowo analizować przegląd i integrację kodu. Można mierzyć czas od utworzenia pull requestu do jego zamknięcia oraz sprawdzać, jak często pull requesty są odrzucane lub wymagają dużych zmian. Może to wskazywać na problemy z jakością kodu albo niejasne wymagania.

Dlaczego to ważne

Łączy prace programistyczne z konkretnymi przeglądami kodu, umożliwiając szczegółową analizę integracji kodu i zapewniania jakości.

Skąd pobrać

Informacje te znajdują się w sekcji „Links” lub „Development” elementu pracy w Azure DevOps.

Przykłady
452145334589
Nazwa projektu
ProjectName
Nazwa projektu Azure DevOps, do którego należy dany element pracy.
Opis

Ten atrybut wskazuje projekt w organizacji Azure DevOps, w którym znajduje się dany element pracy. Daje ogólny kontekst, szczególnie w organizacjach prowadzących wiele projektów.

Nazwa projektu to ważny wymiar filtrowania i porównań. W dashboardzie historycznych trendów czasu cyklu pozwala analizować dane osobno dla każdego projektu. Można dzięki temu sprawdzić, które projekty działają sprawniej, a także ocenić wpływ zmian wprowadzonych w procesie.

Dlaczego to ważne

Pozwala grupować dane do analizy oraz porównywać wyniki i trendy w różnych projektach.

Skąd pobrać

Odpowiada polu „Team Project” elementu pracy w Azure DevOps.

Przykłady
Platforma e-commercePonowne uruchomienie aplikacji mobilnejModernizacja hurtowni danych
Ścieżka iteracji
IterationPath
Sprint lub inny ograniczony czasowo okres prac, do którego przypisano element pracy.
Opis

Ścieżka iteracji, czyli sprint, oznacza określony przedział czasu przeznaczony na prace programistyczne. Elementy pracy przypisuje się do iteracji, aby zrealizować je w tym czasie.

Analiza według ścieżki iteracji pozwala oceniać przebieg procesu sprint po sprincie. Można śledzić zmiany czasu cyklu, analizować zadania przenoszone do kolejnych sprintów i oceniać przewidywalność planowania.

Dlaczego to ważne

Umożliwia analizę sprintów i ocenę wyników zespołu w czasie, co pomaga doskonalić praktyki zwinne.

Skąd pobrać

Odpowiada polu „Iteration Path” elementu pracy w Azure DevOps.

Przykłady
Platforma e-commerce\Sprint 12Platforma e-commerce\Sprint 13Ponowne uruchomienie aplikacji mobilnej\Etap 2\Sprint 4
Waga błędu
Severity
Określa wpływ błędu lub problemu na system albo użytkowników końcowych.
Opis

Waga błędu służy do określenia jego wpływu, od krytycznych awarii systemu po drobne usterki wizualne. Różni się od priorytetu, który określa kolejność pracy. Błąd o dużej wadze może mieć niski priorytet, jeśli istnieje łatwo dostępne obejście.

Ten atrybut dostarcza dodatkowego wymiaru analizy, szczególnie w dashboardzie przepustowości i czasu cyklu według priorytetu. Pozwala sprawdzić na przykład, czy najpierw naprawiane są błędy o największym wpływie, i lepiej ocenić ryzyko związane z realizowanymi pracami.

Dlaczego to ważne

Pozwala klasyfikować elementy pracy według ich wpływu na działalność firmy i sprawdzić, jak skutecznie zespół rozwiązuje problemy o dużym znaczeniu.

Skąd pobrać

Odpowiada polu „Severity” elementu pracy, zwykle dotyczącego błędów, w Azure DevOps.

Przykłady
1 - Krytyczny2 - Wysoki3 - Średni4 - Niski
Wymagane Zalecane Opcjonalne

Działania w cyklu wytwarzania oprogramowania

To najważniejsze kroki procesu i kamienie milowe, które warto rejestrować w dzienniku zdarzeń, aby prawidłowo odkrywać przebieg procesu i wykrywać wąskie gardła.
7 Zalecane 8 Opcjonalne
Działanie Opis
Rozpoczęcie prac programistycznych
To działanie oznacza, że programista rozpoczął pracę nad elementem. Rozpoznaje się je po zmianie jego stanu na „Active”, „In Progress” lub „Committed”.
Dlaczego to ważne

Oznacza początek aktywnego etapu prac programistycznych. Analiza czasu od stanu „Created” do „Development Started” pokazuje, jak długo elementy oczekują w backlogu.

Skąd pobrać

Zdarzenie ustala się na podstawie historii elementu pracy, gdy pole System.State zmienia się ze stanu „New” lub „Approved” na „In Progress”.

Rejestrowanie

Zdarzenie ustala się po zmianie pola State na „Active” lub „In Progress”.

Typ zdarzenia inferred
Rozpoczęcie testów QA
Oznacza początek formalnego etapu testów zapewnienia jakości. Zdarzenie rozpoznaje się, gdy stan elementu pracy zmienia się na „In QA”, „Testing” lub podobną wartość.
Dlaczego to ważne

Oznacza początek cyklu QA. Analiza czasu trwania tego etapu pomaga wykryć wąskie gardła i ocenić sprawność testowania.

Skąd pobrać

Zdarzenie ustala się na podstawie historii elementu pracy, śledząc zmianę pola System.State na „In QA” lub inny wyznaczony stan testowania.

Rejestrowanie

Zdarzenie ustala się po zmianie pola State na „In QA” lub „Testing”.

Typ zdarzenia inferred
Utworzenie elementu pracy
To działanie rozpoczyna cykl wytwarzania oprogramowania i oznacza utworzenie nowego elementu pracy, na przykład User Story, błędu lub zadania. Zdarzenie jest rejestrowane w chwili zapisania nowego rekordu w Azure DevOps Boards.
Dlaczego to ważne

To główne zdarzenie rozpoczynające proces. Jest niezbędne do pomiaru czasu realizacji od początku do końca oraz ustalenia, skąd napływają prace.

Skąd pobrać

Zdarzenie odczytuje się z pola „Created Date” elementu pracy. Tabela historii elementu rejestruje również tę początkową zmianę stanu.

Rejestrowanie

Wartość pochodzi z pola „Created Date” elementu pracy.

Typ zdarzenia explicit
Utworzenie pull request
Oznacza, że programista zakończył wstępne prace nad kodem i przekazał zmiany do przeglądu w pull request. Zdarzenie łączy element pracy z konkretną zmianą kodu w Azure Repos.
Dlaczego to ważne

To ważny moment przekazania pracy z programowania do przeglądu kodu. Śledzenie tego zdarzenia pozwala mierzyć czas kodowania i ustalić, kiedy kod jest gotowy do oceny przez innych członków zespołu.

Skąd pobrać

Zdarzenie odczytuje się z danych Azure Repos, łącząc utworzenie pull request z powiązanym elementem pracy. Zazwyczaj programista tworzy takie powiązanie bezpośrednio.

Rejestrowanie

Zdarzenie utworzenia pull request w Azure Repos powiązanego z elementem pracy.

Typ zdarzenia explicit
Wdrożenie na produkcję
Oznacza pomyślne wdrożenie powiązanego z elementem pracy kodu w środowisku produkcyjnym. Azure Pipelines rejestruje to zdarzenie w dziennikach wydań.
Dlaczego to ważne

To ważny etap oznaczający dostarczenie rozwiązania. Stanowi punkt końcowy przy obliczaniu czasu realizacji i czasu cyklu.

Skąd pobrać

Zdarzenie odczytuje się z danych pipeline wydania w Azure Pipelines, a konkretnie z informacji o zakończeniu wdrożenia na etap „Production” powiązanego z elementem pracy.

Rejestrowanie

Zdarzenie zakończenia wdrożenia w pipeline wydania.

Typ zdarzenia explicit
Zakończenie pull request
Oznacza pomyślne zakończenie przeglądu kodu: pull request zostaje zatwierdzony, a kod scalony z gałęzią docelową. To zdarzenie jest jawnie rejestrowane w Azure Repos.
Dlaczego to ważne

Oznacza koniec przeglądu kodu, który często bywa wąskim gardłem. Analiza czasu od utworzenia do zakończenia PR pokazuje sprawność tego etapu.

Skąd pobrać

Zdarzenie odczytuje się z danych o zakończeniu lub scaleniu pull request w Azure Repos powiązanego z elementem pracy.

Rejestrowanie

Zdarzenie scalenia pull request powiązanego z elementem pracy.

Typ zdarzenia explicit
Zatwierdzenie UAT
Oznacza, że interesariusze biznesowi zatwierdzili zmiany po testach akceptacyjnych użytkowników. Zdarzenie zwykle rozpoznaje się po zmianie stanu z „In UAT” na „UAT Approved” lub „Ready for Release”.
Dlaczego to ważne

To ważny etap zatwierdzenia, który potwierdza, że element pracy spełnia wymagania biznesowe i jest gotowy do wdrożenia na produkcję.

Skąd pobrać

Zdarzenie ustala się na podstawie historii elementu pracy, wykrywając zmianę pola System.State ze stanu UAT na stan zatwierdzony lub oznaczający gotowość do wydania.

Rejestrowanie

Zdarzenie ustala się po zmianie pola State ze stanu „In UAT” na „Ready for Release”.

Typ zdarzenia inferred
Anulowanie elementu pracy
Oznacza, że element pracy został anulowany i nie zostanie ukończony ani wdrożony. Zdarzenie rejestruje się po zmianie stanu na „Removed”, „Cancelled” lub podobny.
Dlaczego to ważne

To alternatywne, niepomyślne zakończenie procesu. Analiza anulowanych elementów może ujawnić problemy z planowaniem, ustalaniem priorytetów lub definiowaniem wymagań.

Skąd pobrać

Zdarzenie ustala się na podstawie historii elementu pracy, gdy pole System.State zmienia się na stan końcowy z kategorii „Removed”.

Rejestrowanie

Zdarzenie ustala się po zmianie pola State na „Removed” lub „Cancelled”.

Typ zdarzenia inferred
Niepowodzenie testów QA
Oznacza, że element pracy nie przeszedł testów QA i wraca do zespołu programistycznego. Zdarzenie rozpoznaje się po zmianie stanu z testowego na „In Progress” lub „Active”.
Dlaczego to ważne

To działanie pomaga wykrywać pętle poprawek. Częste występowanie tego zdarzenia może wskazywać na problemy z jakością kodu, wymaganiami lub procesem testowania.

Skąd pobrać

Zdarzenie ustala się na podstawie historii elementu pracy, wykrywając przejście ze stanu takiego jak „In QA” do stanu takiego jak „Active” lub „In Progress”.

Rejestrowanie

Zdarzenie ustala się po zmianie pola State ze stanu „In QA” z powrotem na „Active”.

Typ zdarzenia inferred
Pomyślne zakończenie kompilacji
To działanie potwierdza, że kod źródłowy wraz z nowymi zmianami został poprawnie skompilowany i spakowany przez pipeline kompilacji. Azure Pipelines jawnie rejestruje to zdarzenie.
Dlaczego to ważne

To ważna bramka jakości, która potwierdza, że nowy kod poprawnie integruje się z projektem i nie powoduje błędów kompilacji. Niepowodzenie na tym etapie może wskazywać na problemy z integracją.

Skąd pobrać

Zdarzenie odczytuje się z danych o zakończeniu kompilacji w Azure Pipelines. Kompilację należy powiązać z elementem pracy bezpośrednio lub przez powiązany pull request.

Rejestrowanie

Zdarzenie zakończenia kompilacji w Azure Pipelines.

Typ zdarzenia explicit
Rozpoczęcie UAT
Oznacza początek testów akceptacyjnych użytkowników (UAT), podczas których interesariusze biznesowi sprawdzają działanie rozwiązania. Zdarzenie zwykle rozpoznaje się po zmianie stanu na „In UAT” lub podobny.
Dlaczego to ważne

Oznacza początek końcowej weryfikacji przed wydaniem. Analiza czasu trwania UAT i oczekiwania na zatwierdzenie pomaga usprawnić proces.

Skąd pobrać

Zdarzenie ustala się na podstawie historii elementu pracy, gdy pole System.State zostaje zaktualizowane do stanu niestandardowego oznaczającego UAT, na przykład „In UAT”.

Rejestrowanie

Zdarzenie ustala się po zmianie pola State na „In UAT”.

Typ zdarzenia inferred
Zakończenie prac programistycznych
Oznacza zakończenie prac programistycznych i testów jednostkowych oraz gotowość elementu do formalnych testów. Zdarzenie zwykle rozpoznaje się po zmianie stanu elementu pracy na „Resolved” lub „Ready for Test”.
Dlaczego to ważne

To ważny moment przekazania pracy z zespołu programistycznego do zespołu QA. Pomiar czasu do rozpoczęcia testów QA pozwala wykryć opóźnienia przy przekazywaniu pracy.

Skąd pobrać

Zdarzenie ustala się na podstawie historii elementu pracy, gdy pole System.State zmienia się na „Resolved” lub stan niestandardowy oznaczający gotowość do testów QA.

Rejestrowanie

Zdarzenie ustala się po zmianie pola State na „Resolved”.

Typ zdarzenia inferred
Zakończenie testów QA
Oznacza pomyślne zakończenie etapu zapewnienia jakości. Zdarzenie ustala się, gdy stan elementu pracy zmienia się ze stanu testowego na przykład na „Ready for UAT” lub „QA Approved”.
Dlaczego to ważne

To ważna bramka jakości, która oznacza gotowość elementu do testów akceptacyjnych użytkowników lub wydania. Opóźnienia po tym etapie mogą wskazywać na wąskie gardła w testach UAT lub planowaniu wydania.

Skąd pobrać

Zdarzenie ustala się na podstawie historii elementu pracy, gdy pole System.State zmienia się ze stanu „In QA” na kolejny stan, na przykład „Ready for UAT” lub „Done”.

Rejestrowanie

Zdarzenie ustala się po zmianie pola State ze stanu „In QA” na „Ready for UAT”.

Typ zdarzenia inferred
Zamknięcie elementu pracy
Oznacza ostateczne zamknięcie elementu pracy po wdrożeniu i ewentualnej weryfikacji powdrożeniowej. Zdarzenie rejestruje się po zmianie stanu na „Closed” lub „Done”.
Dlaczego to ważne

To działanie oznacza pomyślne zakończenie całego procesu dotyczącego danego elementu pracy. Jest końcowym punktem jego cyklu życia.

Skąd pobrać

Zdarzenie ustala się na podstawie historii elementu pracy, gdy pole System.State zmienia się na „Closed” lub podobny stan końcowy z kategorii „Completed”.

Rejestrowanie

Zdarzenie ustala się po zmianie pola State na „Closed”.

Typ zdarzenia inferred
Zatwierdzenie elementu pracy
Oznacza formalne zatwierdzenie elementu pracy, potwierdzające, że został dobrze opisany i jest gotowy do realizacji. Zdarzenie zwykle rozpoznaje się po zmianie pola „State” na wartość taką jak „Approved” lub „Ready for Dev”.
Dlaczego to ważne

Śledzenie zatwierdzeń pozwala analizować czas od zgłoszenia pomysłu do rozpoczęcia prac programistycznych. Ujawnia też możliwe opóźnienia na etapie planowania i porządkowania backlogu.

Skąd pobrać

Zdarzenie ustala się na podstawie historii elementu pracy, wykrywając zmianę pola System.State na „Approved” lub podobny stan niestandardowy.

Rejestrowanie

Zdarzenie ustala się po zmianie pola State na „Approved”.

Typ zdarzenia inferred
Zalecane Opcjonalne

Instrukcje pobierania danych

Jak pobrać dane z Azure DevOps

Gotowi do rozpoczęcia?

Już dziś zacznijcie usprawniać cykl wytwarzania oprogramowania. Ten szablon to pierwszy krok do uzyskania przydatnych informacji o procesie.

Już dziś usprawnij SDLC w Azure DevOps!

Skróć czas cyklu o 30% i wyeliminuj wąskie gardła w workflow SDLC.

Rozpocznij bezpłatny okres próbny

Nie trzeba podawać danych karty płatniczej. Rozpocznij pracę w kilka minut.