Vartotojo istorijų apibrėžimas ir judrus vystymasis
Pagrindinis šiuolaikinių plėtros procesų principas yra judrus vystymasis . Šioje kūrimo metodikoje pabrėžiama, kad reikia apibrėžti, ką sistema daro iš vartotojo perspektyvos, o ne techninę, naudodama mažus, įkandimo dydžio vartotojo pasakojimus. Vartotojui rūpi, ar produktas yra greitas, lengvas naudoti, ir išsprendžia jo problemą. Jiems nesvarbu, ar jie atitinka 3 pakopų architektūrą, ar turi „Mongo DB“, ar naudojasi „Rails“ ar „Asp.net“.
Vartotojo istorijos:
- Tai lengva suprasti ir dalyvauti gali bet kas
- Dirbkite kartojant; juos galima ir reikia dažnai keisti
- Suderinkite kūrėjus, vartotojus ir verslo specialistus su bendrais tikslais ir lūkesčiais
- Daug lengviau perskaityti nei 400 puslapių dokumentai
Storyboard That yra ideali platforma kuriant judrias vartotojų istorijas ir užmezgant pokalbį tokiu formatu, kuris yra daug mažiau apmokestinamas nei teksto siena.
Epinis
Vartotojo pasakojimų kontekste „epas“ yra tiesiog labai platus pasakojimas, kuris vėliau bus suskaidytas į daugelį konkrečių vartotojų istorijų. Pradėję nuo eposo, visi sulygina vieną, aukšto lygio viziją. Epas pasakojime įtvirtina projektą iš viršaus į apačią, o jei nėra prasmės statyti epos, palaikomasis darbas taip pat bus švaistomas pastangomis.
Šioje istorijoje labai aišku, kokia yra ilgalaikė vizija ir kaip turėtų atrodyti sėkmė. Gera epinė istorija turėtų apimti:
- Nustatymas arba kontekstas
- Aktoriai ar vartotojai
- Tikslai ir siekiai
- Veikla ir renginiai
Apibrėžti vartotojus
Ypač kuriant programinę įrangą, svarbu turėti gerą viziją, kokie bus vartotojai. Ne kiekvienas vartotojas tiksliai atitiks šią viziją ir gali būti kelios vartotojų kategorijos, tačiau šias atskiras vizijas reikia aiškiai apibrėžti. Galvojimas apie vartotojus pirmiausia apsaugo nuo perdėto inžinerijos ir per daug apsunkinimo, neleidžiant naujajam produktui turėti visko ir būti naudingu niekam.
Istorijos kūrimas
Įsteigus epas ir apibrėžus vartotojus, galima sukurti mažesnes, konkretesnes istorijas apie tam tikrą vartotojo patirtį. Žemiau pateiktos istorijos suskaido aukščiau aprašytą pasakojimą į du pasakojimus: ieškant užsakymo ir iš naujo užsakius produktą.
Šiuose pasakojimuose nėra techninės informacijos; vartotojams nerūpi, kaip pasiekiami rezultatai, jei tik jis atlieka norimas užduotis. Panašiai UX yra pavaizduotas bendrai, kad nebūtų slopinamos naujovės ar verčiamas kelias. Apskritai, istorijos turėtų būti:
- Mažas - iki 10 dienų darbas
- Vertingi - baigę jie turėtų pateikti ką nors tinkamo naudoti
- Įvertinamas - gali sudaryti daugiausiai pastangų reikalaujančio kamuolių įvertinimo lentelę
Ieškoma užsakymo
Pokalbis ir testavimo planavimas
Šios istorijos turėtų kviesti pokalbį ir klausimus, tokius kaip:
- Ar tai teisingos istorijos, kurios atitiktų mūsų epą?
- Kokias kitas istorijas reikėtų kurti?
- Ar šios istorijos atitinka tai, ką žinome apie savo vartotojus?
Visiškai protinga kurti daugybę istorijų; iš tikrųjų tai turėtų būti skatinama. Kai kurios iš šių istorijų niekada nebus naudojamos, tačiau svarbu pamatyti jų nustatytą kelią. Šis istorijų rinkinys atitiks papildomus reikalavimus ir turės įtakos testavimui.
Pasakojimai turėtų išprovokuoti ir informuoti diskusiją apie tai, kaip programinė įranga bus išbandyta ir kokias verslo taisykles reikia aiškiai apibrėžti. Pavyzdžiui:
- Kaip greitai reikia ieškoti?
- Ar galimas pakartotinių užsakymų terminas?
- Ką turėtų daryti sistema, jei tai yra antrasis užsakymas? Penkta?
- Kokius testus ir papildomus klausimus turėtumėte?
Papildoma literatūra
Storyboard That - tai galingas įrankis kuriant puikias vartotojų istorijas, tačiau jis nėra skirtas savarankiškai naudoti kaip projekto valdymo pagrindą. Čia yra keletas mūsų mėgstamiausių knygų šia tema.
Kainodara
/mėnuo
mokama kasmet
© 2020 - Clever Prototypes, LLC - Visos teisės saugomos.
Sukurta daugiau nei 14 milijonų reklaminių skelbimų lentų
