Da bi User Story bio dovoljno dobro pripremljen i spreman za sprint, mora da prođe određene kriterijume. Cilj ovog teksta je da razjasnimo ne šta je User Story, već kako tačno znamo da je User Story dobro napisan i spreman za sprint.
Iako su prednosti pisanja User Story (korisničkih priča) značajne, Product Owner mora uzeti u obzir i potencijalne nedostatke ili tačnije najčešće zamke na koje je moguće naići. Zato ćemo krenuti upravo od toga, koje zamke treba izbeći prilikom pisanja User Story.
Uobičajene greške kod User Story
Evo nekoliko zamki na koje možete naići prilikom pisanja user story i na koje treba obratiti pažnju:
Nepotpune priče
Iako je zamišljeno da jezik bude neformalan, ponekad su korisničke priče previše nejasne i isključuju neophodne detalje.
Nedovoljno vremena
Pisanje dobre korisničke priče zahteva vreme. To zahteva opsežno istraživanje i redovnu komunikaciju sa zainteresovanim stranama, što se ponekad zanemaruje.c
Uska vizija
Pošto se korisničke priče fokusiraju na jedan jedini zahtev, može ih biti teško skalirati, a timovi ponekad mogu izgubiti iz vida širu sliku. Pre nego što započnete pisanje svoje user story, odvojite malo vremena da identifikujete potencijalne rizike ili nedostatke i navedete kako želite da im se suprotstavite.
Šta je dobar User Story i kada je spreman za sprint?
Još 2003. godine Bill Vake je predstavio INVEST šemu kako bi pomogao da razumemo karakteristike dobre korisničke priče. INVEST šema je dobar način da razumemo kada smo User Story dovoljno detaljno razradili i kada može da uđe u sprint. Ova šema je obavezni deo našeg Scrum Master kursa.
Dobar User Story ili dobra korisnička priča je:
I – Independent – nezavisna
Želite da korisničke priče budu nezavisne jedna od druge, tako da možete slobodno da ih pomerate kroz Product Backlog u zavisnosti od toga kako se prioriteti menjaju. Dakle, User Story treba da bude nezavisna od drugih User Stories i nezavisna od redosleda implementacije.
N – Negotiable – fleksibilna
Upisujete detalje korisničke priče u saradnji između vašeg klijenta i tima koji će je implementirati. Ova saradnja uključuje pregovaranje o obimu: šta će implementacija uključiti, a šta neće. User Story opisuje namenu, a ne pruža specifikaciju i fleksibilnog je obima.
V – Valuable – vredna
Dobra korisnička priča je korisna, pruža vrednost za klijenta/korisnika. Bez te vrednosti, nema smisla ulagati bilo kakav napor u User Story.
E – Estimable – procenjiva
Ako ne možete da procenite User Story, to znači da je još uvek ne razumete dovoljno dobro ili je obim prevelik da bi se lako procenio. Nisu vam potrebne tačne procene, ali kada možete da procenite priču, o tome se može pregovarati. Osim toga, moći ćete da razlikujete priče o vrednom malom trudu i ne tako vrednim pričama o velikom trudu.
S – Small – mala
Želite da napor za implementaciju korisničke priče bude mali. Najviše nekoliko nedelja (od strane jedne osobe), iako mnogi timovi koriste „nekoliko dana“ kao ograničenje. Manje priče je lakše proceniti. Velike priče je teže proceniti, a samim tim je i teže pregovarati o njima.
T – Testable – proverljiva
Svaka User Story mora da ima mogućnost testiranja. Kako ćete klijnetu dokazati da ste nešto uradili na pravi način, baš onako kako je želeo, ako to ne možete testirati. Zato je bitno da svaka User Story može da se testira izbegavajući preradu kao rezultat nesporazuma.
Pored ovog klasičnog INVEST pristupa koji govori o tome šta je dobra User Story, možemo dodatno primeniti 3C metodu.
3C korisničke priče
„3C“ pomaže da se svrha korisničke priče zadrži u perspektivi. Hajde da pogledamo značenje svakog C od koji se korisnička priča u scrumu sastoji.
Card – Kartica
Kartica je čuvar mesta koji predstavlja korisničku priču u njenom sirovom obliku. Rezimira detaljan zahtev. Ovi detalji tek treba da se utvrde. Kartica ima sledeći format: „ko(uloga)“, „šta(akcija)“ i „zašto(koristi)“.
Conversation – Razgovor
Razgovor predstavlja diskusiju između korisnika, tima, vlasnika proizvoda i drugih zainteresovanih strana kako bi se utvrdilo kako se namera može primeniti. U ovom trenutku, kartica se prilagođava na osnovu razumevanja samog razgovora. Iako obično verbalno, može biti podržano i dokumentacijom i drugim automatizovanim testovima.
Confirmation – Potvrda
Potvrda predstavlja uslove koje je potrebno ispuniti da bi se utvrdilo da li priča ispunjava nameru i neke druge detaljnije uslove.
Za uspešno agilno upravljanje projektima jako je važno jasno razumevanje šta su Epics, User Story i zadaci kao i njihovo značenje u Agile/Scrum-u.
Epic – To je nešto toliko veliko da se gotovo sigurno neće uklopiti u sprint, nejasno je u pogledu zahteva klijenata i trebalo bi da se podeli na user stories. Epics se često definišu u ranim fazama mapiranja puta proizvoda, a zatim se razbijaju na User Stories u zaostatku proizvoda kada dodatne informacije postanu dostupne.
User Story – Korisnička priča je sve što može da se primeni u sprint. Ovo su tačke priče i definicije zasnovane na INVEST kriterijumima. Do kraja iteracije, priče bi trebalo da klijentu daju vertikalni deo funkcionalnosti koji je i vredan i potpun. Tipično, priče se razvijaju tokom procesa razvoja proizvoda, posebno pre planiranja sprinta i tokom višeg nivoa mapiranja proizvoda.
Zadatak – Oni su dekomponovani delovi korisničke priče koji definišu kako će se priča završiti. Ako je potrebno, zadaci se mogu proceniti po satu. Zadatke obično definišu pojedinci koji obavljaju posao, dok User Story i Epics obično razvijaju klijenti. Pošto su zadaci privremeni, oni se realizuju unutar sprinta.
Uspeh projekta leži u razumevanju zahteva korisnika tačno i na odgovarajući način, a zatim u njihovoj implementaciji u finalni proizvod. Stoga, zahtevi ili karakteristike proizvoda moraju biti u potpunosti poznati Scrum timu.
Srodne teme: