Dzienniki pracy
Tabela w sekcji "Odkryj więcej" zestawia Kalorie wygenerowane przez uczestnika przy danym tickecie z czasem, jaki zalogował w Jira/Tempo. Widoczna na stronie Uczestnik, wymaga skonfigurowanej integracji z Jirą oraz Tempo, bo pobierane są worklogi, których autorem jest Tempo.
Kolumny
| Kolumna | Co mówi |
|---|---|
| Ticket | Identyfikator ticketu. |
| Podsumowanie ticketu | Tytuł ticketu z Jira. |
| Klucz projektu | Prefiks/klucz projektu w Jira. |
| Dzienniki pracy | Liczba osobnych wpisów czasu (worklogów) zalogowanych przez uczestnika przy tym tickecie. |
| Zalogowany czas uczestnika | Suma czasu zalogowanego przez tego uczestnika przy tym tickecie. |
| Zalogowany czas wszystkich użytkowników | Suma czasu zalogowanego przez wszystkich przy tym tickecie. |
| Udział uczestnika w zalogowanym czasie | Zalogowany czas uczestnika ÷ zalogowany czas wszystkich użytkowników. |
| Kalorie uczestnika | Suma Kalorii uczestnika z commitów powiązanych z tym ticketem. |
| Kalorie na zalogowaną godzinę | Kalorie uczestnika ÷ zalogowany czas uczestnika (w godzinach). |
| Przyrosty | Liczba przyrostów uczestnika powiązanych z tym ticketem. |
Kalorie liczone są z commitów, tak jak wszędzie indziej w Q247. Czas zalogowany w Jira/Tempo to osobne, zewnętrzne źródło danych, tylko zestawiane obok siebie w tej samej tabeli.
Wiąże je klucz ticketu odczytany z wiadomości commita: do danego ticketu doliczają się Kalorie tych commitów uczestnika, w których wiadomości ten klucz wystąpił. Commit bez klucza liczy się do metryk uczestnika, ale nie trafi do żadnego wiersza tej tabeli, a zalecany zapis wiadomości opisują Dodatkowe reguły.
Tabela zestawia dwa niezależne źródła danych o tym samym tickecie: co powstało w kodzie (Kalorie) i ile czasu ktoś zadeklarował w Jira/Tempo (Zalogowany czas). Niska wartość Kalorii na zalogowaną godzinę przy danym tickecie nie musi oznaczać niskiej wydajności: równie dobrze może wskazywać na czas spędzony na czymś, co nie zostawia śladu w commitach (analiza, spotkania, testy manualne), zalogowany mimo to na ten sam ticket. Odwrotnie, bardzo wysoka wartość może wskazywać na niedoszacowane logowanie czasu, nie na wyjątkową efektywność.
Udział uczestnika w zalogowanym czasie pokazuje, czy dany ticket był pracą jednej osoby, czy współdzieloną między kilkoma: niski udział przy wielu uczestnikach danego ticketu to normalny obraz pracy zespołowej (code review, parowanie), nie sygnał problemu.
Wczytywanie danych
Dane wczytują się partiami w tle, licznik przy tytule sekcji pokazuje postęp ("Załadowano dane dla X z Y rekordów").
Worklogi pobierane są z Jiry na żądanie, po jednym zapytaniu na ticket, więc czas ładowania zależy od liczby ticketów uczestnika i od czasu odpowiedzi samej Jiry. Przy większej liczbie ticketów pełne wczytanie tabeli może zająć nawet kilka minut. Sekcję można w tym czasie zostawić otwartą i wrócić do niej później, a raz pobrane worklogi są buforowane, więc kolejne otwarcie tego samego uczestnika działa szybciej.