Από διαγράμματα σε εφαρμογές
Επεξεργαστής διαγραμμάτων δομημένο Event Storming με βοήθεια AI για ομάδες επιχειρησιακής μηχανικής λογισμικού. Παράγει συνεπείς προδιαγραφές λογισμικού για ροές εργασίας πρακτορικού SDLC. Χωρίς εργασίες, χωρίς sprints.
Demo
Αυτό είναι ένα πραγματικό domain ηλεκτρονικού εμπορίου, «Customers», μοντελοποιημένο στο StormPilot: Actors, Actions, Aggregates, Events, Rules, Views και Terms, πλήρως συνδεδεμένα. Υλοποιήθηκε από έναν πράκτορα κώδικα και δημοσιεύτηκε στο https://github.com/codelev/stormpilot.
Παράδοση προϊόντος λογισμικού την επόμενη ημέρα
Αυτό που πραγματικά καθυστερεί το Time to Market ενός προϊόντος λογισμικού σπάνια είναι η ίδια η κωδικοποίηση. Είναι όλα όσα πρέπει να συμβούν πριν ένας πράκτορας, ή ένας μηχανικός, μπορέσει να αλλάξει με ασφάλεια το προϊόν. Μόλις αρχίσατε να εκτελείτε έναν πολυπρακτορικό SDLC, συνεχίζατε να προσκρούετε στα ίδια τέσσερα προβλήματα, ξανά και ξανά.
Κατακερματισμένη γνώση
Η γνώση για το προϊόν ήταν κατακερματισμένη ανάμεσα σε τεχνικά και μη τεχνικά στελέχη, εφαρμογές, εργαλεία παρακολούθησης εργασιών, αποθετήρια κώδικα και έγγραφα. Συνήθως ήταν ελλιπής, ξεπερασμένη και ερμηνευόταν διαφορετικά ανάλογα με το ποιος τη διάβαζε. Πριν καν μπορέσετε να συνθέσετε ένα πακέτο εργασιών αλλαγής (ένα Sprint), έπρεπε πρώτα να συγχρονίσετε όλη αυτή την κατακερματισμένη γνώση.
Ανθρωποκεντρικές εκτιμήσεις εργασιών
Κάθε εργασία αλλαγής έφερε μια ανθρωποκεντρική εκτίμηση (story points) που δεν έπαιζε κανέναν ρόλο μόλις τη δουλειά την έκανε ένας πράκτορας. Ένας πράκτορας δεν χρειάζεται εκτίμηση story points για να ξεκινήσει. Αυτό που απέμενε ήταν μια τελετουργία σχεδιασμού: κατανομή εργασιών και ξεδιάλυμα εξαρτήσεων μεταξύ εργασιών ή ομάδων, μια προσπάθεια που υπήρχε μόνο επειδή οι εργασίες είχαν διαστασιολογηθεί για ανθρώπους, όχι για πράκτορες.
Αντίστροφη μηχανική της υπάρχουσας κατάστασης
Μια εργασία αλλαγής περιγράφει τη διαφορά μεταξύ μιας υπάρχουσας και μιας επιθυμητής κατάστασης. Αυτό ανάγκαζε τον πράκτορα κωδικοποίησης να κάνει πρώτα αντίστροφη μηχανική της υπάρχουσας κατάστασης, πριν καν μπορέσει να ενεργήσει πάνω στη διαφορά. Λόγω των τρεχόντων περιορισμών των LLM, μερικές φορές αυτή η ανακατασκευή γινόταν λανθασμένη ή ελλιπής, και το προϊόν άλλαζε με τρόπους που δεν είχατε ζητήσει.
Απόκλιση ερμηνείας
Κάθε εργασία αλλαγής ήταν γραμμένη σε φυσική γλώσσα, γεγονός που έφερε τον κίνδυνο απόκλισης ερμηνείας: το χάσμα ανάμεσα στη συμπεριφορά του domain που σκοπεύατε και στη συμπεριφορά που τελικά υλοποιήθηκε, που προκαλείται από απώλεια πληροφορίας ή ασάφεια. Λόγω των τρεχόντων περιορισμών των LLM, η ίδια εργασία δοσμένη στον ίδιο πράκτορα μπορούσε να παράγει διαφορετικό κώδικα κάθε φορά, και και πάλι το προϊόν άλλαζε με τρόπους που δεν είχατε ζητήσει.
Spec-Driven Development
Για να το διορθώσουν αυτό, οι ομάδες υιοθετούν ένα από τα πλαίσια Spec-Driven Development (SDD): αρχεία προδιαγραφών, γραμμένα σε φυσική ή μεικτή φυσική και τυπική γλώσσα, γραμμένα πριν την κωδικοποίηση, γίνονται η είσοδος για τον πράκτορα. Υπάρχει μια σύγκριση 15 πλαισίων Spec-Driven Development που τα κατατάσσει σε τρία επίπεδα.
Επίπεδο 1 · Spec-First
Αντιμετωπίζουν την προδιαγραφή ως προκαταρκτικό συμβόλαιο ή επιστολή πρόθεσης.
GitHub Spec Kit, Superpowers, Behavioral Meta-Architectural Design, Goal-Driven Development, SpecSwarm
Επίπεδο 2 · Spec-Anchored
Διατηρούν την προδιαγραφή ως ζωντανό έγγραφο καθ' όλη τη διάρκεια του κύκλου ζωής του έργου.
MUSUBI, Intent, OpenSpec
Επίπεδο 3 · Spec-as-Source
Υλοποιούν μια ρύθμιση μηδενικής απόκλισης όπου το αρχείο προδιαγραφών είναι η απόλυτη μοναδική πηγή αλήθειας.
Tessl, Contractual Specification-Driven Development
Σύγκριση 15 πλαισίων Spec-Driven Development
Δοκιμάσαμε αυτόν τον δρόμο. Τα αρχεία προδιαγραφών βοήθησαν πράγματι να συγκεντρωθεί η γνώση σε ένα μέρος, να περιγραφεί η υπάρχουσα και η επιθυμητή κατάσταση και να μειωθεί η απόκλιση ερμηνείας. Όμως το αρχείο προδιαγραφών παρέμενε ένα ακόμη έγγραφο που ζούσε στο αποθετήριο κώδικα, χρειαζόμενο τον δικό του συγχρονισμό με τα υπόλοιπα τεχνουργήματα του προϊόντος. Και οι επιχειρησιακοί ενδιαφερόμενοι εξακολουθούσαν να μην μπορούν να συνεργαστούν σε ένα αρχείο προδιαγραφών: η κατακερματισμένη γνώση ανάμεσα σε τεχνικούς και μη τεχνικούς ανθρώπους παρέμενε ανεπίλυτη.
Έτσι φτιάξαμε το StormPilot για να αντιμετωπίσουμε και τα τέσσερα προβλήματα ταυτόχρονα.
Event Storming
Το EventStorming είναι μια χαμηλής πιστότητας συνεργατική τεχνική εργαστηρίου που επινοήθηκε από τον Alberto Brandolini για τη διερεύνηση σύνθετων επιχειρηματικών διαδικασιών ως χρονοδιάγραμμα επαναλαμβανόμενων στοιχείων. Το EventStorming δεν προοριζόταν να είναι ψηφιακό εργαλείο. Ο κύριος σκοπός του είναι η συλλογική μάθηση: επιχειρηματικοί και τεχνικοί ειδικοί ανακαλύπτουν και συζητούν πώς λειτουργεί ένας τομέας. Ο πίνακας είναι σκόπιμα ελαφρύς και απτικός, επιτρέποντας στους συμμετέχοντες να προσθέτουν, μετακινούν, ομαδοποιούν, αμφισβητούν και απορρίπτουν στοιχεία γρήγορα. Το φυσικό μέσο των αυτοκόλλητων σημειώσεων αποτελεί μέρος της μεθόδου. Ο συμβολισμός δεν προορίζεται να είναι μια αυστηρή επίσημη γλώσσα μοντελοποίησης.
Δομημένο Event Storming
Το StormPilot παραμένει σε μεγάλο βαθμό πιστό στις έννοιες του Event Storming. Αποφεύγει την ορολογία CQRS χρησιμοποιώντας "View" αντί για "Read Model", "Action" αντί για "Command", "Rule" αντί για "Policy". Προσθέτει το "Term" ως ρητό στοιχείο για τη διατήρηση ενιαίας γλώσσας τομέα. Το δομημένο Event Storming μετατρέπει την τεχνική εκμάθησης σε σύστημα προδιαγραφών. Ενσωματώνει επίσημους συμβολισμούς απευθείας στα στοιχεία για να μειώσει την απόκλιση ερμηνείας: το χάσμα μεταξύ αυτού για το οποίο είναι υπεύθυνος ένας τομέας και αυτού που τελικά κατασκευάζεται, που προκαλείται από χαμένη ή ασαφή πληροφορία. Η προκύπτουσα προδιαγραφή λογισμικού λειτουργεί ως ντετερμινιστική είσοδος για την πρακτορική δημιουργία κώδικα, επιτρέποντας στη γνώση του τομέα να οδηγεί αλλαγές στο προϊόν λογισμικού που παραδίδεται την επόμενη ημέρα.
Βοήθεια AI
Ο βοηθός AI διαβάζει το πραγματικό σας μοντέλο domain και προτείνει συγκεκριμένες διορθώσεις: βελτιώσεις ονοματοδοσίας, στοιχεία που λείπουν, ορισμούς ρόλων, κενά ροής, διευκρινίσεις περιορισμών. Δεχτείτε ό,τι είναι χρήσιμο, απορρίψτε τα υπόλοιπα.
Εκδοχοποίηση
Μια εργασία ως αυτόνομο τεχνούργημα διαχείρισης έργου δεν έχει νόημα σε έναν πολυπρακτορικό SDLC ή σε μια οικονομία tokens. Οι αλλαγές στη γνώση που καταγράφεται σε ένα διάγραμμα δομημένο Event Storming αντιστοιχίζονται απευθείας σε αλλαγές στο προϊόν που θέλουμε να κυκλοφορήσουμε. Γι' αυτό το StormPilot αντικαθιστά τις εργασίες και τα πακέτα εργασιών με εκδοχοποίηση προϊόντος. Έτσι λύνονται οι ανθρωποκεντρικές εκτιμήσεις εργασιών και η αντίστροφη μηχανική της υπάρχουσας κατάστασης.
Συχνές ερωτήσεις
Χρειάζεται να πληρώσω για να το δοκιμάσω;
Όχι. Το Demo είναι ένα δωρεάν, δημόσιο sandbox χωρίς εγγραφή και με όλους τους ρόλους διαθέσιμους. Επαναφέρεται καθημερινά και έχει όριο 5 domains, 2 εκδόσεις το καθένα.
Τι είναι μια έκδοση domain;
Ένας Facilitator μπορεί να παγώσει την τρέχουσα κατάσταση ενός διαγράμματος ως έκδοση. Οι εκδόσεις είναι αμετάβλητες, με χρονοσφραγίδα και μόνο για ανάγνωση.
Τι εξάγει;
Το StormPilot εξάγει User Interface, Application Programming Interface, μοντέλο δεδομένων και σενάρια Behavior.
Γράφει κώδικα η AI;
Όχι. Η AI του StormPilot καθορίζει ΤΙ να κωδικοποιηθεί: το μοντέλο domain και τη συμπεριφορά του. Ο τεχνολογικός στοίβα παραμένει απόφαση της ομάδας μηχανικών.
Γιατί OpenRPC;
Οι επιχειρηματικές Actions ξεπερνούν τη σημασιολογία του REST. Το OpenRPC ταιριάζει ακριβώς με τον συμβολισμό του Event Storming, αποφεύγει την ερμηνευτική απόκλιση και παραμένει ανεξάρτητο πρωτοκόλλου.
Γιατί Gherkin;
Το Given/When/Then αντικατοπτρίζει τα Event Storming Rules και αποφεύγει την ερμηνευτική απόκλιση, καθώς υποστηρίζεται άμεσα από το οικοσύστημα εργαλείων BDD.
Γιατί PlantUML;
Το Event Storming είναι εγγενώς οπτικό, και το PlantUML το διατηρεί κατά την εξαγωγή. Η σύνταξη υποστηρίζεται άμεσα από το οικοσύστημα εργαλείων.
Γιατί SSE;
Τα Events ρέουν μόνο προς μία κατεύθυνση, οπότε η πολυπλοκότητα των WebSockets μένει αχρησιμοποίητη. Το Server-Sent Events παραμένει απλό HTTP και επανασυνδέεται αυτόματα.