Praxe AAF s AI 4: Hledání případů užití s AI

Metodika Agilní analýzy AAF stojí na principu VBM: během vývoje se kontinuálně sleduje, zda produkt stále nese hodnotu, za kterou zákazník zaplatí. Jinak řečeno — systém se při vývoji nesmí špatnými postupy „rozsypat“ a tím tuto hodnotu ztratit.

První předpoklad pro splnění tohoto principu máme už z předešlých kapitol: držíme v ruce odsouhlasený scénář Zlatého chodu procesu (Use Case Epic). Je to pohled na systém a jeho okolí z velké výšky (High Level Analysis). Pro samotnou realizaci ale musíme jít z této úrovně výrazně níž a řešit tzv. Low Level Analysis (LLA), která musí být v návaznosti na HLA proces — a musí být realizována agilně.

Prvky, které vedou z HLA do LLA (a nakonec až do kódu), jsou Use Case 1. druhu. Je tu přímá analogie s interface objektu v OOP: tyto prvky zvenku (z procesu) nabízejí možnost použití podobně jako interface objektu nabízí ven volání metody, uvnitř UC je pak popsána implementace vnitřním scénářem, podobně jako algoritmus — kód, který se má v objektu odehrát v implementaci metody.

Cinknutí systému

Je to základní pojem, který umožňuje nalézat UC 1. druhu alias „interface“ přehledně a systematicky.

Děj běží v procesu — v okolí — a v určitém bodě potřebuje použít náš systém podobně, jako když ve výtahu stisknete tlačítko a výtah „cinkne“. Tomu bodu říkáme Cinknutí systému, resp. bod potřebnosti použití systému.

Jedná se o binární věc: v daném kroku se systém buď použije, nebo nepoužije. Žádná škála, žádné „napůl“. Pro AI ideální situace.

Cinknutí systému je okamžik, kdy se předá řízení z vnějšího děje dovnitř systému — stejně jako v OOP přes VMT.
Use Case 1. druhu tuto hranici určuje přesně. Odděluje takto HLA a LLA, ale současně je propojuje — záleží na úhlu pohledu — zvenku z HLA se díváme na „tlačítko s nápisem užitku“ a zevnitř na „dráty realizace užitku“. Jako objekt v OOP.

A protože je celé pravidlo ostré (cinknutí je / není), je srozumitelné i pro AI. Nemusí nic odhadovat, jen u každého kroku položí jednu otázku:
„Spustí se tady náš systém?“ alias „Budeme toto programovat?“

Může nastat situace, kdy odpověď zatím není jednoznačná — zda už jde o „naše řešení“ (cinklo to), nebo ještě o „děj v externím systému“ (před cinknutím). Například věta ze scénáře:

„Uživatel přistupuje k zařízení a odesílá zprávu do našeho systému.“

Zde není ještě jasné, kde přesně bude bod cinknutí v ději: buď je zařízení „naše“ (= programujeme to), nebo je externí (neprogramujeme to, až příjem zprávy na vstupu). Naučili jsme AI, aby se v takovéto situaci doptal a nechal na human analytikovi a PO otázku, zda zařízení je nebo není součástí řešení. Teprve po relevantní odpovědi je bod cinknutí systému jasný.

Zvláštním případem cinknutí jsou v HLA procesy spouštěné timeoutem. Zavádějí implicitně UC spouštěné časovou událostí.

Jak si s tímto poradí prakticky AI?

Naučili jsme AI Analytika celou předešlou teorii a samozřejmě otestovali ho skrz naskrz (pozn. to „my“ znamená já a můj AI Asistent, tj. AI Claude Code jako moje pravá ruka vývoje AI Analytika).

Ukázka Mobile Ticket Payment

Vzali jsme hotový, ověřený Use Case Epic platby z minulých kapitol a nechali AI projít chod krok po kroku — u každého takového kroku si AI Analytik položil otázku Budeme to programovat?

Pro zájemce tady je raw vstup a výstup testování AI Analytika v PDF

Výsledkem jeho práce byly čtyři prvky Use Case 1. druhu (plus nějaké „drobné“ připomínky):

• UC Založení čekající platby (vygenerování platebního kódu)
• UC Provedení platby (spárování dle kódu a snížení kreditu)
• UC Ověření platby
• UC Zrušení platby (storno čekající platby dle kódu)

Žádné dohadování, žádné skryté Use Case navíc — výčet, na kterém se shodnou dva analytici, protože ho neurčuje cit, ale kotva v textu. Možná zvolí trochu jiné názvy, ale ostrá logika UC je stejná.

Důkaz obecnosti — jiný příklad, HLA Kurýr

Aby bylo jasné, že to není naučené zrovna na MTP projektu: stejnou metodu jsme pustili na úplně jinou „čerstvou“ doménu — vytvořili jsme modelový příklad pro testování Chod procesu u kurýra.

Návrh scénáře Kurýra pro test

Kurýr přiveze zásilku k výdejnímu boxu a u boxu zadá, že ukládá zásilku pro zákazníka (uvede jeho telefon). Systém zásilku zaeviduje, přidělí volnou schránku, vygeneruje vyzvedávací kód a otevře přidělenou schránku. Kurýr zásilku vloží a schránku zavře.
Systém pošle zákazníkovi vyzvedávací kód.
Zákazník přijde k boxu a zadá vyzvedávací kód. Systém kód ověří a otevře příslušnou schránku.
Zákazník zásilku vyjme a schránku zavře. Systém označí zásilku za vyzvednutou.
Událost: Zásilka není do stanovené lhůty vyzvednuta — systém ji označí k vrácení

Jiná doména, stejná kotva, stejný výsledek: AI našla 3 prvky Use Case 1. druhu tam, kde se systém doopravdy použije — ne podle slovníku domény, ale podle cinknutí systému:

• UC Uložení zásilky kurýrem do boxu
• UC Vydání zásilky zákazníkovi
• UC Označení nevyzvednuté zásilky k vrácení

Pro zájemce zápis testování zde v PDF.

Pointa

Všimněte si, k čemu došlo:

Nestavělo se od nuly — vyšlo se z ověřeného HLA scénáře z minulých kapitol. Stále proto držíme užitek systému pro zákazníka. Čistý vstup → čistý výstup.

Prvky Use Case se nehledaly nahodile, ale podle jednoho ostrého pravidla (cinknutí je / není) s nutným přesným označením hranice (někdy je třeba se zeptat). Reprodukovatelné.

Právě ta ostrost dělá metodu uchopitelnou pro AI — nemusí hádat, jen aplikuje pravidlo, resp. se zeptá u nejednoznačnosti („je naše“ / „není naše“).

Metodika ve firmě je — podobně jako v minulé kapitole — zavedena implicitně. Analytik musí protokolovat test AI na vyhledání UC, ergo musí být hotový odsouhlasený Use Case Epic a musí mít také protokol, ergo celé to projde kolečkem s odevzdanou dokumentací. Metodika se neopakuje náhodou — je to pořád tatáž myšlenka, totéž „v bleděmodrém“ v další etapě prací:

Musí se udělat analytický dokument → předložit AI → odevzdat dokument do projektu i s protokolem AI testu.

A asi už správně tušíte, že tomu tak bude i v příští kapitole.

Všimněte si, že AI Analytik zde implicitně vstupuje do role AI Mentora, který vyžaduje dokument v požadované formě. Pokud se dokument odevzdá v odlišné podobě, AI na to upozorní a vyžádá si přesnější formulace — tím také poradí, co se metodicky žádá.

Co bude dál

Podstata agilnosti AAF spočívá v tom, že tímto postupem dostanete velice rychle prvky Use Case 1. druhu a začnete tedy velice brzy řešit jejich scénáře jako algoritmy uvnitř systému — a to se dá programovat. Tady už začíná návaznost logika chodu programu (scénář) → issue do programování anebo specifikace pro AI (technologie SDD)

Stále přitom podle VBM držíte kontext užitku při použití systému z okolí. Prvky Use Case 1. druhu „nevisí ve vzduchu“, ale jsou doslova pověšené (zaháčkované) do modelu chodu procesu, viz názorný ilustrativní obrázek na začátku článku.

Asi správně tušíte, že další kapitolou bude, jak psát scénáře UC tak, aby byly konzistentní a aby jim AI rozuměla. Dá se to — to bude předmětem příští kapitoly.