Blog

Gdy Zespoły zaczynają stosować metodyki zwinne, prawie natychmiast pojawia się dyskusja na temat prędkości, z jaką przetwarzany jest Backlog Produktu, a więc na temat velocity Zespołu. Jeśli wykorzystywana jest metoda Scrum, velocity przez wielu traktowana jest jako jeden z jego podstawowych elementów, choć bynajmniej nim nie jest. Dużo większym problemem jest próba potraktowania velocity jako miary opisującej działanie Zespołu lub rozwój produktu.

Po co nam miary

Jeśli dokonujemy świadomej zmiany w produkcie, procesie jego wytwarzania lub organizacji, poszukujemy sposobu oceny uzyskanych efektów. Chcemy posiadać dane, które obrazują rzeczywistość przed i po zmianie, aby w obiektywny sposób móc zmierzyć, co się zmieniło. Jeśli nie dysponujemy danymi historycznymi, z którymi moglibyśmy porównać bieżący stan spraw, patrzymy na trend zmian w mierzonych parametrach i na tej podstawie oceniamy, czy uzyskaliśmy poprawę, czy pogorszenie sytuacji. Kluczem jest takie wybranie parametrów, których wartości poddajemy ocenie, by ich gromadzenie nie zaburzało procesów, jakie opisują, i aby uzyskiwane wartości nie były podatne na przypadkowe lub celowe przekłamanie.

Miary, bo o nich mowa, należy zdefiniować i monitorować nie tylko wtedy, gdy dokonujemy zmiany przełomowej. Jeśli posługujemy się metodami zwinnymi, zasadniczym celem powinno być ciągłe usprawnianie. Taka jest implikacja stosowania empiryzmu w rozwoju produktu – konieczne bywają modyfikacje procesu, wprowadzanie zmian organizacyjnych, sięganie po nowe praktyki itd. Aby wiedzieć, czy przypadkiem nie popadliśmy w stagnację lub wręcz nie ulegamy regresowi, ale też, by wiedzieć, czy podejmowane usprawnienia faktycznie dają pozytywne efekty – patrzymy na wartości zbieranych miar.

Przykładem parametru, który warto mierzyć, jest czas, jaki mija od momentu zgłoszenia potrzeby lub problemu biznesowego, do chwili dostarczenia produktu lub usługi, który na tę potrzebę odpowiada. Lead time tak zdefiniowany obejmuje nie tylko czas samej pracy, ale również te okresy, kiedy wymaganie czeka, by ktoś się nim zajął. Tym samym jest to dobra miara tego, w jakim stopniu development jest w stanie reagować szybko na potrzeby biznesowe. Taką miarę ciężko przekłamać – bo kalendarz jest bezwzględny i czas płynie, czy nam się to podoba, czy nie; jedynym sposobem usprawnienia – czyli skrócenia tego czasu – jest poprawa procesu tak, by lead time był rzeczywiście krótszy.

Oczywiście to tylko jeden przykład miary; jest ich wiele i zasługują na omówienie w osobnym artykule.

Czym jest velocity?

Jak wspomniałem na początku, jest to prędkość, z jaką Zespół realizuje wymagania, które Product Owner umieścił w Backlogu Produktu. Jak się ją wyznacza? Jest to suma oszacowań tych wymagań, które zostały zrealizowane w jednostce czasu, najczęściej w iteracji (Sprincie w Scrumie). Zrealizowanych, a więc takich, które doczekały się zaspokojenia za pomocą produktu spełniającego ustalone kryteria ukończenia (Definition of Done w Scrumie).

Oczacowania, o których mowa, bywają określane również szacunkami, wycenami albo estymatami – różne Zespoły posługują się tu różną terminologią. Forma tych oszacowań też bywa różna: mogą to być znane z tradycyjnych metod dni robocze (oszacowania czasochłonności), story pointy (bezwymiarowe jednostki do porównania relatywnej wielkości wymagań), function pointy (bezwymiarowe jednostki do porównywania relatywnej złożoności rozwiązań) itd.

Przyjmijmy, że Zespół szacuje wymagania z użyciem story pointów i podjął do realizacji w Sprincie kilka wymagań, którym przypisał następujące wielkości: 3, 5, 8, 8 i 13 punktów. Jeśli udało się zrealizować tylko pierwsze trzy wymagania, a dla pozostałych prace nie zostały jeszcze ukończone, velocity wynosi 3 + 5 + 8 = 16 story pointów. Nawet jeśli dwa nieskończone wymagania zostały zrealizowane w 90%, jeśli nie doczekały się rozwiązania, nie uwzględniamy ich w kalkulacji velocity.

Tak samo działa to dla przypadków, gdy Zespół posługuje się godzinami, dniami roboczymi czy jakąkolwiek inną formą szacowania. Oczywiście jest to nieco nieintuicyjne, gdy mówimy, że prędkość realizowania wymagań z Backlogu to 21 dni, ale można się do tego przyzwyczaić.

A jeśli oszacowania wyrażone nie za pomocą liczb, tylko tekstowo lub symbolicznie (np. mogą to być rozmiary koszulek XXL, XL, L, M, S, XS, XXS)? Można przypisać każdej z takich wartości oszacowania jakąś wartość liczbową i w ten sposób dokonać obliczenia velocity.

Velocity nie jest przesadnie użyteczną miarą

Dlaczego? Po pierwsze dlatego, że podstawą do jego wyliczenia są oszacowania, które z definicji obarczone są błędem, różnym dla każdego wymagania. Zmienność velocity w jakimś okresie nie musi wcale oznaczać, że Zespół pracuje szybciej lub wolniej, ale może być pochodną zmiany sposobu estymowania wymagań. Ciężko więc wyciągać daleko idące wnioski na podstawie zmierzonej prędkości.

Jest to też miara mocno zależna od wielu czynników, na które Zespół po prostu nie ma wpływu. Velocity w Sprincie, w którym ludzie byli na urlopach lub zwolnieniach lekarskich jest niższe nie dlatego, że Zespół pracuje wolniej, ale dlatego, że mniej jest osób, które pracę mogą wykonywać. Dlatego analizując trendy zmian prędkości należałoby pewnie pamiętać, kto i kiedy był dostępny lub nieobecny.

Największą słabością velocity jest jednak to, że można bardzo łatwo uzyskać jego zmianę lub konkretną wartość, jeśli tylko pojawi się taka potrzeba. Jest za niskie? Wystarczy podnieść oszacowania wymagań i robiąc tyle samo, co zwykle, albo i mniej, uzyska się wyższą wartość velocity.

Czasami Zespół dokonuje takiej manipulacji nieświadomie, ale zdarza się, że jest to reakcja na oczekiwania kierownictwa, które za pomocą velocity próbuje oceniać efektywność działań Developerów. Ucierpi na tym wiarygodność oszacowań, jakie przypisywane są wymaganiom, bo celem będzie wykreowanie pożądanej wartości miary, a nie lepsze przygotowanie do planowania Sprintów. Zwiększenie poziomu niepewności w Sprintach utrudni działanie Developerom, więc aby zapobiec spadkowi velocity, być może zaczną oni na wszelki wypadek podwyższać oszacowania. W efekcie mierzona prędkość będzie utrzymywać się na wysokim poziomie, przy jednoczesnym spadku realnego tempa prac.

Informacja o prędkości bywa użyteczna, o ile nie traktuje się jej jako miary postępu prac, sukcesu biznesowego, wartości produktu, efektywności Zespołu, jego skuteczności w działaniu czy produktywności. Jest ona wyłącznie miarą prędkości, z jaką Zespół konsumuje Backlog Produktu, a i to pod warunkiem, że nie dojdzie do jej nieświadomego lub celowego zafałszowania.

Przy pomocy wiarygodnej wartości velocity, można nieco lepiej planować Sprinty, jak i sporządzać prognozy ukończenia poszczególnych elementów Backlogu Produktu. W praktyce istnieją lepsze narzędzia, które można wykorzystać w tym celu (np. miary przepływu, jakimi posługuje się Kanban i sporządzanie na ich odstawie symulacji Monte Carlo, aby tworzyć prognozy o znanym poziomie niepewności).

Do czego Zespół może użyć velocity?

Podczas Planowania Sprintu (lub ogólniej iteracji) Zespół powinien zawsze kierować się realną oceną tego, co jest możliwe do zrobienia w czasie, jakim będzie dysponował, za pomocą posiadanych środków i siłami ludzi, którzy będą dostępni. Dokonując wyboru elementów Backlogu Produktu, jakie podjęte zostaną do realizacji, nie ma sensu kierować się informacją o velocity z poprzednich Sprintów z dwóch powodów.

Po pierwsze, może to może spowodować chęć uzyskania prędkości takiej samej lub większej w Sprincie bieżącym. Efektem może być wciągnięcie do Sprintu za dużej ilości pracy tylko dlatego, że suma jej oszacowań nie przekracza typowej wartości velocity. Może też okazać się, że Developerzy nie zdecydują się na realizację wymagania bardzo prostego tylko dlatego, że jego oszacowanie jest zbyt wysokie. A przecież estymaty często okazują się nietrafione i nie powinny stanowić jedynej podstawy do podejmowania decyzji o zakresie prac w Sprincie.

Po drugie, może dojść do zastąpienia dyskusji merytorycznej o tym, co da się zrealizować przed końcem Sprintu, dyskusją o tym, czy oszacowania są właściwe. Efektem może być plan „uzyskania określonego velocity”, a nie dostarczenia wartościowego produktu.

W istocie nie tylko velocity, ale nawet same oszacowania są mało istotne w trakcie Planowania Sprintu. Przydają się do zarządzania Backlogiem Produktu i sporządzania prognoz na potrzeby interesariuszy itd., ale nie determinują, co jest możliwe do zrealizowania w Sprincie. Tym bardziej że oszacowań dokonuje się zwykle z pewnym wyprzedzeniem, w ramach pielęgnacji Backlogu Produktu, gdy nie wiadomo jeszcze ani kto, ani kiedy, ani jak będzie poszczególne wymagania realizował. Ba, nie sposób w momencie szacowania przewidzieć również tego, jaki będzie stan produktu, narzędzi i praktyk wtedy, gdy realizacja wymagania ostatecznie się rozpocznie.

A to oznacza, że tak naprawdę każde z podejmowanych do realizacji wymagań Developerzy muszą w trakcie Planowania Sprintu na nowo oszacować. I jest to inny szacowania niż ten stosowany przy pielęgnacji Backlogu Produktu – bardziej szczegółowy, oparty o konkretny plan działania określonej grupy ludzi w ograniczonym czasie. I przede wszystkim skupiony na ocenie czasochłonności działań, które trzeba będzie wykonać.

Zamiast więc kierować się oszacowaniami, Developerzy powinni zacząć budować plan działania w Sprincie i ocenić, czy są w stanie go skutecznie zrealizować w czasie, jakim dysponują. A dopiero gdy powstanie prognoza Sprintu (ang. Sprint forecast), która wydaje się racjonalna, można posłużyć się wiedzą o velocity i oszacowaniami podjętych do realizacji wymagań, aby dokonać dodatkowego sprawdzenia.

Jeśli velocity, jakie uzyskałby Zespół w wyniku realizacji prognozy, jest dużo wyższe lub niższe od typowego, jest to sygnał, że być może coś istotnego Zespołowi umknęło. Albo oszacowania wymagań są nietrafione i trzeba je urealnić (a będzie to względnie proste, bo już istnieje przecież plan ich realizacji), albo plan jest wadliwy i czegoś w nim za mało lub za dużo.

Przy czym dopóki rozbieżność w spodziewanym velocity i tym uzyskiwanym zazwyczaj nie jest ekstremalnie duża, nie trzeba na siłę zmieniać prognozy Sprintu. Pamiętać trzeba, że prędkość wyliczana jest z oszacowań, które są wynikiem prób odgadywania przyszłości. To oznacza, że bardziej niepokojąca byłaby sytuacja, gdy Zespół Sprint po Sprincie uzyskuje taką samą velocity, niż że w każdej iteracji jest ona nieco inna.

A nawet jeśli rozbieżność jest ogromna, jeśli Developerzy oceniają, że sporządzona prognoza Sprintu jest realistyczna, nie muszą jej zmieniać. Velocity stanowi przecież jedynie narzędzie diagnostyczne i ma pomagać, a nie być wyznacznikiem tego, co i jak ma robić Zespół.

A do czego velocity wykorzysta Product Owner?

Product Owner może skorzystać z informacji o velocity Zespołu do prognozowania, kiedy poszczególne elementy Backlogu Produktu mogą zostać zrealizowane.

Potrzebna jest do tego wiedza nie tylko o prędkości w ostatnim Sprincie, ale jej minimalną i maksymalną wartość z ostatnich kilku iteracji. A najlepiej, by Product Owner wziął pod uwagę dziesięć ostatnich Sprintów (o ile ten Zespół z tym Backlogiem Produktu już tak długo pracował).

Ustalając wspomniane maksimum velocity, Product Owner może wyliczyć średnią wartość z trzech Sprintów, w których było ono najwyższe. Podobnie da się ustalić minimum jako średnie velocity z trzech iteracji, w których było ono najniższe. W ten sposób da się uniknąć sięgania po wartości skrajne (np. zerowe velocity), a wciąż uwzględnić można ich wystąpienie przy sporządzaniu prognoz.

Mając już maksymalną i minimalną prędkość realizacji wymagań, można nałożyć na Backlog Produktu w jego aktualnym stanie granice przyszłych Sprintów. Robiąc to z użyciem velocity maksymalnego, Product Owner otrzyma prognozę optymistyczną, a z velocity minimalnym pesymistyczną. Oczywiście należy pamiętać, że to jedynie projekcja tego, co możliwe, a nie ustalanie, co rzeczywiście będzie robione – bo Backlog Produktu może dowolnie się zmienić, a każdy Sprint jest planowany dopiero w momencie jego rozpoczęcia.

Używając velocity w ten sposób Product Owner może dość łatwo i szybko, a jednocześnie całkiem precyzyjnie, odpowiadać na pytania „kiedy zostanie ukończone to konkretne wymaganie?” lub „jakie wymagania zostaną zrealizowane w kolejnych trzech Sprintach?”. Mając te odpowiedzi oraz świadomość potrzeb biznesowych (priorytetów), Product Owner może przesuwać wymagania w Backlogu Produktu w górę lub dół tak, by najefektywniej wykorzystać czas pracy Developerów i zapewnić dotrzymanie ewentualnych terminów, jeśli takie zostały wytyczone przez interesariuszy.

Gdyby jednak zrobić z velocity miarę…

…pojawi się presja, by pokazywała ona, że jest dobrze. Pojawi się też pokusa, by domagać się od Zespołu robienia co najmniej tyle, ile wynosi jego velocity. Być może zrodzi się pomysł porównywania Zespołów poprzez porównywanie ich prędkości, choć przecież skala szacowania stosowana w każdym z nich może być kompletnie różna, a zatem i wartości velocity również.

To oczywiście nie musi się stać, ale ryzyko jest spore. Niekoniecznie od razu zauważamy, że velocity staje się narzędziem nacisku z jednej strony, a manipulacji z drugiej. Jak już zdamy sobie z tego sprawę, ciężko użyć tak wyliczonego velocity do wspomożenia się przy planowaniu iteracji lub do sporządzania prognoz, bo wartości miary, jakimi dysponujemy, nie są już wiarygodne.