Szacowanie jest trudne. Dla programistów jest to jeden z najtrudniejszych aspektów pracy — jeśli nie najtrudniejszy. Musi ono uwzględniać wiele czynników, które pomagają product ownerom podejmować decyzje wpływające na cały zespół — i firmę. Przy tak wysokiej stawce nie może dziwić, że wszyscy, od programistów po kierownictwo wyższego szczebla, często bardzo się tym przejmują. Ale to błąd. Szacowanie punktów historyjek Agile to nic innego jak tylko szacowanie. Nie cyrograf.
Nie ma wymogu pracy w weekendy, aby zrekompensować niedoszacowanie fragmentu prac. Spójrzmy jednak na kilka sposobów, dzięki którym szacunki Agile mogą być tak dokładne, jak to tylko możliwe.
Współpraca z product ownerem
W programowaniu Agile product owner ma za zadanie określać priorytety backlogu — uporządkowanej listy zadań, która zawiera krótkie opisy wszystkich pożądanych funkcji i poprawek produktu. Product ownerzy spisują wymagania firmy, ale nie zawsze rozumieją szczegóły realizacji. Tak więc dobre oszacowanie może dać product ownerowi nowy wgląd w poziom wysiłku wymagany w przypadku każdego elementu prac, co następnie pozwala na ocenę względnego priorytetu każdego elementu.
Kiedy zespół inżynieryjny rozpoczyna proces szacowania, zwykle pojawiają się pytania dotyczące wymagań i historyjek użytkownika. I dobrze: te pytania pomagają całemu zespołowi lepiej zrozumieć prace. W szczególności w przypadku product ownerów rozbicie elementów pracy na mniejsze części i oszacowanie ich poprzez punkty historyjek pomaga określić priorytety wszystkich (i potencjalnie ukrytych!) obszarów pracy. A mając już szacunki od zespołu programistycznego, product ownerzy nierzadko zmieniają kolejność pozycji w backlogu.
Szacowanie punktów historyjek Agile to dyscyplina zespołowa
Kluczem jest zaangażowanie wszystkich członków zespołu (programistów, projektantów, testerów, specjalistów od wdrażania...). Każdy członek zespołu wnosi inną perspektywę dotyczącą produktu i pracę wymaganą do dostarczenia historyjki użytkownika. Na przykład jeśli dział zarządzania produktem chce zrobić coś, co wydaje się proste, takie jak dodanie obsługi nowej przeglądarki internetowej, zespoły programistyczny i kontroli jakości muszą wyrazić swoją opinię, ponieważ doświadczenie nauczyło ich, jakie przeszkody mogą napotkać.
Podobnie zmiany projektowe wymagają nie tylko wkładu zespołu projektowego, ale także programistycznego i kontroli jakości. Wykluczenie części szerszego zespołu produktowego z procesu szacowania przekłada się na niższą jakość szacunków, obniża morale (ponieważ kluczowi współpracownicy nie czują się włączeni w proces) oraz pogarsza jakość oprogramowania.
Nie pozwól zatem, aby Twój zespół ucierpiał przez szacunki niemające oparcia w rzeczywistości. To szybka droga do porażki!
Chcesz wypróbować punkty historyjek? Najpierw zarejestruj się lub zaloguj się do systemu Jira.
Punkty historyjek a godziny
Tradycyjne zespoły programistyczne wyrażają szacunki w formie czasu: dni, tygodni, miesięcy. Wiele zespołów Agile przechodzi jednak na punkty historyjek. Punkty historyjek są jednostkami miary wyrażającymi oszacowanie całkowitego wysiłku wymaganego do pełnego wdrożenia backlogu produktu lub jakiegokolwiek innego elementu prac. Zespoły przypisują punkty historyjek zależnie od złożoności prac, ilości potrzebnej pracy oraz ryzyka lub niepewności. Wartości są przypisywane w taki sposób, aby bardziej efektywnie podzielić prace na mniejsze części, dzięki czemu mogą uwzględniać element niepewności. Z biegiem czasu pomaga to zespołom zrozumieć, ile mogą osiągnąć w danym okresie, oraz tworzy konsensus i zwiększa zaangażowanie na rzecz osiągnięcia rozwiązania. Może się to wydawać nieintuicyjne, ale ta abstrakcja jest rzeczywiście pomocna, ponieważ skłania zespół do podejmowania trudniejszych decyzji związanych z trudnością danej pracy. Oto kilka powodów, dla których warto korzystać z punktów historyjek:
- Daty nie uwzględniają prac niezwiązanych z projektem, na które członkowie zespołu muszą nieuchronnie przeznaczyć część swojego dnia, na przykład e-maili, spotkań i wywiadów.
- Daty mają wymiar emocjonalny. Względne szacowanie eliminuje ten emocjonalny komponent.
- Każdy zespół szacuje pracę w nieco innej skali, co oznacza, że ich prędkość (mierzona w punktach) będzie w naturalny sposób inna. To z kolei uniemożliwia zabawę w politykę, w której bronią jest szybkość.
- Gdy uzgodnicie względny wysiłek niezbędny w przypadku każdej wartości punktu historyjki, możecie szybko przypisywać punkty bez potrzeby większych dyskusji.
- Punkty historyjki nagradzają członków zespołu za rozwiązywanie problemów w oparciu o pokonywane trudności, a nie poświęcony czas. Dzięki temu członkowie zespołu koncentrują się na realizacji zadań, a nie wykorzystaniu czasu.
Niestety, punkty historyjek są często używane nieprawidłowo. Dzieje się tak, gdy są używane do osądzania ludzi, przypisywania szczegółowych osi czasu i zasobów, a także gdy są mylnie uważane za miarę produktywności. Zamiast tego zespoły powinny używać punktów historyjek, aby zrozumieć rozmiar prac i ich priorytety. Aby uzyskać szczegółowe informacje na temat punktów historyjek i praktyk szacowania, zapoznaj się z tą dyskusją ekspertów branżowych i zapoznaj się z kolejnymi wskazówkami dotyczącymi szacowania w metodyce Agile w dalszej części samouczka.
Punkty historyjek i Planning Poker
Zespoły rozpoczynające pracę nad punktami historyjek stosują metodę nazywaną Planning Poker. Planning Poker jest powszechną praktyką w całej firmie Atlassian. Zespół bierze element z backlogu i omawia go krótko, a każdy członek dokonuje oszacowania w myślach. Następnie każdy podnosi kartę z liczbą, która odzwierciedla ich oszacowanie. Jeśli wszyscy się zgadzają, to świetnie! Jeśli nie, trzeba poświęcić trochę czasu (ale nie za dużo — wystarczy kilka minut), aby poznać przyczyny różnic w szacunkach. Pamiętaj jednak, że szacowanie powinno być ogólne. Jeśli zespół za bardzo zagłębia się w szczegóły, weź oddech i przenieś dyskusję na wyższy poziom.
Chcesz spróbować?
- Zainstaluj tę aplikację Planning Poker
- Dowiedz się więcej o metodzie Planning Poker
Szacuj mądrzej, nie bardziej intensywnie
Żadne indywidualne zadanie nie powinno zajmować więcej niż 16 godzin pracy. (Jeśli korzystasz z punktów historyjki, możesz wyznaczyć górną granicę na przykład na poziomie 20 punktów). Po prostu zbyt trudno jest oszacować z dużą dozą pewności większe pojedyncze elementy pracy. A ten stopień pewności jest szczególnie ważny w przypadku pozycji na szczycie backlogu. Jeśli coś jest szacowane powyżej 16-godzinnego (lub 20-punktowego) progu Twojego zespołu, jest to sygnał, że warto podzielić to na drobniejsze części i ponownie przeprowadzić szacowanie.
W przypadku pozycji położonych niżej w backlogu zastosuj przybliżone oszacowanie. Zanim zespół faktycznie zacznie pracować nad tymi pozycjami, wymagania mogą ulec zmianie, a aplikacja z pewnością się zmieni. Wcześniejsze szacunki nie będą więc dokładne. Nie trać czasu na szacowanie pracy, która może się zmienić. Wystarczy dać product ownerowi ogólną wartość, której może użyć, aby odpowiednio określić priorytety planu rozwoju produktu.
Ucz się na podstawie wcześniejszych szacunków
Retrospektywy dają zespołowi czas na uwzględnienie wniosków z poprzednich iteracji, w tym dotyczących dokładności ich szacunków. Wiele narzędzi Agile (takich jak Jira) śledzi punkty historyjek, co ułatwia refleksję nad szacunkami i ich kalibrację. Spróbuj na przykład wyciągnąć 5 ostatnich historyjek użytkownika, które zespół dostarczył z wartością punktów historyjki równą 8. Przedyskutuj, czy każdy z tych elementów pracy miał podobny poziom nakładów roboczych. Jeśli nie, omów, z czego to wynika. Wykorzystaj te wnioski w przyszłych dyskusjach dotyczących szacowania.
Jak wszystko inne w metodyce Agile, szacowanie wymaga wprawy. Z czasem jej nabierzesz.
Powiązane zasoby
