Wprowadzenie do szacowania zadań w Scrumie
W ostatnim wpisie zatytułowanym „Scrum w praktyce czyli dlaczego proste zasady są niezwykle trudne w codziennym zastosowaniu” opisałem najczęściej spotykane przeszkody, z którymi muszą zmierzyć się zespoły wprowadzające scruma. Jednym z wspomnianych problemów było oszacowywanie zadań. Proces ten postanowiłem dokładniej przybliżyć w niniejszym tekście. Dodatkowo słowem wprowadzenia chciałbym poruszyć tematykę planowania sprintu oraz wspierania Product Ownera przy „porządkowaniu” Product Backlogu.
Product Backlog
Zacznijmy od przypomnienia czym jest Product Backlog. Zgodnie z definicją pochodzącą z „Scrum Guide” jest to uporządkowana lista wszystkiego, co może być potrzebne w produkcie oraz jedyne źródło wymaganych zmian, które mają być w produkcie wprowadzone. Jest on więc listą wszystkich cech, funkcji, wymagań, ulepszeń oraz korekt błędów, które reprezentują zmiany wprowadzane do produktu w jego przyszłych wydaniach. Warto zapamiętać, że Rejestr Produktu istnieje tak długo, jak istnieje produkt. Oznacza to, że nigdy nie jest kompletny i wraz z rozwojem produktu zmienia się. Czynniki wpływające na produkt przyczyniają się do konieczności wprowadzania zmian w rejestrze produktu. Uporządkowany product backlog jest niezwykle istotny dla płynnej i efektywnej pracy całego zespołu. Jego doskonalenie oraz porządkowanie leży w gestii właściciela produktu, jednak bez pomocy zespołu deweloperskiego nie jest to możliwe. To właśnie zespół deweloperski dostarcza informacji o pracochłonności zadań oraz ewentualnych zależnościach technicznych. Dzięki tym informacjom Product Owner jest w stanie podjąć decyzje, które elementy rejestru produktu powinny być realizowane w pierwszej kolejności. Tylko dobrze zdefiniowane i opisane zadania mogą być oszacowane. Te, które budzą wątpliwości lub nie są zrozumiałe należy doprecyzować. Kolejność elementów w product backlogu powinna odzwierciedlać priorytety rozwoju produktu (m.in. wartość biznesową, ewentualne zależności, możliwości wdrożenia). Zadania znajdujące się wyżej, z reguły powinny być lepiej opisane oraz przygotowane w taki sposób, aby można było włączyć je do realizacji w najbliższych sprintach. Dobrą praktyką, z którą spotkałem się w kilku projektach było wstępne oszacowywanie oraz doprecyzowywanie takiej ilości zadań, którą łatwo można włączyć do realizacji w trzech najbliższych sprintach. Niestety często zapomina się, iż warto poświęcić ok. 10% czasu sprintu na tzw. product backlog grooming czyli wspomniane porządkowanie. Korzyści płynące z regularnego doskonalenia rejestru produktu są wielorakie. Zespół deweloperski zyskuje świadomość czego może spodziewać się w następnych sprintach oraz zdobywa lepszą wiedzę o projekcie. Dodatkowo planowanie sprintu odbywa się sprawniej – zespół może skupić się na tym, jak zrealizować zadania, zamiast próbować zrozumieć o co w nich chodzi. Dzięki takiemu rozwiązaniu podczas sprint planingu nie „traci” się czasu na słabo zdefiniowane zadania. Regularne groomingi zapewniają product ownerowi czas na doprecyzowanie zadań, które nie są jasne dla zespołu (głównie chodzi o te, które musiałby skonsultować z interesariuszami). Kolejną z zalet jest możliwość przewidywania (znając velocity zespołu), w którym sprincie będą realizowane dane zadania. Niewątpliwym atutem jest też możliwość „dociągnięcia” tak zdefiniowanych zadań do trwającego już sprintu (w przypadku, gdyby udało się zrealizować przed końcem sprintu uprzednio zaplanowane zadania). Chociaż spotkania mające na celu doskonalenie rejestru produktu nie są zdefiniowane w ramach zdarzeń w scrumie, to zachęcam do ustalenia stałej daty spotkań oraz wyznaczenia ram czasowych. Tematyce rejestru produktu można by poświęcić osobny artykuł, jednak na potrzeby niniejszego tekstu poruszyłem tylko najistotniejsze zagadnienia niezbędne do kontynuowania tematyki szacowania zadań.
Wprowadzenie do szacowania zadań
Zadania znajdujące się w rejestrze produktu mogą być zdefiniowane z różnym poziomem szczegółowości. Jak już ustaliliśmy wcześniej, te najdokładniej opisane i sprecyzowane (a co za tym idzie przeznaczone do realizacji w najbliższym czasie) najlepiej jeśli znajdowałyby się w górnej części listy. Bardzo dokładne opisywanie wszystkich zadań mieszczących się w rejestrze produktu mija się z celem – wiele z nich może nigdy nie trafić do żadnego sprintu, zaś spora część może stać się nie aktualna. W związku z tym, poszczególne zadania mieszczące się w product backlogu będą szacowane bez znajomości szczegółów. Nie oznacza to, że mogą być niezrozumiałe dla zespołu w trakcie procesu szacowania – chodzi raczej o brak takich informacji jak makiety, sposób wyświetlania komunikatu (popup lub toast), i inne. Ogólne szacunki mają pomóc Product Ownerowi w podjęciu decyzji o priorytecie danego zadania. Dopiero, gdy ogólnie oszacowane zadanie, zostanie uznane za dość ważne, powinno nastąpić uszczegółowienie i ponowna wycena. Niejednokrotnie zdarza się, że jeszcze na poziomie listy w rejestrze produktu, dane zadanie musi zostać podzielone na mniejsze. W zależności od umiejscowienia zadania na liście włożymy różny wysiłek w jego oszacowanie. Dodatkowo podczas planowania sprintu będziemy weryfikować uprzednio oszacowane zadania niejednokrotnie dzieląc je na mniejsze. Przyczyni się to do powstania pewnego rodzaju planu realizacji danego zadania zwiększając jednocześnie dokładność szacunku.
Jakie ryzyka wiążą się z szacunkami wyrażanymi w godzinach?
Zanim przejdziemy do omówienia sposobów szacowania zadań chciałbym przedstawić jakie ryzyka niosą ze sobą estymacje wyrażane w godzinach lub dniach. Zacznijmy od tego, iż zadania powinny być szacowane przez cały zespół. Oznacza to, że szacunki godzinowe podawane przez poszczególne osoby mogą się różnić – w końcu każdy z zespołu dysponuje nieco innymi umiejętnościami. Jeśli nawet przyjmiemy średnią lub medianę to zawsze pozostanie pewien margines błędu wyceny godzinowej. Nie zawsze przy szacunkach będziemy też w stanie przewidzieć wszelkie możliwe komplikacje jakie mogą wystąpić w trakcie realizacji zadania. W zależności od projektu oraz oczekiwań osób zarządzających budżetem, poszczególni członkowie zespołu będą odczuwać presję, co przełoży się na jakość realizacji. W przypadku, gdy zadanie było wycenione na 6 godzin pracy a okaże się, iż na ukończenie potrzeba więcej, to w najlepszym wypadku programista gorzej udokumentuje kod lub pominie testy a w najgorszym powstanie rozwiązanie zawierające usterki. Osoba oczekująca na zadanie również może mieć błędne przeświadczenie, iż otrzyma je po dokładnie określonym czasie. W konsekwencji przy następnych szacunkach zespół będzie przeszacowywać zadania, co również nie będzie korzystne. Niestety przy operowaniu wycenami godzinowymi często podświadomie utożsamia się podane wartości jako coś pewnego i zapomina, iż są to szacunki. Innym problemem może być podejmowanie zadań przez osoby, które niedawno dołączyły do projektu. Będą one niechętnie podejmowały prace nad trudniejszymi funkcjonalnościami, których estymaty są znacząco większe od pozostałych – łatwiej przekroczyć oszacowany czas. W rezultacie może to prowadzić do kreowania niezastąpionych członków zespołu, których urlopy będą równoznaczne z przestojami w projekcie. W realizacji zadań wycenionych godzinowo spotyka się również syndrom mniejszej chęci pomocy innym – poszczególni członkowie zespołu skupiają się na realizowaniu „swoich” zadań w ramach określonej wyceny. Można by jeszcze wymieniać wiele innych negatywnych skutków korzystania z wycen godzinowych, jednak jest też wiele projektów, w których wyceny godzinowe funkcjonują lepiej lub gorzej. Niewątpliwą zaletą tego typu wycen jest ich prostota. Nie oznacza to, że są jedynym i najlepszym rozwiązaniem. Zastanówmy się przez chwilę na czym skupiają się wyceny godzinowe i jakich założeń podczas ich stosowania brakuje. W tym celu najlepiej posłużyć się przykładem grupy biegaczy, którzy mają dotrzeć z punktu A do punktu B, poruszając się po określonej drodze. Czy każdemu z nich zajmie to dokładnie tyle samo czasu? Jeśli pominiemy aspekt czasowy i postaramy się w inny sposób określić „trudność” odcinka pomiędzy punktami, to pierwszą wartością może być liczba kilometrów. Jednak same kilometry nie będą jeszcze wystarczające – należy dodatkowo uwzględnić np. ukształtowanie terenu (liczba podbiegów), podłoże (piasek, błoto, droga asfaltowa), etc. Określając w ten sposób stopień trudności trasy, zyskujemy pewność, że nie uzależniamy go od biegacza i jego umiejętności. Stopień trudności trasy będzie natomiast miarą relatywną wyznaczaną poprzez wzajemne porównanie kilku tras. Inaczej ocenimy odcinek górski a inaczej odcinek prowadzący prostą asfaltową drogą. Dopiero znając wytrenowanie danego biegacza, stopień trudności trasy oraz mając informacje o jego poprzednich biegach, możemy podać przybliżony czas ukończenia trasy. Przyjmując takie założenia unikamy niebezpiecznego skrótu myślowego. Zapytacie pewnie jak to ma się do wyceniania zadań? Często od samego początku staramy się określić czas ich realizacji zamiast oszacować osobno rozmiar pracy (trudność/złożoność zadania). Z pomocą przychodzą nam story points, którymi określamy trudność konkretnych zadań. Podobnie jak w przypadku tras biegowych – w celu określenia rozmiaru pracy będziemy musieli porównać ze sobą poszczególne zadania.
