Lietotāju stāstu un veiklas attīstības definēšana
Mūsdienu attīstības procesu pamatprincips ir veikla attīstība . Šī izstrādes metodika uzsver mazu, koduma izmēru lietotāju stāstu izmantošanu, lai noteiktu, ko sistēma dara no lietotāja, nevis tehniskā viedokļa. Lietotājam rūp, vai produkts ir ātrs, viegli lietojams un atrisina viņa problēmu. Viņiem ir vienalga, vai tam ir 3 līmeņu arhitektūra, vai tam ir Mongo DB, vai tas izmanto Rails vai Asp.net.
Lietotāju stāsti:
- Ir viegli saprotami, un ikviens var piedalīties
- Strādājiet iteratīvi; tos var un vajadzētu bieži mainīt vai grozīt
- Saskaņojiet izstrādātājus, lietotājus un biznesa speciālistus kopīgiem mērķiem un cerībām
- Tie ir daudz vieglāk lasāmi nekā 400 lappušu prasības dokumenti
Storyboard That nodrošina ideālu platformu, lai radītu veiklus lietotāju stāstus un izraisītu sarunas tādā formātā, kas ir daudz mazāk apgrūtinošs nekā teksta siena.
Episks
Lietotāju stāstu kontekstā “eposs” ir vienkārši ļoti plašs stāsts, kas vēlāk tiks sadalīts daudzos īpašos lietotāju stāstos. Sākot ar eposu, ikviens tiek saskaņots ar vienu augsta līmeņa redzējumu. Episkais stāsts nostiprina projektu no augšas uz leju, un, ja nav jēgas veidot eposu, arī palīgdarbs būs pūļu izšķiešana.
Šajā stāstā ir ļoti skaidrs, kāds ir ilgtermiņa redzējums un kādiem vajadzētu izskatīties panākumiem. Labam episkam stāstam jāietver:
- Iestatījums vai konteksts
- Aktieri vai lietotāji
- Mērķi un uzdevumi
- Aktivitātes un pasākumi
Lietotāju definēšana
Īpaši, izstrādājot programmatūru, ir svarīgi, lai būtu labs redzējums par to, kādi būs lietotāji. Ne katrs lietotājs precīzi atbilst šim redzējumam, un var būt vairākas lietotāju kategorijas, taču šīm diskrētajām vīzijām ir nepieciešama artikulācija. Domājot par lietotājiem, vispirms jāaizsargā pret pārmērīgu inženieriju un sarežģījumiem, neļaujot jaunam produktam piedāvāt kaut ko ikvienam un būt noderīgam nevienam.
Stāsta veidošana
Kad eposs ir izveidots un lietotāji ir definēti, par konkrētu lietotāju pieredzi var veidot mazākus, konkrētākus stāstus. Tālāk minētie stāsti sadala iepriekš izklāstīto divos stāstījumos: pasūtījuma meklēšana un produkta atkārtota pasūtīšana.
Šie stāstījumi nesatur tehnisku informāciju; lietotājiem ir vienalga, kā tiek sasniegti rezultāti, ja vien tas veic vēlamos uzdevumus. Līdzīgi UX ir attēlots vispārīgi, lai izvairītos no inovāciju apspiešanas vai ceļa piespiešanas. Kopumā stāstiem jābūt šādiem:
- Mazs - darbs līdz 10 dienām
- Vērtīgi - kad tie ir pabeigti, tiem vajadzētu piegādāt kaut ko lietojamu
- Aprēķināms - spēj izveidot bumbas novērtējumu par to, cik daudz pūļu ir nepieciešams
Pasūtījuma meklēšana
Pārkārtošanas veikšana
Saruna un plānošana testēšanai
Šiem stāstiem vajadzētu rosināt sarunas un jautājumus, piemēram:
- Vai šie ir īstie stāsti, kas atbilst mūsu eposam?
- Kādi vēl stāsti būtu jāveido?
- Vai šie stāsti atbilst tam, ko mēs zinām par mūsu lietotājiem?
Ir pilnīgi saprātīgi izveidot daudzus stāstus; patiesībā tas būtu jāveicina. Daži no šiem stāstiem nekad netiks izmantoti, taču ir svarīgi redzēt ceļu, ko tie nosaka. Šis stāstu krājums izslēgs papildu prasības un ietekmes pārbaudi.
Stāstiem vajadzētu izraisīt un informēt diskusiju par to, kā programmatūra tiks pārbaudīta un kādi uzņēmējdarbības noteikumi ir skaidri jānosaka. Piemēram:
- Cik ātrai jābūt uzmeklēšanai?
- Vai atkārtotiem pasūtījumiem ir noteikts laika ierobežojums?
- Kas jādara sistēmai, ja tas ir otrais atkārtotais pasūtījums? Piektkārt?
- Kādi testi un papildu jautājumi jums būtu?
© 2024 - Clever Prototypes, LLC - Visas tiesības aizsargātas.
StoryboardThat ir uzņēmuma Clever Prototypes , LLC preču zīme, kas reģistrēta ASV Patentu un preču zīmju birojā.