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 podstawowych elementów, choć bynajmniej nim nie jest. Dużo większym problemem jest próba potraktowania velocity jako metryki.

Po co nam metryki

Jeśli dokonujemy świadomej zmiany w produkcie, procesie jego wytwarzania lub organizacji, poszukujemy miary, która pozwoli nam ocenić efekty. Poszukujemy zatem danych, 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, patrzymy na trend zmian w mierzonych parametrach i na tej podstawie oceniamy, czy uzyskaliśmy poprawę, czy pogorszenie sytuacji. Kluczem jest takie wybranie danych, które mierzymy i których wartości poddajemy ocenie, by ich gromadzenie nie zaburzało procesów, jakie opisują, a same wartości nie były podatne na przypadkowe lub celowe przekłamanie.

Metryki, bo o nich mowa, należy zdefiniować i analizować nie tylko wtedy, gdy dokonujemy zmiany przełomowej. Jeśli posługujemy się metodami zwinnymi, zasadniczym celem powinno być ciągłe usprawnianie. To implikuje nieustanne ewolucyjne modyfikacje procesu, zmiany organizacyjne, empiryczny rozwój produktu. Aby wiedzieć, czy przypadkiem nie popadliśmy w stagnację lub wręcz nie ulegamy regresji, ale też by wiedzieć, czy podejmowane usprawnienia faktycznie dają pozytywne efekty – patrzymy na metryki.

Przykładem parametru, który warto mierzyć, jest średni czas jaki mija od momentu zgłoszenia potrzeby lub problemu biznesowego, do chwili jej rozwiązania (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 na ile development jest w stanie reagować szybko na potrzeby biznesowe. Taką metrykę 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 metryki, jest ich wiele, nie jest to wszakże temat na ten wpis.

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 szacunków pracochłonności (czyli „estymat”) tych wymagań, które zostały zrealizowane w jednostce czasu, najczęściej w iteracji (sprincie w Scrumie). Zrealizowanych, a więc takich, na które odpowiada produkt spełniający Definition of Done. Inaczej mówiąc wymaganie zostało zrealizowane, jeśli produkt jaki wytworzyliśmy odpowiada na potrzeby biznesowe opisane tym wymaganiem, i jest w stanie technicznym pozwalającym na jego wydanie i użycie.

Jeśli zatem zespół posługujący się Scrumem w sprincie realizował kilka wymagań, których szacunki pracochłonności wynosiły odpowiednio 3, 5, 8, 8 i 13 story pointów, to gdy 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%, z racji tego, że nie spełnione dla nich zostało Definition of Done, nie uwzględniamy ich w kalkulacji velocity.

Tak samo działa to dla przypadków, gdy zespół posługuje się godzinami, dniami roboczymi, „idealnymi dniami developera” czy jakąkolwiek inną jednostką do oszacowania pracochłonności. Oczywiście jest to nieco nieintuicyjne jeśli mówimy, że prędkość realizowania wymagań z backlogu to… 21 dni. Cóż, sami o to się prosimy, korzystając z oszacowań w takiej formie. Story pointy są jednak dużo użyteczniejsze także w tym aspekcie, bo choć velocity w nich wyrażone jest bezwymiarowe, łatwiej mówić, że prędkość realizacji wymagań wynosi obecnie na przykład 42.

Jednostki nie-liczbowe, takie jak rozmiary koszulek (XXL, XL, L, M, S, XS, XXS) mogą zostać zmapowane do jakichś wartości liczbowych na potrzeby obliczenia velocity. Jeśli korzystamy z podejścia #noestimates, trzeba patrzyć nie na sumę wartości estymat, ale na ilość wymagań zrealizowanych. Tu przypomnienie, że #noestimates nie zakłada braku estymowania (szacowania pracochłonności), tylko dążenie do takiej dekompozycji wymagań, by były one statystycznie porównywalnej wielkości, przez co wartość liczbowa nie jest potrzebna, bo byłaby taka sama dla wszystkich elementów backlogu produktu.

Velocity nie jest użyteczną metryką

Dlaczego? Po pierwsze dlatego, że zmienia się nieustannie, przy czym im jest stabilniejsze, tym lepiej. Urlopy, zwolnienia lekarskie powodują, że tempo realizacji wymagań nie jest stałe. Pamiętać też trzeba, że oszacowania zawsze obłożone są jakimś błędem i często trafiamy na niespodziewany problem, który powoduje, że pracy jest więcej, niż się spodziewaliśmy. To oznacza, że spadek velocity niekoniecznie musi być interpretowany jako objaw, że dzieje się źle, podobnie jak wzrost nie musi oznaczać, że coś usprawniliśmy. Wystarczy, że zaczniemy przypisywać wyższe estymaty do wymagań i już wartość velocity pnie się w górę…

Ponieważ velocity bardzo łatwo przekłamać, użycie jej jako metryki często powoduje, że świadomie lub nie zespół zacznie to robić. To niemal nieuniknione, jeśli ktoś (kierownictwo, a więc ci, co oceniają i przyznają premie pracownikom) przyglądają się metrykom. Jeśli velocity jest jedną z nich, musi być „ładne”, prawda? A skoro musi być, to będzie.

Użycie velocity jako metryki spowoduje tym samym, że wiarygodność szacunków pracochłonności może być niższa, a sam zespół straci cenną informację pozwalającą mu dokonywać usprawnień i planować. Bo o ile dla organizacji czy kierownictwa velocity metryką być nie powinno, zespół sam dla siebie może jej w taki sposób użyć. Bo wie, czy manipulował przy jej wartości, czy nie (czyli czy napompował ją sztucznie, zawyżając oszacowania, czy nie).

Mając wiarygodną informację o prędkości, z jaką udaje się realizować wymagania, można skuteczniej planować zarówno sprinty, jak i wydania.

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, i na tej podstawie wybrać z backlogu produktu wymagania, nad którymi będzie pracował. Na tym etapie nie powinien jeszcze brać pod uwagę velocity z poprzednich sprintów, bo to może spowodować chęć wzięcia przynajmniej tyle samo (lub więcej) w sprincie bieżącym. Dlatego zawsze planujemy oceniając co jest do zrobienia i czy jesteśmy w stanie wykonać to w ciągu iteracji.

Gdy już zespół wybierze wymagania do realizacji (forecast) i wytworzy backlog sprintu (a więc odpowie sobie na pytanie nie tylko co, ale też jak zrobi w kolejnej iteracji), może zsumować oszacowania wybranych do sprintu wymagań (lub policzyć ile ich jest w podejściu #noestimates) i porównać to z velocity ostatniego lub kilku ostatnich sprintów.

Jeśli wartości te są bardzo rozbieżne, jest to sygnał, że coś istotnego zespołowi umknęło. Albo szacunki pracochłonności były zaniżone lub zawyżone i trzeba je urealnić (a będzie to względnie proste, bo już mamy dokładny plan ich realizacji), albo plan jaki wytworzyliśmy jest wadliwy i czegoś w nim za mało, lub za dużo.

Jeśli rozbieżność jest niewielka, być może udaje nam się „przyspieszyć”, czyli począwszy od tego sprintu velocity wzrośnie; albo być może ktoś idzie na urlop, i z racji mniejszej dostępności developerów zrobimy troszkę mniej, niż zwykle.

A do czego velocity wykorzysta Product Owner?

Product Owner może skorzystać z informacji o velocity zespołu za ostatnich kilka sprintów i wyliczyć sobie jego minimum i maksimum. Idealnie jest wziąć pod uwagę około dziesięć ostatnich sprintów (o ile ten zespół z tym backlogiem produktu już tyle pracował, jeśli nie, to bierzemy tyle, ile mamy). W tek próbce można policzyć maksimum jako średnią velocity z trzech sprintów, w których było ono najwyższe, a minimum jako velocity sprintu, w którym najmniej udało się dostarczyć (czyli te sprinty, gdzie nic nie udało się zrobić i prędkość wynosiła równe zero odrzucamy).

Mając już maksymalną i minimalną prędkość realizacji wymagań, można zobaczyć gdzie w backlogu produktu przebiegać będą potencjalne granice przyszłych sprintów. Oczywiście należy pamiętać, że to jedynie projekcja tego, co możliwe, a nie ustalanie, co rzeczywiście będzie robione – bo o tym zespół developerski zdecyduje dopiero podczas planowania iteracji.

W ten sposób Product Owner może dość łatwo i szybko, a jednocześnie całkiem precyzyjnie, odpowiadać na pytania „na kiedy będzie 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.

Gdyby jednak zrobić z velocity metrykę…

…pojawi się presja, by pokazywała ona, że „jest dobrze”. Pojawi się pokusa, by domagać się od zespołu robienia „co najmniej tyle, ile wynosi jego velocity”. Pojawi się pomysł porównywania zespołów, choć przecież ich skala szacowania pracochłonności może być kompletnie różna i wartości velocity również.

To oczywiście nie musi się stać, ale ryzyko jest spore. Niekoniecznie od razu zauważamy, że prędkość, jaką wyliczamy, rośnie bo zawyżamy oszacowania. Jak już zdamy sobie z tego sprawę, ciężko użyć tak wyliczonego velocity do wspomożenia się przy planowaniu iteracji lub do projekcji przyszłych wydań produktu – bo wartości, których używamy, nie są już wiarygodne.