Przejdź do głównej zawartości

Retencja

Widżet OTIF: Retencja z czterema wskaźnikami

Retencja mierzy, jaki procent dodanych linii kodu przetrwał, czyli nie został nadpisany ani usunięty, po określonej liczbie dni. W interfejsie widżet nosi nazwę "OTIF - Retencja", od angielskiego on time in full, czyli miary dostarczenia pracy w całości. Odpowiada na pytanie, czy wprowadzane zmiany się utrzymują, czy są szybko poprawiane albo wycofywane.

Wskaźniki​

Cztery warianty tego samego pomiaru, różniące się tylko liczbą dni, po której sprawdzana jest trwałość zmiany:

  • R1: po 1 dniu.
  • R7: po 7 dniach.
  • R30: po 30 dniach. Jedyny domyślnie widoczny w tabelach.
  • R90: po 90 dniach.

Sposób wyliczania​

Dla każdego commita porównywane są dodane linie z tym, co zostało w kodzie po upływie danej liczby dni. Mechanizm rozpoznaje typowe operacje porządkujące historię Gita (merge, squash, rebase, cherry-pick: różne sposoby łączenia i przepisywania historii commitów, które same w sobie nie zmieniają finalnego kodu) i sprawdza właściwą wersję kodu w zależności od tego, czy dany commit trafił finalnie na główną gałąź, żeby nie karać retencji za tego rodzaju standardowe porządkowanie historii.

Wynik dla projektu, zespołu albo uczestnika to średnia ważona liczbą dodanych linii: commit dodający 500 linii ma większy wpływ na wynik niż commit dodający 5.

Okno obserwacji​

Ocena trwałości wymaga odczekania pełnej liczby dni, więc każdy wskaźnik liczony jest na commitach z wybranego zakresu dat przesuniętego o tyle właśnie dni w tył. Przy zakresie ostatnich 14 dni R1 opisuje commity sprzed 1 do 15 dni, a R90 commity sprzed 90 do 104 dni. Każda z czterech liczb ma więc za sobą pełne okno obserwacji, a commit zbyt świeży, żeby ocenić go dla danego wskaźnika, nie wchodzi do niego wcale.

Ma to jedną istotną konsekwencję przy czytaniu: cztery wskaźniki opisują cztery różne zbiory commitów, a nie ten sam kod oglądany w kolejnych momentach. R30 wyższe od R7 nie jest więc błędem, tylko informacją, że kod pisany miesiąc temu okazał się trwalszy niż ten z ostatniego tygodnia.

Interpretacja poziomu Retencji

Wysoka Retencja (blisko 100%) oznacza, że zmiany danej osoby czy zespołu w większości zostają w kodzie. Niska bywa naturalnym elementem pracy i sama z siebie nie mówi o jej jakości: może wskazywać na intensywną iterację, aktywny code review skutkujący poprawkami albo pracę na wciąż zmieniającej się części kodu.

  • Niska R1 i R7 to obraz kodu poprawianego zaraz po napisaniu: bugfixy, uwagi z przeglądu, dopracowywanie świeżo dodanego fragmentu. Przy utrwalonym wzorcu pracy R30 i R90 są wtedy zwykle również niskie, bo linia raz nadpisana już nie wraca.
  • R30 i R90 wyraźnie niższe od R1 i R7 wskazują na zmiany przychodzące z zewnątrz procesu programowania: przebudowy po zmianie wymagań biznesowych, przez które przepisuje się kod, który wcześniej działał.
  • Wysoka R30 i R90 przy niskiej R1 mówi, że praca z poprzednich tygodni się utrzymała, a ostatnie dni były okresem intensywnych poprawek.

Ponieważ agregacja jest ważona liczbą linii, kilka dużych commitów o niskiej trwałości może zdominować wynik mocniej, niż wynikałoby to z samej liczby commitów. Przy nietypowym wyniku warto sprawdzić, czy nie stoi za nim pojedyncza duża zmiana, na przykład import albo masowa migracja.

Poziomy​

Retencja liczona jest dla uczestnika, potem agregowana (tą samą metodą: średnią ważoną liczbą linii, opisaną wyżej) do projektu, zespołu, i osobno jako łączna retencja uczestnika ze wszystkich jego projektów. Ponieważ ta agregacja jest ważona liczbą linii, a nie zwykłą średnią z wyników poszczególnych uczestników, wynik projektu czy zespołu jest zdominowany przez osoby, które w danym okresie dodały najwięcej kodu: uczestnik z niewielkim wkładem liniowym, nawet przy skrajnie niskiej albo wysokiej własnej Retencji, ma niewielki wpływ na wynik całej grupy.

Zobacz też​