Czy dokładniejsza analiza i więcej czasu spędzone nad wymaganiem zawsze przekłada się na precyzyjne oszacowanie? I po co w ogóle nam dokładne, precyzyjne szacunki co do detali wykonywanej pracy? Oj, dzisiaj będzie kontrowersyjnie…
O szacowaniu słów kilka
Aż dziw bierze, że o szacowaniu mamy do tej pory popełniony tylko parę tekstów – o Story Points, o Planning Pokerze i jeszcze kilka innych. Jednak kategoria #szacowanie świeci pustkami. Owszem, pisaliśmy także o velocity i innych miarach, ale nie zastanawialiśmy się nad istotą samego szacowania. Jak pewnie się domyślacie, to właśnie będzie tematem dzisiejszego tekstu.
Zanim jednak zagłębimy się w fundamentalne rozważania, cofnijmy się na chwilę do początków naszej agile’owej przygody. Nie wiem jak Was, ale mnie na pewno przekonywano, że szacowanie w podejściu zwinnym nie dotyczy tylko i wyłącznie miary czasowej. W oszacowaniu wielkości pracy uwzględniamy także takie czynniki jak niepewność wymagań, ryzyko, zmienność, doświadczenie zespołu, itp.
Zwinne szacowanie stoi niejako w poprzek do klasycznie rozumianego podejścia do harmonogramowania zadań. W tym drugim przypadku chcemy dokładnie wiedzieć kto będzie nad czym kiedy pracował. Chcemy ułożyć harmonogram, zapewnić przekazywanie efektów pracy z jednego zespołu do drugiego i brak opóźnień. Brzmi trochę kanbanowo, gdzie zakładamy, że robimy rzeczy powtarzalne.
W naszej domenie (systemy złożone), niestety nie da się z góry określić precyzyjnie czasu niektórych czynności. Tylko przecież my nie harmonogramujemy prac linii produkcyjnej, gdzie musimy konkretnie wiedzieć, który element spędzi ile czasu na którym stanowisku.
Nam wystarczą przybliżenia.
Po co szacujemy?
Uwielbiam fundamentalne pytania z gatunku „Po co?”, które zmuszają nas do myślenia. Albo irytują, zależy jak patrzeć. Pytanie „Po co szacujemy?” jest bardzo trudne, bo dla każdego odpowiedź będzie inna. Na pewnym poziomie jednak zawsze będzie chodziło o to samo – chcemy się upewnić, że przedsięwzięcie za które się zabieramy w ogóle jest możliwe do realizacji.
Czasami będzie chodziło o czas, czasami będzie chodziło o pieniądze, a czasami o jeszcze inne aspekty. Ale rzadko kiedy odpowiedź będzie „bo potrzebujemy precyzyjnie ułożyć harmonogram prac”. Tego w podejściu zwinnym raczej nie praktykujemy. Skoro na wstępie założyliśmy, że nasz sposób pracy będzie ewoluował, a wymagania będziemy poznawać w trakcie prac nad rozwiązaniem, to szaleństwem byłoby zakładać, że z góry wszystko wiemy.
Zwykle operujemy przybliżeniami, które pozwalają nam na trafne podejmowanie decyzji. To tak jak z objazdową wycieczką zagraniczną – chcemy wiedzieć czy trasa jest realna oraz czy wystarczy nam pieniędzy. Ale już detale w rodzaju ile czasu spędzimy w którym mieście albo czy więcej wydamy na drinki czy na hotele – to już zupełnie wtórne rzeczy. One będą ważne na poszczególnych etapach, ale nie na etapie decydowania o tym czy w ogóle pojechać.
Im więcej mam styczności ze zwinnością (i „zwinnością”) na poziomie dużych firm i korporacji, tym bardziej zaczynam doceniać Release Planning. Bardzo często Sprint to za mało – rzeczy, które robimy są znacznie bardziej skomplikowana niż tylko dwa tygodnie. Z drugiej strony planowanie się szczegółowo na dwa lata do przodu to abstrakcja. Z każdą kolejną iteracją będziemy tylko coraz bardziej rozjeżdżać się z harmonogramem. Ale wcale nie znaczy to, że będziemy robili coś źle.
Czy więcej znaczy lepiej?
Łukasz przekonywał, że „worse is better„. Ja mówię – znajdźmy złoty środek. Wiadomo, że w wariancie minimum musimy umieć wyszacować nasze wymagania zerojedynkowo. Albo się mieszczą w Sprincie, albo się nie mieszczą. Potem dochodzi kwestia tego, ile jesteśmy w stanie zrobić w tym czasie. I to jest ok dla zespołu, ale już za mało dla Product Ownera czy całej organizacji.
Chcemy wiedzieć, na ile możemy liczyć w najbliższych kilku miesiącach oraz jakoś planować odległą przyszłość. I tu dość naturalne jest, że nie potrzebujemy precyzji w szacowaniu prac, które będziemy realizować kiedyś tam. Ponownie – interesuje nas poziom „czy to w ogóle jest realne”. I jeżeli będziemy w stanie oszacować na przysłowiowych „grubych klockach”, to jest to ten poziom „good enough„.
„Potrzebujemy więcej czasu na analizę, to wtedy wyszacujemy dokładniej.”
Pamiętajmy, że nawet jeśli spędzimy całe tygodnie na analizie tematu, to i tak mogą pojawić się niespodzianki. Ponadto, jeżeli nasz „przeanalizowany temat” będzie leżał i czekał na realizację, to się zestarzeje zanim weźmiemy się za robotę i będzie potrzebna kolejna analiza, żeby dostosować go do nowych realiów. Mówiąc wprost – nie ma sensu dokładnie analizować tylko i wyłącznie po to, aby coś wyszacować.
Z drugiej strony, jeżeli będziemy strzelać w ciemno, to możemy rozminąć się o rząd wielkości albo nawet o kilka. Więc jakieś rozpoznanie tematu jest potrzebne. Pytanie tylko, czy na pewno tak precyzyjne jak się niektórym wydaje. Śmiem twierdzić, że do oszacowania pracochłonności potrzebny jest nam tylko i wyłącznie refinement, a nie szczegółowa i precyzyjna analiza.
W szczególności do dużych tematów planowanych na kilka miesięcy do przodu potrzebujemy o-sza-co-wa-nia, a nie precyzyjnego określenia pracochłonności. Oszacowania ze swojej natury są przecież przybliżeniami.
A co z pieniędzmi?
Na koniec zajmijmy się jeszcze jednym tematem, od którego nie sposób uciec. Musimy płacić za wykonywane prace. Co więcej, często też potrzebujemy budżetować prace, które będą wykonywane w przyszłości. Czy nasze oszacowania mogą nam w tym pomóc?
I tak, i nie. Z jednej strony w pewnej skali nasze szacunki zaczynają się uśredniać. Jeden Sprint jednego zespołu może się rozjechać całkiem sporo. Ale dziesięć Sprintów dziesięciu zespołów prawdopodobnie będziemy w stanie oszacować bardzo dokładnie. Wracamy tu do motywu przewodniego dzisiejszego tekstu, czyli „odpowiedniej precyzji szacowania”.
Pamiętajmy jednak, że nasze szacunki mogą nam powiedzieć o tym „ile” będziemy w stanie zrealizować w założonym budżecie, ale niekoniecznie musza nam określić „co” powstanie. Backlog przecież zmienia się cały czas. Więc nawet jeżeli zmieścimy się w oszacowanym budżecie, to niekoniecznie musimy zrealizować to, co szacowaliśmy. Zmiany wymagań są częste i spodziewane.
Ufff, chyba wystarczy tych rozważań na dzisiaj. Jeżeli sprawiłem, że rozpoczniecie u siebie dyskusję na temat „Po co w ogóle potrzebne nam są oszacowania?”, to będę zadowolony. W końcu całe to bycie agile, to nic innego niż zdrowy rozsądek. Którego życzę Wam jak najwięcej w Waszym otoczeniu.
