Zašto je izvršavanje projekata nepredvidivo?
Zamislite….
... da vodite kompaniju koja kreira proizvod ili uslugu za tržište.
... da imate posvećen tim koji radi na proizvodu.
... da postoji roadmap, plan. Uz njega postoje i očekivanja… Očekivanja od stakeholdera, od tima, od korisnika, od vas.
... ako se plan ispuni, svi će biti zadovoljni, biće proslava, biće mnogo tapšanja po ramenu, možda čak i finansijskih stimulacija.
Sada prestanite da zamišljate!
Svi izgleda daju sve od sebe, ali stvari ne prate plan. Funkcionalnosti kasne, milestone-i se propuštaju, rokovi se odlažu. Ali najgore od svega je to što nema ritma, nema predvidljivosti! Šta god tim planira, šta god obećate stakeholderima, koje god buffer-e ubacite u planove — jednostavno nije dovoljno. To narušava vaše samopouzdanje, razara poverenje koje imaju stakeholderi i potpuno uništava moral svih ljudi koji rade na proizvodu.
Propuštanje rokova je loša stvar, ali najgora noćna mora svakog ko se bavi isporukom jeste nedostatak predvidljivosti. Zato vredi uložiti vreme da se razume odakle to dolazi.
Postoji nekoliko razloga zašto isporuka postaje nepredvidiva i zašto ne možete da kažete kada će neka funkcionalnost biti gotova:
- Razumevanje onoga što se gradi je nisko
- Neiskusan tim radi na proizvodu (pod tim se misli na sve ljude: dizajnere, developere, product ljude…)
- Problemi u procesu rada
Hajde da dublje uđemo u prvi razlog. Jasno je da je razumevanje problema koji rešavamo ključni korak ka pronalaženju rešenja. Postoji mnogo stvari koje utiču na nisko razumevanje, ali jedna je posebno zanimljiva – neadekvatna veličina radnih elemenata.
Uzmimo banalan primer:
Ako biste morali da prepišete celu Bibliju (ili bilo koju drugu knjigu), da li biste mogli da procenite koliko vremena je potrebno?
Šanse su da nikada niste imali takav zadatak, pa verovatno ne biste mogli da procenite vreme. Iako ste ceo život pisali razne stvari i to radite svakodnevno.
Ono što MOŽETE da procenite jeste koliko vam treba za jednu stranicu, ili još bolje — za jedan red teksta.
Poenta je da mnogo bolje procenjujemo manje delove posla. Bolja procena daje veću predvidljivost output-a, odnosno kada će posao biti završen.
Problem predvidljivosti
Sada, posle ovog „biblijskog“ zaključka, vratimo se na realnost isporuke projekata.
Kreiramo nove stvari, nove proizvode, nove funkcionalnosti… Iako liče na nešto što smo ranije radili, one nisu kopije. Kontekst se promenio, MI smo se promenili, što znači da prethodno iskustvo nije idealan vodič za procenu vremena.
Umesto da se oslanjamo samo na iskustvo, treba da delimo projekat na manje delove — manje zadatke koji se lakše procenjuju.
Ovde se može reći: user story je dovoljno mali da bi bio procenjiv. Tačno — AKO je zaista mali. Vrlo često timovi imaju problem sa veličinom user story-ja.
U veličini user story-ja leži koren problema predvidljivosti.
Da bi tim bio predvidljiv i mogao da daje dobre procene, radni komadi moraju biti dovoljno mali da omoguće dobro razumevanje problema i preciznu procenu.
Kako postići male user story-je?
Deljenje user story-ja nije lako.
Prvo, osoba koja ih piše često misli da su već dovoljno mali. Jedan kolega je jednom rekao da je njegov prvi user story bio: „Kreiraj aplikaciju za video streaming.“ Vidite problem?
Drugo, nakon podele, nove priče moraju zadovoljiti INVEST principe — moraju biti vredne. To znači da podela po slojevima (backend/frontend) nema smisla, jer backend sam po sebi nema vrednost. Kao da prvo kopirate samo brojeve stranica knjige, pa tek onda tekst — nema vrednosti u praznim delovima.
Zato svaki novi user story mora imati smisla sam za sebe i donositi vrednost stakeholderima.
Pristupi deljenja user story-ja
Spidr je akronim za 5 tehnika koje pomažu u deljenju user story-ja:
SPIKE
Spike je aktivnost koja je namenjena sticanju znanja o nekom problemu. U ovom slučaju o konkretnoj user story. Zahteva vreme, pa je dobra ideja da se uradi ili pre workshop-a za deljenje story-ja, ili posle njega ako sve druge tehnike nisu bile korisne.
PATH
Ova tehnika deli story-je na osnovu putanja koje korisnici aplikacije mogu koristiti. Obično se koristi kada postoji više načina da se izvrši neka aktivnost. Na primer, ako se možete prijaviti koristeći username i password, ili Google nalog, ili otisak prsta, ili sertifikat na ličnoj karti. Svaki metod prijave može biti poseban user story.
INTERFACES
Tehnika Interfaces deli user story-je na osnovu različitih interfejsa koji treba da budu implementirani. Na primer, ako vaša aplikacija treba da bude dostupna na računaru, tabletu i mobilnom telefonu, to mogu biti odvojeni user story-ji.
DATA
Ova strategija nam pomaže da podelimo user story-je na osnovu podataka koji su potrebni ili koje aplikacija pruža. Na primer, ako vaša aplikacija treba da segmentira korisnike na osnovu različitih karakteristika, možete imati jedan user story koji kreira segmente na osnovu mesta stanovanja, drugi koji koristi njihove godine, i treći koji segmentira korisnike na osnovu njihovih godišnjih prihoda.
RULES
Rules je poslednja tehnika u ovom framework-u. Ona koristi poslovna pravila i tehnološke standarde da podeli story. Možete preskočiti neko poslovno pravilo koje stvara kompleksnost kako biste kreirali funkcionalnost, a zatim kasnije dodati to preskočeno pravilo. Naravno, nećete koristiti funkcionalnost u produkciji dok sva kritična pravila nisu završena. Takođe, žrtvovanje performansi i dozvoljavanje da stvari rade sporije nego što bi trebalo je prihvatljiv pristup u deljenju story-ja. To ne ide u release, ali možete dobiti povratne informacije od internih stakeholdera.
SAMO NEKOLIKO SAVETA
Savet #1 Tim
Nemojte zaboraviti da je glavni razlog deljenja to što je story preobiman da bi ga razvojni tim mogao proceniti. Zato deljenje treba raditi zajedno, kako bi svi bili svesni razloga deljenja, šta je proizašlo iz originalnog story-ja i zašto.
Savet #2 Postavljajte pitanja
Pitajte developere gde leži kompleksnost, šta otežava procenu. Obično odgovor na ovo pitanje daje dobar osnov da se odredi linija gde treba preseći. Na primer, ako radimo in-app tutorijal za korišćenje aplikacije, tim može reći da kompleksnost dolazi od korišćenja slika u tutorijalu jer to nikada ranije nisu radili, nisu sigurni gde da skladište slike, koja bi trebala da bude odgovarajuća veličina slike… U tom slučaju možemo razmotriti podelu story-ja duž te linije. Drugim rečima, možemo imati user story koji isporučuje tutorijal samo sa tekstom, i drugi gde dodajemo slike.
Savet #3 Magija brojeva
Imajte na umu da deljenje user story-ja ne znači da novi story-ji treba da imaju isti ukupan broj story pointova (ako ih koristite) kao originalni story. Deljenje nije magično smanjenje broja story pointova, već povećanje predvidljivosti isporuke. Drugim rečima, imati jedan user story procenjen na 8 poena koji se razvlači kroz dva sprinta ima manju vrednost nego imati 4 user story-ja procenjena na 3, 3, 2, 3 poena koji se završe u jednom sprintu.
Sada razmislite o ovome….
... i počnite da kreirate manje user story-je, počnite da delite one koji uvode nesigurnost, produžavaju izvršenje i narušavaju stabilan tempo i predvidljivost. Delite ih sa timom i istražujte izvore kompleksnosti!
Autor: Predrag Rajković
Kao što sam već spomenuo: deljenje user story-ja nikada nije lako. Ovde možete pročitati više o Agile Zahtevima & User Story-jima, ali molim vas, nemojte se plašiti da zatražite pomoć!
