Estimate or not estimate?
… przypomina mi to pewną historię. Dawno, dawno temu w pewnym projekcie mieliśmy wyestymować zadania. Po stronie klienta zaczęły pojawiać się wątpliwości dotyczące jakości tych estymat. Zdzwoniliśmy się i zacząłem być przepytywany z każdego zadania, dlaczego tutaj X godzin, a nie Y godzin. Starałem się wytłumaczyć raz po raz, schodząc w detale techniczne, które interesowały klienta. Dało się wyczuć, że nie pasują mu te godziny. Dyskusja poszła w kierunku rozwiązań, które powinniśmy zastosować “aby było szybciej”. Rozmowa zaczęła mnie coraz bardziej bawić, gdyż rozmawiałem z CIO, osobą, która nie napisała linijki kodu od kilkunastu lat. Czara goryczy przelała się w momencie kiedy nad jednym zadaniem rozmawialiśmy już dłuższy czas i żadna argumentacja nie trafiała do klienta.
– To powinno zająć dwie godziny, a nie cztery!
– Tak? Dlaczego tak sądzisz?
– Kiedy byłem programistą to w Visual Basicu zajęłoby mi to dwie godziny
– Tak Joe, dobrze mówisz, byłeś programistą.
( … ) <połączenie zerwane>
Nie minęło 5 minut i wylądowałem u swojego szefa na dywaniku 🙂 ale to już inna historia.
Nie zachowałem się wtedy zbyt profesjonalnie – to fakt. Niemniej poziom dyskusji i irytacji w młodo upieczonym i niedoświadczonym wtedy menadżerze osiągnął swój pułap.
- Straciliśmy kilka dobrych godzin z zespołem na wyestymowanie zadań (liczba członków zespołu x N godzin)
- Straciłem kolejne 2 godziny na tłumaczenie się z każdej estymaty
- Punktem zapalnym okazała się niezgoda co do tego, czy zadanie ma być wykonane w 2, czy w 4 godziny (sic!)
Pomijając to, że odczuwaliśmy mocny “mikromenedżment” od dawna i sam projekt nie zakończył się sukcesem, sytuacja ta utkwiła w mojej pamięci, ponieważ była w mojej ocenie dość absurdalna. Stawialiśmy w tym projekcie na transparentność i zawsze staraliśmy się tłumaczyć techniczne aspekty, których wymagała zmiana biznesowa.
Przemyślenia
Po kilku latach podróży przez różne projekty jeżeli chodzi o wycenę zadań, stawiam sobie kilka pytań i wniosków:
- Wycena zadań zajmuje czas (czy ktoś wycenia czas “wyceny”? <sic!>) – jeżeli czas przeznaczony na wycenę zadania zabiera nam znaczny % czasu z samego wykonywania zadania to czy jest sens wyceniać?
- Często zapominane jest, że wycena to przybliżenie – myślę, że trzeba to mocno podkreślać, tym bardziej jeżeli ktoś będzie nas z nich rozliczał
- Czy mamy wystarczające dane przed wyceną? Często jest tak, że nie wiemy, ile nie wiemy, ale z doświadczenia wiemy, że czegoś nie wiemy 🙂 Wtedy możemy wyceniać w przedziałach. Niemniej, co klientowi po tym, że powiemy, że projekt potrwa od roku do pięciu lat? Moim zdaniem jest to informacja o “niepewności” i ryzykach, które uwzględniliśmy. Jeżeli chcemy tę niepewność zmniejszyć, musimy wchodzić w poszczególne obszary głebiej – ale to też wymaga czasu i nie gwarantuje sukcesu
- Pytanie, które sobie często stawiam – kogo najbardziej interesuje wycena i w jakim kontekście?
- fixed-priced – deklaracja ukończenia projektu w ustalonej kwocie i czasie – tutaj najmniej chcemy się pomylić, a pomylić się jest najłatwiej;
- sprint – chcemy wiedzieć, czy uda się dostarczyć wartość po sprincie – czy potrzeba to przeliczać na godziny? A może lepiej postawić pytanie, ile tej wartości biznesowej uda nam się dostarczyć w sprincie?
- często menadżerowie potrzebują dokładnych planów/harmonogramów – w im dłuższej perspektywie planujemy, tym bardziej będziemy się mylić, stąd podejście do planowania Epic -> Feature -> Story. Skupiamy się mocno na najbliższej przyszłości (story), reszta jest bardzo nieznana, ale znamy pełniejszą perspektywę
- Celowo wyżej napisałem o szacowaniu w godzinach. W projektach “zwinnych” używamy planning pokera, przypisując punkty abstrakcyjne oznaczające wartość skomplikowania (złożoność) zadania, wartość tych punktów można porównać jedynie w kontekście jednego zespołu, który tak samo je rozumie (zakładam, że dotarliśmy się już w tym szacowaniu). To, że zadanie A wyceniliśmy na 5 punktów, nie oznacza, że inny zespół wyceniłby je tak samo. Często też byłem świadkiem mimowolnego przeliczania tych punktów na godziny. Bo przecież skoro nasze velocity wynosi 40 i sprint trwa dwa tygodnie to aż kusi, aby to przeliczać i określić, że 1pkt kosztuje np. 4h – niestety to podstawowy błąd. Główną wartością szacowania przez zespół jest dyskusja o story z różnych perspektyw, biznesowej, technicznej, jak i tego, w jaki sposób powinniśmy je przetestować. Planning poker używa też skali ciągu Fibonacciego, pokazując, że czym więcej punktów przyznajemy estymowanemu zadaniu, tym bardziej możemy się pomylić. Dlatego naszym zadaniem jako zespołu jest rozbijać funkcjonalności na takie fragmenty, aby łatwiej można było przewidzieć czy ukończymy coś w sprincie, czy nie, i ile nam się w nim zmieści.
- Ważna rzecz z wyceną story. Nie robimy story na testy, na przygotowanie skryptów instalacyjnych itp. Wyceniamy story całościowo, z testami, dokumentacją, wdrożeniem itd. czyli wszystkim, co prowadzi do wydania.
Nie jestem zupełnym przeciwnikiem wycen. Po głowie chodzi mi jednak manifest
Dyskusja na temat złożoności zadania i głębsza dekompozycja
ponad
długo ciągnące się niepewne i szczegółowe estymaty
Daniel Dec
Estymaty błędów
Technik i metod wyceny jest bardzo dużo, ale nie chciałem tego wpisu temu poświęcać. Kamila zainspirowała mnie, pytaniem do naszej grupy – “czy estymujemy błędy?”
Błąd wykryty sprincie przy testach story
Nie wyceniałbym tego, tylko naprawiał na bieżąco, tym bardziej, gdy jesteśmy w procesie CI oraz ciągłego testowania. Dosyć paradoksalne byłoby wyceniać błędy, które tutaj powstają, skoro dopiero co wycenialiśmy story. Jeżeli tak się dzieje, jest to dla mnie sygnał, że coś jest mocno nie tak z tym story (np. nie wiemy, co dokładnie robimy, brakuje kryteriów akceptacyjnych, zabrakło dyskusji)
Błędy z produkcji
To ma już większy sens. Zakładam, że to, co zostanie znalezione na produkcji, było mocno nie do przewidzenia (skoro przeszło wszystkie poziomy testów automatycznych, testy eksploracyjne itd.). Błąd z produkcji, jeżeli wpływa na biznes – chcemy wiedzieć kiedy wrócimy do stanu operacyjnego, ważne jest tutaj określenie wpływy błędu na biznes, jego implikacje i zależności. Z grubsza możemy oszacować nawet ten błąd w postaci strat $$$ na godzinę/dzień/tydzień/miesiąc.
Usłyszałem opinię, że błąd ciężko wycenić … wydaje mi się, że dużo ciężej wycenić wprowadzaną zmianę (moje uwagi wyżej) niż skutek, który powoduje awarię i jej naprawę. Jeżeli nie umiemy wycenić błędu z produkcji dla mnie to znak, że straciliśmy kontrolę nad naszym softwarem …
Jak jest u Ciebie w zespole? Kiedy wycena jest “good enough”?