Kaip rašyti naudotojų istorijas (su pavyzdžiais ir priėmimo kriterijais)

Naudotojo istorija yra trumpas funkcijos aprašymas naudotojo akimis: „Kaip [naudotojo tipas], noriu [tikslo], kad [priežastis].“ Po ja rašai priėmimo kriterijus – kelias konkrečias sąlygas, kurios turi būti įvykdytos, kad istorija būtų laikoma atlikta. Kiekviena istorija turi būti pakankamai maža, kad būtų galima ją sukurti ir ištestuoti vienu kartu, o kriterijai parašyti taip, kad juos gali patikrinti bet kas.

Naudotojų istorijas populiarino agile programinės įrangos komandos, bet jos lygiai taip pat naudingos, kai kuri vienas su DI programėlių kūrimo įrankiu. Gera istorija – gera užklausa.

Formatas

Naudotojo istorija turi tris dalis:

Kaip [kas], noriu [ko] kad [kodėl].

• Kas yra konkretus naudotojų tipas: pirmą kartą apsilankantis lankytojas, mokantis narys, klinikos registratorė, administratorius. Ne „naudotojas“.
• Ko yra veiksmas, kurio jie nori, jų žodžiais. Ne tai, kaip veikia ekranas.
• Kodėl yra rezultatas, kuris jiems rūpi. Tai dalis, kurią žmonės praleidžia ir dėl kurios galiausiai kuria ne tai, ko reikia.

Pavyzdys:

Kaip sporto klubo narys, noriu atšaukti pamokos rezervaciją iš telefono, kad kas nors iš laukiančiųjų eilėje galėtų užimti mano vietą ir nebūtų skaičiuojamas nerodymo mokestis.

„Kodėl“ pasako du dalykus, kurių „ko“ nepasakė: tai turi veikti telefone, ir čia dalyvauja eilės ir mokesčių taisyklės.

Priėmimo kriterijai

Istorija pasako, ko norima. Priėmimo kriterijai pasako, kada ji baigta. Jie turi būti pakankamai konkretūs, kad du žmonės sutiktų, ar kiekvienas praeina.

Dažnas būdas juos rašyti – Duota / Kai / Tada:

• Duota pradinė situacija
• Kai naudotojas ką nors daro
• Tada tai yra rezultatas

Sporto klubo rezervacijos istorijai:

1. Duota, kad turiu rezervaciją daugiau nei už 12 valandų, kai paspaudžiu Atšaukti ir patvirtinu, tada rezervacija pašalinama ir matau „Rezervacija atšaukta“.
2. Duota, kad atšaukiu rezervaciją ir pamokai yra laukiančiųjų eilė, kai atšaukimas išsaugomas, tada pirmas eilėje laukiantis asmuo gauna vietą ir el. laišką.
3. Duota rezervacija likus mažiau nei 12 valandų, kai paspaudžiu Atšaukti, tada prieš patvirtindamas matau, kad taikomas vėlyvo atšaukimo mokestis.
4. Duota, kad esu telefono pločio ekrane, tada Atšaukti mygtukas matomas be slinkimo į šalis.

Paprastas kontrolinis sąrašas taip pat tinka, jei kiekvienas punktas patikrinamas. „Atšaukti lengva“ nepatikrinama. „Atšaukti užtrunka ne daugiau kaip du bakstelėjimus nuo rezervacijų sąrašo“ patikrinama.

Žingsnis po žingsnio: kaip parašyti gerą istoriją

1 žingsnis: pradėk nuo tikro naudotojo ir tikros problemos

Pasirink vieną naudotojų tipą ir dalyką, su kuriuo jis šiandien kovoja. Jei kalbėjai su klientais, naudok jų žodžius. „Visada pamirštu atšaukti ir mane nuskaičiuoja“ yra geresnis pradžios taškas nei „pridėti atšaukimo funkciją“.

2 žingsnis: parašyk vienos eilutės istoriją

Užpildyk šabloną. Jei negali parašyti įtikinamo „kad“, paklausk, ar funkcija apskritai reikalinga.

3 žingsnis: pridėk tris–šešis priėmimo kriterijus

Pirmiausia apimk pagrindinį sėkmingą atvejį, paskui svarbius variantus: kitą vaidmenį, tuščią būseną, ribą, klaidą. Jei rašai daugiau nei šešis, istorija tikriausiai per didelė.

4 žingsnis: pažymėk, kas nepriklauso apimčiai

Viena eilutė sutaupo daug tarpusavio derinimų: „Nepriklauso apimčiai: mokamų pamokų grąžinimai; administratoriai, atšaukiantys narių vardu.“ Tai sustabdo istorijos augimą kuriant.

5 žingsnis: patikrink pagal INVEST

INVEST yra dažnas gerų istorijų kontrolinis sąrašas. Istorija turi būti:

Neprivalai vertinti kiekvienos istorijos. Tai naudingiausia, kai istorija atrodo neteisinga ir nori žinoti kodėl.

Geri ir blogi pavyzdžiai

Kaip padalyti per didelę istoriją

Didelės istorijos yra vieta, kur projektai įstringa. Dažni būdai dalyti:

• Pagal naudotojo vaidmenį. Nariai atšaukia savo rezervacijas; darbuotojai atšaukia bet kieno.
• Pagal srauto žingsnį. Naršyti pamokas; rezervuoti pamoką; gauti priminimą.
• Pirma paprastas atvejis. Atšaukti nemokamą pamoką dabar; mokesčius ir grąžinimus tvarkyti vėlesnėje istorijoje.
• Pagal duomenų variaciją. Pirma palaikyti vieną vietą, vėliau kelias.
• Pagrindinis kelias, paskui klaidos. Pirma padaryk, kad veiktų, paskui pridėk apdorojimą pilnoms pamokoms, pasibaigusioms abonementams ir panašiai.

Kiekviena dalis vis tiek turi būti tai, ką naudotojas galėtų panaudoti ir pastebėtų.

Naudotojų istorijos kaip užklausos

Naudotojo istorija su priėmimo kriterijais yra labai artima geram raginimui DI programėlių kūrimo įrankiui. Ji duoda DI kas, ko, kodėl ir baigtumo apibrėžimą. Siųsk po vieną istoriją vienoje žinutėje:

Kaip sporto klubo narys, noriu atšaukti pamokos rezervaciją iš telefono, kad kas nors iš laukiančiųjų eilėje galėtų užimti mano vietą. Priėmimo kriterijai:

1. Atšaukimas yra kiekvienoje rezervacijoje skiltyje Mano rezervacijos, su patvirtinimo žingsniu.
2. Atšaukus daugiau nei 12 valandų prieš pamoką, rezervacija tiesiog pašalinama.
3. Likus mažiau nei 12 valandų, prieš patvirtinant rodyk „Taikomas vėlyvo atšaukimo mokestis – 5 USD“ ir įrašyk mokestį rezervacijoje.
4. Jei pamokai yra laukiančiųjų eilė, pirmas asmuo gauna vietą ir el. laišką.
5. Veikia telefono pločio ekrane. Nepriklauso apimčiai: grąžinimai, darbuotojai, atšaukiantys narių vardu. Sukurk tai, tada patikrink kiekvieną kriterijų peržiūroje ir pasakyk, kurie praeina.

Gali taip pat paprašyti DI parengti istorijas iš grubios idėjos, o tada jas pats redaguoti:

Štai mano programėlės idėja: [du ar trys sakiniai]. Parašyk pirmos versijos naudotojų istorijas, sugrupuotas pagal naudotojo tipą, kiekviena su 3–5 Duota/Kai/Tada priėmimo kriterijais. Pažymėk, kurios būtinos paleidimui, o kurios gali palaukti.

Visada perskaityk ir redaguok rezultatą. DI nežino tavo naudotojų; tu žinai.

Priėmimo kriterijai taip pat veikia kaip tavo testų planas. Kai istorija sukurta, pats peržiūrėk kiekvieną kriterijų. Mūsų vadovas apie programėlės testavimą prieš paleidimą remiasi šiuo principu.

Kur naudotojų istorijos telpa tarp kitų dokumentų

• Produkto reikalavimų dokumentas aprašo visą produktą: problemą, naudotojus, apimtį. Naudotojų istorijos yra jo detalios dalys. Žr. kaip parašyti PRD su DI.
• Klaidos ataskaita aprašo kažką, kas sugedo, palyginti su jau sukurta istorija. Žr. kaip parašyti gerą klaidos ataskaitą.
• MVP yra mažiausias istorijų rinkinys, kuris duoda pagrindinę vertę. Žr. kas yra MVP.

Dažniausios klaidos

• „Kaip naudotojas…“ Per miglota. Įvardyk konkretų naudotojų tipą.
• „Kad“ praleidimas. Be priežasties negali priimti pagrįstų kompromisų.
• Sprendimo rašymas vietoj poreikio. „Noriu išskleidžiamojo sąrašo“ įtvirtina dizainą, kol niekas dar negalvojo apie jį.
• Kriterijai, kurių negalima patikrinti. „Lengva“, „greita“ ir „intuityvu“ yra norai, o ne kriterijai.
• Istorijos, kurios iš tikrųjų yra epinės. „Tvarkyti mano paskyrą“ yra dešimt istorijų.
• Visų istorijų rašymas iš anksto. Parašyk kelias artimiausias detaliai; likusias palik kaip vienos eilutės aprašymus, kol prie jų priartėsi.

Istorijos Mythex

Mythex Plan režimas yra gera vieta paversti idėją istorijomis: agentas aptaria metodą prieš bet ką redaguodamas. Kai istorija paruošta, perjunk į Build ir įklijuok ją, po vieną istoriją vienoje žinutėje. Po kiekvienos /test gali perklikinėti peržiūrą ir patikrinti srautą, o bet kurį atsakymą gali grąžinti su Revert to this point, jei nukrypo ne ta linkme. Žr. veiksmingas užklausas dokumentacijoje ir mūsų vadovą kaip rašyti užklausas DI programėlių kūrimo įrankiams.

Naudotojų istorijos kontrolinis sąrašas

• Įvardija konkretų naudotojų tipą
• Aprašo poreikį, o ne dizainą
• Turi tikrą „kad“ priežastį
• Turi tris–šešis patikrinamus priėmimo kriterijus
• Apima bent vieną kraštutinį atvejį ar klaidą
• Nurodo, kas nepriklauso apimčiai
• Pakankamai maža, kad būtų sukurta ir ištestuota vienu kartu
• Kriterijai patikrinti po sukūrimo, vienas po kito

Klausimai