8.2 Prasību specifikācija - Lietotāju stāsti
Stundas uzdevums: 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. Izveido skaidru sarakstu ar to, ko Tavam jaunajam "Krustiņi un nullītes" spēlesm ir jāspēj izdarīt.
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) "Krustiņi un nullītes" projektam.
70 min plāns: Teorija un paraugs (~10 min) · 1. uzdevums (~15 min) - uzraksti trīs lietotāju stāstus · 2. uzdevums (~25 min) - pievieno akceptēšanas kritērijus · 3. uzdevums (~20 min) - sakārto backlog pēc prioritātes. Papildu uzdevumu sāc tikai tad, ja pārējie trīs ir gatavi.
Pirms sāc: izveido savā projekta mapē failu PRASIBAS.md. Noderēs 8.1 stundā formulētā problēma - stāstiem jārisina tieši tā.
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 KrustiniNullites_Arhitektura
- Izveido prasību dokumentu un atver to kodu redaktorā:
ni PRASIBAS.md
code PRASIBAS.md
Praktiskie uzdevumi
1. uzdevums -
Uzraksti trīs lietotāju stāstus
Beigās katra funkcija būs aprakstīta no lietotāja skatpunkta.
- Izveido failu
PRASIBAS.md. - Uzraksti pirmo stāstu pēc formulas:
Kā [lietotājs], es vēlos [darbība], lai [ieguvums]. - Uzraksti otro stāstu no spēlētāja skatpunkta.
- Uzraksti trešo stāstu no skolotāja vai satura autora skatpunkta.
- Pārbaudi, vai katrā stāstā ir visas trīs daļas.
- Izsvītro no stāstiem visus tehniskos vārdus, piemēram
masīvsvaifunkcija.
Gatavs, kad: failā ir trīs stāsti, katrs ar visām trim daļām un bez tehniskiem terminiem.
2. uzdevums -
Pievieno akceptēšanas kritērijus
Beigās tu varēsi pārbaudīt, vai funkcija tiešām ir gatava.
- Pievieno zem katra stāsta sadaļu
## Akceptēšanas kritēriji. - Uzraksti katram stāstam vismaz divus kritērijus ar rūtiņām
- [ ]. - Formulē katru kritēriju tā, lai uz to var atbildēt tikai jā vai nē.
- Pārbaudi, vai kritērijs neprasa viedokli, piemēram
izskatās labi. - Pārraksti tos kritērijus, kurus nevar pārbaudīt.
- Iedod vienu stāstu klasesbiedram un palūdz pateikt, kā viņš to pārbaudītu.
Gatavs, kad: uz katru kritēriju var atbildēt ar jā vai nē, un klasesbiedrs zināja, kā tos pārbaudīt.
3. uzdevums -
Sakārto backlog pēc prioritātes
Beigās tu zināsi, ar kuru funkciju sākt.
- Pievieno katram stāstam atzīmi
M(obligāts) vaiV(vēlams). - Novērtē katram stāstam darba apjomu ar skaitli no 1 līdz 5.
- Pārkārto stāstus tā, lai obligātie ar mazāku apjomu būtu augšā.
- Pieraksti, kurš stāsts būs pirmais izstrādē.
- Pamato šo izvēli vienā teikumā.
- Pārbaudi, vai pirmais stāsts tiešām risina 8.1 stundā formulēto problēmu.
Gatavs, kad: saraksta augšā ir obligātais stāsts ar mazāko apjomu, un tas sasaucas ar tavu problēmas formulējumu.
Papildu uzdevums - Uzraksti pretstāstu
Ja pamatdarbs ir gatavs, pieraksti, ko sistēma apzināti NEDARĪS.
- Pievieno sadaļu
## Ārpus apjoma. - Uzraksti trīs lietas, ko šī versija nedarīs.
- Pamato katru ar vienu teikumu.
- Pārbaudi, vai neviena no tām nav obligātais stāsts.
- Parādi sarakstu klasesbiedram un pajautā, vai kaut kas šķiet nepareizi izslēgts.
Gatavs, kad: sadaļā ir trīs skaidri izslēgtas lietas ar pamatojumu.
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. |
Koda piemērs (pārbaudāmi akceptēšanas kritēriji - grūtākā daļa)
## User Story
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ĀRBAUDĀMI (tā vajag)
- [ ] Nospiežot "i", ekrānā parādās saraksts ar visiem priekšmetiem
- [ ] Tukšs inventārs rāda tekstu "Inventārs ir tukšs", nevis kļūdu
- [ ] Katram priekšmetam redzams nosaukums un skaits
- [ ] No inventāra var atgriezties spēlē ar "q"
Uz katru var atbildēt tikai JĀ vai NĒ.
## Akceptēšanas kritēriji - NEPĀRBAUDĀMI (tā nevajag)
- [ ] Inventārs izskatās labi <-- kā to izmērīt?
- [ ] Inventārs strādā ātri <-- cik ātri? 1 s? 10 ms?
- [ ] Lietotājam ir ērti <-- kuram lietotājam?
## Ārpus apjoma
- Priekšmetu pārdošana (nav šajā versijā)