8. tēma: Projektēšana. 2. stunda: Lietotāju stāsti.

Tavs šīs stundas izaicinājums: Iemācīties definēt programmatūras funkcijas no lietotāja skatpunkta. Programmētāji bieži mēdz aizrauties ar tehnisko pusi, aizmirstot, kam kods ir domāts. Šodien Tu izveidosi skaidru sarakstu ar to, ko Tavam jaunajam CYOA dzinējam ir jāspēj izdarīt.

SR 2.4.4. (Definē programmatūras prasības no lietotāja skatpunkta)

Stundas mērķi:

Formulēt prasības lietotāju stāstu (User Stories) formātā.
Definēt akceptēšanas kritērijus (Acceptance Criteria), lai pārbaudītu funkcijas izpildi.
Izveidot prioritizētu funkciju sarakstu (Backlog) CYOA projektam.

Teorija: User Stories — Kāpēc un Kā?

Kas ir User Story? Tas ir īss, vienkāršs funkcijas apraksts, kas uzrakstīts no tās personas viedokļa, kura šo funkciju izmantos.
Zelta formula: "Kā [lietotājs], es vēlos [darbība], lai [ieguvums]."
- Piemērs: "Kā spēlētājs, es vēlos redzēt savu inventāru, lai zinātu, kādus priekšmetus esmu savācis."
Akceptēšanas kritēriji: Pārbaudes saraksts, kas definē, kad uzdevums ir pabeigts.
- Piemērs: 1) Saraksts ir redzams, nospiežot pogu 'I'. 2) Tukšs saraksts izvada ziņojumu "Soma ir tukša".
Prioritāte: Ne visas funkcijas ir vienlīdz svarīgas. Mēs sākam ar tām, bez kurām spēle nav spēlējama (MVP — Minimum Viable Product).

Vides sagatavošana (Windows)

Šodienas prasību specifikāciju mēs rakstīsim Markdown (.md) failā, kas ir standartizēts veids, kā programmētāji veido dokumentāciju GitHub vidē.

Atver PowerShell.
Ieej sava projekta mapē:


cd CYOA_Arhitektura

Izveido prasību dokumentu un atver to kodu redaktorā:


ni PRASIBAS.md
code PRASIBAS.md

Praktiskie uzdevumi

1. Līmenis (Vienkāršs): "Pirmie stāsti"

Uzraksti 3 lietotāju stāstus savai spēlei, izmantojot zelta formulu.

Atver PRASIBAS.md.
Izveido vienu stāstu no Spēlētāja pozīcijas (piem., par pārvietošanos).
Izveido vienu stāstu no Rakstnieka/Satura veidotāja pozīcijas (piem., par stāsta ielādi no faila).
Izveido vienu stāstu no Izstrādātāja pozīcijas (piem., par kļūdu ziņojumiem).

Sagaidāmais rezultāts: Trīs skaidri formulēti teikumi Markdown saraksta formā.

2. Līmenis (Viduvējs): "Kā mēs zināsim, ka strādā?"

Papildini savus stāstus ar pārbaudes sarakstu.

Izvēlies vienu no saviem uzrakstītajiem stāstiem.
Pievieno tam sadaļu "Akceptēšanas kritēriji".
Definē vismaz 3 punktus, kuriem jābūt izpildītiem, lai Tu varētu teikt, ka šī funkcija ir pabeigta.

Sagaidāmais rezultāts: Viens detalizēts lietotāja stāsts ar tehnisku pārbaudes sarakstu (piem., datu tipu pārbaudes, vizuālie elementi).

3. Līmenis (Padziļināts): "Projekta Backlog"

Izveido pilnu funkciju sarakstu (Backlog) savam CYOA 2.0 projektam, sadalot tās prioritātēs.

Failā PRASIBAS.md izveido tabulu vai sarakstu ar divām kategorijām:
- Kritiski (Must-have): Funkcijas, bez kurām spēle nedarbosies (piem., CSV nolasīšana).
- Vēlams (Nice-to-have): Funkcijas, kas uzlabo pieredzi (piem., krāsains teksts konsolē, skaņas efekti).
Katram punktam pievieno īsu tehnisko piezīmi (kuru Python bibliotēku vai metodi plāno izmantot).

Sagaidāmais rezultāts: Strukturēts plāns, kas skaidri definē darba apjomu un secību nākamajām 4 nedēļām.

Snieguma līmeņa apraksts (SLA)

Kritēriji	4-6 (Turpina apgūt)	7-8 (Apguvis)	9-10 (Padziļināti)
Lietotāju stāsti	Stāsti ir nepilnīgi vai neievēro formulu.	Stāsti ir skaidri un no dažādām lomām.	Stāsti ir profesionāli, iekļaujot biznesa vērtību (ieguvumu).
Kritēriji	Nav definēti pārbaudes punkti.	Definēti vienkārši punkti funkcijas darbībai.	Definēti tehniski un robežgadījumu (edge-case) punkti.
Prioritizācija	Visi uzdevumi ir vienā sarakstā bez secības.	Uzdevumi sadalīti pēc svarīguma.	Pamatots "Must-have" un "Nice-to-have" sadalījums.