Nuo diagramų iki programų
DI asistuojamas struktūrizuotas Event Storming diagramų redaktorius verslo programinės įrangos inžinerijos komandoms. Jis kuria nuoseklias programinės įrangos specifikacijas agentinėms SDLC darbo eigoms. Jokių užduočių, jokių sprintų.
Demonstracija
Tai tikras el. prekybos domenas, „Customers“, sumodeliuotas StormPilot: Actors, Actions, Aggregates, Events, Rules, Views ir Terms, visiškai sujungti. Jį įgyvendino kodavimo agentas ir paskelbė https://github.com/codelev/stormpilot.
Programinės įrangos produkto pristatymas kitą dieną
Tai, kas iš tikrųjų sulėtina programinės įrangos produkto Time to Market, retai yra pats kodavimas. Tai viskas, kas turi įvykti prieš agentui ar inžinieriui saugiai pakeičiant produktą. Kai tik pradėjote naudoti multiagentinį SDLC, vis susidurdavote su tomis pačiomis keturiomis problemomis.
Suskaidytos žinios
Žinios apie produktą buvo išsklaidytos tarp techninių ir netechninių vadovų, programų, užduočių sekimo įrankių, kodo saugyklų ir dokumentų. Paprastai jos buvo nepilnos, pasenusios ir skirtingai interpretuojamos priklausomai nuo to, kas jas skaitė. Prieš sudarant keičiančių užduočių paketą (Sprintą), pirmiausia reikėjo sinchronizuoti visas šias suskaidytas žinias.
Žmogui orientuoti užduočių vertinimai
Kiekviena keičianti užduotis turėjo žmogui orientuotą vertinimą (story points), kuris nebeteko prasmės, kai darbą atlikdavo agentas. Agentui nereikia story point vertinimo, kad pradėtų. Liko tik planavimo ceremonija: užduočių paskirstymas ir tarpusavio ar tarp komandų priklausomybių išpainiojimas, pastangos, kurios egzistavo tik todėl, kad užduotys buvo pritaikytos žmonėms, o ne agentams.
Esamos būsenos atvirkštinė inžinerija
Keičianti užduotis apibūdina skirtumą tarp esamos ir norimos būsenos. Tai vertė kodavimo agentą pirmiausia atvirkštine inžinerija atkurti esamą būseną, kol jis apskritai galėjo veikti pagal skirtumą. Dėl dabartinių LLM apribojimų ši rekonstrukcija kartais būdavo neteisinga arba nepilna, ir produktas pasikeisdavo tokiais būdais, kurių jūs neprašėte.
Interpretacijos nuokrypis
Kiekviena keičianti užduotis buvo rašoma natūralia kalba, o tai kėlė interpretacijos nuokrypio riziką: atotrūkį tarp numatyto domeno elgesio ir faktiškai įgyvendinto elgesio, sukelto informacijos praradimo ar dviprasmiškumo. Dėl dabartinių LLM apribojimų ta pati užduotis, pateikta tam pačiam agentui, kiekvieną kartą galėjo sukurti skirtingą kodą, ir produktas vėl pasikeisdavo tokiais būdais, kurių jūs neprašėte.
Spec-Driven Development
Norėdamos tai ištaisyti, komandos pasirenka vieną iš Spec-Driven Development (SDD) sistemų: specifikacijų failai, parašyti natūralia arba mišria natūralia ir formalia kalba, parengti prieš kodavimą, tampa agento įvestimi. Yra 15 Spec-Driven Development sistemų palyginimas, kuris suskirsto jas į tris lygius.
1 lygis · Spec-First
Traktuoja specifikaciją kaip preliminarią sutartį ar ketinimų laišką.
GitHub Spec Kit, Superpowers, Behavioral Meta-Architectural Design, Goal-Driven Development, SpecSwarm
2 lygis · Spec-Anchored
Palaiko specifikaciją kaip gyvą dokumentą per visą projekto gyvavimo ciklą.
MUSUBI, Intent, OpenSpec
3 lygis · Spec-as-Source
Įgyvendina nuokrypio neturinčią sąranką, kurioje specifikacijos failas yra absoliutus vienintelis tiesos šaltinis.
Tessl, Contractual Specification-Driven Development
15 Spec-Driven Development sistemų palyginimas
Išbandėme šį kelią. Specifikacijų failai iš tiesų padėjo sutelkti žinias vienoje vietoje, aprašyti esamą ir norimą būseną bei sumažinti interpretacijos nuokrypį. Tačiau specifikacijos failas vis tiek buvo dar vienas dokumentas, gyvenantis kodo saugykloje, kuriam reikėjo savo sinchronizacijos su kitais produkto artefaktais. O verslo suinteresuotosios šalys vis tiek negalėjo bendradarbiauti prie specifikacijos failo: suskaidytos žinios tarp techninių ir netechninių žmonių liko neišspręstos.
Todėl sukūrėme StormPilot, kad iš karto išspręstume visas keturias problemas.
Event Storming
EventStorming yra paprasta bendradarbiavimo dirbtuvių technika, kurią sukūrė Alberto Brandolini sudėtingiems verslo procesams tyrinėti kaip pasikartojančių elementų laiko juostai. EventStorming nebuvo skirtas būti skaitmeniniu įrankiu. Pagrindinis jos tikslas yra kolektyvinis mokymasis: verslo ir techniniai ekspertai kartu atranda ir aptaria, kaip veikia sritis (domenas). Lenta yra sąmoningai lengva ir apčiuopiama, leidžianti dalyviams greitai pridėti, perkelti, grupuoti, kelti klausimus ir pašalinti elementus. Fizinė lipnių lapelių priemonė yra metodo dalis. Notacija nėra skirta būti griežta formalia modeliavimo kalba.
Struktūrizuotas Event Storming
StormPilot iš esmės yra ištikimas Event Storming koncepcijoms. Jis vengia CQRS terminologijos, naudodamas "View" vietoj "Read Model", "Action" vietoj "Command", "Rule" vietoj "Policy". Jis prideda "Term" kaip aiškų elementą, skirtą palaikyti bendrą srities kalbą. Struktūrizuotas Event Storming paverčia mokymosi techniką specifikacijų sistema. Jis įterpia formalias notacijas tiesiai į elementus, kad sumažintų interpretacijos nuokrypį: atotrūkį tarp to, už ką sritis atsakinga, ir to, kas iš tikrųjų sukuriama, kurį sukelia prarasta ar dviprasmiška informacija. Gauta programinės įrangos specifikacija tarnauja kaip determinuotas įvestis agentiniam kodo generavimui, leidžiant srities žinioms valdyti programinės įrangos produkto pakeitimus, pristatomus kitą dieną.
DI pagalba
DI asistentas nuskaito jūsų realų domeno modelį ir siūlo konkrečius pataisymus: pavadinimų patobulinimus, trūkstamus elementus, vaidmenų apibrėžimus, srauto spragas, apribojimų patikslinimus. Priimkite tai, kas naudinga, atmeskite likusią dalį.
Versijavimas
Užduotis kaip atskiras projektų valdymo artefaktas neturi prasmės multiagentiniame SDLC ar žetonų ekonomikoje. Struktūrizuotas Event Storming diagramoje užfiksuotų žinių pokyčiai tiesiogiai atsispindi produkto, kurį norime išleisti, pokyčiuose. Todėl StormPilot pakeičia užduotis ir užduočių paketus produkto versijavimu. Taip sprendžiami žmogui orientuoti užduočių vertinimai ir esamos būsenos atvirkštinė inžinerija.
DUK
Ar reikia mokėti, kad išbandyčiau?
Ne. Demonstracija yra nemokama, vieša smėlio dėžė be registracijos, su visais prieinamais vaidmenimis. Ji atstatoma kasdien ir apribota iki 5 domenų, kiekvienam po 2 versijas.
Kas yra domeno versija?
Facilitator gali užšaldyti dabartinę diagramos būseną kaip versiją. Versijos yra nekintamos, su laiko žyma ir tik skaitomos.
Ką ji eksportuoja?
StormPilot eksportuoja User Interface, Application Programming Interface, duomenų modelį ir Behavior scenarijus.
Ar DI rašo kodą?
Ne. StormPilot DI nurodo, KĄ koduoti: domeno modelį ir jo elgesį. Technologijų steką vis dar renkasi inžinerijos komanda.
Kodėl OpenRPC?
Verslo Actions viršija REST semantiką. OpenRPC tiksliai atitinka Event Storming notaciją, išvengia interpretacijos dreifo ir yra nepriklausomas nuo protokolo.
Kodėl Gherkin?
Given/When/Then atspindi Event Storming Rules struktūrą ir išvengia interpretacijos dreifo, nes tiesiogiai palaikoma BDD įrankių ekosistemos.
Kodėl PlantUML?
Event Storming iš prigimties yra vizualus, o PlantUML tai išsaugo eksportuojant. Sintaksę tiesiogiai palaiko įrankių ekosistema.
Kodėl SSE?
Events juda tik viena kryptimi, todėl WebSockets sudėtingumas lieka nepanaudotas. Server-Sent Events lieka paprastu HTTP ir automatiškai prisijungia iš naujo.