Jednym z trudniejszych wyzwań około programistycznych, które są przede mną stawiane w codziennej pracy, jest szacowanie wartości pracy potrzebnej do wykonania powierzonego zadania. Trudności wynikają z kilku różnych czynników, z reguły jest to brak przełożenia teoretycznej wiedzy o zakresie zadania na realne zadania do wykonania w kodzie, co jestem w stanie ustalić dopiero na późniejszym etapie. Co ciekawe, będąc juniorem miałam tendencję do niedoszacowywania zadań, czyli wskazywania na to, że ich złożoność jest mniejsza niż wyceniali to doświadczeni programiści.
Na czym polega szacowanie
O tym co to jest szacowanie napisałam już z grubsza we wpisie dotyczącym Scruma. Pisałam wtedy o estymacji w kontekście jednego ze spotkań, którego celem jest wycena zadań z backlogu w konkretnej jednostce obowiązującej w projekcie. Dla przypomnienia:
Estymacja (szacowanie) może odbywać się w różnych jednostkach. Niektóre zespoły preferują wycenę w tzw. man-dayach, czyli jednostce pracy jednego człowieka przez jeden dzień. Można również szacować w story points, czyli jednostce względnej oddającej stosunek jednego zdania do innych w kolejnych liczbach z ciągu Fibonacciego. Oznacza to tyle, że jeden zespół może wycenić zadanie na 5 a drugi na 13 i wszystko będzie ok, bo zależy tylko od tego jaką miarę przyjmą na zadanie za 1 story point.
https://devolajf.pl/kulisy-pracy/jak-wyglada-praca-w-scrumie/
Szacowanie jest jednym ze spotkań, który ma ustaloną datę i do którego mogę się przygotować zaglądając w backlog oraz mniej więcej przemyśleć znajdujące się tam zadania. W praktyce zdarza się jednak, że pewne zadania trzeba wykonać nagle, choćby dlatego, że nastąpiły jakieś nieprzewidziane zmiany w innych modułach projektu i bez wykonania pewnej pracy nie będzie możliwe prawidłowe działanie aplikacji.
Szacowanie w biegu
To właśnie takich sytuacji nie lubię najbardziej – analitycy ciągle pracują nad tym aby rozwikłać zadanie, nikt do końca nie jest pewien ustaleń i wytycznych, ja mam mniej więcej mgliste pojęcie co i gdzie mam zrobić. W idealnym świecie i idealnym projekcie taka sytuacja nigdy nie miałaby miejsca, jednak w świecie realnym zdarzają się różne rzeczy. W końcu pada pytanie: „na ile wyceniasz to zadanie?” Nic, tylko siąść i płakać…
W takich sytuacjach staram się przede wszystkim opanować emocje związane z trudnością sytuacji, w jakiej zostałam postawiona. Jedyne co mogę zrobić to odpowiedzieć na pytanie zgodnie z moją aktualnie najlepszą wiedzą, nic ponadto. Co zatem robię aby wyszacować zadanie?
Po pierwsze: czytam
Pierwsze co robię to oczywiście zaglądam jak wygląda zadanie w Jira. Z reguły zadania mają opisy, opisy mają odnośniki do specyfikacji, use case’ów, gdziekolwiek. Generalnie im więcej wiem tym lepiej dla mnie. Zdarza się, że jest dołączony link do makiety lub w komentarzach znajdują się szczegóły (tak, w komentarzach, nie w opisie, kilka razy zdarzyło mi się przez to przeoczyć znaczące informacje).
Po drugie: pytam
Analitycy z reguły nie zamieszczają w Jira informacji, których nie są pewni (thank you Captain Obvious!), często mają jednak niepotwierdzone informacje lub wytyczne, które po prostu czekają na „klepnięcie”. Z tego powodu w takich niejasnych sytuacjach staram się z nimi pogadać o zadaniu i o czających się niejasnościach.
Po trzecie: skanuję
„Skanowanie” brzmi być może niefortunnie i nieintuicyjnie, ale rozumiem je tutaj jako powierzchowne czytanie. Kiedy dysponuję już z grubsza informacjami o zakresie zadania i wiem, że dotyczy miejsc w kodzie, których znam zbyt dobrze, lub dokonały się w nich znaczące zmiany, to staram się właśnie „przeskanować” wzrokiem co się w tym kodzie dzieje.
Po czwarte: liczę
Kiedy już mniej więcej wiem na czym polega zadanie i jakie miejsca w kodzie będę musiała modyfikować lub jakie funkcjonalności dodawać, staram się na bazie swojego doświadczenia przełożyć tę pracę na jednostkę używaną w projekcie, czyli story points. Szacuję także ile czasu to zadanie mi zajmie. Określenie czasu nie jest umieszczane w Jira, ale może mieć istotne znaczenie dla zakończenia zadań przewidzianych na sprint do zakończenia tegoż.
Z innej strony: fajnie jest kiedy wszyscy w zespole mają świadomość tego czy ktoś jest super zajęty i pracuje nad zadaniem, które zajmie mu jeszcze 5 dni, a ktoś za godzinę skończy i będzie mógł pomóc innym.
Po piąte: komunikuję
Po całej tej procedurze nie pozostaje mi nic innego, jak zakomunikować swoją wycenę, oczywiście z informacją, że jeżeli wytyczne mocno się zmienią, to zmianie ulegnie również wycena.
Co to znaczy 1 story point?
Cała zabawa z szacowaniem w story poitns polega na tym, że jest to jednostka względna i dla każdego zespołu może oznaczać zupełnie co innego. Story points zapisuje się w postaci kolejnych liczb z ciągu Fibonacciego i na początku pracy z tą jednostką dobrze jest ustalić co oznacza zadanie o złożoności 1 SP. W takim wypadku można porównywać szacowane zadania z zadaniem wzorcowym wycenionym na 1.
Co istotne, doświadczenie i biegłość osoby, która będzie wprowadzać zmiany nie powinna mieć wpływu na wycenę, ponieważ story points nie oddaje czasu wykonania zadania, a jedynie jego złożoność.
Podsumowanie
Szacowanie pracy potrzebnej do wykonania zadań nie jest moim ulubionym zajęciem. Jako juniorowi często zdarzało mi się niedoszacowywanie wycenianych zadań, co moim zdaniem wynikało z braku znajomości aplikacji oraz stosowanych powszechnie rozwiązań. Obecnie podchodzę bardziej zachowawczo i o wiele mniej hurra optymistycznie do estymowania 😉 Doświadczenie nauczyło mnie również, że pojawianie się niespodziewanych zwrotów akcji jest bardziej regułą w pracy w projekcie niż wyjątkiem.