Rozwijanie produktów bez szacowania ich rozmiaru? #NoEstimates

Oszacowania traktowane jako deklaracja

Oszacowania traktowane jako deklaracja

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.

Komentarze do wpisu: “Rozwijanie produktów bez szacowania ich rozmiaru? #NoEstimates

  1. Świetny artykuł, dziękuję za poranną inspirację.

    Ciekawy temat. Pracuję jako PO z dwoma zespołami. Jeden stawia duży opór i nie chce estymować twierdząc, że estymaty bierze z powietrza, drugi jest zadowolony z estymat i wręcz nie chce podjąć się zadania bez wcześniejszych szacowań.
    Wydaje mi się, że przejście do stanu bez estymat wymaga niezwykłej otwartości, głębokiego zaufania między klientem a zleceniodawcą oraz bardzo ścisłej współpracy dającej transparencje.

    Zdanie “nie da się podzielić na mniejsze części” słyszę praktycznie w każdym tygodniu pracy, ale co ciekawe mówi to ten sam zespół, który nieakceptuje estymat. Drugi zespół – estymujący z sukcesami (tzn. tak że mogę skorzystać z estymat), dokonuje też sprawnie podziału zadań. Oba zespoły pracują ze sobą tak samo długo. Natomiast duża różnica jest w wieku poszczególnych członków zespołu.
    Ciekawe czy przychodzące z wiekiem doświadczenie można jakoś zasymulować :).

    • Jacek Wieczorek

      Dzięki Iza za Twój komentarz. Ciekawe obserwacje! Jak te dwa skrajne podejścia do estymowania przekładają się na produkty końcowe?

      BTW, jak znajdziesz odpowiedź na pytanie, które zadałaś na końcu wypowiedzi, koniecznie daj znać 🙂

  2. Jest polskie słowo „emergencja”. Zgrabnym synonimem dla mnie jest „wyłanianie się”, np.: wyłaniające się rozwiązanie, wyłaniająca się architektura, wyłaniający się design.

  3. Jacek Wieczorek

    Dzięki Bogdan! Przyznam, że nie wiedziałem o polskim odpowiedniku. Szukałem pojedynczego słowa, aby utrzymać konwencję „3xE”, Twoja propozycja rozwiązała problem, już zaktualizowałem wpis.

  4. Nalezy pamietac, ze estymacja ma sluzyc bardziej dla zrozumienia wymagan i zlozonosci problemu/zadan niz samej estymacji, prosty przyklad estymacja w Story Points

    • Jacek Wieczorek

      Dzięki za to spostrzeżenie. Liczba powstała w wyniku estymacji to niejako produkt uboczny cennych dyskusji, który nadal może być sensownie wykorzystany podczas planowania – zarówno sprintów jak i wdrożeń produktu. Czyli właściwie mamy dwie pieczenie na jednym ogniu.


Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

*

Ta strona używa Cookies. Korzystając ze strony wyrażasz zgodę na używanie ciasteczek zgodnie z aktualnymi ustawieniami przeglądarki.
Akceptuję, bo lubię Was czytać.
x