Metryki kondycji
Metryki kondycji opisują sposób pracy zespołu: jak duże są pull requesty, czy przechodzą przez review, jak długo czekają na merge i czy praca dzieje się w godzinach pracy.
Każda z pięciu metryk pokazuje udział procentowy pracy mieszczącej się w przyjętej normie. Pojedynczy projekt czy zespół dostaje na tej podstawie jedną z czterech ocen kondycji, widoczną na Pulpicie, na Zespołach oraz w nagłówku własnej strony.
Jednostką pomiaru jest tu projekt albo zespół, nigdy pojedyncza osoba. Metryki kondycji opisują proces wytwarzania, a nie wkład uczestników, i nie dają się rozbić na oceny indywidualne.
Metryki kondycji są w wersji beta. To rozwiązanie będziemy jeszcze zmieniać i usprawniać, więc w kolejnych wydaniach mogą zmienić się wartości progów, zestaw samych metryk oraz sposób prezentacji wyników.
Dane źródłowe pozostają te same, bo metryki liczą się z tych samych commitów i pull requestów co pozostałe statystyki w Q247.
Metryki kondycji pojawiają się dopiero po włączeniu ich przez administratora w Konfiguracji i wymagają Enterprise Plugin w wersji q247-enterprise-plugin-linux-v2.4.2 lub nowszej.
Na Pulpicie sekcję widzi osoba mająca dostęp do danych całego projektu, czyli rola Manager albo Viewer, oraz menedżer gałęzi struktury obejmującej ten projekt. Rola Member, czyli zwykły uczestnik, nie widzi więc sekcji kondycji.
Na Zespołach sekcję widzi osoba zarządzająca przynajmniej jednym zespołem. Pełny model ról opisują Uprawnienia.
Pięć metryk kondycji
Cztery z nich liczone są z pull requestów: Zbyt duże PR-y, PR bez recenzji, Zaległe PR-y i Błyskawiczne PR-y. Piąta, Aktywność w nadgodzinach, liczy się ze zdarzeń w commitach i w dokumentacji, zestawionych z kalendarzem pracy organizacji.
| Metryka | Co pokazuje | Zdrowy od | Krytyczny poniżej | Minimalna próbka |
|---|---|---|---|---|
| Zbyt duże PR-y | udział pull requestów mieszczących się w progu rozmiaru | 90,0% | 85,0% | 5 zmergowanych PR |
| PR bez recenzji | udział pull requestów, które przeszły przez review | 75,0% | 60,0% | 5 zmergowanych PR |
| Zaległe PR-y | udział zrecenzowanych pull requestów rozstrzygniętych w terminie | 85,0% | 75,0% | 5 zmergowanych PR |
| Błyskawiczne PR-y | udział pull requestów, które nie zostały zmergowane natychmiast | 85,0% | 75,0% | 5 zmergowanych PR |
| Aktywność w nadgodzinach | udział pracy wykonanej w godzinach pracy | 85,0% | 75,0% | 25 zdarzeń |
Wartość między progiem krytycznym a progiem zdrowia daje stan Obserwacja. Wszystkie progi ustawia administrator, osobno dla całej organizacji, na stronie konfiguracji.
Zbyt duże PR-y
Udział pull requestów, których rozmiar mieści się w progu. Domyślnie za zbyt duży uznawany jest pull request powyżej 450 Kalorii.
Metryka liczy udział liczby pull requestów, więc jeden bardzo duży pull request waży dokładnie tyle samo, co każdy inny przekraczający próg.
Przy kilkuset zmienionych liniach recenzent przestaje czytać zmianę i zaczyna ją przeglądać. Uwagi schodzą wtedy na poziom formatowania i nazw, a realne błędy logiki przechodzą dalej.
Rosnący udział zbyt dużych pull requestów zapowiada więc spadek jakości review, zanim jeszcze widać go w liczbie błędów.
Organizacja może mieć ustawiony próg ukrywania przyrostów, który chowa bardzo duże przyrosty z wykresów i statystyk. Cztery metryki liczone z pull requestów pozostają poza jego zasięgiem, bo pull request jest zapisem cyklu życia zmiany, a nie przyrostem.
Przy metryce rozmiaru jest to dodatkowo zamierzone: to właśnie wielkość pull requesta jest tutaj przedmiotem pomiaru.
PR bez recenzji
Udział pull requestów, które przed mergem przeszły przez review, liczony wśród wszystkich pull requestów zmergowanych w okresie.
Za dowód review uznawane są dwie rzeczy: formalne review wystawione przez inną osobę oraz merge wykonany przez kogoś innego niż autor. Drugi przypadek odpowiada praktyce, w której druga osoba przegląda zmianę i od razu ją merguje, bez zostawiania formalnego wpisu.
Nie liczy się natomiast jako review merge wykonany przez samego autora, przez jego alias ani przez konto techniczne, czyli bota lub konto serwisowe.
Review jest ostatnim momentem, w którym błąd kosztuje minuty zamiast godzin. Pull request bez niego przenosi cały ciężar wykrycia na testy i na produkcję, a wiedza o zmianie zostaje u jednej osoby.
Zaliczenie review przez sam fakt merge'a dotyczy wyłącznie tej metryki. Zaległe PR-y i Błyskawiczne PR-y patrzą na co innego, więc ten sam pull request może mieć tutaj status zrecenzowanego i jednocześnie wpadać w Błyskawiczne PR-y.
Zaległe PR-y
Udział pull requestów rozstrzygniętych w akceptowalnym czasie, liczonym od momentu zgłoszenia gotowości do review. Domyślnie za akceptowalne uznawane są 2 dni robocze, z dokładnością do części dnia.
Do tej metryki wchodzą wyłącznie pull requesty z formalnym review, wystawionym przez recenzenta. Tożsamość osoby mergującej nie ma tu znaczenia.
Pull request leżący tydzień wymusza powrót do kodu, którego nikt już nie pamięta. Autor odtwarza kontekst od nowa, recenzent czyta zmianę oderwaną od decyzji, które ją tłumaczyły, a gałąź w tym czasie rozjeżdża się z główną.
Zaległe pull requesty przedłużają więc cały proces bardziej, niż wynikałoby z samego czasu oczekiwania.
Mianownik obejmuje wszystkie stany pull requesta: otwarte, zmergowane i zamknięte bez merge'a. Dla pull requesta wciąż otwartego czas liczy się do chwili obecnej, więc leżąca od tygodnia zrecenzowana zmiana pogarsza wynik już teraz.
Błyskawiczne PR-y
Udział pull requestów, które nie zostały zmergowane natychmiast po zgłoszeniu. Domyślnie za merge natychmiastowy uznaje się 1 minutę od zgłoszenia gotowości.
Metryka patrzy wyłącznie na czas. Obecność review i osoba mergująca nie mają tu znaczenia, więc pull request zrecenzowany, ale zmergowany w kilkanaście sekund od zgłoszenia, także zostanie policzony jako błyskawiczny.
Merge w ciągu kilkudziesięciu sekund oznacza zwykle, że pull request powstał jako formalność, a praca trafiła do gałęzi głównej bez realnego przejrzenia. Metryka wyłapuje ten wzorzec i dlatego jej próg liczony jest w minutach.
Aktywność w nadgodzinach
Udział zdarzeń wykonanych w godzinach pracy organizacji. Poza godzinami pracy liczą się wieczory, noce, weekendy i święta, wszystko zgodnie z kalendarzem pracy.
Ta jedna metryka nie korzysta z pull requestów. Sięga po zdarzenia w commitach i w dokumentacji, w tym po commity ręcznie przywrócone do statystyk oraz pracę z gałęzi wyłączonych ze skanowania, których pozostałe widoki nie pokazują.
Cztery stany oceny
| Stan | Na karcie węzła | Kiedy występuje |
|---|---|---|
| Zdrowy | ZDROWY | wszystkie ocenione metryki na poziomie progu zdrowia lub wyżej |
| Obserwacja | OBSERWOWANY | przynajmniej jedna metryka między progiem krytycznym a progiem zdrowia |
| Krytyczny | KRYTYCZNY | przynajmniej jedna metryka poniżej progu krytycznego |
| Brak danych | BRAK DANYCH | żadna metryka nie zebrała minimalnej próbki |
Ocena węzła według najgorszej metryki
Projekt czy zespół dostaje ocenę najgorszej ze swoich ocenionych metryk. Cztery metryki w stanie Zdrowy i jedna w stanie Krytyczny dają węzłowi ocenę Krytyczny.
Taki sposób liczenia sprawia, że ocena zbiorcza jest sygnałem, gdzie zajrzeć. Konkretną przyczynę pokazują dopiero pigułki poszczególnych metryk w nagłówku strony projektu albo zespołu.
Minimalna próbka
Metryka, która nie zebrała minimalnej próbki, nie dostaje stanu i nie wchodzi do oceny węzła ani do zestawień zbiorczych. Cztery metryki z pull requestów potrzebują 5 zmergowanych pull requestów, Aktywność w nadgodzinach potrzebuje 25 zdarzeń.
Wymóg próbki jest stały dla wszystkich organizacji. Administrator zmienia progi, ale nie minimalną próbkę.
Gdy żadna metryka nie przejdzie tej bramki, węzeł dostaje stan Brak danych. Na poziomie pojedynczej metryki stan ten nie ma własnej pigułki: osobna karta, pozycja w podsumowaniu i odcinek paska rozkładu dotyczą całego węzła.
Do progu 25 zdarzeń każde dziesięć zdarzeń dokumentacyjnych liczy się jak jedno. Próg 25 odpowiada więc 250 zdarzeniom w samej dokumentacji, a commity liczą się pojedynczo.
Miejsca, w których widać kondycję
| Widok | Postać |
|---|---|
| Pulpit | sekcja "Przegląd kondycji projektów", węzłami są projekty |
| Zespoły | sekcja "Przegląd kondycji zespołów", z przechodzeniem w głąb struktury |
| Projekt | pigułka Kondycja: {stan} w nagłówku strony |
| Zespół | pigułka Kondycja: {stan} w nagłówku strony |
Pigułki pojedynczych metryk pojawiają się w nagłówku tylko dla metryk w stanie Obserwacja i Krytyczny. Projekt oceniony jako Zdrowy ma więc obok pigułki kondycji puste miejsce i jest to poprawny widok.
Repozytoria wyłączone z pomiaru
Pojedyncze repozytorium można wyłączyć z metryk kondycji na liście Źródeł. Wyłączone repozytorium nie wchodzi do żadnej z pięciu metryk, na żadnym poziomie i w żadnym oknie czasowym, a jego projekt nie liczy się też do podsumowania liczby węzłów.
Wykluczenie obejmuje wyłącznie metryki kondycji. Te same commity i pull requesty w tym samym okresie pozostają widoczne na wykresie, w Obciążeniu, w Adopcji AI, w statystykach projektu i uczestnika, w indeksach dynamiki pracy oraz w Retencji.
Zmiana progów a dane historyczne
Zmiana progów przez administratora obowiązuje również dla okresów sprzed zmiany, bo stany wyliczane są od nowa przy najbliższym przeliczeniu.
Historia ocen nie jest przechowywana osobno, więc po obniżeniu progu projekt oceniony wcześniej jako Krytyczny może pokazać stan Obserwacja także dla dat wstecz.
Zobacz też
- Progi Health Check: ustawienia progów i wykresy rozkładu
- Źródła: wyłączanie pojedynczych repozytoriów
- Kalendarz pracy: godziny pracy i święta
- Kalorie, Przyrosty i Linie: jednostka, w której mierzony jest rozmiar pull requesta