Lekce 3 - Specifikace MVP ve VS Code s Codexem Nové
V minulé lekci, Spec-driven development a Codex, jsme začali vytvářet specifikaci portálu
EnergoSun v souboru SPEC.md, popsali současný firemní proces a
pomocí Codexu odhalili nejasnosti v jeho popisu.
V tomto tutoriálu kurzu vývoje aplikací s
AI rozšíříme ve Visual Studio Code soubor
SPEC.md o návrh první použitelné verze portálu interních
požadavků EnergoSun. Určíme cílový proces, uživatelské role, rozsah
MVP a základní pravidla požadavku. Programový kód zatím
vytvářet nebudeme.
Minimum viable product
Při vývoji aplikace nemusíme hned vytvářet všechny funkce, které by mohla v budoucnu obsahovat. Nejprve se můžeme zaměřit na MVP (Minimum viable product), tedy nejmenší verzi řešení, kterou je možné smysluplně vyzkoušet.
MVP si můžeme představit jako malý dům, ve kterém už lze bydlet, ale zatím nemá garáž, bazén ani další plánované části. U našeho portálu proto vybereme jen funkce potřebné k ověření hlavního procesu. Další možnosti můžeme doplnit později.
Cíl portálu EnergoSun
Než navrhneme jednotlivé funkce, upřesníme, čeho má aplikace ve firmě dosáhnout. Nestačí pouze určit, že vytvoříme webovou aplikaci. Potřebujeme také vědět, jaký problém má vyřešit.
Pro EnergoSun chceme, aby interní požadavky byly evidované na jednom místě, zaměstnanec viděl jejich průběh a firma měla přehled o otevřených případech.
Návrh cílového procesu
Současný proces používá několik komunikačních kanálů a požadavek se může při předávání ztratit. V nové aplikaci proto chceme evidovat požadavek i jeho předávání mezi řešiteli.
Žadatel často ví, kdo požadavek řeší. Například administrativní požadavek může poslat rovnou pracovníkovi, který se dané agendě věnuje. Pokud si jistý není, může ponechat předvoleného vedoucího.
Otevřeme ve VS Code soubor SPEC.md. Dosavadní obsah zachováme
a na jeho konec budeme postupně přidávat nové části specifikace. Začneme
cílovým procesem:
## 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ě.
Pokud žadatel neví, komu požadavek předat, může být jako výchozí řešitel předvolený jeho vedoucí. Žadatel jej ale může před odesláním změnit.
Cílový proces můžeme zobrazit také diagramem:
Diagram zachycuje pouze tok požadavku. Neřeší vzhled aplikace ani technologii, pomocí které ji později vytvoříme.
Uživatelské role a případy užití
Aplikaci nebude každý používat stejně. Uživatelskou roli si můžeme představit podobně jako klíče od kanceláří. Podle role má uživatel přístup k určitým informacím a činnostem.
Pro přehled rolí a jejich činností se často používá Use Case diagram, který je součástí modelovacího jazyka UML (Unified Modeling Language). Případ užití, anglicky use case, popisuje činnost uživatele v systému.
V diagramu jsou role zobrazené jako postavy, činnosti jako ovály a obdélník vymezuje naši aplikaci:
Pro MVP použijeme tři 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 není prostředníkem každého požadavku. Zasahuje pouze v situacích, které běžný proces nevyřeší.
Při vývoji budeme jednotlivé role zkoušet pomocí několika testovacích uživatelů, například Jany jako žadatelky, Milana jako řešitele a Evy jako administrátorky. Skutečné přihlašování zatím není součástí MVP, proto budeme mezi testovacími uživateli dočasně přepínat. Produkční aplikace by místo tohoto přepínače používala skutečné přihlášení a řízení přístupových práv.
Rozsah MVP
Nyní určíme, které funkce bude první verze portálu obsahovat a které naopak ponecháme mimo její rozsah.
Pro první verzi vybereme jen funkce potřebné k ověření hlavního
procesu. Do SPEC.md přidáme následující části:
## 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 rozsah neznamenají, že je aplikace nikdy nebude obsahovat. Pouze jsme rozhodli, že nejsou nutné pro první ověření hlavního procesu.
Základní pravidla požadavku
Pro fungování MVP zatím potřebujeme zachytit jen několik základních pravidel.
Na konec 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 jsme stanovili hlavní pravidla, ale nesnažíme se předem popsat každou možnou výjimku. Pokud během vývoje zjistíme, že nějaké rozhodnutí chybí, vrátíme se ke specifikaci a doplníme jej.
Stejně důležité je, aby Codex za nás firemní pravidla nevymýšlel. Může upozornit například na chybějící rozhodnutí, ale výslednou volbu musíme udělat my.
Soubor SPEC.md uchovává důležité požadavky a rozhodnutí
na jednom místě. Při zadávání dalších úkolů můžeme Codex výslovně
požádat, aby si specifikaci nejprve přečetl. Díky tomu nemusíme celý
kontext projektu opakovat v každém promptu.
Navrhli jsme MVP portálu EnergoSun – cílový proces,
uživatelské role, rozsah první verze i základní pravidla požadavků.
Všechny tyto informace jsme doplnili do souboru SPEC.md. Máme tak
připravené zadání, podle kterého můžeme pokračovat v návrhu a vývoji
aplikace.
V příští lekci, Wireframy a kontrola specifikace ve VS Code s Codexem, ve Visual Studio Code navrhneme wireframy portálu EnergoSun, doplníme akceptační kritéria a pomocí Codexu zkontrolujeme konzistenci specifikace.
Měl jsi s čímkoli problém? Vzorové řešení je ke stažení každých pár lekcí. Zatím pokračuj dál, a pak si svůj projekt porovnej se vzorem a snadno oprav.
