Doświadczony scrum master nie musi czytać tego tekstu. Nie raz pewnie zjadł zęby na tym, żeby tłumaczyć biznesowi czym są story points i dlaczego programistom tak trudno wycenić nakład pracy w godzinach. Ale mam cichą nadzieję, że kropla drąży skałę i moje sugestie wpłyną poniekąd na kadrę managerską. W branży IT bowiem niektórzy pozjadali rozumy i wciąż próbują nas przekonać, że developer, jak budowlaniec, powinien wiedzieć ile czasu zajmie mu wykonanie kompleksowej roboty: od zalania fundamentów po zrobienie dachu. Problem w tym, że programista nigdy nie był budowlańcem.
Estymacje w praktyce
Załóżmy sytuację jak najbardziej prawdopodobną:
Na życzenie klienta przychodzi manager do scrum mastera lub team leada, aby zapytać o estymacje dotyczące konkretnej funkcjonalności. Klient jest w gorącej wodzie kąpany, a chciałby wiedzieć czy zapięcie do systemu automatycznej wysyłki maili z customową templatką, to kilka, czy kilkadziesiąt godzin prac. Czas to pieniądz, wiadomo. Niestety sprawa nie wygląda na tak prostą jak mogłoby się wydawać.
Okazuje się, że podobna automatyzacja była już kiedyś pisana, ale została wyłączona, bo nie działała według oczekiwań biznesu. Mimo to, w kodzie wciąż zalega sporo linijek, które nigdy nie widziały refaktoru. Testów jednostkowych brak. W międzyczasie, aplikacja bardziej się rozrosła. Niestety, nie wprowadzano wcześniej mikroserwisów, ani też żadnej innej formy modularyzacji systemu, stąd spaghetti code rozrósł się jak kulturysta tuczony paszą dla owiec. Do nowej templatki nie ma designów, a wymagania muszą zostać doprecyzowane. Jakby tego było mało, w ostatnich tygodniach wymieniła się połowa składu developerskiego, ponieważ kilku doświadczonych devów przeszło na inny projekt. Aha, no i manager też jest nowy w firmie. I weź tu chłopie bądź mądry, dając biznesowi estymacje w godzinach lub dniach developerskich. To się zwyczajnie mija z celem.
Jak ocenić stopień skomplikowania zadania
Chciałbym powiedzieć, że opisana wyżej sytuacja jest wyjątkowa. Jedna na milion. Ale tak nie jest. Bywają projekty, gdzie większośc funkcjonalności wycenia się w ciemno. Koniec końców, team developerski czuje frustrację, a biznes się wścieka. Załóżmy, że to ty jesteś tym nowym managerem w firmie. Z jednej strony masz presję zarządu, z drugiej – zespołu programistów. Tej konkretnej sytuacji już nie uratujesz i z pewnością dostaniesz wycenę czasową wywróżoną z fusów. Możesz natomiast uniknąć takiej jazdy bez trzymanki w przyszłości. Będzie to jednak kosztować trochę pracy, ażeby wprowadzić regularne iteracje oparte na wycenach w story pointach.
Jeśli jakimś cudem nigdy nie słyszałeś o story pointach, to po pierwsze odrób lekcje w Google, a po drugie – skup się teraz jeszcze bardziej. Story pointy to taka egzotyczna jednostka, która pomaga ocenić poziom skomplikowania zadania. Skalę wycen można przyjąć taką, jakiej chce zespół. Gdy pracowałem jeszcze jako scrum master, najczęściej przyjmowaliśmy z programistami skalę od 1 do 23 story points dla funkcjonalności. Jeśli w czasie planning pokera wyceniliśmy feature na 23 punkty, oznaczało to, że możemy nie wyrobić się w jednym sprincie. Należało wtedy spróbować rozbić implementację na dwa etapy, aby w każdym z nich dać użytkownikowi jakąś wartość. Ten wątek rozwinę jednak przy okazji innego tekstu. A teraz czas na meritum.
Story points lepsze od wycen godzinowych
Wyjaśnijmy coś sobie. Praca programisty nie ma nic wspólnego z robotą taśmową. To nie są powtarzalne czynności jak w przypadku wykładania pudełek na linię produkcyjną w fabryce długopisów. Za każdym razem developer musi jakoby wejść w rolę odkrywcy. Przedrzeć się przez dżunglę kodu, najczęściej podróżując bez mapy. Napotykając po drodze niespodzianki i niebezpieczeństwa. Musi pokonać przeciwności, aby zbliżyć się do założonego celu. A kiedy już dotrze na miejsce, czeka go jeszcze kilka łamigłówek, żeby znaleźć najlepsze rozwiązanie. I za każdym razem ta podróż wygląda inaczej. Zatem – również przy bardzo dobrych intencjach i dużym doświadczeniu – nawet najlepszy podróżnik miałby problem z oszacowaniem czasu potrzebnego na wyprawę do dżungli kodu. I tu wchodzą story pointy, ubrane całe na biało.
„Scrum jest dla dorosłych ludzi”
Ken Schwaber
Po to stworzono regularne iteracje w branży IT, żeby móc planować zadania w segmentach czasowych. Czy sprint trwa tydzień, dwa, czy dłużej, zależy od projektu oraz zespołu. Niemniej jednak są to pewne ramy czasowe, na których ty, jako manager, już możesz bazować. Wprawny menago dołoży też wszelkich starań, żeby utrzymać niezmieniony skład teamu jak najdłużej. Jest to o tyle ważne, że po kilku sprintach można zmierzyć spalanie zespołu w obecnym składzie. Jeśli w ostatnich iteracjach nie udało się dowieźć funkcjonalności wycenionych w sumie na ok. 30 story points, to jasny sygnał dla ciebie oraz scrum mastera, że kolejne sprinty nie powinny być tak obłożone. Mając wiedzę o spalaniu na poziomie, powiedzmy, 20 story pointów w jednej iteracji, wspólnie z wyższym kierownictwem jesteście w stanie lepiej zaplanować wydania kolejnych wersji aplikacji.
Zgodzę się, że teoria zawsze brzmi łatwiej niż to wygląda w praktyce. Przedstawiciele biznesu nie muszą rozumieć story pointów i innych artefaktów scrumowych. Ale po to zostałeś (lub zostaniesz) managerem IT, żeby edukować swoje kierownictwo, dlaczego najwłaściwszą jednostką czasu powinny być sprinty zamiast godzin, dni lub developero-tygodni. Programiści nie wykładają truskawek na taśmę. Oni biegną przez dżunglę nowatorskich rozwiązań, gdzie technologia spotyka się z biznesem i obie strony muszą rozumieć siebie nawzajem.
A ty, co myślisz o story pointach? Podziel się swoją opinią w komentarzu. Chętnie poznam inny punkt widzenia!