No diagrammām līdz lietotnēm
MI atbalstīts strukturēts Event Storming diagrammu redaktors biznesa programmatūras izstrādes komandām. Tas rada konsekventas programmatūras specifikācijas aģentiskām SDLC darbplūsmām. Bez uzdevumiem, bez sprintiem.
Demo
Šis ir reāls e-komercijas domēns, „Customers”, modelēts StormPilot: Actors, Actions, Aggregates, Events, Rules, Views un Terms, pilnībā savienoti. To ieviesa un publicēja kodēšanas aģents https://github.com/codelev/stormpilot.
Programmatūras produkta piegāde nākamajā dienā
Tas, kas patiešām palēnina programmatūras produkta Time to Market, reti ir pati kodēšana. Tas ir viss, kam jānotiek, pirms aģents vai inženieris var droši mainīt produktu. Tiklīdz sākāt izmantot multiaģentisku SDLC, jūs atkal un atkal saskārāties ar tām pašām četrām problēmām.
Sadrumstalotas zināšanas
Zināšanas par produktu bija sadrumstalotas starp tehniskajiem un netehniskajiem vadītājiem, lietotnēm, uzdevumu izsekotājiem, koda repozitorijiem un dokumentiem. Parasti tās bija nepilnīgas, novecojušas un tika interpretētas atšķirīgi atkarībā no lasītāja. Pirms varēja saskaņot izmaiņu uzdevumu paketi (Sprintu), vispirms bija jāsinhronizē visas šīs sadrumstalotās zināšanas.
Uz cilvēku vērstas uzdevumu novērtējumi
Katrs izmaiņu uzdevums nesa uz cilvēku vērstu novērtējumu (story points), kam nebija nekādas nozīmes, kad darbu veica aģents. Aģentam nav vajadzīgs story point novērtējums, lai sāktu. Palika tikai plānošanas ceremonija: uzdevumu sadale un starp-uzdevumu vai starp-komandu atkarību atšķetināšana, piepūle, kas pastāvēja tikai tāpēc, ka uzdevumi bija izmērīti cilvēkiem, nevis aģentiem.
Esošā stāvokļa reversā inženierija
Izmaiņu uzdevums apraksta atšķirību starp esošo un vēlamo stāvokli. Tas piespieda kodēšanas aģentu vispirms veikt esošā stāvokļa reverso inženieriju, pirms tas vispār varēja rīkoties saistībā ar atšķirību. Pašreizējo LLM ierobežojumu dēļ šī rekonstrukcija dažkārt izrādījās nepareiza vai nepilnīga, un produkts mainījās veidos, ko jūs nebijāt vēlējušies.
Interpretācijas novirze
Katrs izmaiņu uzdevums bija rakstīts dabiskajā valodā, kas radīja interpretācijas novirzes risku: plaisu starp iecerēto domēna uzvedību un faktiski ieviesto uzvedību, ko izraisīja informācijas zudums vai neskaidrība. Pašreizējo LLM ierobežojumu dēļ viens un tas pats uzdevums, dots vienam un tam pašam aģentam, katru reizi varēja radīt atšķirīgu kodu, un produkts atkal mainījās veidos, ko jūs nebijāt vēlējušies.
Spec-Driven Development
Lai to novērstu, komandas pieņem vienu no Spec-Driven Development (SDD) ietvariem: specifikācijas faili, rakstīti dabiskajā vai jauktā dabiskajā un formālajā valodā, sagatavoti pirms kodēšanas, kļūst par aģenta ievaddatiem. Ir pieejams 15 Spec-Driven Development ietvaru salīdzinājums, kas sadala tos trīs līmeņos.
1. līmenis · Spec-First
Uztver specifikāciju kā provizorisku līgumu vai nodomu vēstuli.
GitHub Spec Kit, Superpowers, Behavioral Meta-Architectural Design, Goal-Driven Development, SpecSwarm
2. līmenis · Spec-Anchored
Uztur specifikāciju kā dzīvu dokumentu visā projekta dzīves ciklā.
MUSUBI, Intent, OpenSpec
3. līmenis · Spec-as-Source
Ievieš beznovirzes iestatījumu, kurā specifikācijas fails ir absolūtais vienīgais patiesības avots.
Tessl, Contractual Specification-Driven Development
15 Spec-Driven Development ietvaru salīdzinājums
Mēs izmēģinājām šo ceļu. Specifikācijas faili patiešām palīdzēja apkopot zināšanas vienuviet, aprakstīt esošo un vēlamo stāvokli un samazināt interpretācijas novirzi. Bet specifikācijas fails joprojām bija vēl viens dokuments, kas dzīvoja koda repozitorijā un kam bija vajadzīga sava sinhronizācija ar pārējiem produkta artefaktiem. Un biznesa ieinteresētās puses joprojām nevarēja sadarboties pie specifikācijas faila: sadrumstalotās zināšanas starp tehniskajiem un netehniskajiem cilvēkiem palika neatrisinātas.
Tāpēc mēs izveidojām StormPilot, lai vienlaikus risinātu visas četras problēmas.
Event Storming
EventStorming ir vienkārša sadarbības darbnīcas tehnika, ko izveidoja Alberto Brandolini sarežģītu biznesa procesu izpētei kā atkārtojošos elementu laika skalu. EventStorming nebija paredzēts kā digitāls rīks. Tā galvenais mērķis ir kolektīva mācīšanās: biznesa un tehniskie eksperti kopā atklāj un pārrunā, kā darbojas domēns. Dēlis ir apzināti viegls un taustāms, ļaujot dalībniekiem ātri pievienot, pārvietot, grupēt, apšaubīt un izņemt elementus. Fizisks līmlapiņu materiāls ir metodes daļa. Apzīmējumu sistēma nav paredzēta kā stingra formāla modelēšanas valoda.
Strukturēts Event Storming
StormPilot lielā mērā ir uzticams Event Storming koncepcijām. Tas izvairās no CQRS terminoloģijas, izmantojot "View" nevis "Read Model", "Action" nevis "Command", "Rule" nevis "Policy". Tas pievieno "Term" kā skaidru elementu, lai uzturētu vienotu domēna valodu. Strukturēts Event Storming pārvērš mācīšanās tehniku specifikāciju sistēmā. Tas iegulda formālus apzīmējumus tieši elementos, lai samazinātu interpretācijas novirzi: plaisu starp to, par ko domēns ir atbildīgs, un to, kas faktiski tiek uzbūvēts, ko izraisa pazaudēta vai neskaidra informācija. Iegūtā programmatūras specifikācija kalpo kā deterministisks ievads aģentiskai koda ģenerēšanai, ļaujot domēna zināšanām virzīt izmaiņas programmatūras produktā, kas tiek piegādāts nākamajā dienā.
MI atbalsts
MI asistents nolasa jūsu faktisko domēna modeli un piedāvā konkrētus labojumus: nosaukumu uzlabojumus, trūkstošos elementus, lomu definīcijas, plūsmas nepilnības, ierobežojumu precizējumus. Pieņemiet to, kas ir noderīgs, atmetiet pārējo.
Versiju kontrole
Uzdevumam kā patstāvīgam projektu vadības artefaktam nav jēgas multiaģentiskā SDLC vai marķieru ekonomikā. Izmaiņas zināšanās, kas fiksētas strukturēts Event Storming diagrammā, tieši atspoguļojas produkta izmaiņās, ko vēlamies izlaist. Tāpēc StormPilot aizstāj uzdevumus un uzdevumu paketes ar produkta versiju kontroli. Tā tiek risinātas uz cilvēku vērstas uzdevumu novērtējumi un esošā stāvokļa reversā inženierija.
Biežāk uzdotie jautājumi
Vai man jāmaksā, lai to izmēģinātu?
Nē. Demo ir bezmaksas, publiska smilškaste bez reģistrācijas un ar visām pieejamām lomām. Tā tiek atiestatīta katru dienu un ir ierobežota līdz 5 domēniem, katram ar 2 versijām.
Kas ir domēna versija?
Facilitator var iesaldēt diagrammas pašreizējo stāvokli kā versiju. Versijas ir nemainīgas, ar laika zīmogu un tikai lasāmas.
Ko tas eksportē?
StormPilot eksportē User Interface, Application Programming Interface, datu modeli un Behavior scenārijus.
Vai MI raksta kodu?
Nē. StormPilot MI nosaka, KAS jākodē: domēna modeli un tā uzvedību. Tehnoloģiju steks joprojām ir inženieru komandas ziņā.
Kāpēc OpenRPC?
Biznesa Actions pārsniedz REST semantiku. OpenRPC precīzi atbilst Event Storming notācijai, izvairās no interpretācijas dreifa un nav atkarīgs no protokola.
Kāpēc Gherkin?
Given/When/Then atspoguļo Event Storming Rules struktūru un izvairās no interpretācijas dreifa, jo to tieši atbalsta BDD rīku ekosistēma.
Kāpēc PlantUML?
Event Storming pēc būtības ir vizuāls, un PlantUML to saglabā eksportējot. Sintaksi tieši atbalsta rīku ekosistēma.
Kāpēc SSE?
Events plūst tikai vienā virzienā, tāpēc WebSockets sarežģītība paliek neizmantota. Server-Sent Events paliek vienkāršs HTTP un automātiski atjauno savienojumu.