Drugie dno szacowania

Większość osób nie lubi szacować pracy. Uzyskane wyniki bardzo często bywają błędne, stąd wielu z nich nie widzi większego sensu w szacowaniu, skoro finalnie i tak okazuje się to wyłącznie spekulacją. Idąc dalej, obawa przed możliwością niewywiązania się z obietnicy powoduje, że mało kto lubi odpowiadać na pytania o czas potrzebny na wykonanie pracy.

Warto dostrzec jednak drugie dno szacowania, a mianowicie okazję do wymiany oraz pogłębienia wiedzy dotyczącej konkretnego zagadnienia. Korzyść ta jest szczególnie wyraźnie widoczna w samowystarczalnych, interdyscyplinarnych zespołach.

Jak to wygląda w praktyce?

Dowolne wymaganie poddawane jest szacowaniu na dwóch poziomach:

  1. Historii Użytkownika (wysokopoziomowe), oraz
  2. zadań technicznych (niskopoziomowe).

Szacowanie Historii Użytkownika

Wyobraźmy sobie przykładową Historię Użytkownika:

Jako Użytkownik chcę mieć możliwość dodania przedmiotu do koszyka, tak abym mógł go kupić.

Zespół, po zapoznaniu się w wystarczającym stopniu z wymaganiami, korzystając np. z Planning Pokera, określa złożoność zadania. Padają następujące wartości:

3, 3, 1, 8

Wygląda na to, że członkowie Zespołu różnie określają złożoności zadania. Rozpoczyna się dyskusja. Osoba, która szacowała złożoność na 1, omawia dlaczego jej zdaniem jest to jedynka. Następnie osoba odpowiedzialna za oszacowanie złożoności na 8, przedstawia swój punkt widzenia. Po zakończonej dyskusji, Zespół ponownie szacuje skomplikowanie zadania:

3, 5, 3, 5

Ze względu na dalszą rozbieżność wyników, następuje kolejna runda szacowania. Uczestnicy znów podają swoje wartości. Cykl ten trwa to tak długo, aż Zespół, na skutek wymiany wiedzy, dojdzie do porozumienia w kwestii złożoności konkretnego zadania.

Ze względu na zgrubny charakter tych oszacowań, nie ma konieczności, aby poświęcać na tego typu szacowanie zbyt dużej ilości czasu.

Szacowanie zadań technicznych

Kiedy mogło by się wydawać, że mamy już gotowe oszacowanie, a poziom ogólnej wiedzy w Zespole jest zadowalający, przechodzimy do drugiej fazy szacowania. Zespół dekomponuje Historię Użytkownika na zadania techniczne, i tak dla wspomnianego wyżej przykładu otrzymujemy przykładowe zadania:

  • przygotowanie warstwy prezentacji
  • stworzenie logiki biznesowej
  • zrealizowanie testów
  • refaktoryzacja istniejącego kodu

Dla tych konkretnych zadań technicznych, Zespół podaje szacowany czas pracy w godzinach. I znów, kiedy widać duże rozbieżności w proponowanych wartościach, Zespół dyskutuje o konkretnym zadaniu technicznym tak długo, aż zostanie osiągnięte porozumienie.

Ze względu na fakt, iż zejście na poziom zadań technicznych oznacza, że zadaniem będziemy zajmować się w najbliższej perspektywie (iteracja, Sprint), wskazane jest aby dokonać tych oszacować z większą precyzją, aniżeli w przypadku zgrubnego szacowania Historii Użytkownika.

Podsumowanie

Warto traktować szacowanie pracy nie tylko jako narzędzie dostarczające konkretne wartości liczbowe przydatne do planowania, ale także jako okazję do pogłębienia wiedzy o wymaganiach w Zespole. Dodatkowo, członkowie Zespołu mogą się wiele od siebie nauczyć – szczególnie, jeśli dysponują różnym doświadczeniem, a platforma na której pracują jest skomplikowana.

NADCHODZĄCE WARSZTATY

A może spotkajmy się na żywo?

Chcesz dowiedzieć, jak zwinne wytwarzać produkty z klientem zewnętrznym w Scrumie? Zobacz moje 2-dniowe warsztaty “Scrum dla software houseów”, które przygotowałem na bazie moich doświadczeń w pracy z klientami z USA, UK, Irlandii, Niemiec oraz Polski.

DWIEDZ SIĘ WIĘCEJ O WARSZTATCH →

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.