Oko toga šta je dobra priča vjerovatno se lome komlja u akademskim krugovima, ali i među običnim svijetom. Nekada je neka dobra priča iz akademskog ugla veoma ogavna, dok je kod običnog svijeta itekako prihvaćena zbog njene jasnoće, preciznosti izražaja, i obrnuto.
Ono što nas u svijetu inžinjerstva kao dobra priča zanima, ne tiče se previše niti akademskih krugova, a niti običnog svijeta, nego priča koja jasno opisuje šta je to što treba da se uradi kako bi se napravio progres kod izrade rješenja i postizanja konačnog cilja/rezultata.
Svi timovi pokušavaju da usvoje neku od agilnih metoda rada kako bi ubrzalil procese, smanjili troškove i naravno ostvarili veći profit na kraju. Jedana od najpopularnijih agilnih metoda je svakako i Scrum unutar koje se može naći nešto što se zove Backlog item. Teoretičari Scrum-a će reći kako njih apsolutno ne interesuje šta piše u opisu jednog Backlog item-a, nego samo da li je valjano procijenjena njegova kompleknost kako bi se moglo pratiti njegovo sagorijevanje na dijagramu sagorijavanja. Tj. kakav je napredak ukupnog projekta ili funkcionalnosti na kojoj se trenutno radi. Međutim, oni koji se bave praktičnom primjenom bilo koje agilne metodologije, pa bila ona Scrum, Kanban, Lean ili neka potpuno druga itekako vode računa i znaju da je veoma važno, ako ne i najvažnije prije početka rada na nekom zadatku (item), znati šta u njemu piše.
Ono što piše u nekom zadatku nazivamo pričom (Story).
Praksa je pokazala da je najbolje pisati priče slijedeći XP (Extreme programming) model, a taj model je nalik na (šablon):
Ja kao neka uloga želim da:
- Nabrajanje aktivnosti
- Nabrajanje aktivnosti
Tako što ću:
- Nabrajanje uslova
- Nabrajanje uslova
Da bih dobio:
- Nabrajanje rezultata
- Nabrajanje rezultata
Pri čemu trebaju da budu ispunjeni slijedeći kriteriji:
- Navođenje kriterija
- Navođenje kriterija
Svakako, šablon iznad ne mora biti zadovoljen u spomenutom obliku, ali tačke koje vode ka konačnom obliku priče, bi trebale da budu tu (ne obavezno sve, one trebaju biti smjernice), a te tačke su:
- Ko je onaj/ona koji traži tu funkcionalnost. To može biti specifična osoba, kao recimo Kranji korisnik, Administrator, Anonimna osoba, Servis koji će korisitti taj servis i slično. Nije obavezno da to bude ličnost, ljudsko biće, može biti i neki servis svakako.
- Šta se želi raditi? To može biti jedna ili više, povezanih ili zasebnih akcija. Ako akcija ima previše, posebno ako nisu vezane, onda treba možda razmisliti da se priča podijeli u više zasebnih priča.
- Na koji način se želi raditi? Uz pomoć pomagala, kao što je npr, mišem, tastaturom, prstom na mobitelu ili mahanjem ruke na pametnoj narukvici i slično.
- Šta se želi dobiti kao rezultat rada? To može biti jedna stvar ili više povezanih ili ne. Međutim, kako smo naveli iznad, ako se želi više nepovezanih rezultata, možda da se razmisli o tome kako podijeliti priču u više zasebnih priča.
- Šta je prihvatljivo, a šta ne tokom gore navedenih akcija? Kod kriterija šta se želi imati i na koji način se žele postaviti granice, mnogi od nas zaborave postaviti granice i kriterije šta se NE ŽELI vidjeti unutar rješenja/rezultata koje će se dostaviti. Na ovaj način se neće događati prekomjerna izrada (overengineering) i izvršioci će znati da ne trebaju da razmišljajuu preširoko tokom izrade. Za uspješan i kvalitetan progres šta se NE ŽELI je veoma važna stvar. Kriteriji se inače mogu podijeliti u nekoliko vrsta i to, npr: funkcionalni, nefunkcionalni, sigurnosni i performansni.
U nastavku ćemo dati jedan primjer kako bi neka priča trebala da izgleda.
Primjer
Ja kao Administrator, želim da mogu:
- Dodati novog korisnika.
Prillikom dodavanja korisnika želim da upišem slijedeće podatke:
- Ime, prezime, adresu, email, broj telefona.
Na taj način korisnik bi trebao biti pripravan i u mogućnosti da se prijavi.
Kriteriji prihvatljivosti:
- Korisnik mora biti označen kao pripravan.
- Jednom kada se korisnik prijavi i potvrdi email adresu promijeniće mu se status iz pripravan u aktivan.
- Korisnik ne može biti označen kao neaktivan tokom dodavanja.
- Ne želim dodati nikakve dodatne informacije osim navedenih uključujući i sliku korisnika.
- Korisnik ne može dobiti nikakva dodatna prava osim prava običnog korisnika tokom njegovog dodavanja.
- Korisnik će dobiti početne prijavne podatke na sistem putem email-a u kojem će se nalaziti: korisničko ime/email adresa za prijavu, početna šifra koju će korisnik morati promijeniti nakon prve prijave i URL adresa na kojoj će korisnik sve obaviti.
- Kao administrator želim dobiti obavijest da je korisnik primio email.
- Kao administrator želim dobiti obavijest da se korisnik prvi put prijavio i promijenio svoj status iz pripravan u aktivan.
Sada je na red došlo da se kaže ko je taj koji će sve ovo napisati. U zavisnosti od strukture firme, timova i organizacionih jedinica, te čime se bave tu čast mogu imati različite uloge u timovima. No, kada govorimo o IT svijetu i slijeđenju agilnih metodologija, onda tu odgovornost i obavezu mora na sebe preuzeti prvi tzv. stakeholder, odnosno Vlasnik proizvoda (Product owner).
Mala napomena.
Product owner, nije isto što i Project owner. Također, Product owner ne smije ni u kom slučaju da menadžeriše ljude koji rade na proizvodu, nego sam proizvod! Ovo je za mnoge veoma teško, posebno ako su stariji ili pak radili u organizacijama koje vuku organizacione korijene još iz doba prije pada Berlinskog zida.
0Hits: 1