Kaip parašyti geras judrių vartotojų istorijas
Vienas iš pirmųjų žingsnių pristatant kokybišką produktą yra gerų vartotojų istorijų rašymas. Šiame įraše aprašome, kaip rašyti geras vartotojų istorijas ir ką reikėtų įtraukti.
Vartotojo istorija yra vieta, kur užfiksuoti produkto funkcionalumą, ir, kaip rodo pavadinimas, vartotojų istorijose aprašoma, kaip klientas ar vartotojas naudos produktą.
Vartotojo istorija reiškia nedidelį funkcionalumą, kuris turi verslo vertę, kurią komanda gali suteikti sprinto metu. Skirtumas tarp vartotojo istorijos ir tradicinio reikalavimo dokumento yra detalumo lygis.
Reikalavimų dokumentuose paprastai yra daug teksto ir jie yra labai išsamūs, o vartotojų istorijos daugiausia grindžiamos pokalbiais.
Vartotojo istorijos struktūrą galime suskaidyti taip:
- Trumpas poreikio apibūdinimas
- Pokalbiai, vykstantys dėl atsilikimo ir sprinto planavimo, kad išsiaiškintų detales
- Priėmimo testai, kurie patvirtina patenkinamą istorijos užbaigimą
Svarbus momentas, į kurį reikia atkreipti dėmesį rašant vartotojo istorijas, yra tai, kad jie parašyti iš vartotojo, kuris galiausiai naudos produktą, perspektyvos, todėl svarbu, kad rašydami vartotojo istorijas aiškiai nustatytume, kas yra vartotojas.
Kaip parašyti geras vartotojų istorijas
Kaip taisyklė, gera vartotojo istorija turėtų atitikti INVEST akronimą:
Aš ndependent - vartotojo istorijos neturėtų priklausyti viena nuo kitos, todėl jas galima kurti bet kokia tvarka.
N egoistiškas - venkite per daug detalių; išlaikyti juos lanksčius, kad komanda galėtų pakoreguoti, kiek istorijos įgyvendinti.
V aluable - istorija turėtų suteikti tam tikrą vertę jos vartotojams.
IS stimuliuojamas - komanda turi mokėti įvertinti istoriją.
S prekybos centras - vartotojų pasakojimai turėtų būti pakankamai maži, kad tilptų į sprintą; dideles istorijas sunku įvertinti ir suplanuoti.
T estable - užtikrinti, kad tai, kas kuriama, gali būti tinkamai patikrinta ir išbandyta.
Koks formatas naudojamas vartotojo istorijoms rašyti?
Vartotojų istorijos paprastai yra tokio formato:
_A kaip aš noriu taip ._
Pavyzdys: Kaip a klientas abc.com, noriu a Prisijungti funkcionalumą, kad galėčiau prisijungti prie mano sąskaitos informacijos internete .
Kaip minėta anksčiau, atkreipkite ypatingą dėmesį į tai, kas yra produkto vartotojas, ir venkite bendro „Vartotojo“ vaidmens. Jei nežinote, kas yra vartotojai ir klientai ir kodėl jie norėtų naudoti produktą, turėtumėte tai padaryti ne rašyti bet kokias vartotojų istorijas.
Pasakojimas
- Pirmoji vartotojo istorijos dalis yra Pasakojimas. 2–3 sakiniai, naudojami aprašyti istorijos tikslą. Tai tik tyčios santrauka.
Pokalbiai
- Svarbiausias vartotojo istorijos aspektas yra pokalbiai, kurie turėtų vykti nuolat tarp kūrėjų komandos, kliento, produkto savininko ir kitų suinteresuotųjų šalių, kad būtų įtvirtintos vartotojo istorijos detalės.
Priėmimo kriterijai
- Priėmimo kriterijai atspindi pasitenkinimo sąlygas, kurios yra parašytos kaip scenarijai, paprastai Gherkin (Given, When, Then) formatu. Priėmimo kriterijai taip pat pateikia istorijos apibrėžimą „Atlikta“.
Kas turėtų rašyti vartotojų istorijas?
Daugeliu atvejų vartotojų istorijas rašo a Produkto savininkas arba „Verslo analitikas“ ir pirmenybė teikiama neužbaigtame gaminyje. Tačiau tai nereiškia, kad rašyti vartotojo istorijas yra tik produkto savininko pareiga. Tiesą sakant, bet kuris komandos narys gali rašyti vartotojų istorijas, tačiau produkto savininkas yra atsakingas už tai, kad būtų sukurtas nepilnas naudotojų istorijų sąrašas ir jie būtų prioritetiniai.
Svarbu, ar tos vartotojų istorijos neturėtų traktuoti kaip reikalavimų dokumentą, kurį parašius, jis bus perduotas kūrimo komandai įgyvendinti.
Vartotojų pasakojimai turėtų būti vertinami kaip priemonė skatinti produkto savininką ir kūrėjų komandą, todėl turėtų būti rašomi kartu per produkto nenaudojamų prekių priežiūros seansus.
Privalumas įtraukti kūrėjų komandą rašant vartotojų istorijas yra tas, kad jei yra kokių nors techninių apribojimų, juos galima iš anksto paryškinti. Testuotojai gali ypač prisidėti kurdami veiksmingus priėmimo kriterijus ir iš anksto suplanuoti, ką ir kaip reikia išbandyti.
Kiek išsamios turėtų būti vartotojų istorijos?
Vartotojų istorijose daugiausia dėmesio skiriama kliento vertei.
Pagrindinis skirtumas tarp vartotojo istorijų ir kitų reikalavimų specifikacijų yra detalumo lygis. Vartotojo istorija yra atlikto darbo metafora, o ne išsamus darbo aprašymas. Faktinis atliekamas darbas yra tobulinamas bendradarbiaujant aplink vartotojo istoriją, kai sistemos plėtojimasis vyksta.
Jei aprašymas pasidaro per ilgas (daugiau nei tiks indekso kortelėje), turėtumėte dar kartą peržiūrėti vartotojo istoriją. Tikėtina, kad bandote įtraukti per daug detalių.
Atminkite, kad vartotojo pasakojimo tikslas yra skatinti bendradarbiavimą. Tai nėra skirta dokumentuoti kiekvieną darbo aspektą, kaip paprastai būna tradicinių reikalavimų teiginiuose.
Be to, per daug informacijos aprašyme gali trūkti informacijos priėmimo kriterijuose.
Prieš sutikdama dirbti su istorija, komanda turi suprasti priėmimo kriterijus. Tai yra būtina norint žinoti, ką reikia padaryti, norint patenkinti vartotojo istoriją. Priėmimo kriterijai turėtų būti pakankamai išsamūs, kad apibrėžtų, kada vartotojo istorija yra patenkinta, tačiau ne tokie išsamūs, kad panaikintų bendradarbiavimą.
Dažniausios klaidos rašant vartotojų istorijas
Per daug formali ar per daug detalių. Gerų ketinimų turintys produktų savininkai dažnai bando parašyti itin išsamias vartotojų istorijas. Jei komanda mato iteracijos planavimo istoriją, panašią į IEEE reikalavimų dokumentą, ji dažnai mano, kad yra visos detalės, ir praleis išsamų pokalbį.
Vartotojo istorijų rašymas atliekant technines užduotis. Didelę „Agile“ galios dalį suteikia darbinis programinės įrangos prieaugis kiekvienos iteracijos pabaigoje. Jei jūsų pasakojimai iš tikrųjų yra tik techninės užduotys, kiekvienos kartojimo pabaigoje dažnai nenaudojate programinės įrangos ir prarandate lankstumą nustatydami prioritetus.
Pokalbio praleidimas. Istorijos yra sąmoningai neapibrėžtos prieš kartojant iteraciją. Jei praleisite priėmimo kriterijų pokalbį, rizikuosite judėti netinkama linkme, praleisti krašto atvejus ar nepastebėti klientų poreikių.
Ar turite patarimų, kuriuos galima pridėti prie aukščiau pateiktos informacijos, kaip rašyti geras vartotojų istorijas? Nedvejodami įrašykite juos į komentarus.
