Korisnička priča (eng: User Story) i Funkcionalni zahtjev korisnika (eng: Functional requirement) su uobičajeni pojmovi koji se koriste u softverskoj industriji. Ali šta su oni? Da li su drugačiji ili je to potpuno ista stvar? Odgovorićemo na ova pitanja u ovom postu.
Šta je Korisnička priča - User story?
Korisničke priče su kratki opisi funkcionalnosti iskazanih iz perspektive korisnika. Fokus je na zašto i kako korisnik komunicira sa softverom. Korisnička priča je u osnovi definicija visokog nivoa onoga što softver treba da bude u stanju da radi. Obično se svaka povratna informacija ili zahtjev koji potiče od preduzeća ili krajnjeg korisnika može napisati kao korisnička priča. To se radi na stikeru dimenzija 5x12 cm i stavljaju se na tablu, tako da opis (Description) ide na prvu stranu a detalji (Acceptance criteria) iza. Nakon toga slijedi diskusija o svakom pojedinačnom, izbacivanje ili dodavanje novih i redanje po prioritetima.
Dobra korisnička priča napisana je jednostavnim jezikom i govori o razlogu i očekivanim prednostima određenog područja softvera. Obično slijede templejtu kao što je ovaj:
Kao <tip korisnika>
želim <neki željeni ishod>
tako da <neki razlog>
Evo primjera korisničke priče za izradu aplikacije za e-prodavnica:
Kao kupac, želim da mogu pregledati predmete u svojoj korpi, tako da znam šta kupujem.
Kriterijumi prihvatanja (Acceptance criteria) često prate korisničku priču. Ovi kriterijumi su granice korisničke priče (karakteristike) i u suštini određuju kada je korisnička priča završena (Definition of done):
Kriterijumi prihvatanja su takođe ono za šta će izvođač napisati a zatim i sprovesti svoje testove. Kriterijume prihvatanja možete smatrati funkcionalnim zahtjevima koji podržavaju korisničku priču. Oni potvrđuju prioritete i integrišu perspektivu korisnika u pristup razvojnog tima. Korisničke priče se često koriste u aglilnom razvoju softverskih rješenja i prisutni su u Scrum framework-u kao početni i neizostavni element.
Šta je funkcionalni zahtjev?
Tradicionalni funkcionalni zahtjevi opisuju kako softver treba da djeluje. Glavni cilj je sistem. Dokumenti sa funkcionalni zahtjevima sadrže vrlo detaljne specifikacije o načinu na koji softver treba da funkcioniše. Obično služe u svrhu vođenja načina na koji će tim softvera nešto napraviti.
Iako su korisničke priče jednostavne, funkcionalni zahtjevi predstavljaju dokumente sa mnogo detalja za čiju izradu je potrebno dosta vremena. Dokumenti sa funkcionalnim zahtjevima često sadrže stvari poput sažetaka za menadžment, obuhvata projekta, BBP As Is, BBP ToBe, Rizika i još mnogo toga. Oni postavljaju nivo kvaliteta funkcionalnosti, performansi i korisničkog iskustva.
Evo primjera nekoliko funkcionalnih zahtjeva za aplikaciju e-prodavnica:
- Prikažite ime svakog predmeta u korpi za kupovinu.
- Prikažite količinu svakog proizvoda u korpu za kupovinu.
- Dozvolite korisniku da ukloni sve predmete iz korpe za kupovinu.
Koje su glavne razlike?
Generalno, korisničke priče se češće koriste u okviru agilne metodologije i Scrum framework-a, dok su funkcionalni zahtjevi, zahtjevni dokumenti često povezani sa tradicionalnom metodologijom implementacije tzv. vodopad:
Zbog jednostavne prirode korisničkih priča, one promovišu više diskusije i saradnje nego kod dokumenata o funkcionalnim zahtjevima. Kao što možete vidjeti u gornjim primjerima, funkcionalni zahtjevi postavljaju visok nivo detaljnosti, dok primjer korisničke priče ostavlja prostor za diskusiju. Ovi razgovori mogu se odvijati prije ili u toku sesije planiranja. U slučaju korisničkih priča, glavnu ulogu vodi Product owner koji uz pomoć Scrum Master-a i tima za razvoj završavaju posao implementacije.
U dokumentaciji funkcionalnih zahtjeva, svi veći detalji su već razrađeni. Prilično je rijetko da programer sam dodaje ili izmjeni funkcionalne zahteve bez provođenja propisane procedure kao što je Zahtjev za izmjenom (Change request).
Važno je napomenuti da do trenutka implementacije softvera po dokumentaciji sa funkcionalnim zahtjevima, stvarni zahtjevi su se možda promijenili.
Pomoću korisničkih priča svako i u svakom trenutku bi mogao da doprinese dopuni Product Backlog-a kad god se ukaže potreba za tim. To može biti programer koji postavlja pitanja o tehničkoj realizaciji, klijent koji zahtjeva novu funkciju ili tester koji je primjetio problem sa UX-om. Product Backlog je zajednički napor i samim tim osigurava da se posao koji se obavlja usklađuje sa potrebama klijenata.
Rezime
Iako su slične prirode, korisničke priče i funkcionalni zahtjevi su prilično različiti i uključuju drugačiji pristup radu i izgradnji softvera.
Agilni timovi imaju tendenciju da koriste korisničke priče češće nego funkcionalne zahtjevi jer omogućavaju fleksibilnost i saradnju, dok timovi koriste vodopad metodologiju kako bi dobili dokumente sa funkcionalnim zahtjevima kako bi:
- unaprijed odredili najsitnije detalje korisničkih potreba i zahtjeva,
- da rezervišu sve potrebne resurse za realizaciju - implementaciju,
- da spriječe izmjene zahtjeva od strane korisnika u toku implementacije.
Projekat FBI Sentinel
Toplo preporučujem da pogledajte ovu kratku priču o projektu FBI Sentinel. Vidjećete koliko je novca za implementaciju FBI potrošio i na koji način je uspio. U ovom videu možete videti i činjenice tradicionalne implementacije vodopada i implementacije Agile sa Scrum-om:
Vezani tekstovi:
- BESPLATAN Scrum Kurs: Full Course: Learn How Scrum Works in 30 Minutes
- Vodič za Scrum - Pravila igre za polaganje ispita
- Šta je to Product Owner i koja je njegova odgovornost?
Ako vam se ovaj članak dopao, lajkujte FB stranicu DM Spot, Twitter ili LinkedIn i budite obavješteni kad novi članak bude objavljen.
