Diagramoktól az alkalmazásokig
AI-asszisztált strukturált Event Storming diagramszerkesztő üzleti szoftverfejlesztő csapatok számára. Konzisztens szoftverspecifikációkat készít az ágensalapú SDLC munkafolyamatokhoz. Nincsenek taskok, nincsenek sprintek.
Demo
Ez egy valódi e-kereskedelmi domain, a „Customers”, StormPilotban modellezve: Actors, Actions, Aggregates, Events, Rules, Views és Terms, teljesen összekapcsolva. Egy kódoló ágens valósította meg és tette közzé itt: https://github.com/codelev/stormpilot.
Szoftvertermék szállítása másnapra
Ami valójában lassítja egy szoftvertermék Time to Marketjét, az ritkán maga a kódolás. Az minden, aminek meg kell történnie, mielőtt egy ágens vagy egy mérnök biztonságosan megváltoztathatja a terméket. Amint elkezdtek egy multiágens SDLC-t futtatni, újra és újra ugyanabba a négy problémába ütköztek.
Széttöredezett tudás
A termékkel kapcsolatos tudás szétszórva volt a technikai és nem technikai vezetők, alkalmazások, feladatkövetők, kódtárolók és dokumentumok között. Általában hiányos, elavult volt, és attól függően, ki olvasta, másképp értelmezték. Mielőtt egyáltalán összeállíthatták volna a változtatási feladatok csomagját (egy Sprintet), előbb szinkronizálni kellett ezt a szétszórt tudást.
Emberközpontú feladatbecslések
Minden változtatási feladat magával hozott egy emberközpontú becslést (story pointokat), amelynek semmi szerepe nem volt, ha egy ágens végezte a munkát. Egy ágensnek nincs szüksége story point becslésre a kezdéshez. Ami maradt, az egy tervezési ceremónia volt: feladatok elosztása és a feladatok közötti vagy csapatközi függőségek kibogozása, erőfeszítés, amely csak azért létezett, mert a feladatok emberekre voltak méretezve, nem ágensekre.
A meglévő állapot visszafejtése
Egy változtatási feladat a meglévő és a kívánt állapot közötti különbséget írja le. Ez arra kényszerítette a kódoló ágenst, hogy előbb visszafejtse a meglévő állapotot, mielőtt egyáltalán reagálhatott volna a különbségre. A jelenlegi LLM-korlátok miatt ez a rekonstrukció néha hibás vagy hiányos lett, és a termék olyan módon változott, ahogyan nem szerették volna.
Értelmezési eltérés
Minden változtatási feladat természetes nyelven íródott, ami magában hordozta az értelmezési eltérés kockázatát: a szándékolt domain-viselkedés és a ténylegesen megvalósított viselkedés közötti szakadékot, amelyet információvesztés vagy kétértelműség okoz. A jelenlegi LLM-korlátok miatt ugyanaz a feladat, ugyanannak az ágensnek átadva, minden alkalommal más kódot eredményezhetett, és a termék ismét olyan módon változott, ahogyan nem szerették volna.
Spec-Driven Development
Ennek orvoslására a csapatok az egyik Spec-Driven Development (SDD) keretrendszert alkalmazzák: a specifikációs fájlok, természetes vagy vegyes természetes-formális nyelven írva, a kódolás előtt elkészítve, az ágens bemenetévé válnak. Létezik egy összehasonlítás 15 Spec-Driven Development keretrendszerről, amely három szintbe sorolja őket.
1. szint · Spec-First
A specifikációt előzetes szerződésként vagy szándéknyilatkozatként kezelik.
GitHub Spec Kit, Superpowers, Behavioral Meta-Architectural Design, Goal-Driven Development, SpecSwarm
2. szint · Spec-Anchored
A specifikációt élő dokumentumként tartják fenn a teljes projektéletciklus alatt.
MUSUBI, Intent, OpenSpec
3. szint · Spec-as-Source
Egy eltérésmentes beállítást valósítanak meg, ahol a specifikációs fájl az abszolút egyetlen igazságforrás.
Tessl, Contractual Specification-Driven Development
15 Spec-Driven Development keretrendszer összehasonlítása
Kipróbáltuk ezt az utat. A specifikációs fájlok valóban segítettek egy helyen összegyűjteni a tudást, leírni a meglévő és a kívánt állapotot, és csökkenteni az értelmezési eltérést. De a specifikációs fájl továbbra is egy újabb dokumentum volt a kódtárolóban, amelynek saját szinkronizálásra volt szüksége a termék többi artefaktumával. Az üzleti érdekeltek pedig még mindig nem tudtak együttműködni egy specifikációs fájlon: a technikai és nem technikai emberek közötti széttöredezett tudás megoldatlan maradt.
Ezért építettük fel a StormPilotot, hogy mind a négy problémát egyszerre kezeljük.
Event Storming
Az EventStorming egy alacsony technológiájú, együttműködésen alapuló workshop-technika, amelyet Alberto Brandolini alkotott meg összetett üzleti folyamatok feltárására, ismétlődő elemek idővonalaként. Az EventStorming eredetileg nem digitális eszköznek készült. Elsődleges célja a közös tanulás: üzleti és technikai szakértők együtt fedezik fel és vitatják meg, hogyan működik egy domain. A tábla szándékosan könnyű és tapintható, lehetővé téve a résztvevők számára, hogy gyorsan hozzáadjanak, mozgassanak, csoportosítsanak, megkérdőjelezzenek és eltávolítsanak elemeket. A fizikai öntapadós cetli mint eszköz a módszer része. A jelölésrendszer nem szigorú, formális modellezési nyelvnek készült.
Strukturált Event Storming
A StormPilot nagyrészt hűen követi az Event Storming koncepcióit. Elkerüli a CQRS terminológiát azáltal, hogy "View"-t használ "Read Model" helyett, "Action"-t "Command" helyett, "Rule"-t "Policy" helyett. Hozzáadja a "Term"-et mint explicit elemet az egységes doménnyelv fenntartásához. A strukturált Event Storming a tanulási technikát specifikációs rendszerré alakítja. Formális jelöléseket épít közvetlenül az elemekbe, hogy csökkentse az értelmezési eltérést: a szakadékot aközött, amiért egy domain felelős, és aközött, ami valójában megépül, amit elveszett vagy kétértelmű információ okoz. Az így kapott szoftverspecifikáció determinisztikus bemenetként szolgál az ágensalapú kódgeneráláshoz, lehetővé téve, hogy a doménismeret a másnap szállított szoftvertermék változásait vezérelje.
AI-asszisztencia
Az AI-asszisztens beolvassa a tényleges domain-modellt, és konkrét javításokat javasol: elnevezési javítások, hiányzó elemek, szerepdefiníciók, folyamatbeli hiányosságok, feltétel-pontosítások. Fogadja el, ami hasznos, a többit vesse el.
Verziózás
Egy feladatnak mint önálló projektmenedzsment-artefaktumnak nincs értelme egy multiágens SDLC-ben vagy egy tokengazdaságban. A strukturált Event Storming diagramban rögzített tudás változásai közvetlenül leképeződnek a kiadni kívánt termék változásaira. Ezért a StormPilot a feladatokat és feladatcsomagokat termékverziózással váltja fel. Így oldódik meg az emberközpontú feladatbecslés és a meglévő állapot visszafejtése.
GYIK
Fizetnem kell a kipróbáláshoz?
Nem. A Demo egy ingyenes, nyilvános homokozó regisztráció nélkül, minden szereppel elérhetően. Naponta visszaáll, és legfeljebb 5 domainre korlátozott, mindegyikhez 2 verzióval.
Mi az a domainverzió?
Egy Facilitator lefagyaszthatja egy diagram jelenlegi állapotát verzióként. A verziók megváltoztathatatlanok, időbélyeggel ellátottak és csak olvashatók.
Mit exportál?
A StormPilot exportálja a User Interface, Application Programming Interface, az adatmodell és a Behavior forgatókönyveket.
Az AI ír kódot?
Nem. A StormPilot AI-ja azt specifikálja, MIT kell kódolni: a domain-modellt és annak viselkedését. A technológiai stack továbbra is a mérnöki csapat döntése.
Miért OpenRPC?
Az üzleti Actions túlmutatnak a REST szemantikáján. Az OpenRPC pontosan illeszkedik az Event Storming jelöléséhez, elkerüli az értelmezési driftet, és protokollfüggetlen marad.
Miért Gherkin?
A Given/When/Then tükrözi az Event Storming Rules szerkezetét, és elkerüli az értelmezési driftet, mivel közvetlenül támogatja a BDD-eszközökből álló ökoszisztéma.
Miért PlantUML?
Az Event Storming eredendően vizuális, a PlantUML pedig megőrzi ezt az exportálás során. A szintaxist közvetlenül támogatja az eszközökből álló ökoszisztéma.
Miért SSE?
Az Events csak egy irányba áramlik, így a WebSockets komplexitása kihasználatlan marad. A Server-Sent Events egyszerű HTTP marad, és automatikusan újracsatlakozik.