Od diagramov do aplikacij

Z umetno inteligenco podprt urejevalnik diagramov strukturirani Event Storming za ekipe poslovnega razvoja programske opreme. Ustvarja skladne specifikacije programske opreme za agentne SDLC delovne tokove. Brez nalog, brez sprintov.

ActorCustomerActionPlace OrderAggregateOrderEventOrder Placed

Demo

To je resnična domena e-trgovine, „Customers“, modelirana v StormPilotu: Actors, Actions, Aggregates, Events, Rules, Views in Terms, popolnoma povezani. Implementiral in objavil ga je kodirni agent na https://github.com/codelev/stormpilot.

Domena Customers, modelirana v StormPilotu, ki prikazuje povezane elemente Actor, Action, Aggregate, Event, Rule in View

Dostava programskega izdelka do naslednjega dne

Tisto, kar dejansko upočasnjuje Time to Market programskega izdelka, redko je samo kodiranje. Gre za vse, kar se mora zgoditi, preden lahko agent ali inženir varno spremeni izdelek. Ko ste začeli izvajati multiagentni SDLC, ste znova in znova naleteli na iste štiri probleme.

Razdrobljeno znanje

Znanje o izdelku je bilo razdrobljeno med tehničnimi in netehničnimi vodji, aplikacijami, orodji za sledenje nalog, repozitoriji kode in dokumenti. Običajno je bilo nepopolno, zastarelo in različno razumljeno glede na to, kdo ga je bral. Preden ste sploh lahko sestavili paket spreminjajočih se nalog (Sprint), ste morali najprej uskladiti vse to razdrobljeno znanje.

Na človeka osredotočene ocene nalog

Vsaka spreminjajoča se naloga je nosila na človeka osredotočeno oceno (story points), ki ni imela nobene vloge, ko je delo opravljal agent. Agent za začetek ne potrebuje ocene v story points. Kar je ostalo, je bila ceremonija načrtovanja: razporejanje nalog in razpletanje odvisnosti med nalogami ali ekipami, napor, ki je obstajal samo zato, ker so bile naloge prilagojene ljudem, ne agentom.

Povratno inženirstvo obstoječega stanja

Spreminjajoča se naloga opisuje razliko med obstoječim in želenim stanjem. To je kodirnega agenta prisililo, da je najprej s povratnim inženirstvom rekonstruiral obstoječe stanje, preden je sploh lahko ukrepal glede razlike. Zaradi trenutnih omejitev LLM-jev je bila ta rekonstrukcija včasih napačna ali nepopolna, izdelek pa se je spremenil na načine, ki jih niste zahtevali.

Odstopanje pri interpretaciji

Vsaka spreminjajoča se naloga je bila napisana v naravnem jeziku, kar je pomenilo tveganje odstopanja pri interpretaciji: vrzel med nameravanim vedenjem domene in vedenjem, ki je bilo dejansko implementirano, povzročeno zaradi izgube informacij ali dvoumnosti. Zaradi trenutnih omejitev LLM-jev je lahko ista naloga, dana istemu agentu, vsakič ustvarila drugačno kodo, izdelek pa se je znova spremenil na načine, ki jih niste zahtevali.

Spec-Driven Development

Da bi to odpravile, ekipe sprejmejo enega od ogrodij Spec-Driven Development (SDD): specifikacijske datoteke, napisane v naravnem ali mešanem naravno-formalnem jeziku, pripravljene pred kodiranjem, postanejo vhod za agenta. Obstaja primerjava 15 ogrodij Spec-Driven Development, ki jih razvršča v tri ravni.

Raven 1 · Spec-First

Obravnavajo specifikacijo kot predhodno pogodbo ali pismo o nameri.

GitHub Spec Kit, Superpowers, Behavioral Meta-Architectural Design, Goal-Driven Development, SpecSwarm

Raven 2 · Spec-Anchored

Ohranjajo specifikacijo kot živ dokument skozi celoten življenjski cikel projekta.

MUSUBI, Intent, OpenSpec

Raven 3 · Spec-as-Source

Uvajajo nastavitev brez odstopanja, kjer je specifikacijska datoteka absolutni edini vir resnice.

Tessl, Contractual Specification-Driven Development

Primerjava 15 ogrodij Spec-Driven Development

To pot smo preizkusili. Specifikacijske datoteke so res pomagale zbrati znanje na enem mestu, opisati obstoječe in želeno stanje ter zmanjšati odstopanje pri interpretaciji. Vendar je bila specifikacijska datoteka še vedno en dokument več, ki je živel v repozitoriju kode in je potreboval lastno usklajevanje z ostalimi artefakti izdelka. Poslovni deležniki pa še vedno niso mogli sodelovati pri specifikacijski datoteki: razdrobljeno znanje med tehničnimi in netehničnimi ljudmi je ostalo nerešeno.

Zato smo zgradili StormPilot, da bi hkrati rešili vse štiri probleme.

Event Storming

EventStorming je nizkotehnološka skupna delavniška tehnika, ki jo je izumil Alberto Brandolini za raziskovanje kompleksnih poslovnih procesov kot časovnice ponavljajočih se elementov. EventStorming ni bil zamišljen kot digitalno orodje. Njegov glavni namen je kolektivno učenje: poslovni in tehnični strokovnjaki skupaj odkrivajo in razpravljajo, kako deluje domena. Tabla je namenoma lahka in otipljiva, kar udeležencem omogoča hitro dodajanje, premikanje, združevanje, spraševanje in odstranjevanje elementov. Fizični medij lepljivih listkov je del metode. Notacija ni mišljena kot strog formalni jezik modeliranja.

Video o Event Stormingu

Strukturirani Event Storming

StormPilot je večinoma zvest konceptom Event Storminga. Izogiba se terminologiji CQRS z uporabo "View" namesto "Read Model", "Action" namesto "Command", "Rule" namesto "Policy". Dodaja "Term" kot izrecen element za ohranjanje enotnega domenskega jezika. Strukturirani Event Storming spremeni tehniko učenja v specifikacijski sistem. Vgrajuje formalne notacije neposredno v elemente, da zmanjša odstopanje pri interpretaciji: vrzel med tem, za kar je domena odgovorna, in tem, kar je dejansko zgrajeno, ki jo povzroči izgubljena ali dvoumna informacija. Nastala programska specifikacija služi kot deterministični vhod za agentno generiranje kode, kar omogoča, da domensko znanje poganja spremembe v programski opremi, dostavljeni naslednji dan.

Strukturirani Event Storming

Pomoč UI

Asistent z umetno inteligenco prebere vaš dejanski model domene in predlaga konkretne popravke: izboljšave poimenovanja, manjkajoče elemente, definicije vlog, vrzeli v pretoku, pojasnila omejitev. Sprejmite, kar je koristno, zavrnite ostalo.

Asistent z umetno inteligenco StormPilot predlaga izboljšave poimenovanja, manjkajoče elemente, definicije vlog, vrzeli v pretoku in pojasnila omejitev, ob celotnem diagramu domene

Različičenje

Naloga kot samostojen artefakt vodenja projektov nima smisla v multiagentnem SDLC ali v ekonomiji žetonov. Spremembe znanja, zajetega v diagramu strukturirani Event Storming, se neposredno preslikajo v spremembe izdelka, ki ga želimo izdati. Zato StormPilot naloge in pakete nalog nadomesti z različičenjem izdelka. Tako se rešita na človeka osredotočeno ocenjevanje nalog in povratno inženirstvo obstoječega stanja.

Plošča zgodovine različic StormPilot, ki prikazuje razliko med dvema nespremenljivima različicama domene

Pogosta vprašanja

Ali moram plačati, da to preizkusim?

Ne. Demo je brezplačno javno peskovnik brez registracije z vsemi razpoložljivimi vlogami. Ponastavi se dnevno in je omejen na 5 domen, vsaka z 2 različicama.

Kaj je različica domene?

Facilitator lahko zamrzne trenutno stanje diagrama kot različico. Različice so nespremenljive, s časovnim žigom in samo za branje.

Kaj izvozi?

StormPilot izvozi User Interface, Application Programming Interface, podatkovni model in scenarije Behavior.

Ali umetna inteligenca piše kodo?

Ne. Umetna inteligenca StormPilot določa, KAJ kodirati: model domene in njegovo vedenje. Tehnološki sklad ostaja odločitev tehnične ekipe.

Zakaj OpenRPC?

Poslovni Actions presegajo REST semantiko. OpenRPC natančno ustreza notaciji Event Storming, se izogiba razhajanju pri razlagi in ostaja neodvisen od protokola.

Zakaj Gherkin?

Given/When/Then odraža strukturo Event Storming Rules in se izogiba razhajanju pri razlagi, saj ga neposredno podpira ekosistem orodij BDD.

Zakaj PlantUML?

Event Storming je po naravi vizualen, PlantUML pa to ohrani pri izvozu. Sintakso neposredno podpira ekosistem orodij.

Zakaj SSE?

Events tečejo samo v eno smer, zato kompleksnost WebSockets ostaja neizkoriščena. Server-Sent Events ostaja navaden HTTP in se samodejno znova poveže.

Skladno z GDPR. Podatki se obdelujejo znotraj EU, z uporabo infrastrukturnih in obdelovalnih partnerjev, ki upoštevajo enak standard.