3. diel - Špecifikácia MVP vo VS Code s Codexom Nové

V minulej lekcii, Spec-driven development a Codex , sme začali vytvárať špecifikáciu portálu EnergoSun v súbore SPEC.md, popísali súčasný firemný proces a pomocou Codexu odhalili nejasnosti v jeho popise.

V tomto tutoriále kurzu vývoja aplikácií s AI rozšírime vo Visual Studio Code súbor SPEC.md o návrh prvej použiteľnej verzie portálu interných požiadaviek EnergoSun. Určíme cieľový proces, užívateľské role, rozsah MVP a základné pravidlá požiadavky. Programový kód zatiaľ vytvárať nebudeme.

Minimum viable product

Pri vývoji aplikácie nemusíme hneď vytvárať všetky funkcie, ktoré by mohla v budúcnosti obsahovať. Najprv sa môžeme zamerať na MVP (Minimum viable product), teda najmenšiu verziu riešenia, ktorú je možné zmysluplne vyskúšať.

MVP si môžeme predstaviť ako malý dom, v ktorom sa už dá bývať, ale zatiaľ nemá garáž, bazén ani ďalšie plánované časti. U nášho portálu preto vyberieme len funkcie potrebné na overenie hlavného procesu. Ďalšie možnosti môžeme doplniť neskôr.

Cieľ portálu EnergoSun

Než navrhneme jednotlivé funkcie, upresníme, čo má aplikácia vo firme dosiahnuť. Nestačí iba určiť, že vytvoríme webovú aplikáciu. Potrebujeme tiež vedieť, aký problém má vyriešiť.

Pre EnergoSun chceme, aby interné požiadavky boli evidované na jednom mieste, zamestnanec videl ich priebeh a firma mala prehľad o otvorených prípadoch.

Návrh cieľového procesu

Súčasný proces používa niekoľko komunikačných kanálov a požiadavka sa môže pri odovzdávaní stratiť. V novej aplikácii preto chceme evidovať požiadavku aj jej odovzdávanie medzi riešiteľmi.

Žiadateľ často vie, kto požiadavku rieši. Napríklad administratívna požiadavka môže poslať rovno pracovníkovi, ktorý sa danej agende venuje. Ak si istý nie je, môže ponechať predvoleného vedúceho.

Otvoríme vo VS Code súbor SPEC.md. Doterajší obsah zachováme a na jeho koniec budeme postupne pridávať nové časti špecifikácie. Začneme cieľovým procesom:

## Cílový proces

1. Žadatel vytvoří požadavek pomocí formuláře a vybere řešitele. Pokud řešitele nezná, může ponechat předvoleného vedoucího.
2. Aplikace požadavek uloží, přidělí mu identifikátor a stav Nový.
3. Řešitel požadavek převezme, nebo jej předá jinému vhodnému řešiteli.
4. Řešitel zahájí práci změnou stavu na V řešení.
5. Řešitel zapíše výsledek a změní stav na Vyřešený.
6. Žadatel sleduje stav, řešitele a výsledek na jednom místě.

Ak žiadateľ nevie, komu požiadavku odovzdať, môže byť ako východiskový riešiteľ predvolený jeho vedúci. Žiadateľ ho však môže pred odoslaním zmeniť.

Cieľový proces môžeme zobraziť aj diagramom:

Diagram zachytáva iba tok požiadavky. Nerieši vzhľad aplikácie ani technológiu, pomocou ktorej ju neskôr vytvoríme.

Užívateľské role a prípady použitia

Aplikáciu nebude každý používať rovnako. Užívateľskú rolu si môžeme predstaviť podobne ako kľúče od kancelárií. Podľa úlohy má používateľ prístup k určitým informáciám a činnostiam.

Pre prehľad rolí a ich činností sa často používa Use Case diagram, ktorý je súčasťou modelovacieho jazyka UML (Unified Modeling Language). Prípad použitia, anglicky use case, popisuje činnosť užívateľa v systéme.

V diagrame sú rolky zobrazené ako postavy, činnosti ako ovály a obdĺžnik vymedzuje našu aplikáciu:

Pre MVP použijeme tri role. Do SPEC.md doplníme:

## Uživatelské role

- Žadatel vytvoří požadavek, vybere řešitele a sleduje vlastní požadavky.
- Řešitel pracuje s přidělenými požadavky a může je předat jinému řešiteli.
- Administrátor vidí všechny požadavky a může zasáhnout, pokud se některý požadavek zasekne.

Administrátor nie je prostredníkom každej požiadavky. Zasahuje iba v situáciách, ktoré bežný proces nevyriešia.

Pri vývoji budeme jednotlivé role skúšať pomocou niekoľkých testovacích užívateľov, napríklad Jany ako žiadateľky, Milana ako riešiteľa a Evy ako administrátorky. Skutočné prihlasovanie zatiaľ nie je súčasťou MVP, preto budeme medzi testovacími užívateľmi dočasne prepínať. Produkčná aplikácia by namiesto tohto prepínača používala skutočné prihlásenie a riadenie prístupových práv.

Rozsah MVP

Teraz určíme, ktoré funkcie bude prvá verzia portálu obsahovať a ktoré naopak ponecháme mimo jej rozsahu.

Pre prvú verziu vyberieme len funkcie potrebné na overenie hlavného procesu. Do SPEC.md pridáme nasledujúce časti:

## Rozsah MVP

- Žadatel vytvoří požadavek, vybere řešitele a sleduje jeho průběh.
- Řešitel požadavek zpracuje, předá jinému řešiteli nebo uzavře s výsledkem.
- Administrátor vidí všechny požadavky a může změnit řešitele.

## Mimo rozsah MVP

- skutečné přihlašování, správa účtů a produkční zabezpečení,
- přílohy, komentáře a automatické notifikace,
- mobilní aplikace a produkční nasazení.

Položky mimo rozsahu neznamenajú, že ich aplikácia nikdy nebude obsahovať. Iba sme rozhodli, že nie sú potrebné na prvé overenie hlavného procesu.

Základné pravidlá požiadavky

Na fungovanie MVP zatiaľ potrebujeme zachytiť len niekoľko základných pravidiel.

Na koniec SPEC.md doplníme:

## Základní pravidla

- Požadavek obsahuje identifikátor, název, popis, prioritu, žadatele, řešitele, stav a výsledek.
- Nový požadavek má stav Nový. Řešitel jej může předat nebo změnit stav na V řešení a později na Vyřešený.
- Vyřešený požadavek musí obsahovat výsledek a předání nebo změna stavu se ukládají do historie.

Tým sme stanovili hlavné pravidlá, ale nesnažíme sa vopred popísať každú možnú výnimku. Ak počas vývoja zistíme, že nejaké rozhodnutie chýba, vrátime sa k špecifikácii a doplníme ho.

Rovnako dôležité je, aby Codex za nás firemné pravidlá nevymýšľal. Môže upozorniť napríklad na chýbajúce rozhodnutie, ale výslednú voľbu musíme urobiť my.

Súbor SPEC.md uchováva dôležité požiadavky a rozhodnutia na jednom mieste. Pri zadávaní ďalších úloh môžeme Codex výslovne požiadať, aby si špecifikáciu najskôr prečítal. Vďaka tomu nemusíme celý kontext projektu opakovať v každom prompte.

Navrhli sme MVP portálu EnergoSun – cieľový proces, užívateľské role, rozsah prvej verzie aj základné pravidlá požiadaviek. Všetky tieto informácie sme doplnili do súboru SPEC.md Máme tak pripravené zadanie, podľa ktorého môžeme pokračovať v návrhu a vývoji aplikácie.

V budúcej lekcii, Wireframy a kontrola špecifikácie vo VS Code s Codexom , vo Visual Studio Code navrhneme wireframy portálu EnergoSun, doplníme akceptačné kritériá a pomocou Codexu skontrolujeme konzistenciu špecifikácie.