Metryki przepływu (czas realizacji / czas cyklu)

Sekcja nosi w interfejsie nazwę "Metryki przepływu (Lead / Cycle Time)" i ustawia globalne granice, dziedziczone przez wszystkie projekty, chyba że projekt ma własne nadpisanie (patrz Projekty). Nie ma tu przełącznika włączającego funkcję: sekcja pojawia się, gdy organizacja ma integrację z systemem ticketowym.

Pola i wartości domyślne

Organizacja, która nigdy nie dotknęła tej sekcji, ma poprawnie liczone Lead i Cycle Time, bo wszystkie granice mają wartości domyślne oparte o natywne kategorie statusów Jiry.

Pole	Domyślnie	Co to oznacza
Początek Lead Time	Utworzenie ticketu	Czas realizacji liczy się od daty utworzenia ticketu, więc obejmuje też czas oczekiwania w kolejce.
Początek Cycle Time	Kategoria "In Progress"	Czas cyklu startuje przy pierwszym wejściu w dowolny status z tej kategorii, na przykład In Progress, In Review albo In Development.
Koniec (Lead i Cycle)	Kategoria "Done"	Oba czasy kończą się przy pierwszym wejściu w dowolny status z kategorii Done, na przykład Done, Closed albo Deployed.
Typy ticketów	puste, czyli "Wszystkie typy ticketów"	Brak filtra: do metryk wchodzą tickety każdego typu.
Kategorie rozkładu przepływu	Improvement, New Feature, Story i Task jako Funkcje, Bug jako Błędy	Wstępna propozycja podziału, na której opiera się widżet Rozkład przepływu.

Alternatywą dla Początku Lead Time jest Punkt podjęcia, czyli lista nazwanych statusów; metryka startuje wtedy przy pierwszym wejściu w którykolwiek z nich. Dla dwóch pozostałych granic alternatywą są Nazwane statusy.

Podział na Funkcje i Błędy

Nazwy typów ticketów należą do systemu ticketowego Klienta, więc Q247 nie rozpoznaje ich automatycznie: Story, Historyjka czy Sub-task są dla platformy zwykłymi ciągami znaków. Rozkład przepływu dzieli tickety na Funkcje i Błędy według przypisania nazw typów do jednej z tych dwóch grup, a wstępna propozycja obejmuje angielskie nazwy domyślne Jiry: Improvement, New Feature, Story i Task jako Funkcje oraz Bug jako Błędy.

Organizacja z własnymi albo przetłumaczonymi nazwami typów musi tę listę uzupełnić, bo dopasowanie idzie po dosłownej nazwie. Pozostałe zasady:

• Typ nieprzypisany do żadnej z grup, na przykład Epic albo Sub-task, raportowany jest jako Inne, więc podział zawsze sumuje się do Prędkości przepływu.
• Ten sam typ nie może należeć do obu grup naraz; zapis takiej konfiguracji jest odrzucany.
• Wielkość liter nie ma znaczenia przy dopasowaniu.
• To grupowanie przy odczycie, więc jego zmiana działa od razu i nie przelicza historii.

Kategoria statusu a nazwane statusy

To rozróżnienie decyduje o poprawności wyników, a z samych nazw pól nie wynika.

Kategoria statusu to grupa, którą prowadzi Jira, i obejmuje wiele statusów naraz. Kategoria "In Progress" złapie więc również statusy nazwane "In Review" czy "In Development", nie tylko ten dosłownie nazwany "In Progress". Dla większości organizacji to właściwy wybór, bo nie wymaga aktualizacji przy każdej zmianie procesu w Jirze.

Nazwane statusy wskazuje się wprost i wtedy zastępują kategorię, a nie sumują się z nią. Jeśli podasz listę statusów, kategoria przestaje być brana pod uwagę. Ten wariant przydaje się, gdy proces w Jirze ma statusy przypisane do kategorii w sposób, który nie odpowiada rzeczywistemu momentowi podjęcia albo zakończenia pracy.

Status bez kategorii nie spełnia granicy opartej o kategorię

Instancje Jira Data Center pozwalają zostawić status bez kategorii ("No Category"). Taki status nigdy nie dopasuje się do granicy kategorii, więc ticket, który przez niego przechodzi, nie dostanie w tym miejscu ani startu, ani końca pomiaru. Jeśli proces ma takie statusy, wskaż granice nazwanymi statusami albo uzupełnij kategorie po stronie Jiry.

Skutki zmiany ustawień

Zmiana	Co się dzieje
Zmiana granicy początku albo końca	metryki są przeliczane wstecz, na całej historii
Zmiana nadpisania w projekcie	to samo przeliczenie, bo granica projektu zastępuje granicę organizacji
Zmiana listy typów ticketów	tylko filtrowanie przy odczycie, bez przeliczania
Zmiana podziału na Funkcje i Błędy	tylko grupowanie przy odczycie, bez przeliczania

Przeliczenie odbywa się na historii zmian statusów, którą Q247 już ma u siebie, więc nie wymaga ponownego pobierania danych z Jiry. Na dużej organizacji zajmuje jednak trochę czasu, więc granice warto ustalić raz, po rozmowie z osobami odpowiadającymi za proces, zamiast dobierać je metodą prób.

Cała sekcja wymaga integracji z Jirą. Więcej o samych metrykach w Metrykach przepływu.