Korisničke Priče i Skladan Razvoj

Definiranje korisničkih priča i agilni razvoj

Temeljno načelo modernih razvojnih procesa je agilni razvoj . Ova razvojna metodologija naglašava korištenje malih, kratkih korisničkih priča kako bi se definiralo što sustav radi iz korisničke, a ne tehničke perspektive. Korisniku je bitno je li proizvod brz, jednostavan za korištenje i rješava li njegov problem. Nije ih briga slijedi li 3-slojnu arhitekturu, ima li Mongo DB ili koristi li Rails ili Asp.net.

Korisničke priče:

• Lako ih je razumjeti i svatko može sudjelovati
• Raditi iterativno; mogu se i trebaju često mijenjati ili dopunjavati
• Uskladite programere, korisnike i poslovne stručnjake oko zajedničkih ciljeva i očekivanja
• Puno su lakši za čitanje od potrebnih dokumenata od 400 stranica

Storyboard That pruža idealnu platformu za stvaranje agilnih korisničkih priča i poticanje razgovora u formatu koji je mnogo manje naporan od zida teksta.

Ep

U kontekstu korisničkih priča, "ep" je jednostavno vrlo široka priča koja će se kasnije raščlaniti na mnoge specifične korisničke priče. Počevši od epa, svi se usklađuju s jednom vizijom visoke razine. Epska priča usidri projekt od vrha prema dolje, a ako nema smisla konstruirati ep, pomoćni rad također će biti gubitak truda.

U ovoj priči vrlo je jasno što je dugoročna vizija i kako bi uspjeh trebao izgledati. Dobra epska priča trebala bi uključivati:

• Postavka ili kontekst
• Glumci ili korisnici
• Ciljevi i ciljevi
• Aktivnosti i događanja

Definiranje korisnika

Osobito kod dizajniranja softvera važno je imati dobru viziju kakvi će biti korisnici. Neće svaki korisnik točno odgovarati ovoj viziji i može postojati više kategorija korisnika, ali ove diskretne vizije trebaju artikulaciju. Razmišljanje o korisnicima prvo štiti od pretjeranog inženjeringa i prekompliciranja, sprječavajući da novi proizvod ima ponešto za svakoga i da nikome ne bude koristan.

Stvaranje priče

Nakon što se uspostavi ep i korisnici definiraju, mogu se konstruirati manje, specifičnije priče o određenim korisničkim iskustvima. Priče u nastavku raščlanjuju gore navedeno na dvije priče: traženje narudžbe i ponovno naručivanje proizvoda.

Ovi narativi ne sadrže tehničke informacije; korisnike nije briga kako se postižu rezultati, sve dok obavlja željene zadatke. Slično tome, UX je prikazan generički, kako bi se izbjeglo gušenje inovacija ili forsiranje puta. Općenito, priče bi trebale biti:

• Mali – manje od 10 dana rada
• Vrijedan – Nakon dovršetka trebali bi isporučiti nešto upotrebljivo
• Procjenjivo – Sposobnost stvaranja okvirne procjene koliko je truda uključeno

Traženje narudžbe

Izvođenje ponovnog naručivanja

Razgovor i planiranje testiranja

Ove bi priče trebale potaknuti na razgovor i pitanja, kao što su:

• Jesu li ovo prave priče koje odgovaraju našem epu?
• Koje druge priče treba stvoriti?
• Jesu li ove priče u skladu s onim što znamo o našim korisnicima?

Savršeno je razumno stvarati mnogo priča; zapravo, treba ga poticati. Neke od tih priča nikada neće biti iskorištene, ali važno je vidjeti put kojim su krenule. Ova zbirka priča će ukloniti dodatne zahtjeve i utjecati na testiranje.

Priče bi trebale potaknuti i informirati raspravu o tome kako će se softver testirati i koja pravila poslovanja treba eksplicitno definirati. Na primjer:

• Koliko brza pretraga mora biti?
• Postoji li vremensko ograničenje za ponovne narudžbe?
• Što bi sustav trebao učiniti ako je to druga ponovna narudžba? Peti?
• Koje biste testove i dodatna pitanja imali?