Co daje szacowanie relatywne zespołowi?

Jednym z celów estymacji (szacowania) zadań w Scrum jest pozyskanie przez Zespół Deweloperski informacji, jak wiele zadań mogą “włożyć” do Sprintu (iteracji), który trwa od 1 tygodnia do 1 miesiąca. Scrum różni się w związku z tym od tradycyjnych metodyk gdzie estymacja często jest robiona na początku trwania projektu i dotyczy całego jego przebiegu.

W tym wpisie, który jest kontynuacją moich poprzednich dotyczących estymowania (metody wyceny wymagań, jak wytłumaczyć szacowanie relatywne) chcę wam przybliżyć korzyści jak i wady estymowania relatywnego.

Na początku chcę Wam jeszcze raz przybliżyć pojęcia estymacji relatywnej (szacowania relatywnego) i estymacji klasycznej.

Warsztaty Labirynty Scruma, 9-10 grudnia we Wrocławiu

Z estymacją klasyczną możecie się spotkać częściej się w projektach realizowanych według tradycyjnych metodyk. Polega ona na oszacowaniu czasu trwania danego zadania w roboczogodzinach lub roboczodniach (ang. mandays). Spotkałem się ze stwierdzeniem, że szacowaniem zadań w sposób klasyczny jest tylko iluzją dokładności i przewidywalności.

Z etymowaniem relatywnym mamy do czynienia w metodykach zwinnych (np. Scrum) i polega na porównywaniu zadań między sobą (albo bardziej do jednego reprezentatywnego). Określona wartość dla danego zadania jest nazywana estymatą. Ale nie zawiera ona w sobie tylko pracochłonności, jak w podejściu klasycznym, ale także trudność w realizacji, czas trwania (zadanie może być proste, ale długotrwałe w robieniu), ryzyka (np. “nigdy wcześniej nie zmienialiśmy nic w tym obszarze aplikacji i nie znamy go”).

Dalej skupię się już tylko na podejściu relatywnym i ewentualnych jego zaletach, tudzież wadach w kontekście całego Zespołu Scrumowego (Zespół Deweloperski oraz Właściciel Produktu i Scrum Master).

Scrum został wymyślony bazując m.in na obserwacji, że budowa oprogramowania (ang. software development) jest bardzo skomplikowana. W złożonym środowisku przewidywanie przyszłości, nawet tej niedalekiej jest czasami niemożliwe.

To prowadzi nas do wymienionych poniżej wniosków dotyczących estymat:

  • dokładne estymaty złożoności zadania (nie tylko czasu trwania) są niemożliwe – nawet szczegółowe techniki nie przewidzą wszystkich scenariuszy, potencjalnych problemów, zdarzeń w otoczeniu zewnętrznym mogących wpłynąć na naszą pracę,
  • żadna estymata nie może uzyskać gwarancji jej niezmienności – estymata jest prostą predykcją bazującą na informacjach znanych Zespołowi. Pojawiające się nowe informacje, zdobywanie przez Zespół nowej wiedzy i nowego doświadczenia może tą estymatę znaczącą zmienić,
  • czas spędzony nad estymowaniem zadań może być czasem straconym (ang. waste) – innymi słowy estymata może się dramatycznie zmienić pod wpływem nowych informacji lub dane zadanie może w bardzo pesymistycznym scenariuszu być nawet usunięte z Rejestru Produktu,
  • estymaty zadań są wynikiem rozmowy Zespołu Deweloperskiego. I ten punkt jest chyba najważniejszy, ponieważ rozmowa nad danym zadaniem pozwala zespołowi “wyrównać” wiedzę na jego temat. Innymi słowy estymowanie zadań jest formą budowania wspólnego zrozumienia przez Zespół Deweloperski danego wymagania, pracy z nim związanej, idei za nim stojącej. Kiedy zespół ma problem z estymowaniem danego zadania, nie jest to problem estymacji, ale problemem zrozumienia danego wymagania, jego domeny, produktu.

Czytając powyższe podpunkty możecie dojść do wniosku, że estymaty zadań są zbędne (kiedyś natknąłem się na stwierdzenie Esther Derby, które podsumowuje to zdanie –  „Estimating is often helpful, estimates are often not” ). I w jakimś stopniu to jest racja (ale patrz ostatni w.w podpunkt). Poświęcanie wiele czasu na proces, który z natury i tak jest błędny jest stratą czasu. Lepiej poświęcić go na budowę wartościowego oprogramowania i użycie wymienionego wcześniej empiryzmu celem nauczenia się domeny, kodu, produktu, który chcemy rozwinąć lub zbudować.

Zalety estymat relatywnych dla Product Ownera

  • mniejszy czas potrzebny na estymację  przez Zespół Deweloperski, porównując go z czasem estymacji w podejściu klasycznym
  • możliwość przewidywania przyszłości z jakimś prawdopodobieństwem (raczej małym, czytając moje wyżej wymienione tezy)

Wady estymat relatywnych dla PO

  • dokładność
  • wymyślona skala, co może prowadzić do błędnego zrozumienia przez interesariuszy

Zalety estymat relatywnych dla Zespołu Deweloperskiego

  • krótszy czas potrzebny na estymację porównując go z czasem estymacji w podejściu klasycznym,
  • dużo łatwiej, wg badań, szacować ludziom coś porównując do czegoś innego, niż robić ten proces bez żadnej skali porównawczej,
  • bazowanie na skali nie dotyczącej tylko czasu (najczęściej jest to ciąg Fibonaciego) ale również ww, innych elementów,
  • unikanie “napompowania” czasu trwania zadania – często w metodykach tradycyjnych estymacja zadań uwzględnia “ryzyko”, czyli jest ona podnoszona przez Project Managera, bazującego na swoim lub organizacji doświadczeniu, o jakiś konkretny współczynnik (np. wszystkie estymaty zespołu są mnożone razy 1.5!),
  • estymacja relatywna jest dokładniejsza (mimo tego, co możecie przeczytać wyżej) od estymacji klasycznej. We wcześniejszych wpisach dotyczących tego tematu podawałem Wam linki do badań dotyczących tego zagadnienia. Wpadło mi w ręce jeszcze jedno badanie, z którym możecie zapoznać się tutaj,

Wady estymat relatywnych dla Zespołu Deweloperskiego

  • dokładność, podobnie jak w przypadku perspektywy Product Ownera,
  • niezrozumienie procesu estymacji przez interesaruszy i uważanie przez nich wyestymowanej złożoności zadania za niepodważalne zobowiązanie; nie dopuszczanie głosu, że estymata może się zmienić,

Jest jeszcze jeden aspekt, o którym warto wspomnieć. Cały ten post jest mocno skierowany ku braku szacowania. Nie jest moim zamiarem przekonanie Was do tego typu praktyki, jednakże gdybyście chcieli spróbować, powinniście być świadomi całego nurtu #NoEstimates. Szczegółowo opisywał ten ruch i jego założenia Jacek, w jednym z jego wcześniejszych wpisów. Nie chcę tutaj wywołać dyskusji czy ruch i podejście, które promuje, jest dobre. W zamian chce Wam na zakończenie pokazać pewien alternatywny sposób szacowania zadań:

  1. Wyznacz, ile zadań możecie jako zespół w sprincie zrealizować. Przykładowo, z danych historycznych wiecie, że zespół średnio kończy 6 – 8 zadań per sprint
  2. Wyznacz koszyki dla odpowiedniej wielkości zadań. Przykładowo koszyki mogą nosić oznaczenia rozmiarów koszulek (XL, L, M, S)
  3. Przypisz odpowiednie zadanie już zrealizowane do odpowiedniego koszyka, czyli przykładowo 2 zadania w koszyku L, 3 zadania w koszyku M, 2 zadania w S
  4. Przypisz odpowiednie zadanie planowane do odpowiedniego koszyka, czyli przykładowo 1 zadanie w koszyku XL, 3 zadania w koszyku L, 1 zadanie w koszyku M, 1 zadanie w S. Uwaga: zadania muszą być w miarę jednakowej wielkości (Jak je podzielić? Odpowiedź znajdziecie w jednym z moich poprzednich wpisów)
  5. Potwierdź z Zespołem Deweloperskim, że faktycznie taką ilość planowanej pracy chce wziąć na najbliższy sprint i dobrze się z nią czuje

PS. Trzy kropki są w tym wpisie celowo. Jest to miejsce, które zostawiłem na Wasze wady i zalety szacowania w perspektywie opisywanych ról. Podzielcie się nimi w komentarzach!

Źródła zdjęć: flickr.com udostępnione na licencji CC BY-NC-ND 2.0

Komentarze do wpisu: “Co daje szacowanie relatywne zespołowi?

  1. Dorzucę w takim razie coś od siebie w temacie zalet/wad estymat relatywnych:

    Zarówno dla PO jak i dla DEV nie można w prosty sposób badać dokładności estymat relatywnych w celu wyciągnięcia wniosków na temat tego co spowodowało taką, a nie inną dokładność/niedokładność i co powinniśmy zrobić, żeby lepiej szacować (retrospektywa?). W ujęciu klasycznym możemy powiedzieć: Story X: estymacja = 8h, faktyczna zmierzona realizacja = 16h. To pokazuje, że faktycznie realizacja kosztowała 100% więcej (czasu) niż zakładaliśmy. Dlaczego? to osobny temat …Mimo wszystko w zespołach DEV częstą praktyką jest raportowanie czasu pracy przepracowanego w projektach (np. w celu rozliczenia się z klientem za „użyte” godziny pracy, wymagania organizacji itp). Często takie raportowanie odbywa się własne na poziomie ticketu z jakiegoś issue trackera (Gitlab, JIRA, itp.) który albo sam w sobie jest już jakimś elementem Backlogu (Story) albo jego częścią. Stąd można czerpać informacje zarówno o całkowitej estymacji takiego elementu Backlogu oraz faktycznego kosztu jego realizacji.

    Innym aspektem estymacji klasycznej jest jest powtarzalność i dokładność wraz ze stopniem zaawansowania produktu (całkowitego czasu implementacji) lub/i wraz z reużywalnością komponentów softwareowych. Jeśli zespół DEV implementuje kolejną z serii funkcji, która nie różni się znacząco od już gotowych, to w prosty sposób bazując na wiedzy o przeszłości można oszacować czas realizacji nowej funkcji w jednostkach czasu. Podobnie sprawa ma się z reużywalnością. Jeśli zespół (lub organizacja) ma opracowane pewne gotowe komponenty, które mogą być użyte to także łatwo oszacować koszt ich adaptacji do aktualnych wymagań tworzonego produktu.

    Podsumowując, moim zdaniem im mniejsza wiedza nt dziedziny produktu, niezrozumienie wymagań i innowacyjność tworzonego rozwiązania tym bardziej się przydają estymaty relatywne. Im bardziej doświadczony zespół, dziedzina bardziej znana i zaawansowany produkt tym bardziej sprawdzają się (w sensie dokładności) estymaty klasyczne.

    tyle ode mnie 🙂
    pozdrawiam,
    Tomek.

    • Dawid Lewandowicz

      Dzięki Tomek za komentarz. Dwie rzeczy mi się nasuwają w związku z nim:
      1. Co do powtarzalności – zgadza się jak najbardziej. Patrzę na przez pryzmat szacowania relatywnego i tam jest tak samo. To znaczy, że bazując na danych historycznych i doświadczeniu dużo łatwiej oszacować złożoność zadania. Czyli szacowanie klasyczne i relatywne jest w tym temacie bardzo podobne.
      2. Drugi aspektem jest znajomość dziedziny produktu. Zgadzam się z tym co napisałeś – im mniejsza jest znajomość dziedziny (w tym większe ryzyka), tym bardziej powinniśmy iść w szacowanie relatywne. Przychodzi mi na myśl http://technicalleadership.pl/wiedza/model-cynefin/


Dodaj komentarz

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

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Ta strona używa Cookies, korzystając z niej wyrażasz zgodę na używanie ciasteczek zgodnie z ustawieniami przeglądarki. Nasza Polityka Prywatności
Akceptuję, bo lubię Was czytać.
x
X