Velocity – uważaj co mierzysz! 

Velocity to chyba najczęściej nadużywany agile’owy miernik. Gdzie nie pojawia się Scrum, tam zaraz management chce wiedzieć jak szybko zespoły realizują wymagania. Po co i co to ma wspólnego z agile?

Czym jest Velocity?

Lubimy rozpoczynać nasze posty na blogu od słowniczka. Czasami nawet poświęcamy całe teksty na próbach zdefiniowania znaczenia pewnych słów. „Metodologia, metodyka, metoda” to idealny tego przykład. Dziś jednak definicja posłuży nam jako pretekst do dyskusji o miernikach.

Velocity należy rozumieć dosłownie. Tłumacząc te słowo z angielskiego, zwykle użyjemy wiernego, polskiego odpowiednika „prędkość”. Przeważnie będziemy mówić o „velocity zespołu”, bo ta miara interesowała będzie nas najbardziej.

„Prędkość” idealnie wpisuje się w scrumowe Sprinty. Skoro mamy „sprint”, czyli szybki bieg, to prędkość powinna być istotna. Wydawałoby się, że im szybciej będziemy biec, tym szybciej dotrzemy do mety. Oczywiście, o ile biegniemy w dobrym kierunku i po drodze nie stracimy tchu.

Prędkość (ang. Velocity) – średnia liczba zrealizowanych wymagań w jednej iteracji.

Velocity najczęściej używane jest w parze ze Story Points. Jeżeli mamy wymagania wycenione w punktach, to prędkość poszczególnych zespołów będzie wyrażana w punktach na Sprint. Jeżeli zaś wszystkie nasze wymagania zapisane są np. jako User Story o podobnej pracochłonności, to Velocity możemy liczyć po prostu w liczbie historyjek zrealizowanych per Sprint.

Co mierzy Velocity?

Velocity mówi o prędkości realizacji elementów z backlogu. Pozwala nam prognozować kiedy zabierzemy się za które wymaganie, o ile oczywiście ich kolejność nie ulegnie większym zmianom.

„Stable Velocity. Sustainable Pace.” – Mike Cottmeyer

Jeżeli realizujemy od 3 do 5 wymagań per Sprint, to wymaganie które jest dziesiąte na liście w najlepszym wypadku trafi do realizacji na Sprint n+2. W wariancie pesymistycznym dopiero na Sprint n+4. W najgorszym zaś wypadku nie zostanie ono zrealizowane nigdy, jeżeli do backlogu ciągle będą trafiały wymagania o wyższym priorytecie.

Oczywiście takie prognozy możemy robić tylko i wyłącznie pod warunkiem, że mamy zrównoważone i stabilne tempo. Jeśli w jednej iteracji realizujemy 5 punktów, w drugiej 35, to jakiekolwiek plany możemy wyrzucić do śmieci. Najpierw musimy zająć się rozwiązaniem problemu chaotycznego, nierównego tempa prac.

Prędkość wcale nie jest jedynym istotnym wskaźnikiem w dążeniu do celu. Liczy się również kierunek. Jeżeli bardzo szybko poruszamy się w przeciwną niż zakładana stronę, to po prostu skutecznie oddalamy się od celu. Rzeczy, które powodują zboczenie z trasy mają negatywny wpływ na naszą realną prędkość, nawet jeśli wydaje się, że robimy mnóstwo kilometrów.

Tak samo w przypadku agile’owego Velocity powinniśmy zwracać uwagę na kierunek. To, że robimy „dużo i szybko”, to za mało. Czy robimy to dobrze? Czy utrzymujemy wysoką jakość? Czy w ogóle nasza praca się komuś przydaje? Nie ma nic gorszego niż wykonanie „dobrego kawałka nikomu niepotrzebnej roboty”. Dodajmy do tego jeszcze plagę nadgodzin w Scrum, dokręcania śruby i zwiększania tempa i mamy przepis na katastrofę.

Miary gorszego sortu

Mierzenie Velocity nie jest nam do niczego potrzebne. Chociaż niewątpliwie bywa przydatne, to nie jest to cel sam w sobie. Ani nasza organizacja, ani nasz agile’owy projekt nie osiągnie większego sukcesu tylko dlatego, że zespoły pracują z większym Velocity.

Co gorsza, mierząc i publikując prędkość poszczególnych zespołów wpływamy na sposób pracy ludzi w naszej organizacji. Nietrudno sobie wyobrazić ambitne jednostki, które będą próbowały podnosić prędkość przez kreatywną księgowość czy inflację punktową. Wiele przykładów na takie ludzkie zachowanie daliśmy już w tekście o motywacji.

Celem każdej komercyjnej organizacji jest zarabianie pieniędzy. W takiej sytuacji miary pierwszego rzędu to zysk, przychód i koszty. Miara drugiego rzędu to np. liczba zamówień. Nie powinniśmy skupiać się na optymalizacji miar dalszych rzędów, bo wpadniemy w pułapkę, którą opisywaliśmy już mówiąc o motywacji. Nasi pracownicy będą robić wszystko w celu zapewnienia zadowalającego poziomu wskaźników, zamiast działać na korzyść przedsiębiorstwa.

Jeżeli przedsiębiorstwo traci na każdym zamówieniu, to zwiększanie liczby zamówień skończy się większymi stratami.

Podobną sytuację czasami widzimy w projektach agile. Zespoły skupiają się na ograniczaniu Work In Progress, pilnowaniu wydarzeń Scrum, zwiększaniu Velocity, ale nikt nie patrzy na to, czy wykonywana praca przynosi faktyczną korzyść. Jest to wina zbytniego przywiązania się do nieistotnych mierników.

Każdą metrykę można łatwo wypaczyć. Wystarczy, że skupimy się na liczbie, a nie na tym, co ona reprezentuje. I niestety Velocity przoduje, jeśli chodzi o błędne wykorzystanie cyfr w zarządzaniu zwinnymi projektami.

Użyteczność Velocity

Velocity nie jest stałą wartością – zmienia się co Sprint. Niektórzy zamiast średniego Velocity z całego projektu używają „kroczącej prędkości”. Wyliczana jest ona zawsze z kilku ostatnich Sprintów. W ten sposób uwzględniane są wszystkie zmiany w zespole, technologii i samym projekcie.

Inni próbują określić „rzeczywistą prędkość” odejmując dni wolne od pracy, urlopy i niespodziewane przeszkody. Próbują na jego podstawie szacować, jaka będzie prędkość zespołów w przyszłości. I jedni i drudzy kompletnie zapominają o czarnych łabędziach. Przeszłość daje nam jedynie wskazówki co do tego, jak może wyglądać przyszłość. Nie jest w stanie jej przewidzieć.

„Działające oprogramowanie jest podstawową miarą postępu.” – Agile Manifesto

I tu wracamy do tego, co właściwie mierzymy i po co. Interesuje nas gotowe, wdrożone, działające na środowisku produkcyjnym i używane przez klientów oprogramowanie. Velocity nic nam nie mówi o jego użyteczności, o korzyściach płynących dla klienta ani nawet o tym czy nasza praca została faktycznie wdrożona.

Jedyne do czego możemy używać miary drugiego rzędu, jaką jest Velocity, to prognozowanie okresu w którym Zespoły Deweloperskie będą realizowały poszczególne wymagania. Taka prognoza, pod warunkiem stabilnego tempa, to nie punkt w czasie, ale zakres „od” (liczony według maksymalnego historycznego Velocity) „do” (minimalna historyczna prędkość).

A prognozy, jak wiemy, nie zawsze się sprawdzają.

Tematykę prędkości, a także innych miar i czyhających w związku z nimi pułapek poruszamy na naszych szkoleniach Scrum i agile.