W metodologii Agile, zespoły, przygotowując się do kolejnych sprintów, definiują zakres zadań za pomocą historii użytkownika. Historia ta precyzuje konkretne działanie w ramach danej funkcjonalności, uwzględniając opis i kryteria akceptacji.
Sprinty trwają zazwyczaj od dwóch do czterech tygodni. W tym czasie zespół musi ocenić, ile pracy jest w stanie zrealizować w danym sprincie, tak aby dotrzymać terminu.
W tradycyjnym podejściu do zarządzania projektami, nakład pracy szacowany jest zazwyczaj w osobodniach. Określa to, ilu pracowników w pełnym wymiarze godzin potrzebnych jest do wykonania danego zadania. W takim przypadku szacowanie opiera się na liczbie dni i zaangażowanych osobach.
W metodyce Agile podejście jest odmienne. Nie analizujemy już dni ani liczby osób do oszacowania nakładu pracy. Wręcz przeciwnie, unikamy przeliczania wysiłku na osobodni. Zamiast tego, zespół przypisuje każdej historii ujednoliconą wartość, która reprezentuje ogólną ocenę złożoności.
Sama wartość nie ma kluczowego znaczenia. Najczęściej używane są punkty historii. Są to liczby z ciągu Fibonacciego, zaczynające się od 0, 1, 2, 3, 5, 8, 13, 21 itd. Każda kolejna wartość jest sumą dwóch poprzednich. Takie podejście pomaga rozróżnić złożoność historii, ponieważ kolejne liczby w ciągu rosną coraz bardziej.
Jednak punkty historii nie są jedynym rozwiązaniem. Można użyć rozmiarów ubrań (XXS, XS, S, M, L, XL, XXL) lub, bardziej kreatywnie, nazw zwierząt z ZOO, aby oszacować wielkość zadania.
W tym podejściu kluczową rolę odgrywa intuicja całego zespołu. To zespół decyduje, która liczba (lub zwierzę) najlepiej odzwierciedla złożoność danej historii. Ważne jest, aby pamiętać, że nie chodzi o szacowanie czasu. Czas trwania sprintu jest z góry ustalony, a zespół musi zrealizować wszystkie wybrane historie w jego ramach.
Elementy składowe szacowania punktów historii
Szacowanie punktów historii nie polega tylko na ocenie trudności zadania. Zespół, wyceniając historię, powinien wziąć pod uwagę różne aspekty i odzwierciedlić je w ostatecznej wartości.
Ostateczna ocena to suma tych wszystkich aspektów wyrażona jedną liczbą. Poniżej przedstawiamy, co powinna obejmować taka wycena.
#1. Złożoność techniczna
Zakładając, że historie szacuje zespół programistów, poziom trudności technicznej będzie jednym z pierwszych czynników branych pod uwagę.
To całkowicie naturalne. Zespół ekspertów technicznych powinien najlepiej ocenić ten aspekt. Zespół może rozważyć:
- Porównanie złożoności technicznej tej historii z innymi, które zostały już zrealizowane.
- Liczbę plików kodu, które zespół musi utworzyć lub zmodyfikować.
- Liczbę dodatkowych zmian w systemie, jakie wywoła dana historia.
- Poziom skomplikowania algorytmu lub logiki procesu do wdrożenia.
#2. Zależności zewnętrzne i ryzyko
Często sukces realizacji historii w sprincie zależy od innych zespołów lub osób spoza zespołu.
Najłatwiejsze do oszacowania są historie, które zespół może zrealizować samodzielnie. Sytuacja komplikuje się, gdy potrzebna jest pomoc z zewnątrz. Dla osób spoza zespołu realizacja tych zadań nie będzie priorytetowa. Zespół musi uwzględnić to ryzyko w swoich szacunkach.
O ile ten czynnik podniesie ostateczne szacunki zależy od doświadczenia zespołu i poziomu zależności od zewnętrznych czynników. Zazwyczaj, po kilku sprintach, zespół naturalnie wypracowuje spójne podejście do oceny wpływu zależności zewnętrznych na powodzenie projektu.
#3. Możliwość ponownego wykorzystania
Kolejnym ważnym aspektem jest to, czy zespół może ponownie wykorzystać istniejące elementy, aby zrealizować historię. Oczywiście, jeśli jakieś części są już gotowe, nie ma potrzeby tworzenia ich od zera. Zamiast tego, zespół może ponownie użyć istniejącego rozwiązania, co znacznie przyspieszy pracę.
Taka możliwość obniża ogólne oszacowanie, nawet jeśli historia bez ponownego użycia byłaby bardziej złożona ze względu na zakres.
#4. Zrozumienie możliwości zespołu
Jednym z unikalnych czynników, nieuwzględnianych w szacowaniu opartym na osobodniach, jest świadomość doświadczenia i możliwości zespołu.
Współpracując w kolejnych sprintach, członkowie zespołu poznają się nawzajem. Zaczynają rozumieć, kto w czym jest dobry. Kiedy zespół dobrze się zna, może wykorzystać tę wiedzę podczas szacowania.
Jeśli realizacja historii wymaga konkretnych umiejętności, a zespół je posiada, oczywiste jest, że realizacja będzie łatwiejsza. Odwrotnie, jeśli zespół nie ma potrzebnych umiejętności, potrzebuje więcej czasu na zapoznanie się z tematem, co powinno znaleźć odzwierciedlenie w szacunkach.
Szacowanie historii
Oszacowanie historii powinno być efektem pracy zespołowej. Żaden pojedynczy głos nie powinien narzucać poziomu jej złożoności. Celem jest przedyskutowanie oszacowania, aż wszyscy członkowie zespołu dojdą do porozumienia.
Szacowanie może odbyć się podczas dyskusji nad udoskonaleniem sprintu (spotkanie, podczas którego zespoły omawiają i wyjaśniają historie) lub w ramach specjalnie na to poświęconego czasu.
Przykład procesu szacowania
Planowanie Sprintu
Zespół ma już listę historii, które zostały oszacowane. Idealnie, historie mają przypisany priorytet, co ułatwia wybór tych, które trafią do kolejnego sprintu.
Podczas planowania sprintu zespół wybiera historie na podstawie:
✅ Historii o najwyższym priorytecie, które są brane pod uwagę w pierwszej kolejności.
✅ Doświadczenia zespołu w zakresie liczby punktów historii, jaką jest w stanie zrealizować w sprincie. Ta wiedza wynika z czasu i doświadczenia zespołu. Potrzeba kilku sprintów, aby dostroić i właściwie zrozumieć tę zdolność.
✅ Uwzględnienia nie tylko całkowitej liczby punktów historii i priorytetu. Inny ważny aspekt to umiejętności członków zespołu w kontekście wybranych historii. Na przykład, jeśli zespół ma tylko dwóch programistów front-end, nie można wybrać wyłącznie historii związanych z front-endem. Doprowadzi to do przeciążenia tych dwóch osób, a reszta zespołu nie będzie w pełni wykorzystana. Wiedza o umiejętnościach zespołu jest kluczowa dla skutecznego planowania sprintu.
Współczynnik prędkości
Kluczowa jest szybkość zespołu, która odnosi się do nadchodzącego sprintu. Liczba ta nie ma związku z całkowitą liczbą punktów historii, lecz pokazuje, w jakim stopniu zespół będzie dostępny do pracy w nadchodzącym sprincie.
Aby móc precyzyjnie zaplanować zakres sprintu, należy połączyć te dwa aspekty:
Osiągnięcie właściwej równowagi wymaga czasu i praktyki.
Korzyści i typowe błędy
Niesamowite, jak często zespoły same komplikują sobie transformację w stronę metodologii Agile. Trzeba „zrozumieć” te procesy, zanim zacznie się je wdrażać.
Ten pierwszy krok jest najtrudniejszy i może zająć lata, szczególnie w środowiskach korporacyjnych, gdzie czas stoi w miejscu.
Gdy zespół w końcu zrozumie, proces przynosi następujące korzyści:
- Nie ma już potrzeby obliczania dni czy osób, aby oszacować termin realizacji zadania.
- Zespół uczy się tworzyć historie o takim zakresie, który zmieści się w sprincie. Zbyt złożone historie są dzielone na mniejsze.
- Zespół ma dokładne szacunki każdego zadania i wie dokładnie, kiedy może je zrealizować.
- Zwiększa się niezawodność i przewidywalność zespołu.
- Wszyscy członkowie zespołu rozumieją zadania w podobny sposób. Z czasem mogą nawet przestać szacować, ponieważ widzą taką samą złożoność zadania, co pozwala na zaangażowanie się w historie bez formalnego szacowania.
Oto, co zazwyczaj dzieje się, gdy zespół nie rozumie procesu:
- Zespół nadal trzyma się tradycyjnego szacowania osobodni. Wszystko przeliczają na dni lub liczbę zaangażowanych osób. Punkty historii czy liczby Fibonacciego stają się zamaskowaną liczbą dni, bezpośrednio lub poprzez transformacje.
- Kierownictwo porównuje zespoły na podstawie liczby punktów historii dostarczonych w każdym sprincie, co jest błędem. Każdy zespół ma swoją własną skalę szacowania punktów historii. Nie ma sensu dążyć do synchronizacji szacunków między zespołami.
- Punkt historii jednego zespołu może oznaczać narysowanie koła, a dla innego zespołu – narysowanie domu z płaskim dachem, czterema oknami i drzwiami. I to jest w porządku.
- Zespoły szacują większość zadań za pomocą kilku wartości. Może obawiają się, że przypisanie historii wartości 123 zostanie odebrane jako liczba dni. Tymczasem skala Fibonacciego jest nieskończona. Nie trzeba ograniczać się do 3, 5 czy 8. Możemy (i być może robimy to już) tworzyć historie tak, aby były tej samej wielkości, co jest całkowicie w porządku.
- Szacowanie jest zdominowane przez starszych członków zespołu, którzy narzucają innym swoją wizję. Nie wolno dopuszczać do wpływania na ocenę przez jednego członka zespołu. Każdy ma równe prawo do wypowiedzi i bycia wysłuchanym.
Podsumowanie
Przejście z tradycyjnego szacowania na Agile nie jest łatwe. Wymaga dostosowania zarówno od zespołu, jak i od kierownictwa. Aby to zadziałało, obie strony muszą rozumieć proces. Jeśli któraś z nich nie rozumie, okres przejściowy będzie trudny i pełen sprzecznych oczekiwań.
Gdy wszystko się ułoży, zespoły będą lepiej szacować i planować swoją pracę, a kierownictwo będzie miało bardziej przewidywalne terminy i plany.
Na koniec, warto sprawdzić, jakie niezdrowe procesy mogą zrujnować Twój sprint.