Lietotāju Stāsti un Agile Attīstība

Autors Ārons Šermens

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:


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.


Izveidojiet Agile Lietotāja Stāstu*

Customer Care Generic Epic

Izmantojiet šo veidni

(Tas sāks 2 nedēļu bezmaksas izmēģinājuma versiju - kredītkartes nav nepieciešamas)


Š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:



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.


Izveidojiet Agile Lietotāja Stāstu*

Acme Corp. Users

Izmantojiet šo veidni

(Tas sāks 2 nedēļu bezmaksas izmēģinājuma versiju - kredītkartes nav nepieciešamas)


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:

Pasūtījuma meklēšana


Izveidojiet Agile Lietotāja Stāstu*

Acme Corp. - Looking up an Order

Izmantojiet šo veidni

(Tas sāks 2 nedēļu bezmaksas izmēģinājuma versiju - kredītkartes nav nepieciešamas)


Pārkārtošanas veikšana


Izveidojiet Agile Lietotāja Stāstu*

Acme Corp. Replacement Order

Izmantojiet šo veidni

(Tas sāks 2 nedēļu bezmaksas izmēģinājuma versiju - kredītkartes nav nepieciešamas)


Saruna un plānošana testēšanai

Šiem stāstiem vajadzētu rosināt sarunas un jautājumus, piemēram:


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:




Izveidojiet Agile Lietotāja Stāstu*