Izazovi sa User Story-jem
“Isporučite vrednost korisniku brže, minimizujte birokratiju”
Dr Alistair Cockburn
Kakva sjajna definicija Agile-a od Dr Alistair Cockburna! Najviši prioritet svake kompanije trebalo bi da bude zadovoljstvo korisnika kroz ranu i kontinuiranu isporuku vrednog proizvoda. Pa zašto se onda toliko kompanija muči sa tim?
Na osnovu našeg iskustva, postoji mnogo razloga: testiranje u razvoju, kultura kompanije, hijerarhijska organizacija, zahtevi…
Hajde da se fokusiramo na zahteve!
Šta je problem sa zahtevima?
- Zahtevi se menjaju i to često – različita istraživanja pokazuju da se više od 35% zahteva promeni tokom tipičnog projekta.
- Vrlo često klijent ne zna tačno šta želi (što je u redu, jer, kako se kaže u product management-u, klijent poseduje problem, a mi posedujemo rešenje) – čak i kada klijent zna šta mu je potrebno, može imati poteškoća da to jasno artikuliše ili definiše. A čak i kada su zahtevi dobro definisani, možemo ih potpuno pogrešno razumeti i implementirati nešto što ne odgovara stvarnim potrebama.
Dakle…
…problem sa zahtevima je problem komunikacije.
Šta treba da uradimo?
User Story je Agilne tehnika za definisanje zahteva koja može pomoći u ovom izazovu. To je odličan način za predstavljanje zahteva.
Međutim, mnogi timovi imaju poteškoća u korišćenju User Story-ja.
Izazovi sa User Story-jem
User Story-ji su preveliki (Epics)
Ove priče ne mogu da se završe i „putuju“ iz sprinta u sprint. To demotiviše tim, usporava protok rada i učenje. Epic treba podeliti na manje User Story-je pre ulaska u sprint. Kada su priče male, razumljive, primenjive i vredne – spremne su za realizaciju.
User Story nije jasan razvojnom timu ili Product Owneru
Često ne postoje jasni acceptance kriterijumi i tim ima problem da razume opseg, cilj ili način testiranja. Nejasan User Story dovodi do gubitaka tokom sprinta i ponovnog prebacivanja priča u naredne sprintove.
Nedostatak komunikacije o User Story-ju
User Story je samo početak razgovora – on treba da bude dopunjen diskusijom između Product Ownera i tima. Mnoge kompanije preskaču ovaj deo, pa Product Owner pokušava da napiše previše detaljne priče, što nije svrha User Story-ja. Neophodno je obezbediti kvalitetnu komunikaciju (npr. kroz radionice ili video sastanke). Alternativno, mogu se koristiti i druge tehnike poput Use Case-ova.
Pogrešna svrha
User Story opisuje zahteve krajnjeg korisnika, a ne tehničke zahteve. Ako tim previše koristi tehničke zahteve, to može značiti da su organizovani kao komponentni timovi. Primer pogrešnog korišćenja je: „Kao developer želim…“. Osim ako developer nije krajnji korisnik, ovo nije ispravan pristup. Rešenje može biti formiranje feature timova koji isporučuju vrednost od početka do kraja.
* Postoje situacije gde su komponentni timovi neophodni – tada User Story nije najbolja tehnika i treba koristiti druge pristupe.
Dakle, šta iz ovoga možemo zaključiti?
User Story nije specifikacija, već alat za komunikaciju i saradnju.
On pomera fokus sa pisanja zahteva na razgovor o zahtevima. Suština je u diskusiji sa korisnikom. User Story opisuje kako korisnik koristi proizvod, jednostavnim jezikom.
Product Owner je odgovoran za Product Backlog i predstavlja korisnike, pa mora duboko razumeti njihove potrebe – User Story mu u tome pomaže.
User Story se ne „predaje“ timu, već se zajednički razmatra – tokom refinement-a ili najkasnije na sprint planiranju. Tim bi trebalo da izdvoji do 10% kapaciteta u sprintu za refinement narednih User Story-ja.
Efikasna komunikacija je ključ, a User Story je zajednički jezik koji povezuje korisnike i tim.
User Story-ji predstavljaju jedan od najvećih izazova u ulozi Product Ownera, posebno tokom planiranja sprinta. Agile Serbia, pored sertifikacionih edukacija, organizuje i timske i mentorske programe kako bi pomogla klijentima da se nose sa ovakvim izazovima. Ako vam je potrebna pomoć, znate gde nas možete pronaći.
