Szablon danych cyklu wytwarzania oprogramowania

Czas rozpoczęcia zdarzenia wskazuje dokładną datę i godzinę rozpoczęcia działania. Ustala chronologiczną kolejność wszystkich zdarzeń w ramach jednej sprawy, co jest niezbędne do prawidłowego odtworzenia przebiegu procesu.

Znaczniki czasu stanowią podstawę analiz process mining opartych na czasie. Służą do obliczania wskaźników KPI, takich jak czas cyklu, czas oczekiwania i czas realizacji między działaniami. Analiza znaczników czasu pomaga wykrywać wąskie gardła, mierzyć sprawność procesu i określać czas trwania poszczególnych etapów cyklu życia prac rozwojowych. Na przykład czas między „Przekazaniem kodu do przeglądu” a „Zakończeniem przeglądu kodu” może ujawnić opóźnienia w przeglądzie.

Ten znacznik czasu jest niezbędny do prawidłowego uporządkowania zdarzeń i obliczenia wszystkich miar opartych na czasie, takich jak czas cyklu i czas trwania wąskich gardeł.

Dostępny w dziennikach zdarzeń, ścieżkach audytowych lub tabelach historii rejestrujących zmiany elementów prac rozwojowych.

Identyfikator elementu pracy rozwojowej to klucz główny, który jednoznacznie identyfikuje każdą sprawę w całym cyklu życia oprogramowania. Każdy identyfikator odpowiada odrębnej jednostce pracy, takiej jak historyjka użytkownika, zadanie lub poprawka błędu, od utworzenia do ostatecznego rozwiązania lub wdrożenia.

W analizie process mining ten atrybut jest niezbędny do odtworzenia pełnej ścieżki każdego elementu pracy. Umożliwia połączenie powiązanych działań, takich jak „Rozpoczęcie prac rozwojowych”, „Zakończenie przeglądu kodu” i „Wdrożenie na produkcję”, w spójny przebieg procesu. Analiza cyklu życia poszczególnych elementów pracy pomaga wykryć różnice, opóźnienia i pętle poprawek związane z konkretnymi zadaniami.

To podstawowy identyfikator sprawy, niezbędny do śledzenia pełnego cyklu życia każdego elementu pracy rozwojowej od początku do końca.

Zwykle znajduje się w głównych tabelach elementów pracy lub zgłoszeń w systemie zarządzania pracami rozwojowymi.

Nazwa działania opisuje konkretny krok lub zmianę statusu w procesie wytwarzania oprogramowania. Działania te tworzą węzły mapy procesu i przedstawiają ważne etapy, takie jak „Zatwierdzenie elementu pracy do realizacji”, „Przekazanie kodu do przeglądu” lub „Zakończenie testów QA”.

Ten atrybut jest niezbędny do wizualizacji przebiegu procesu i zrozumienia kolejności zdarzeń. Analiza działań pozwala zespołom wskazać najczęstsze ścieżki, wykryć odstępstwa od procesu i zmierzyć czas spędzony na poszczególnych etapach. Stanowi podstawę analizy wąskich gardeł, wykrywania poprawek i sprawdzania zgodności z docelowym modelem procesu.

Określa kroki procesu, dzięki czemu można wizualizować i analizować workflow prac rozwojowych.

Często pochodzi z dzienników zmian statusu, strumieni zdarzeń lub tabel historii powiązanych z elementami prac rozwojowych.

Atrybut „Ostatnia aktualizacja danych” zapisuje datę i godzinę ostatniego pobrania lub zaktualizowania danych z systemu źródłowego. Informuje, jak aktualne i przydatne są dane.

Ta informacja pomaga upewnić się, że analizy i dashboardy opierają się na bieżących danych. Interesariusze mogą szybko sprawdzić, kiedy ostatnio zaktualizowano widok procesu, i ocenić aktualność uzyskanych wniosków. To ważne metadane przy zarządzaniu pipeline'ami danych i planowaniu ich odświeżania.

Informuje o aktualności danych, dzięki czemu analiza może wspierać podejmowanie bieżących i trafnych decyzji.

Ta wartość jest zwykle generowana i zapisywana w potoku ekstrakcji, transformacji i ładowania danych (ETL).

Atrybut „System źródłowy” wskazuje aplikację lub platformę, w której zarejestrowano dane dotyczące cyklu życia prac rozwojowych. Jest to szczególnie przydatne w środowiskach korzystających z kilku narzędzi, na przykład Jira do obsługi zgłoszeń i GitLab do zarządzania kodem źródłowym.

W analizie wskazanie systemu źródłowego ułatwia weryfikację danych i zapewnia kontekst. Pozwala porównywać procesy obsługiwane w różnych systemach oraz prawidłowo interpretować dane, ponieważ nazwy pól i przyjęte zasady mogą się różnić. Można też filtrować analizę, aby uwzględnić dane z konkretnego narzędzia.

Informuje o pochodzeniu danych, co ma znaczenie przy ich weryfikacji i analizie obejmującej kilka zintegrowanych systemów.

Zwykle jest to stała wartość dodawana podczas pobierania danych, która wskazuje pochodzenie rekordów.

Czas zakończenia zdarzenia oznacza koniec czynności. Wiele kroków procesu jest rejestrowanych jako zdarzenia chwilowe, w których czas rozpoczęcia i zakończenia jest taki sam. Niektóre czynności trwają jednak określony czas. Na przykład przegląd kodu może mieć osobny czas rozpoczęcia i zakończenia.

Ten atrybut jest niezbędny do obliczania aktywnego czasu realizacji poszczególnych zadań i odróżniania go od przestojów lub oczekiwania. Porównując czas rozpoczęcia i zakończenia zdarzenia, analitycy mogą zmierzyć nakład pracy na czynności przynoszące wartość. Pozwala to dokładniej analizować wykorzystanie zasobów i wskazać zadania, które pochłaniają najwięcej aktywnego czasu pracy.

Pozwala obliczyć aktywny czas realizacji poszczególnych czynności, oddzielić go od czasu oczekiwania i lepiej ocenić nakład pracy.

Można ją znaleźć w dziennikach zdarzeń lub wyznaczyć na podstawie znacznika czasu kolejnej czynności w sekwencji dotyczącej tego samego elementu pracy.

Nazwa projektu pozwala uporządkować elementy pracy według produktu, inicjatywy lub bazy kodu. Praktyki programistyczne i czas cyklu mogą się znacznie różnić między projektami, na przykład między systemem starszego typu a nową aplikacją tworzoną od podstaw.

Ten atrybut umożliwia zbiorcze porównywanie procesów programistycznych w różnych częściach organizacji. Kierownicy mogą filtrować analizę według projektu, aby ocenić stan i sprawność poszczególnych prac programistycznych. Atrybut pomaga też zrozumieć, jak wyniki procesu zależą od kontekstu i środowiska technicznego projektu.

Pozwala podzielić analizę procesu według produktu lub inicjatywy i wykryć różnice w wynikach związane z kontekstem projektu.

Standardowe pole w rekordzie elementu pracy lub zgłoszenia albo nazwa repozytorium w systemach takich jak Git.

Ten atrybut wskazuje konkretny zespół, grupę lub squad odpowiedzialny za realizację elementu pracy programistycznej. W większych organizacjach praca jest często podzielona między wyspecjalizowane zespoły, takie jak frontend, backend, mobile czy platforma.

Analiza według nazwy zespołu pozwala porównywać wyniki i dzielić się dobrymi praktykami. Pomaga odpowiedzieć na pytania: „Który zespół ma najkrótszy czas cyklu?” albo „Czy w jednym zespole częściej trzeba poprawiać wykonaną pracę?”. Analiza może ujawnić różnice w workflow, kompetencjach lub dostępności zasobów, które wpływają na wyniki realizacji. Dzięki temu można lepiej ukierunkować działania usprawniające proces.

Umożliwia porównywanie wyników różnych zespołów, wskazywanie dobrych praktyk i obszarów wymagających poprawy.

Często jest powiązana z przypisanym użytkownikiem lub dostępna jako osobne pole w rekordzie projektu albo elementu pracy.

Atrybut „Priorytet” określa pilność biznesową lub techniczną danego elementu pracy. Zwykle przyjmuje wartości takie jak „Wysoki”, „Średni” lub „Niski” i pomaga zespołom ustalić, nad czym pracować w pierwszej kolejności.

W process mining priorytet jest przydatnym wymiarem analizy. Pozwala sprawdzić, czy elementy o wysokim priorytecie rzeczywiście są realizowane szybciej niż te o niskim priorytecie. Porównanie czasu cyklu dla różnych poziomów priorytetu pokazuje, czy proces uwzględnia potrzeby biznesowe. Częste opóźnienia w realizacji zadań o wysokim priorytecie mogą wskazywać na problemy z planowaniem, przydziałem zasobów lub projektem workflow.

Pomaga sprawdzić, czy prace o wysokim priorytecie szybciej przechodzą przez proces, oraz wskazać wąskie gardła, które szczególnie opóźniają realizację pilnych zadań.

Standardowe pole w rekordzie elementu pracy lub zgłoszenia w większości systemów do zarządzania pracami programistycznymi.

Ten atrybut wskazuje osobę lub grupę odpowiedzialną za wykonanie bieżącego kroku albo całego elementu pracy. W trakcie jego realizacji przypisanie może się zmieniać, odzwierciedlając przekazywanie zadań między różnymi rolami, takimi jak programiści, testerzy QA i osoby przeprowadzające przegląd.

Analiza atrybutu „Przypisano do” pomaga zrozumieć obciążenie zespołu, sprawność przekazywania zadań i sposób współpracy. Można filtrować mapę procesu, aby zobaczyć pracę konkretnej osoby lub zespołu i wskazać wąskie gardła związane z zasobami. Analiza sieci współpracy oparta na przekazywaniu zadań między przypisanymi osobami może ujawnić luki komunikacyjne lub nadmiernie złożone relacje.

Pozwala analizować obciążenie zasobów, częstotliwość przekazywania zadań i sposób współpracy, co pomaga usprawnić pracę zespołu.

Informacje te znajdują się w rekordzie elementu pracy lub zgłoszenia, często w historii elementu albo dzienniku audytowym.

Status elementu pracy programistycznej określa stan elementu pracy w danym momencie. Nazwa czynności opisuje zdarzenie zmiany statusu, a ten atrybut wskazuje sam stan. Może to pomóc w analizie stanu pracy w chwili wystąpienia zdarzenia.

Atrybut ten często służy do tworzenia nazw czynności, ale może też dostarczyć dodatkowego kontekstu. Analiza pola statusu pozwala na przykład sprawdzić, jak długo elementy pozostają w określonym stanie, takim jak „Zablokowany” lub „Oczekuje na przegląd”. Wiedza o czasie spędzonym w stanach nieproduktywnych pomaga wykrywać opóźnienia systemowe i usprawniać przepływ pracy.

Pozwala analizować czas spędzony w różnych stanach, wykrywać opóźnienia i sprawdzać, jak długo elementy pozostają w statusach nieprzynoszących wartości, takich jak „Zablokowany”.

Dostępny jako podstawowe pole w rekordzie elementu pracy lub zgłoszenia. Jest też zapisywany w historii.

Ten atrybut określa rodzaj wykonywanej pracy. Różne typy elementów pracy często przebiegają według innych ścieżek procesu i podlegają odmiennym oczekiwaniom dotyczącym wyników. Na przykład błąd może wymagać szybkiej poprawki, a funkcja przechodzi standardowy cykl programowania i testowania.

Analitycy mogą wykorzystać ten atrybut do porównania przebiegu i wyników procesu dla różnych typów pracy. Pozwala to odpowiedzieć na pytania: „Czy proces naprawiania błędów przebiega szybciej niż tworzenie funkcji?” albo „Czy prace związane z długiem technicznym częściej wymagają poprawek?”. To podstawowy wymiar analizy, który pozwala podzielić dane i uzyskać bardziej szczegółowe, przydatne wnioski.

Umożliwia porównanie przebiegu procesów i wyników dla różnych kategorii pracy oraz wskazanie nieefektywności charakterystycznych dla określonych typów prac programistycznych.

Standardowe pole w rekordzie elementu pracy lub zgłoszenia w większości systemów do zarządzania pracami programistycznymi.

Atrybut „Planowane wydanie” łączy element pracy programistycznej z konkretnym harmonogramem dostaw lub wersją. Często służy do planowania wydań, w których funkcje i poprawki grupuje się z myślą o skoordynowanym wdrożeniu.

Analiza według planowanego wydania pomaga ocenić przewidywalność i niezawodność procesu wydawniczego. Pozwala śledzić terminowość, porównując planowane wydanie z faktyczną datą wdrożenia. Ułatwia też zarządzanie zakresem i analizę prac przeznaczonych do danego wydania, a także wskazywanie zagrożeń i opóźnień, które mogą wpłynąć na termin dostawy.

Łączy prace programistyczne z harmonogramem dostaw, umożliwiając analizę terminowości i przewidywalności wydań.

Standardowe pole, takie jak „Wersja poprawki”, „Wydanie docelowe” lub „Ścieżka iteracji”, w narzędziach do planowania zwinnego i programowania.

Atrybut „Twórca” wskazuje osobę, która zainicjowała element pracy. Może to być menedżer produktu tworzący historyjkę użytkownika, tester QA zgłaszający błąd lub pracownik obsługi klienta przekazujący zgłoszenie klienta.

Analiza osób tworzących elementy pracy pozwala lepiej zrozumieć źródła napływających zadań. Duża liczba błędów zgłaszanych przez użytkowników końcowych może na przykład wskazywać na problemy z jakością ostatnich wydań. Można też ocenić jasność i jakość początkowych wymagań, sprawdzając, czy osoba zgłaszająca wiąże się z późniejszymi poprawkami lub opóźnieniami.

Pomaga wskazać osoby inicjujące pracę i analizować źródła zapotrzebowania, błędów lub zgłoszeń dotyczących nowych funkcji.

Standardowe pole, takie jak „Zgłaszający” lub „Autor”, w rekordzie utworzonym przy rejestracji elementu pracy.

Waga problemu różni się od priorytetu. Określa techniczny wpływ problemu, a priorytet wskazuje pilność jego naprawy. Literówka na rzadko odwiedzanej stronie może mieć niską wagę i niski priorytet, natomiast poważne uszkodzenie danych będzie miało wysoką wagę i wysoki priorytet.

Ten atrybut jest szczególnie przydatny w analizie jakości, zwłaszcza procesu naprawiania błędów. Pozwala ocenić, czy zespół w pierwszej kolejności rozwiązuje najpoważniejsze problemy. Analiza czasu cyklu dla różnych poziomów wagi pomaga sprawdzić, czy krytyczne problemy systemowe są rozwiązywane szybko, aby ograniczyć ich wpływ na klientów.

Pozwala ocenić, jak skutecznie zespół rozwiązuje problemy w zależności od ich wpływu technicznego, i sprawdzić, czy krytyczne usterki są usuwane bez zbędnej zwłoki.

Standardowe pole w systemach do zarządzania pracami programistycznymi, szczególnie dla elementów typu „Błąd” lub „Incydent”.

Wskaźnik poprawek to wyliczany atrybut logiczny lub kategoryczny, który oznacza zdarzenia należące do cyklu poprawek. Zwykle można go ustalić, gdy przebieg procesu cofa się, na przykład z „Testów QA” do „Programowania w toku”, albo gdy występują określone czynności, takie jak „Wykryto konieczność poprawki podczas QA”.

Ten atrybut jest przydatny w analizie jakości i sprawności procesu. Pozwala bezpośrednio obliczać odsetek poprawek i wskazywać etapy, na których powstaje ich najwięcej. Filtrowanie czynności związanych z poprawkami pomaga zespołom ustalić, dlaczego problemy jakościowe nie są wykrywane wcześniej. Ograniczenie liczby poprawek może przyspieszyć prace programistyczne i poprawić jakość produktu.

Pozwala bezpośrednio mierzyć liczbę poprawek, analizować ich przyczyny i śledzić zmiany jakości w czasie.

Zwykle wyliczany podczas transformacji danych na podstawie cofnięć w przebiegu procesu lub nazw czynności wskazujących na niepowodzenie.