Sytuacja kobiet w IT w 2024 roku
23.03.20226 min
Amanda Quint

Amanda QuintCo-Founder and Fullstack Developer

3 metryki do mierzenia programistycznego postępu inne niż Velocity

Wszystkie metryki mają wady i zalety, a dane można interpretować na różne sposoby. Poznaj 3 metryki inne niż Velocity.

3 metryki do mierzenia programistycznego postępu inne niż Velocity

Jeśli pracowałeś w zwinnym środowisku rozwoju oprogramowania, prawdopodobnie znasz koncepcję pomiaru prędkości działania zespołu.

Velocity to metryka, którą można mierzyć w story pointach lub godzinach i która może pomóc odpowiedzieć na pytanie, czy zespół pracuje w stałym tempie, a także dać wyobrażenie o tym, ile pracy zespół może dostarczyć w ciągu iteracji.

Przykładowo, jeśli zespół utrzymywał średnie tempo na poziomie 25 punktów na sprint przez kilka ostatnich sprintów, można ogólnie założyć, że będzie utrzymywał podobne tempo później, o ile nic drastycznie się nie zmieni (nowy projekt lub narzędzia, zmiana członków zespołu itd.). Choć w grę mogą wchodzić również inne czynniki, oznacza to, że ukończenie projektu, który według szacunków ma zawierać 100 punktów historyjek użytkownika, zajmie im około 4 sprinty.

Velocity to ważna metryka dla wielu zespołów programistycznych, ale z mojego doświadczenia wynika, że często jest to najważniejsza metryka w zarządzaniu – często kosztem pominięcia pozostałych aspektów.

Oto kilka innych programistycznych metryk, które warto wziąć pod uwagę, analizując dane swojego zespołu.

Earned Business Value

Być może spotkałeś się z sytuacją, w której twój zespół ma wysoką, stałą velocity i praca jest wykonywana, ale twoi klienci (lub zespół sprzedaży) nie widzą wartości, która pojawia się w całym systemie.

Czasami może to oznaczać, że Twój zespół koncentruje się na nie zawsze widocznych długach technologicznych lub poprawianiu drobnych błędów — a obie te rzeczy są dobre! Musisz jednak pamiętać, aby zachować równowagę pomiędzy pracami nad refaktoryzacją a pracami, które przynoszą wartość interesariuszom Twojego produktu.

Jednym ze sposobów na to jest wykorzystanie Earned Business Value (EBV) dla każdej historyjki. Aby wykorzystać tę metrykę, musisz przypisać każdej z wyróżniających się historyjek swojego produktu wartość punktową z ogólnej puli punktów.

Załóżmy, że na drodze twojego produktu znajdują się 3 nowe funkcje: Funkcja A, Funkcja B i Funkcja C. Każda funkcja składa się z podzbioru mniejszych historyjek użytkownika, ale mają one różną złożoność.

Współpracujesz z interesariuszami i ty decydujesz, ile punktów jest do zdobycia. Może to być dowolna liczba, ale warto, aby była ona na tyle duża, aby nie kończyła się w połowie punktów. W tym przykładzie użyjemy 1000 punktów.

Teraz Twój interesariusz przechodzi do poszczególnych elementów pracy i przypisuje im wartości punktowe. Punkty są przypisywane do najmniejszych jednostek pracy na podstawie tego, jak dużą wartość dla firmy będzie miało wykonanie każdego zadania. Wartość ogólniejsza każdego elementu jest sumą wartości jego dzieci.

W tym przykładzie oczywistym jest, że zespół powinien zacząć od funkcji A, następnie funkcji C, a potem funkcji B. Może się jednak zdarzyć, że skoro historyjka A1 otwiera większość wartości funkcji A, to historyjkę A2 można odłożyć do czasu, gdy funkcje B i C zostaną ukończone.

Podobnie jak Velocity, EBV może pomóc w tworzeniu wykresów burnup/burndown, ale zamiast tylko przepracowanych punktów, uzyskuje się również wgląd w to, ile wartości produktu zostało dostarczone.

Jedną z wad EBV jest to, że wymaga ona aktywnego zaangażowania interesariuszy w proces rozwoju, posiadających wiedzę pozwalającą na przypisywanie wartości historyjkom. Zamiast pomocy aktywnego interesariusza można spróbować przypisać historyjkom punkty za pomocą techniki MAUT, w celu określenia względnego priorytetu.

Czas cyklu

Być może twój zespół kończy średnio 25 story pointów w każdym sprincie, ale interesariusze skarżą się, że elementy nigdy nie zostają ukończone. W takiej sytuacji warto sprawdzić czas cyklu.

Czas cyklu to średni czas potrzebny do ukończenia pojedynczego elementu pracy; rozpoczyna się w momencie utworzenia elementu, a kończy się, gdy element zostanie ukończony. W powyższym przykładzie możesz wykonywać mnóstwo pracy w każdym sprincie, ale jeśli pracujesz tylko nad historyjkami, które powstały dwa lata temu, twój czas cyklu będzie naprawdę długi.

Znając czas cyklu, jesteś w stanie oszacować, kiedy dana jednostka pracy może zostać ukończona. Jeśli czas cyklu dla elementów o zwykłym priorytecie wynosi cztery tygodnie, to prawdopodobnie nowa historyjka o zwykłym priorytecie zostanie wykonana w ciągu około czterech tygodni.

Przydatne może być także obliczenie odchylenia standardowego czasu cyklu. Spójrz na historyjki, dla których zapisaliśmy czas cyklu w dniach.

  • Średni czas trwania cyklu wynosi 20 dni (lub 4 tygodnie).
  • Odchylenie standardowe wynosi około 4,5 dnia, co można zaokrąglić w górę do 1 tygodnia.


Oznacza to, że większość Twoich historyjek mieści się w przedziale czasowym 3-5 tygodni. Może być to przydatne zarówno w planowaniu przyszłej pracy, jak i w identyfikacji historyjek nietypowych (trwających krócej niż 3 tygodnie lub dłużej niż 5), które warto przeanalizować – lub wyrzucić z przyszłych obliczeń. Sytuacja taka dotyczyłaby historyjki nr 5 z powyższego przykładu, której ukończenie zajęło tylko 2 tygodnie.

Przepływ kumulacyjny

Jeśli Twój zespół dostarcza 25 punktów na sprint, to czy liczba zrealizowanych punktów sumuje się płynnie w trakcie sprintu, czy też w magiczny sposób skacze z 3 punktów do 25 w ostatnich dwóch dniach sprintu? Najlepiej byłoby, gdyby liczba punktów rosła przez cały czas trwania sprintu, ale sprawdzenie przepływu kumulacyjnego projektu może pomóc w znalezieniu wąskich gardeł w całym procesie.

Diagramy przepływu kumulacyjnego mogą być początkowo trudne do zrozumienia, ale mogą dostarczyć wielu przydatnych informacji. Weźmy jako przykład taki oto sprint. Poniższa tabela pokazuje, ile było historyjek w każdym statusie w danym dniu sprintu (zauważ, że początkowo jest 10 historyjek, ale szóstego dnia sprintu dodaje się jedenastą).

W powyższej tabeli zespół ma w tym procesie pięć kontenerów (bucket): Backlog, In-Progress, Reviewing, Pre-Release i Completed. W miarę postępu sprintu elementy pracy są przenoszone z Backlogu, aż w końcu zostają ukończone (completed). Poniższy wykres przepływu kumulacyjnego przedstawia to w formie graficznej.


Co taki wykres może nam powiedzieć o tym sprincie?

  • W danym dniu można zobaczyć, jak rozmieszczone są elementy pracy. Na przykład w szóstym dniu łatwo zauważyć, że mamy prace na wszystkich pięciu etapach w realizacji, a większość z nich jest In progress.
  • Ponieważ zarówno Reviewing, jak i Pre-Release są dość wąskie, a za nimi rośnie coraz to większa kolejka, może to wskazywać na wąskie gardła, choć dla pewności należałoby to porównać z danymi z innych sprintów.
  • Szerokość pasm informuje o tym, ile czasu elementy są w określonym stanie i pomaga określić największe elementy składowe ogólnego czasu cyklu.


Przepływ kumulacyjny dobrze współgra z innymi metrykami, takimi jak czas cyklu, ponieważ umożliwia sprawdzenie, które części procesu zajmują najwięcej czasu. Pozwala to na zidentyfikowanie problematycznych obszarów; Jeśli „Testing” jest tą częścią procesu, która zajmuje najwięcej czasu, być może twojemu zespołowi przydałby się dodatkowy Test Engineer.

Podsumowując

  1. Aby większość metryk dotyczących oprogramowania miała sens, zespół musi być stabilny. Oznacza to, że nie można dodawać ani usuwać członków zespołu, ani też pracować z zespołem, który przez ostatni rok pracował nad stosem A, i nagle przydzielać go do pracy nad stosem B, oczekując takich samych rezultatów.
  2. Najbardziej przydatne metryki mogą się zmieniać w zależności od funkcji pełnionej przez zespół.Jeśli pracujesz z zespołem, który pracuje głównie nad usuwaniem usterek, jego priorytety (a więc i metryki) będą wyglądały inaczej niż w przypadku zespołu, który koncentruje się głównie na dostarczaniu nowych funkcji i funkcjonalności.
  3. Wszystkie metryki mają wady i zalety– a dane można interpretować na różne sposoby. Jest to jeden z powodów, dla których dobrze jest stosować różne metryki, aby uzyskać różne spojrzenia na to, co dzieje się w zespole i aby nie polegać zbytnio tylko na jednej metryce.


Mam nadzieję, że te informacje okazały się pomocne i jestem bardzo ciekawy, czy ty też masz jakąś ulubioną metrykę w swoim zespole.


Oryginał tekstu w języku angielskim przeczytasz tutaj.

<p>Loading...</p>