Szablon danych dotyczących cyklu wytwarzania oprogramowania

Jira Software
Szablon danych dotyczących cyklu wytwarzania oprogramowania

Szablon danych dotyczących cyklu wytwarzania oprogramowania

Ten szablon pokazuje, jak zebrać dane potrzebne do analizy cyklu wytwarzania oprogramowania. Zawiera podstawowe pola danych, kroki procesu do śledzenia oraz praktyczne wskazówki dotyczące pobierania informacji z Jira Software. Skorzystajcie z niego, aby przygotować dziennik zdarzeń do analizy process mining.
  • Zalecane atrybuty do zebrania
  • Najważniejsze działania do śledzenia
  • Wskazówki dotyczące pobierania danych z Jira Software
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 przeprowadzić pełną analizę cyklu wytwarzania oprogramowania.
5 Wymagane 6 Zalecane 10 Opcjonalne
Nazwa Opis
Czas zdarzenia
EventTime
Dokładna data i godzina wystąpienia konkretnej czynności lub zdarzenia związanego z pracami rozwojowymi.
Opis

Czas zdarzenia to znacznik czasu wskazujący, kiedy miała miejsce dana czynność. Stanowi podstawę czasową wszystkich analiz process mining i określa chronologiczną kolejność zdarzeń w każdym case.

Ten atrybut jest niezbędny do obliczania wszystkich miar opartych na czasie, w tym czasu realizacji, czasu przetwarzania i czasu oczekiwania między czynnościami. Umożliwia analizę wyników procesu w czasie i pomaga ustalić, kiedy oraz na jakim etapie cyklu tworzenia oprogramowania pojawiają się opóźnienia.

Dlaczego to ważne

Ten znacznik czasu pozwala prawidłowo uporządkować zdarzenia i obliczyć wszystkie miary czasu trwania, które pomagają ocenić sprawność procesu i wykryć opóźnienia.

Skąd pobrać

Odpowiada znacznikowi czasu „created” dla każdego wpisu w dzienniku zmian lub historii zgłoszenia.

Przykłady
2023-10-26T10:00:00Z2023-11-15T14:35:10Z2024-01-05T09:00:00Z
Czynność
Activity
Nazwa konkretnego zdarzenia lub zmiany statusu w cyklu życia elementu prac rozwojowych.
Opis

Ten atrybut oznacza odrębny krok lub kamień milowy w procesie tworzenia oprogramowania. Czynności są określane na podstawie zmian pola statusu zgłoszenia Jira lub innych istotnych zdarzeń, takich jak zatwierdzenie kodu czy przegląd.

W process mining sekwencja tych czynności tworzy mapę procesu. Ich analiza pomaga zrozumieć przebieg procesu, zmierzyć czas poszczególnych etapów i wykryć odstępstwa od standardowego workflow, na przykład pętle poprawek lub pominięte kontrole jakości.

Dlaczego to ważne

Czynności wyznaczają kolejne kroki procesu. Ich kolejność pozwala zobrazować jego przebieg, wykryć wąskie gardła i przeanalizować różnice w realizacji.

Skąd pobrać

Zwykle określa się ją na podstawie zmian pola „status” w historii lub dzienniku zmian zgłoszenia Jira. Można ją też uzupełnić danymi z połączonych narzędzi programistycznych.

Przykłady
Rozpoczęto programowaniePrzeprowadzono przegląd koduZakończono testy QAWdrożono na środowisko produkcyjne
Element prac rozwojowych
DevelopmentItem
Unikalny identyfikator pojedynczej jednostki pracy w Jira Software, takiej jak historyjka, błąd lub zadanie.
Opis

Element prac rozwojowych jest głównym identyfikatorem case i oznacza odrębną jednostkę pracy, na przykład funkcję, poprawkę błędu lub zadanie. Łączy wszystkie działania dotyczące danego elementu, od wstępnego pomysłu i planowania po prace rozwojowe, testy i wdrożenie. W Jira jest to zwykle klucz zgłoszenia, na przykład „PROJ-123”.

Analiza tego atrybutu pozwala prześledzić pełny cykl życia każdego elementu pracy. Stanowi podstawę do tworzenia map procesów, obliczania czasu realizacji i wykrywania różnic w przebiegu prac nad poszczególnymi elementami.

Dlaczego to ważne

To podstawowy identyfikator, który łączy powiązane działania rozwojowe i pozwala prześledzić drogę pojedynczego elementu pracy od początku do końca.

Skąd pobrać

To standardowe pole „key” obiektu zgłoszenia w Jira Software Issue API.

Przykłady
PROJ-101CORE-5432API-789
Ostatnia aktualizacja danych
LastDataUpdate
Znacznik czasu wskazujący, kiedy dane dotyczące tego procesu zostały ostatnio odświeżone z systemu źródłowego.
Opis

Ten atrybut zapisuje datę i godzinę ostatniego pobrania danych z Jira Software. Informuje, jak aktualne są analizowane dane.

Znajomość czasu ostatniej aktualizacji pomaga ocenić aktualność wniosków dotyczących procesu. Analitycy i użytkownicy biznesowi mogą sprawdzić, czy pracują na bieżących danych, oraz ustalić, do którego momentu uwzględniono zdarzenia w analizie.

Dlaczego to ważne

Informuje o aktualności danych, dzięki czemu można sprawdzić, czy analizy i dashboardy odzwierciedlają bieżący przebieg procesu.

Skąd pobrać

Ten znacznik czasu jest generowany i zapisywany po zakończeniu procesu pobierania, przekształcania i ładowania danych (ETL).

Przykłady
2024-03-15T02:00:00Z2024-03-16T02:00:00Z
System źródłowy
SourceSystem
System, z którego pobrano dane o cyklu życia prac rozwojowych.
Opis

Ten atrybut wskazuje źródło danych. W tym procesie będzie to zawsze „Jira Software”, ale pozwala odróżnić dane, gdy w szerszej analizie łączy się informacje z kilku systemów źródłowych.

W większym środowisku IT wskazanie systemu źródłowego zapewnia przejrzystość pochodzenia danych i ułatwia zarządzanie ich jakością oraz integracją między platformami.

Dlaczego to ważne

Zapewnia jasną informację o pochodzeniu danych, co ma znaczenie przy łączeniu danych z wielu systemów, zarządzaniu danymi i audycie.

Skąd pobrać

To stała wartość, którą należy dodać podczas pobierania i przekształcania danych.

Przykłady
Jira Software
Nazwa projektu
ProjectName
Nazwa projektu Jira, do którego należy element prac rozwojowych.
Opis

W Jira wszystkie elementy pracy są uporządkowane w projektach. Nazwa projektu zapewnia ogólny kontekst i często odpowiada konkretnemu produktowi, zespołowi lub inicjatywie.

Ten atrybut pozwala filtrować i porównywać dane. Umożliwia analizę i porównanie procesu SDLC w różnych projektach lub produktach. Można dzięki temu ustalić, które projekty są realizowane sprawniej, gdzie częściej pojawiają się poprawki i czy zespoły stosują różne warianty procesu.

Dlaczego to ważne

Pozwala podzielić analizę procesu według projektu, produktu lub zespołu, porównać wyniki i wskazać dobre praktyki.

Skąd pobrać

To pole „project” w obiekcie „fields” odpowiedzi Jira Issue API.

Przykłady
Tworzenie aplikacji mobilnejPlatforma podstawowaData science
Nazwa zespołu
TeamName
Zespół programistyczny odpowiedzialny za element pracy.
Opis

Oznacza konkretny zespół agile lub zespół produktowy przypisany do elementu prac rozwojowych. W Jira jest to często pole niestandardowe. Zespół można też określić na podstawie innych informacji, takich jak projekt lub konkretny komponent.

Ten atrybut umożliwia analizę wyników pracy poszczególnych zespołów. Dashboardy można filtrować, aby wyświetlać miary takie jak czas realizacji, odsetek poprawek i przepustowość dla każdego zespołu. Atrybut jest wykorzystywany w dashboardach „Sprawność przekazywania pracy między etapami” oraz „Obciążenie programistów i postęp prac nad elementami”.

Dlaczego to ważne

Pozwala mierzyć i porównywać wyniki różnych zespołów programistycznych, wskazywać zespoły osiągające dobre wyniki i dzielić się sprawdzonymi praktykami.

Skąd pobrać

Często jest to pole niestandardowe w Jira. Nazwę właściwego pola, na przykład „Team” lub „Squad”, można ustalić z administratorem Jira.

Przykłady
Zespół PhoenixUsługi podstawoweMściciele UI/UX
Osoba przypisana
Assignee
Użytkownik aktualnie odpowiedzialny za realizację elementu prac rozwojowych.
Opis

Osoba przypisana odpowiada za element pracy na jego obecnym etapie. W Jira jest to standardowe pole, które zmienia się, gdy element przechodzi między osobami lub zespołami.

Analiza osób przypisanych pozwala zrozumieć przydział zasobów, rozkład obciążenia i momenty przekazywania pracy. Pomaga ustalić, którzy programiści lub zespoły uczestniczą w poszczególnych etapach, gdzie powstają wąskie gardła i jak rozkłada się praca w organizacji.

Dlaczego to ważne

Wskazuje użytkownika lub zasób odpowiedzialny za daną czynność. Umożliwia analizę obciążenia, zarządzanie zasobami i śledzenie przekazywania pracy między osobami.

Skąd pobrać

To pole „assignee” w obiekcie „fields” odpowiedzi Jira Issue API.

Przykłady
Alice SmithBob JohnsonNieprzypisane
Priorytet elementu
ItemPriority
Poziom priorytetu przypisany do elementu prac rozwojowych, określający jego pilność.
Opis

Priorytet elementu określa względne znaczenie lub pilność danego elementu pracy. Jira udostępnia standardowe pole „priority” z konfigurowalnymi poziomami, takimi jak najwyższy, wysoki, średni i niski.

Analiza priorytetu pomaga sprawdzić zgodność z wymaganiami i wykryć wąskie gardła dotyczące pilnych elementów. Na przykład dashboard „Kontrola zgodności obsługi elementów o wysokim priorytecie” wykorzystuje ten atrybut, aby sprawdzić, czy pilne elementy są obsługiwane szybciej, czy też trafiają do tych samych kolejek co elementy o niskim priorytecie.

Dlaczego to ważne

Pomaga sprawdzić, czy elementy o wysokim priorytecie są przetwarzane szybciej niż te o niskim priorytecie i czy przechodzą krótszą ścieżkę, co ułatwia dotrzymanie SLA.

Skąd pobrać

To pole „priority” w obiekcie „fields” odpowiedzi Jira Issue API.

Przykłady
NajwyższyWysokiŚredniNiski
Status elementu
ItemStatus
Bieżący status elementu prac rozwojowych w jego workflow.
Opis

Ten atrybut wskazuje etap, na którym znajduje się element prac rozwojowych w danym momencie, na przykład „In Progress”, „In Review” lub „Done”. Sekwencja zmian statusu w czasie wyznacza czynności analizowane w process mining.

Atrybut „Activity” oznacza zdarzenie zmiany, a „ItemStatus” określa stan elementu. Można go używać jako wymiaru do filtrowania i analizy, na przykład aby sprawdzić, ile elementów znajduje się obecnie w danym stanie lub jakie cechy mają elementy długo pozostające w określonym statusie.

Dlaczego to ważne

Pokazuje, na jakim etapie cyklu życia znajduje się element. Umożliwia analizę według statusu i ocenę bieżącego stanu prac w toku.

Skąd pobrać

To pole „status” w obiekcie „fields” odpowiedzi Jira Issue API.

Przykłady
Do zrobieniaW trakcie realizacjiW trakcie przegląduZakończono
Typ elementu
ItemType
Klasyfikacja elementu prac rozwojowych, na przykład błąd, historyjka, zadanie lub epik.
Opis

Typ elementu określa charakter wykonywanej pracy. Jira używa standardowego pola „issuetype”, aby rozróżniać rodzaje elementów pracy, które często mają różne workflow.

Ten atrybut jest potrzebny do porównań. Pozwala filtrować proces według rodzaju pracy, na przykład porównać cykl życia błędu z cyklem historyjki. Dzięki temu można sprawdzić, czy określone rodzaje pracy częściej wiążą się z opóźnieniami, poprawkami lub odstępstwami od standardowego procesu.

Dlaczego to ważne

Pozwala podzielić analizę procesu według rodzaju pracy, na przykład porównać obsługę błędów i nowych funkcji oraz wskazać różnice w przebiegu.

Skąd pobrać

To pole „issuetype” w obiekcie „fields” odpowiedzi Jira Issue API.

Przykłady
HistoryjkaBłądZadanieEpik
Całkowity czas cyklu
CycleTime
Łączny czas realizacji elementu prac rozwojowych od początku do końca.
Opis

Czas cyklu to okres od utworzenia elementu prac rozwojowych do jego ostatecznego rozwiązania, na przykład wdrożenia na produkcję. Wartość oblicza się dla każdego case jako różnicę między timestampem pierwszego i ostatniego zdarzenia.

To podstawowy KPI służący do pomiaru tempa i efektywności całego procesu. Na tym obliczeniu opierają się KPI „Średni czas cyklu od początku do końca” oraz dashboard „Analiza całkowitego czasu cyklu SDLC”. Skrócenie czasu cyklu jest częstym celem inicjatyw usprawniających procesy.

Dlaczego to ważne

Mierzy tempo realizacji procesu wytwarzania oprogramowania od początku do końca i pokazuje ogólną efektywność oraz szybkość dostarczania.

Skąd pobrać

To atrybut obliczany na poziomie case. Dla danego „DevelopmentItem” jest to timestamp ostatniego zdarzenia pomniejszony o timestamp pierwszego zdarzenia.

Przykłady
12096002592000604800
Czas oczekiwania na przekazanie pracy
HandoffWaitTime
Czas bezczynności między kolejnymi działaniami.
Opis

Ta miara określa czas oczekiwania między zakończeniem jednego działania a rozpoczęciem następnego. Pokazuje, jak długo praca pozostaje bezczynna, zanim ktoś się nią zajmie.

To istotna miara dla KPI „Średni czas oczekiwania na przekazanie pracy” i dashboardu „Efektywność przekazywania pracy między etapami”. Długi czas przekazania często wskazuje na problemy z koordynacją, ograniczoną dostępność zasobów lub nieskuteczną komunikację między zespołami, na przykład między programistami a zespołem QA. Skrócenie tego czasu bezczynności pomaga zmniejszyć całkowity czas cyklu.

Dlaczego to ważne

Pokazuje czas bezczynności lub oczekiwania w kolejce, ujawniając nieefektywne przekazywanie pracy między zespołami lub osobami oraz problemy z koordynacją.

Skąd pobrać

To miara obliczana na podstawie różnicy między czasem rozpoczęcia działania a czasem zakończenia poprzedniego działania w tym samym case.

Przykłady
017280043200
Czas zakończenia zdarzenia
EventEndTime
Znacznik czasu zakończenia czynności lub zmiany statusu.
Opis

Ten atrybut wskazuje czas zakończenia czynności. Jest to znacznik czasu kolejnej czynności w sekwencji dla danego case.

„EventTime” (StartTime) oznacza początek czynności, a EventEndTime jej koniec. Różnica między tymi znacznikami czasu to czas przetwarzania danej czynności. Atrybut jest niezbędny do obliczenia KPI „Średni czas przetwarzania etapu” i tworzenia dashboardów analizujących czas trwania czynności.

Dlaczego to ważne

Określa moment zakończenia czynności, co pozwala obliczyć czas trwania każdego kroku procesu i analizować wąskie gardła.

Skąd pobrać

To atrybut pochodny. Dla danego zdarzenia czas zakończenia jest równy czasowi rozpoczęcia kolejnego zdarzenia w tym samym case.

Przykłady
2023-10-26T12:30:00Z2023-11-15T18:00:15Z2024-01-05T11:45:00Z
Czy wystąpiły poprawki
IsRework
Wskaźnik informujący, czy czynność jest częścią pętli poprawek.
Opis

Ten atrybut logiczny ma wartość prawda, jeśli czynność oznacza cofnięcie się w procesie, na przykład powrót do etapu „Rozpoczęto prace rozwojowe” po niezaliczeniu kontroli jakości. Wartość ustala się na podstawie sekwencji czynności w danym case.

Wykrywanie poprawek jest podstawą usprawniania procesu i poprawy jakości. Atrybut bezpośrednio wspiera KPI „Odsetek czynności wymagających poprawek” oraz dashboard „Częstotliwość i ścieżki pętli poprawek”. Pozwala zmierzyć nakład pracy, który trzeba było powtórzyć, i wskazać źródłowe przyczyny problemów z jakością.

Dlaczego to ważne

Wyraźnie oznacza działania należące do nieefektywnych pętli poprawek, co pozwala precyzyjnie mierzyć i analizować straty oraz problemy z jakością procesu.

Skąd pobrać

To atrybut obliczany. Wymaga określenia oczekiwanego przebiegu procesu, a następnie oznaczenia działań, które od niego odbiegają, cofając się do wcześniejszego etapu.

Przykłady
truefalse
Komponent
Component
Podsekcja lub obszar funkcjonalny projektu, do którego należy element.
Opis

W Jira komponenty służą do dzielenia zgłoszeń w projekcie na mniejsze, łatwiejsze do zarządzania grupy. Mogą oznaczać obszar funkcjonalny, taki jak „Uwierzytelnianie użytkowników”, warstwę techniczną, na przykład „Backend API”, lub moduł, taki jak „Raportowanie”.

Analiza według komponentów pozwala dokładniej przyjrzeć się procesowi tworzenia oprogramowania. Pomaga ustalić, czy określone części aplikacji generują więcej błędów, mają dłuższy cykl rozwoju lub wymagają więcej poprawek. Może to wskazywać obszary długu technicznego lub złożoności.

Dlaczego to ważne

Pozwala podzielić proces według obszarów funkcjonalnych lub technicznych produktu i wskazać komponenty powodujące opóźnienia lub problemy z jakością.

Skąd pobrać

To standardowe pole „components” w obiekcie „fields” odpowiedzi Jira Issue API.

Przykłady
Interfejs użytkownikaBaza danychBrama APIUwierzytelnianie
Nazwa sprintu
SprintName
Nazwa sprintu agile, do którego przypisano element prac rozwojowych.
Opis

W zespołach korzystających ze Scrum sprint to ograniczony czasowo okres, w którym realizuje się określony zakres prac. Ten atrybut zapisuje nazwę lub identyfikator sprintu, do którego należy dany element.

Analiza według sprintów jest podstawą process mining w zespołach agile. Pomaga ocenić wyniki poszczególnych sprintów, zrozumieć, które prace przechodzą do kolejnego sprintu, i śledzić postępy względem celów sprintu. Zapewnia dokładniejszy kontekst czasowy niż ogólne zakresy dat.

Dlaczego to ważne

Zapewnia zespołom agile kontekst potrzebny do analizy sprawności procesu i przepustowości w podziale na sprinty.

Skąd pobrać

Te informacje są zwykle przechowywane w polu niestandardowym „Sprint”, zarządzanym przez Jira Software (Agile). Dane są dostępne przez Issue API.

Przykłady
Sprint 1 PROJSprint 3, IV kwartał 2023Sprint 2, listopadowy PI
Planowane wydanie
PlannedReleaseVersion
Docelowa wersja oprogramowania lub wydanie, w którym planuje się wdrożyć element.
Opis

Ten atrybut, często zapisany w Jira w polu „Affects Version/s”, wskazuje planowane wydanie funkcji lub poprawki. Wyznacza termin lub cel zakończenia prac.

To ważny atrybut KPI „Odsetek wydań dostarczonych na czas”. Porównanie rzeczywistej daty wdrożenia z planowaną datą wydania przypisaną do tej wersji pozwala zmierzyć dotrzymywanie harmonogramu i przewidywalność procesu wydawania.

Dlaczego to ważne

Określa docelowy termin dostarczenia lub wydanie, co pozwala obliczyć odsetek dostaw na czas i analizować dotrzymywanie harmonogramu.

Skąd pobrać

Odpowiada polom „versions” lub „fixVersions” w Jira Issue API. Pole używane do planowania może się różnić.

Przykłady
Wersja 2.1Wydanie z I kwartału 2024Uruchomienie projektu Phoenix
Rozwiązanie elementu
ItemResolution
Końcowy wynik lub powód zamknięcia elementu prac rozwojowych.
Opis

Rozwiązanie wyjaśnia, dlaczego element został zamknięty. Status może mieć wartość „Closed”, a rozwiązanie „Done”, „Won't Do”, „Duplicate” lub „Cannot Reproduce”. Dostarcza ono ważnych informacji o wyniku prac.

Analiza rozwiązania pozwala odróżnić pomyślnie zakończone prace od elementów anulowanych lub odrzuconych. Ma to znaczenie przy analizie jakości i ocenie rzeczywistej liczby wartościowych prac w porównaniu z nakładem poświęconym na elementy, które ostatecznie odrzucono.

Dlaczego to ważne

Pozwala odróżnić pomyślnie zakończone elementy od tych zamkniętych z innych powodów, co jest ważne przy rzetelnej analizie produktywności i jakości.

Skąd pobrać

To pole „resolution” w obiekcie „fields” odpowiedzi Jira Issue API. Zwykle jest uzupełniane dopiero po zamknięciu zgłoszenia.

Przykłady
ZakończonoNie będzie realizowaneDuplikatNie można odtworzyć
Wersja poprawki
FixVersion
Wersja oprogramowania, w której element prac rozwojowych został faktycznie rozwiązany i wydany.
Opis

Pole „Fix Version” w Jira wskazuje wydanie zawierające ukończone prace nad elementem. Określa konkretny wynik prac rozwojowych.

Ten atrybut podaje rzeczywiste wydanie, które można porównać z „PlannedReleaseVersion”, aby przeanalizować terminowość dostaw. Pozwala też grupować wszystkie elementy dostarczone w danym wydaniu i sprawdzić, co zostało zrealizowane.

Dlaczego to ważne

Potwierdza, w którym wydaniu znalazły się dane prace. Stanowi wiarygodną podstawę do analizy wydań i śledzenia dostarczonych funkcji.

Skąd pobrać

Odpowiada polu „fixVersions” w odpowiedzi Jira Issue API.

Przykłady
v2.1.1, poprawka awaryjnav3.0.0, wydanie głównev2.2.0
Zgłaszający
Reporter
Użytkownik, który utworzył lub zgłosił element prac rozwojowych.
Opis

Zgłaszający to osoba, która utworzyła zgłoszenie w Jira. Może to być programista, tester QA, product manager lub klient korzystający z integracji z service desk.

Analiza zgłaszających pozwala ustalić, skąd pochodzi praca. Można na przykład sprawdzić, czy błędy zgłaszane przez zespół QA przechodzą inny cykl życia niż błędy zgłaszane przez klientów. Pomaga to również zrozumieć sposób komunikacji i przepływ informacji na początku procesu.

Dlaczego to ważne

Wskazuje źródło elementu pracy i pozwala analizować wzorce związane z osobami tworzącymi zadania lub zgłaszającymi błędy.

Skąd pobrać

To pole „reporter” w obiekcie „fields” odpowiedzi Jira Issue API.

Przykłady
Charles DarwinMarie CurieIsaac Newton
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 dokładnie odkryć przebieg cyklu wytwarzania oprogramowania.
6 Zalecane 8 Opcjonalne
Działanie Opis
Rozpoczęto programowanie
Oznacza moment, w którym programista rozpoczyna aktywną pracę nad elementem prac rozwojowych. Zwykle można go ustalić na podstawie zmiany statusu w workflow Jira, na przykład gdy zgłoszenie otrzymuje status „W toku”.
Dlaczego to ważne

To ważny punkt odniesienia przy mierzeniu czasu aktywnego programowania. Pozwala odróżnić czas oczekiwania od pracy przynoszącej wartość, co pomaga wykrywać wąskie gardła.

Skąd pobrać

Informację można wywnioskować z dziennika zmian zgłoszenia Jira. Jest to znacznik czasu pierwszej zmiany pola „status” na „W toku”, „W trakcie programowania” lub podobny status oznaczający aktywną pracę.

Rejestrowanie

Znacznik czasu zmiany statusu na „W toku”.

Typ zdarzenia inferred
Rozpoczęto testy QA
To zdarzenie oznacza początek formalnych testów zapewnienia jakości elementu prac rozwojowych. Można je wywnioskować ze zmiany statusu w Jira, gdy zgłoszenie otrzymuje status taki jak „W QA”, „W testach” lub „Gotowe do testów”.
Dlaczego to ważne

To ważny punkt rozpoczęcia cyklu kontroli jakości. Pomiar czasu od „Zakończono programowanie” do tego momentu ujawnia opóźnienia przy przekazywaniu pracy między zespołami programistycznym i QA.

Skąd pobrać

Informację można wywnioskować z dziennika zmian zgłoszenia Jira. Jest to znacznik czasu zmiany pola „status” na status testów QA, na przykład „W QA”.

Rejestrowanie

Znacznik czasu zmiany statusu na „W QA” lub „W testach”.

Typ zdarzenia inferred
Utworzono element prac rozwojowych
To początek cyklu. Nowy element prac rozwojowych, na przykład historyjka, błąd lub zadanie, zostaje formalnie zarejestrowany w Jira. System zapisuje to zdarzenie i znacznik czasu utworzenia każdego zgłoszenia.
Dlaczego to ważne

To jednoznaczny początek procesu. Jest niezbędny do obliczania czasu realizacji od początku do końca oraz śledzenia łącznej liczby napływających prac.

Skąd pobrać

To podstawowe zdarzenie dla każdego zgłoszenia Jira. Znacznik czasu utworzenia jest zapisany w polu „created” rekordu zgłoszenia i dostępny przez Jira API.

Rejestrowanie

Pole znacznika czasu „created” w obiekcie zgłoszenia Jira.

Typ zdarzenia explicit
Wdrożono na środowisko produkcyjne
To zdarzenie oznacza moment, w którym zmiany kodu powiązane z elementem prac trafiają do środowiska produkcyjnego. Można je rozpoznać po końcowej zmianie statusu na „Done” lub „Released” albo zarejestrować na podstawie jawnego zdarzenia zintegrowanego narzędzia CI/CD.
Dlaczego to ważne

To główny punkt końcowy procesu, który oznacza jego pomyślne zakończenie. Jest niezbędny do obliczenia całkowitego czasu realizacji oraz pomiaru częstotliwości wdrożeń i przepustowości.

Skąd pobrać

Zdarzenie można rozpoznać w historii zmian zgłoszenia Jira, gdy status zmieni się na „Released” lub „Done”. Dokładniejsze dane zapewniają zdarzenia wdrożeniowe z narzędzi CI/CD, takich jak Jenkins czy Bamboo, albo funkcja Deployments w Jira.

Rejestrowanie

Znacznik czasu zmiany statusu na „Done” lub „Released”.

Typ zdarzenia inferred
Zakończono testy QA
Oznacza, że element prac rozwojowych pomyślnie przeszedł wszystkie kontrole QA i jest gotowy do kolejnego etapu, na przykład testów akceptacyjnych użytkowników lub wydania. Można to wywnioskować ze zmiany statusu z głównego statusu testów.
Dlaczego to ważne

To koniec ważnej bramki jakości. Analiza czasu trwania etapu QA pomaga usprawnić testowanie i przydział zasobów.

Skąd pobrać

Informację można wywnioskować z dziennika zmian zgłoszenia Jira. Jest to znacznik czasu zmiany pola „status” z „W QA” na kolejny status, na przykład „Gotowe do UAT” lub „Gotowe do wydania”.

Rejestrowanie

Znacznik czasu zmiany statusu z „W QA” na „Gotowe do UAT”.

Typ zdarzenia inferred
Zatwierdzono UAT
Oznacza pomyślne zakończenie testów akceptacyjnych użytkowników i zgodę interesariuszy na wydanie. Można to wywnioskować ze zmiany statusu z „W UAT” na „Gotowe do wydania” lub „Zakończono”.
Dlaczego to ważne

Ten punkt kontrolny potwierdza akceptację biznesową i pozwala przygotować element do wdrożenia na produkcję. To ważny etap, który pomaga upewnić się, że dostarczone rozwiązanie spełnia oczekiwania użytkowników.

Skąd pobrać

Informację można wywnioskować z dziennika zmian zgłoszenia Jira. Jest to znacznik czasu zmiany statusu z „W UAT” na kolejny status w workflow, oznaczającej zatwierdzenie.

Rejestrowanie

Znacznik czasu zmiany statusu z „W UAT” na „Gotowe do wydania”.

Typ zdarzenia inferred
Anulowano element prac rozwojowych
Oznacza zakończenie prac nad elementem przed jego ukończeniem. Zdarzenie można rozpoznać po zmianie statusu na końcowy, taki jak „Canceled”, „Rejected” lub „Won't Do”. Często towarzyszy temu ustawienie odpowiedniego rozwiązania.
Dlaczego to ważne

To zdarzenie pozwala śledzić niepomyślne wyniki procesu. Analiza przyczyn anulowania elementów może ujawnić problemy z planowaniem, ustalaniem priorytetów lub definiowaniem wymagań.

Skąd pobrać

Zdarzenie rozpoznawane na podstawie historii zmian zgłoszenia Jira. Jest to znacznik czasu zmiany pola „status” na „Canceled” lub „Won't Do” i ustawienia odpowiedniego rozwiązania.

Rejestrowanie

Znacznik czasu zmiany statusu na „Canceled”, „Rejected” lub „Won't Do”.

Typ zdarzenia inferred
Element prac rozwojowych gotowy do realizacji
Oznacza, że element prac rozwojowych został w pełni opisany, sprawdzony i otrzymał priorytet, więc programista może rozpocząć pracę. Zwykle można to wywnioskować ze zmiany statusu w workflow, na przykład z „Backlog” na „Do zrobienia” lub „Gotowe do programowania”.
Dlaczego to ważne

Śledzenie tego etapu pomaga ocenić, czy backlog jest gotowy do realizacji, i zmierzyć, jak długo elementy czekają na rozpoczęcie prac. Pozwala oddzielić czas planowania i dopracowywania wymagań od czasu aktywnego programowania.

Skąd pobrać

Informację można wywnioskować z dziennika zmian zgłoszenia Jira. Należy znaleźć znacznik czasu zmiany pola „status” na wartość taką jak „Gotowe do programowania”, „Do zrobienia” lub „Wybrane do realizacji”.

Rejestrowanie

Znacznik czasu zmiany statusu na stan oznaczający gotowość do rozpoczęcia prac.

Typ zdarzenia inferred
Przeprowadzono przegląd kodu
Oznacza, że inny programista lub lider zespołu sprawdził jakość, zgodność ze standardami i działanie kodu. Można to wywnioskować ze zmiany statusu, na przykład z „Do przeglądu” na „Gotowe do QA”, albo zarejestrować bezpośrednio w zintegrowanych narzędziach programistycznych.
Dlaczego to ważne

To istotna bramka jakości. Analiza czasu trwania przeglądu i jego wyników, takich jak konieczność poprawek, pomaga poprawić jakość kodu i ograniczyć liczbę błędów wykrywanych na późniejszych etapach.

Skąd pobrać

Zwykle można to wywnioskować z dziennika zmian zgłoszenia Jira, gdy status przestaje mieć wartość „Przegląd kodu”. Zdarzenie można też zarejestrować bezpośrednio po integracji z narzędziami repozytorium kodu, takimi jak Bitbucket lub GitHub.

Rejestrowanie

Znacznik czasu zmiany statusu z „Do przeglądu” na kolejny status.

Typ zdarzenia inferred
Przygotowano do wydania
Oznacza, że element prac przeszedł wszystkie kontrole i został przypisany do konkretnej wersji wydania oprogramowania, ale czeka na wdrożenie. Zdarzenie można zwykle rozpoznać po zmianie statusu zgłoszenia na „Ready for Release” lub uzupełnieniu pola „Fix Version”.
Dlaczego to ważne

To zdarzenie pomaga ocenić gotowość do wydania oraz czas oczekiwania na okno wdrożeniowe po zakończeniu prac programistycznych i testów.

Skąd pobrać

Zdarzenie można zwykle rozpoznać w historii zmian zgłoszenia Jira po zmianie statusu na „Ready for Release”. Można też wykorzystać znacznik czasu ustawienia pola „Fix Version/s”.

Rejestrowanie

Znacznik czasu zmiany statusu na „Ready for Release” lub uzupełnienia pola „Fix Version”.

Typ zdarzenia inferred
Rozpoczęto UAT
Oznacza początek testów akceptacyjnych użytkowników, podczas których interesariusze biznesowi lub użytkownicy końcowi sprawdzają nowe funkcje. Można to wywnioskować ze zmiany statusu w Jira na „W UAT” lub „Testy akceptacyjne użytkowników”.
Dlaczego to ważne

To początek końcowego etapu weryfikacji przed wydaniem. Analiza czasu jego trwania pomaga zrozumieć i ograniczyć opóźnienia związane z dostępnością interesariuszy lub przekazywaniem informacji zwrotnych.

Skąd pobrać

Informację można wywnioskować z dziennika zmian zgłoszenia Jira. Jest to znacznik czasu aktualizacji pola „status” na „W UAT” lub podobny status.

Rejestrowanie

Znacznik czasu zmiany statusu na „W UAT”.

Typ zdarzenia inferred
Testy QA zakończone niepowodzeniem
Oznacza, że zespół QA wykrył błąd i odesłał element prac rozwojowych do programistów w celu wprowadzenia poprawek. Można to wywnioskować ze zmiany statusu na wcześniejszy, na przykład z „W QA” na „W toku” lub „Do zrobienia”.
Dlaczego to ważne

To działanie pomaga wykrywać powroty do poprawek. Śledzenie ich częstotliwości pozwala zmierzyć koszt niskiej jakości i wskazać obszary wymagające poprawy w programowaniu lub opisie wymagań.

Skąd pobrać

Informację można wywnioskować z dziennika zmian zgłoszenia Jira. Zdarzenie jest rejestrowane, gdy pole „status” zmienia się ze statusu testów, na przykład „W QA”, na wcześniejszy status programowania, na przykład „W toku”.

Rejestrowanie

Znacznik czasu zmiany statusu z etapu testów na etap programowania.

Typ zdarzenia inferred
Zakończono programowanie
Oznacza, że programista zakończył kodowanie, a element jest gotowy do kolejnego etapu, na przykład przeglądu kodu lub testów. Można to wywnioskować ze zmiany statusu w Jira, na przykład z „W toku” na „Do przeglądu” lub „Gotowe do QA”.
Dlaczego to ważne

To koniec głównego etapu programowania. Pozwala analizować czas kodowania i sprawność przekazywania pracy do zespołu zapewnienia jakości.

Skąd pobrać

Informację można wywnioskować z dziennika zmian zgłoszenia Jira, zapisując znacznik czasu zmiany pola „status” z aktywnego statusu programowania na kolejny, na przykład „Do przeglądu” lub „Gotowe do QA”.

Rejestrowanie

Znacznik czasu zmiany statusu z „W toku” na „Do przeglądu” lub „Gotowe do QA”.

Typ zdarzenia inferred
Zamknięto element prac rozwojowych
To końcowa czynność administracyjna, która potwierdza, że nie przewiduje się dalszych prac nad elementem. Zdarzenie można zwykle rozpoznać po zmianie statusu na „Closed” i uzupełnieniu pola „Resolution”.
Dlaczego to ważne

Oznacza bezwzględny koniec cyklu życia elementu. Porównanie tego zdarzenia z „Wdrożono na środowisko produkcyjne” może ujawnić opóźnienia administracyjne lub okres monitorowania po wdrożeniu.

Skąd pobrać

Zdarzenie rozpoznawane na podstawie historii zmian zgłoszenia Jira. Jest to znacznik czasu zmiany pola „status” na „Closed” i ustawienia rozwiązania.

Rejestrowanie

Znacznik czasu zmiany statusu na „Closed”.

Typ zdarzenia inferred
Zalecane Opcjonalne

Instrukcje pobierania danych

Jak pobrać dane z Jira Software

Gotowi, aby zacząć?

Zacznijcie optymalizować cykl wytwarzania oprogramowania już dziś. Przygotujcie dane za pomocą tego szablonu i odkryjcie możliwości przyspieszenia dostarczania oraz poprawy jakości.

Zoptymalizujcie SDLC w Jira Software. Zacznijcie już dziś!

Wykryjcie nieefektywności i skróćcie czas cyklu SDLC o 30%.

Rozpocznij okres próbny

Nie trzeba podawać danych karty płatniczej. Optymalizację można rozpocząć w kilka minut.