Praxe AAF s AI 2: AI a Zlatý proces

V této kapitole uvidíte, jak AI dokáže rozebrat logiku procesu tak přesně, že odhalí chyby, které běžně přežijí až do implementace.

Ale ještě než se pustíme do dalších kroků: každý odborný pojem, který tady použiju, má v dokumentaci AAF vysvětlení, najdete ho zde pod odkazy.

Minule jsme z hromady zadání vydestilovali sirup — čisté Funkční požadavky.

Další práce pokračují zpracováním tzv. Zlatého klíčového procesu.

V AAF začínáme právě s ním ze dvou důvodů: Je to proces, který drží hodnotu pro zákazníka a za druhé, informace v něm se „logicky vzato konzumují“. Nezačínat tzv. tanečky okolo (podpůrné procesy), ty pouze nastavují informace pro tuto konzumaci – čtení (nastavení číselníků, pomocných entit atd.) a jdou až v druhé vlně agilnosti.

Artefakt chodu procesu je na úrovni High Level Analysis (nikoliv implementace). Pracujeme na tom tři „vývojáři“: analytik, produktový vlastník (PO) a AI Analytik.

A všichni tři tomu dobře rozumíme.

Chod procesu se tvoří nejprve jasně a srozumitelně jako tzv. Use Case Epic ve formě všem srozumitelného textu, včetně laiků. Jakýkoliv PO znalý domény může reálně oponovat a rozhodovat — ne kývat na něco, čemu nevidí pod kapotu.

Zpátky k našemu modelovému příkladu, Platba lístků mobilem (projekt Mobile Ticket Payment). Vymýšleli jsme různé testy jako simulace situací při zpracování Zlatého procesu. Začali jsme od opravdu primitivních až po ty složité.

Z obchodu — alias PO — dodali (jakože) na počátku jednoduchý text, jak si Zlatý proces Platby představují . Dali jsme to jako testy k rozboru AI Analytikovi, a hned postupně vylepšovali ve třech kolech.

Jak si AI poradí s tak abstraktní věcí, jako je slovní scénář chodu procesu a přitom bude deterministický a výsledek bude doložitelný?

V každém testu to s ním stálo za to.

Jeden zákon se bude opakovat, tak ho představím hned tady: každá informace musí mít zdroj, odkud se vzala. Když nějaký prvek (včetně prvků z okolí) „ví“ něco, co nemá jak zjistit, je to chyba. V AAF se to nazývá Zákon zachování informace, nebo také „žádná jasnovidnost u nikoho, ani uvnitř systému a ani venku mimo systém“.

Sledujme AI při práci – jak u něj proběhly testy analýzy chodu procesu

Kolo 1

USE CASE EPIC návrh scénáře 1 (jednoduchá představa obchodu):

• Divák si na webu kina rezervuje lístky, dostane od kina kód.
• Divák zaplatí mobilem lístky s tímto kódem v našem systému.
• Kino ho vpustí do sálu, protože je zaplaceno.

Odpověď AI ANALYTIKA:

Kino neví, že je zaplaceno, není žádný kanál. Kino je tu jasnovidné. To je porušení Zákona zachování informace.

Není splněn FP „Chybná platba nesmí projít — blbovzdornost“ .

Takže identifikoval správně oba zásadní nedostatky.

Jdeme dál. Obchod to vzal a opravili jsme to, další test.

Kolo 2

USE CASE EPIC návrh scénáře v2:

• Divák si na webu kina rezervuje lístky, dostane od kina kód a současně ho kino pošle nám.
• Divák zaplatí s kódem, my u sebe spárujeme platbu s tímto kódem.
• Divák jde do kina.

Odpověď AI ANALYTIKA:
Kód generuje kino — nekontrolovatelný vnějšek. Párovací klíč má správně vyrábět náš systém (kino je pro nás anonym, nemůžeme se na něj v logice spolehnout). To je porušení Anonymity klienta.

Kino je jasnovidné. Kino neví, že je zaplaceno, není žádný kanál. To je porušení Zákona zachování informace.

AI Analytik zopakoval předešlý nález a identifikoval porušení dalšího principu zvaného Anonymita klienta. Na vnějšek se v logice vnitřku nespoléháme, protože vnějšek není pod naší kontrolou. Kdyby kino ten kód generovalo špatně, my ho sice nepřijmeme, ale služba se zastaví a je to náš obchodní problém, protože je to naše služba, která nechodí.

Spolu s obchodem jsme opravili i tohle. Princip Anonymity klienta říká: „Na koho se můžete spolehnout, když se nemůžete na nikoho spolehnout?“ Ano, správně: „Na sebe“. Takže kód budeme generovat my. Pokud to bude špatně, opravíme to — a nebudeme o to nikoho prosit.

Kolo 3

USE CASE EPIC návrh scénáře v3:

• Divák si na webu kina rezervuje lístky, kino nás zavolá, požádá o kód, my založíme čekající platbu s tímto kódem, vracíme kinu kód, kino ho zobrazí divákovi.
• Divák zaplatí s kódem, my u sebe spárujeme platbu s tímto kódem.
• Když se změní stav platby, pošleme ho kinu.

Odpověď AI ANALYTIKA:
Generování kódu u nás, anonymita v pořádku.

„pošleme ho kinu“ nález: náš systém volá kino. To odporuje tomu, jak je rozhraní postavené, podle FP: kino volá nás, ne my je. Kino se na stav stejně musí umět zeptat samo (při tisku, u vstupu). Dva kanály na totéž.

Tady AI chytila dvě věci najednou: směr informace (kdo koho volá) a neduplikovat tentýž kanál dvakrát, princip DRY v integracích: jeden fakt, jeden kanál.

Finále

Pár dalších kol vyladilo i drobnosti, jako co se stane, když platba selže, a kdo a kdy ruší nezaplacenou rezervaci. Nakonec návrh finálního tvaru vzniklý za oponentury AI:

USE CASE EPIC Zlatý proces Platby final

• Divák si na webu kina rezervuje lístky, kino nás požádá o kód – my založíme čekající platbu, vygenerujeme kód a vložíme do ní, kód vracíme kinu, kino ho zobrazí divákovi.
• Divák zaplatí s kódem, my u sebe spárujeme platbu s tímto kódem.
• Pokud divák chce tisk, kino se zeptá na stav platby s tímto kódem u nás.
• Pokud divák nechce tisk, jde do kina, nahlásí kód, kino se zeptá na stav platby s tímto kódem u nás.
• Pokud v kině expiruje rezervace, pošle nám požadavek na storno platby s daným kódem, u nás pokud je ve stavu čekající, stornujeme také a vracíme její stav.

AI ANALYTIK
Má jediný nález u finálu, nalezen přes technické okrajové podmínky: pokud kino nebude mít spojení, nemůže uvolnit rezervaci (při delším výpadku pro kino problém).

Perlička: Tady mě naopak AI dostala, této logické díry jsem si jako tester nevšiml. A to je přesně to, co od AI Analytika chceme — ne genialitu, ale neúnavnou důslednost. V modelovém příkladu vyřešeno šalamounsky přes možnost použít záložní kanál pro tyto výjimečné situace (jsme provideři a můžeme si to dovolit).

Jeho závěr nad Final Epic: Jinak žádná jasnovidnost, anonymita drží, jeden kanál místo dvou. Nalezl ještě čtyři prvky Use Case 1. druhu (umí to podle signálu Cinknutí systému jako kotva atomicity ), přičemž identifikoval re-use „UC Ověření platby“ ze dvou bodů chodu podniku (tisk a návštěva kina):

• 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)

A takhle má vypadat report — ne „AI jako black box nic nenašla“, ale „prošli jsme to spolu a víme, že to drží, tady to máte jako na stříbrném podnose“. Hra s otevřenými kartami.

Pointa

Všimněte si, co se právě stalo. Tři verze, tři různé typy chyb — a všechny jsou to chyby v logice děje: někdo ví něco, co nemá odkud; spoléháme na externí prvek; děláme jednu věc dvěma kanály. Tyhle věci se v seznamu požadavků ani v hezky napsané specifikaci nepoznají. Poznají se jen tady — v chodu procesu, na úrovni High Level Analysis:

• V požadavcích to nevidíte.
• V backlogu to nevidíte.
• V UML to nevidíte.
• Ve specifikaci pro AI to nevidíte
• Vidíte to jen v logice chodu procesu — a proto AAF začíná právě tady.

Chod Zlatého klíčového procesu je něco jako bible projektu — je to jediný artefakt jako zdroj pravdy oponovaný jak PO, tak AI, ke kterému se vracíme, když se něco láme. Jediný artefakt, který drží logiku systému s ohledem na očekávané hodnoty pro zákazníka (princip VBM). Základní zdroj informací a stanovená pravidla systému s mantinely, co se řeší. Vše ostatní se od něj odvíjí (viz postup Nabalování řešení).

Platí „zlaté pravidlo Zlatého procesu“: Držte neustále konzistentní logiku chodu Zlatého procesu odsouhlaseného PO a z něj odvozených dalších prvků. Držíte tak pevně opratě projektu a jeho mantinely.

Když tyto opratě pustíte, projekt se rozběhne na všechny strany a rozsype se.

Nejsou to žádné artefakty pro okrasu projektu, ale jediná věc, která je schopna držet logiku pohromadě. Když to pustíte, projekt se rozpadne rychleji, než stihnete zjistit proč.

Nad konzistentním a srozumitelným textem Use Case Epic zůstává PO v obraze a diskutuje s námi „oběma analytiky“, takže řešení se hledá společně podle základního principu Value Based Management (VBM).

AI vám pomůže v otrocké práci — chytí nálezy i u hodně košatých stromů procesů (např. Chod úvěru, co pamatuji z praxe, to byla fakt „lahůdka“) a u každého nálezu řekne proč — můžete si to po ní zkontrolovat. A můžete si to s ní zopakovat kdykoliv při každé změně, třebas i o půlnoci.

Co bude dál

Tohle byla jedna varianta chodu. V příští kapitole přijde obchod s úplně jiným nápadem — místo strhávání kreditu zablokovat částku stejně jako u karty — a uvidíme, jak si AI poradí s úplně novou logikou.