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.



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!

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