Zašto je isporuka projekata nepredvidiva?
Zamislite….
… vodite kompaniju koja razvija proizvod ili uslugu za tržište.
… imate posvećen tim koji radi na tom proizvodu.
… postoji roadmap, postoji plan. Uz plan dolaze i očekivanja — od strane stakeholder-a, tima, klijenata, pa i vas samih.
… ako se plan ispuni, svi će biti zadovoljni. Biće slavlja, tapšanja po ramenu, možda čak i finansijskih nagrada.
Sada prestanite da zamišljate.
Everyone seems to be doing their best, but things don’t follow the plan. Features are late, milestones are missed, deadlines are postponed. But the worst part is that there is no Svi rade najbolje što mogu, ali stvari ne prate plan. Funkcionalnosti kasne, milestone-ovi se propuštaju, rokovi se pomeraju. Ali najgori deo nije samo kašnjenje — već nedostatak ritma i predvidivosti. Šta god tim planira, šta god obećate stakeholder-ima, koliko god „buffer-a“ ubacite u plan — jednostavno nije dovoljno. To poljulja samopouzdanje, narušava poverenje stakeholder-a i ruši moral ljudi koji rade na proizvodu.
Propušteni rokovi su neprijatni, ali najgora noćna mora za sve koji se bave isporukom jeste nedostatak predvidivosti. Zato vredi uložiti vreme da se razume odakle on dolazi.
Postoji nekoliko razloga zašto isporuka postaje nepredvidiva i zašto ne možemo da kažemo kada će funkcionalnost biti spremna:
- Nedovoljno razumevanje onoga što se gradi
- Neiskusan tim koji radi na proizvodu (pod timom se podrazumevaju svi uključeni — dizajneri, developeri, product…)
- Problemi u procesu rada
Zadržimo se na prvom razlogu. Razumevanje problema koji rešavamo ključan je korak ka pronalaženju rešenja. Postoji mnogo faktora koji utiču na slabo razumevanje, ali jedan je posebno zanimljiv — neadekvatna veličina radnih elemenata.
Uzmimo jednostavan primer.
Kada biste morali da prepišete celu Bibliju (ili bilo koju knjigu), da li biste mogli da procenite koliko vam vremena treba? Verovatno ne. Nikada ranije niste prepisivali celu knjigu tog obima, pa je teško proceniti trajanje. Iako svakodnevno pišete i to radite godinama.
Ono što MOŽETE da procenite jeste koliko vam treba da prepišete jednu stranicu — ili još bolje, jedan red.
Poenta je jasna: mnogo smo bolji u procenjivanju manjih delova posla. A bolja procena donosi veću predvidivost — odnosno jasniju sliku kada će posao biti završen.
Problem predvidivosti
Vratimo se sada sa biblijskog primera na svakodnevicu — isporuku projekata.
Stvaramo nove stvari: nove proizvode, nove funkcionalnosti. Iako liče na ono što smo radili ranije, to nisu kopije prethodnih rešenja. Kontekst se promenio. Mi smo se promenili. Zato naše prethodno iskustvo nije idealan vodič za procenu vremena potrebnog da se posao završi.
Umesto da se oslanjamo isključivo na iskustvo, potrebno je projekat razbijati na manje delove — na manje zadatke koji se lakše mogu proceniti.
Ovde neko može reći: „User story je već dovoljno mala, pa bi trebalo da se može proceniti.“ Tačno — ako je zaista mala. Međutim, timovi se često bore upravo sa veličinom user story-ja.
U veličini user story-ja leži koren problema predvidivosti.
Da bi tim bio predvidiv i mogao da daje pouzdane procene, radne celine moraju biti dovoljno male da omogućavaju dobro razumevanje problema, a samim tim i preciznije procene.
Kako do malih user story-ja?
Deljenje user story-ja nije jednostavno.
Prvo, osoba koja piše user story obično ih piše tako da budu „male“ — po njenim standardima. Jedan kolega mi je jednom rekao da je prva user story koju je napisao glasila:
„Napraviti aplikaciju za video streaming.“
Jasno je u čemu je problem.
Drugo, kada podelimo originalnu priču, sve nove priče moraju zadovoljiti INVEST principe — pre svega da budu vredne (Valuable). To znači da deljenje po tehničkim slojevima (backend, frontend) nema mnogo smisla, jer backend sam po sebi nema vrednost za korisnika.
Vratimo se na primer sa knjigom: to bi bilo kao da prvo prepisujemo samo brojeve stranica, zatim prve rečenice na svakoj stranici… Stranice sa samo brojevima nemaju nikakvu vrednost.
Zato je važno da svaka nova user story „seče kroz“ ceo zahtev — da ima smisla za stakeholder-e (ne zaboravite da su i korisnici stakeholder-i) i da donosi vidljivu vrednost.
Pristup deljenju user story-ja
SPIDR je akronim za skup od pet tehnika koje mogu pomoći u deljenju user story-ja na manje i smislenije celine.
SPIKE
Spike je aktivnost usmerena na sticanje dodatnog znanja o problemu — u ovom slučaju o user story-ju koji pokušavamo da razumemo. Zahteva vreme, pa ga je dobro raditi pre radionice za deljenje user story-ja ili nakon nje, ako se druge tehnike nisu pokazale korisnim.
PATH
Ova tehnika deli priče prema različitim putevima koje korisnici mogu koristiti u aplikaciji. Korisna je kada postoji više načina za obavljanje iste aktivnosti.
Na primer, prijava u sistem može se obaviti putem korisničkog imena i lozinke, Google naloga, otiska prsta ili sertifikata na ličnoj karti. Svaki od tih načina može biti zasebna user story.
INTERFACES
Tehnika Interfaces deli user story-je prema različitim interfejsima koje je potrebno implementirati.
Na primer, ako aplikacija treba da radi na računaru, tabletu i mobilnom telefonu, svaki od tih interfejsa može predstavljati posebnu user story.
DATA
Ova strategija deli user story-je prema podacima koji su potrebni ili koje aplikacija obrađuje.
Na primer, ako aplikacija segmentira korisnike prema različitim karakteristikama, jedna user story može obuhvatiti segmentaciju prema mestu stanovanja, druga prema starosti, a treća prema visini prihoda.
RULES
Tehnika Rules koristi poslovna pravila i tehničke standarde za deljenje priče. Ponekad je moguće privremeno izostaviti kompleksno pravilo kako bi se funkcionalnost brže razvila, a zatim ga dodati kasnije. Naravno, funkcionalnost se neće koristiti u produkciji dok sva ključna pravila nisu implementirana.
Takođe, prihvatljivo je privremeno žrtvovati performanse — dozvoliti da funkcionalnost radi sporije — kako bi se dobio rani feedback od internih stakeholder-a.
Još nekoliko saveta
Savet #1 – Timski rad
Ne zaboravite da je glavni razlog za deljenje user story-ja to što je ona prevelika da bi je razvojni tim mogao pouzdano proceniti. Zato deljenje treba raditi zajedno, kako bi svi razumeli razloge za podelu, šta je proizašlo iz originalne priče i zašto.
Savet #2 – Postavljajte pitanja
Zamolite developere da objasne gde leži kompleksnost i šta otežava procenu. Odgovor na to pitanje često daje dobar trag gde treba napraviti rez.
Na primer, ako radite na in-app tutorijalu, tim može reći da je najveća nepoznanica rad sa slikama — gde ih čuvati, koje dimenzije koristiti i slično. U tom slučaju, priču možete podeliti tako da prvo isporučite tutorijal samo sa tekstom, a zatim dodate slike kroz posebnu user story.
Savet #3 – „Magija brojeva“
Deljenje user story-ja ne znači da zbir story point-a mora ostati isti kao kod originalne priče. Cilj nije „smanjiti broj poena“, već povećati predvidivost isporuke.
Jedna user story procenjena na 8 poena koja se razvlači kroz dva sprinta manje vredi od četiri manje priče procenjene na 3, 3, 2 i 3 poena koje se završe u jednom sprintu.
Razmislite o ovome…
i počnite da kreirate manje user story-je. Delite one koje unose nesigurnost, produžavaju izvršenje i narušavaju stabilan ritam i predvidivost.
Delite ih zajedno sa timom i istražujte izvore kompleksnosti.
Autor: Predrag Rajković
Kao što je već rečeno — deljenje user story-ja nikada nije lako. Možete pročitati više o temi Agile Requirements & User Stories, ali nemojte se ustručavati da potražite pomoć.