Szablon danych cyklu wytwarzania oprogramowania
Szablon danych cyklu wytwarzania oprogramowania
- Zalecane atrybuty do zebrania
- Najważniejsze działania do śledzenia w SDLC
- Szczegółowe wskazówki dotyczące pobierania danych z Azure DevOps
Atrybuty cyklu wytwarzania oprogramowania
| 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
|
|||
Działania w cyklu wytwarzania oprogramowania
| 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
|
|||
Instrukcje pobierania danych
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.
Nie trzeba podawać danych karty płatniczej. Rozpocznij pracę w kilka minut.