Techniki

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.

Photo by Scott Webb on Unsplash

Czytaj dalej
Scrum

Krótkie Sprinty w Scrumie

Preferujemy krótkie lecz intensywne dystanse. Sprinty trwają jeden tydzień. Odpowiada to zarówno Właścicielowi Produktu jak i Zespołowi Deweloperskiemu. Nie jest to jednak najpopularniejsza długość iteracji.

Często słyszę głosy:

„Wydłużyliśmy sobie Sprint z jednego do dwóch tygodni. W jednotygodniowym Sprincie nic sensownego nie potrafimy oddać.”

Uważam, że nic tak nie uczy zwinnego podejścia, jak podejmowanie wyzwania oddawania małych przyrostów w krótkim okresie czasu. Dlaczego, skoro nie potrafimy napisać software’u w tydzień, ma się to nam udać w dwa tygodnie?

Poniższy cytat Mike’a Cohn’a z książki „Succeeding with Agile: Software Development Using Scrum” podsumowuje powyższe rozważania i mocno działa na wyobraźnie:

„Learning how to identify small pieces of functionality is one of the first big hurdles for a new Scrum team. I remember my first Scrum project: Initially there were times we struggled to find anything we could deliver in less than six weeks. Looking back on that system many years later, I now see many ways we could have split that work. In fact, I see enough ways to split the work now that we could have done one-day sprints if we had wanted to.”

Pokazuje też, gdzie (zapewne) jesteśmy dzisiaj oraz dokąd tak naprawdę zmierzamy.

Obraz morzaszum z Pixabay

Czytaj dalej
1 12 13 14