Przejdź do treści

Doc Norton: Uciec od velocity.

Velocity jest bardzo zmienne i jedocześnie używamy go do prognozowania przyszłości – jak długo zajmie implementacja jakiejś funkcjonalności.

Zacznijmy od definicji: ilość wykonanej pracy w danym czasie.

Velocity to lagging indicator. To może pokazywać trendy ale nie powinno być używane do predykcji. Jednocześnie mamy do czynienia ze złożonym środowiskiem co nie da się określić jedną liczbą. Taka jedna wartość nie daje nam wystarczająco dużo informacji by stwierdzić czy projekt jest „zdrowy”.

Zwiększanie velocity można osiągnąć w różny sposób – najłatwiej poprzez chodzenie na skróty, co prowadzi tylko do problemów. Dlatego nie wolno stawiać celu „zwiększania velocity”. Najczęściej pomysły na takie cele pojawiają się na poziomie managerskim – nie róbmy tego.

Velocity jest używane do odpowiedzi na pytanie „kiedy to będzie zrobione?” – nawet nie na pytanie dotyczące jak długo to zajmie. Wtedy bierzemy velocity z kilku ostatnich sprintów, obliczamy średnią i wizualizujemy za pomocą burn up lub burn down. Moment w którym prognozowana linia przecina się z linią ilości pracy do wykonania – uznajemy to za datę ukończenia. Jak bardzo możesz ufać tak wykonanej prognozie?

Zamiast tego używajmy prognozowania statystycznego Monte Carlo.

Na zmienność velocity ma wpływ wiele czynników. Jednym z nich jest dług techniczny a w zasadzie „odroczone dbanie o kod”. To co możemy zmierzyć to skomplikowanie kodu, które dodatkowo jest pozytywnie skorelowane z ilością defektów. Możemy zmierzyć ilość defektów na produkcji. Możemy zmierzyć ilość (częstość) wypuszczania rzeczy na produkcję. Możemy zmierzyć coupling – jak bardzo zależne od siebie są elementy systemu. Możemy mierzyć ilość pracy w toku – im więcej pracy tym większa różnorodność velocity. Używaj Cumulative Flow Diagram, na którym można zobaczyć dużo użytecznych informacji.

Metryki nie są dla managerów. Metryki są dla zespołu.”

Źródło: https://www.youtube.com/watch?v=4W2YSQ26Vqk