Mało kto lubi szacować pracę, którą ma do wykonania. Ze względu na złożoną naturę wytwarzania oprogramowania, szacowanie zadań bardzo często okazuje się nieprecyzyjne, a zespoły otwarcie przyznają, że zdarza się, że estymaty brane są “z powietrza”. Jeżeli dołożymy do tego pospolitą praktykę traktowania przez management prognozowanych oszacowań jako deklaracji, która zdaje się być podpisana krwią, problem zaczyna nabierać realnych rozmiarów. Marsze śmierci, stres oraz demotywacja to ciemna strona branży IT, często wynikająca z błędnych założeń wejściowych, jeśli chodzi o termin dostarczenia gotowego produktu.
Okazuje się jednak, że nie wszyscy widzą wartość w przeznaczaniu czasu na szacowanie zadań. Osoby takie jak Neil Killick, Woody Zuill czy Vasco Duarte są ewangelistami ruchu nazwanego #NoEstimates, który – jak sama nazwa wskazuje – zachęca to zrezygnowania z szacowania.
Kiedy przychodzi do wytłumaczenia nowej osobie, o co chodzi ze zrezygnowaniem z oszacowań, autorzy sięgają po trzy aspekty #NoEstimates, nazwane “3xE”.
Ethics (etyka) – w tradycyjnym podejściu do szacowania skupiamy się na harmonogramie, deklarujemy zakres oraz czas, dostarczamy (często) niewłaściwe rozwiązanie po zadeklarowanym czasie (równie często), co powoduje osłabienie zaufania.
Empiricism (empiryzm) – zgodnie z Manifestem Agile jedyną sensowną miarą progresu prac jest działające oprogramowanie i na tej podstawie powinniśmy podejmować decyzje (nie na podstawie harmonogramu).
Emergence (ekspozycja emergencja*) – o rzeczywistej wartości dostarczanych rozwiązań dowiadujemy się dopiero po otrzymaniu informacji zwrotnej z rynku lub od klienta.
Jak więc w praktyce rozwijać produkty, nie estymując? Oto kilka wskazówek:
Skupienie na ograniczeniu czasowym oraz budżetowym – w przeciwieństwie do podejścia, w którym skupiamy się na realizacji wcześniej ustalonego planu, #NoEstimates zachęca do skupiania się na iteracyjnym dostarczaniu wartości, gdzie jedynym ograniczeniem jest albo ograniczenie czasowe (“musimy mieć to gotowe przed wakacjami”), albo finansowe (“możemy na to wydać maksymalnie 300 tys PLN”). Takie przestawienie myślenia sprawia, że co iterację dostarczamy zmianę o największej aktualnie możliwej wartości, zamiast tej zaplanowanej z dużym wyprzedzeniem i najprawdopodobniej niekoniecznie najbardziej wartościowej.
Iteracyjne rozwijanie produktu – często pomimo deklaracji zespołów, że “są agile” lub “używają Scruma”, ich Product Backlog jest po prostu sztywną listą wymagań, które trzeba zrealizować, jakby zapominając o iteracyjno-adaptacyjnej naturze procesu wytwarzania. #NoEstimates idzie w kierunku, gdzie Product Backlog traktowany jest jako lista opcji, które realizujemy w iteracjach, a drogę rozwoju kształtuje informacja zwrotna z rynku lub od klienta. Na podstawie przewidywanej wartości biznesowej oraz nabytej w trakcie sprintu wiedzy, podejmujemy kolejne decyzje dotyczące rozwoju produktu.
Skupienie na procesie – pokusa dostarczenia całego zadeklarowanego zakresu produktu może powodować, że zespoły realizują dużo tematów na raz, pozornie optymalizując proces pracy. Rzeczywistość w tej kwestii jest bezlitosna i powoduje, że im więcej rzeczy robimy na raz, tym większy jest koszt przełączania kontekstu. #NoEstimates stawia na limity WIP (ang. Work In Progress), które ograniczają pracę w toku, stawiają nacisk na kończenie zadań, zamiast zaczynania kolejnych, podczas gdy duża ich liczba utyka na etapie “in progress”.
Korzystanie z metryk – #NoEstimates zachęca do mierzenia procesu, np. korzystając z metryki “cycle time”, mówiącej nam ile średnio zajmuje realizacja zadania od momentu rozpoczęcia pracy nad nim, do momentu osiągnięcia gotowości do oddania.
Praca z małymi kawałkami produktu – niejednokrotnie słyszy się w zespołach, że są zadania, których “nie da się podzielić na mniejsze części”. Praktyka pokazuje, że zazwyczaj ograniczeniem nie jest produkt sam w sobie, a sposób myślenia osoby biorącej udział w rozbijaniu wymagań na mniejsze części. #NoEstimates opiera się na pracy na bardzo małych kawałkach, co powoduje, że skoro wszystko co robimy jest małe i zbliżone do siebie, płynnie możemy przejść od klasycznego mierzenia velocity zespołu (suma punktów skończonych zadań per sprint) do mierzenia – po prostu – liczby zmian per iterację.
Pozornie ruch #NoEstimates wygląda jak namowa do zaniechania estymowania i niestety tak często jest odbierana przez jego przeciwników. Gdy jednak bardziej przyjrzymy się tej ideii, jest to tak naprawdę zachęta do zagłębienia się w świat agile’a i spojrzenia na niego z nieco innej perspektywy. Z ciekawie brzmiącego hasła wyłania się bowiem głęboko empiryczne, adaptacyjne podejście do dostarczania wartości, które pomimo wszechobecnej popularności agile’a wcale nie jest tak oczywiste dla przeciętnego zespołu.
Zachęcam do śledzenia hashtaga #NoEstimates na twitterze.
* – trudno mi o lepsze tłumaczenie słowa „emergence” w tym kontekście – jeśli potrafisz przetłumaczyć to lepiej, koniecznie zostaw komentarz.
UPDATE: zmiana nazwy zgodnie z propozycją Bogdana.