Vibe coding wkroczył nie tylko do sfery oprogramowania. W jednym z poprzednich wpisów argumentowałem, że w obszarze zespołów projektowych IT nastąpią redukcje wskutek rosnącej produktywności, spadających kosztów i rosnącej dostępności kodu. Rolą, która moim zdaniem wygra jest analityk biznesowy. Więcej o tym możecie przeczytać tutaj link

Dzisiaj znajomy dołożył cegiełkę potwierdzającą moją tezę o nazwie Specification Driven Development SDD.

SDD to framework, który moim zdaniem ma szansę urosnąć do nowej metodyki pracy w zespołach IT i jest całkowicie oparty na vibe-codingu. Podstawą jest integracja środowiska do czatu z edytorem kodu takim, jak VS Code.

Analityk nie zaczyna jednak od tworzenia funkcji, a od spisania specyfikacji. Prekonfigurowani agenci prowadzą rozmowę przez kolejne etapy tworzenia dokumentacji wymagań. Z grubsza kroki pracy są takie:

    1. Zdefiniowanie konstytucji.
    2. Spisanie wymagań.
    3. Doszczegółowienie wymagań.
    4. Walidacja wymagań.
    5. Zdefiniowanie planu technicznego.
    6. Zaplanowanie zadań.
    7. Wykonanie rozwiązania.

Jak widać 6 z 7 kroków dotyczy specyfikowania. Zakłada się, że samo kodowanie i testowanie może być autonomiczne, o ile mamy dobrą specyfikację. Co więcej rozwiązanie może być niezależne od technologii. To znaczy, że z tej samej specyfikacji dzisiaj możemy wygenerować aplikację WWW, a jutro na iPhone. Trzeba tylko wyedytować plik konstytucji.

Aby przejść od kroku do kroku, zmieniając tryb działania agentów, wystarczy wpisać polecenie, np. speckit.checklist, albo speckit.clarify.

Konstytucja

Centralnym dokumentem sterującym procesem specyfikacji i produkcji oprogramowania jest konstytucja. Na czacie wywołujemy po prostu polecenie /speckit.consitution i czat rozpoznaje, że teraz zamierzamy definiować konstytucję właśnie. Jest to definicja architektury systemu, zasad stosowanych w pisaniu kodu, zasad dokumentowania, walidowania, ewentualnie założonej struktury rozwiązania w wymiarze danych, Wszystko, co dotyczy całościowo rozwiązania i powinno być zawsze przestrzegane.

SDD zakłada, że to specyfikacja przede wszystkim żyje, podlega wersjonowaniu, zarządzaniu, przeglądom. Późniejsze generowanie systemu i jego testowanie działa niezależnie.

Zasady SDD

(cytat z metodyki)

Specyfikacje jest centralnym punktem wiedzy o rozwiazaniu, nie kod, ani nie jego dokumentacja. Specyfikacja jest podstawowym artefaktem. Kod staje się jego wyrazem w określonym języku i frameworku. Utrzymywanie oprogramowania oznacza utrzymywanie specyfikacji.

To specyfikacje są wykonywalne. Zatem muszą być precyzyjne, kompletne i wystarczająco jednoznaczne, aby generować działające systemy. Eliminuje to lukę między intencją a implementacją.

Ciągłe udoskonalanie: Walidacja spójności odbywa się w sposób ciągły, a nie jako jednorazowa bramka. Sztuczna inteligencja analizuje specyfikacje pod kątem niejednoznaczności, sprzeczności i luk w ramach ciągłego procesu. Pozwól AI działać.

Kontekst oparty na badaniach: Agenci badawczy gromadzą krytyczny kontekst w całym procesie specyfikacji, badając opcje techniczne, implikacje dla wydajności i ograniczenia organizacyjne. Tu pojawia się odniesienie do product discovery, innymi słowy intencje powinny być ugruntowane w danych na temat potrzeb klienta.

Dwukierunkowe sprzężenie zwrotne: Rzeczywistość produkcyjna wpływa na ewolucję specyfikacji. Metryki, incydenty i wnioski operacyjne stają się danymi wejściowymi do udoskonalania specyfikacji. Innymi słowy AI też buduje specyfikację na podstawie tworzonego kodu i rozmowy z człowiekiem.

Rozgałęzianie dla eksploracji: Generowanie wielu podejść wdrożeniowych na podstawie tej samej specyfikacji w celu eksploracji różnych celów optymalizacji — wydajności, łatwości utrzymania, doświadczenia użytkownika i kosztów. Znowu odniesienie do product discovery, bowiem, co stoi na przeszkodzie, aby rozdzielić specyfikację na dwa warianty i stworzyć dwa systemy, a potem sprawdzić, który lepiej klika.

Zalecenia SDD

Pisz wprost - jednoznacznie opisuj, co ma robić system i z jakiego powodu.

Nie skupiaj się na technologii - nie opisuj, jak coś ma być zaimplementowane. W kroku 7 możesz wrócić do kwestii technicznych, ale to niech AI za ciebie rozwiąże problemy.

Iteruj i dopracuj specyfikacje przed wdrożeniem. Lepiej długo czatować na temat wymagań i potem szybko zakodować. (trochę odwrócenie paradygmatu zwinności).

Zweryfikuj plan przed rozpoczęciem kodowania. (jak widać SDD mocno zaznacza potrzebę kaskadowego etapowania, ale etapy nie trwają tygodni tylko godziny)

Pozwól agentowi ds. kodowania zająć się szczegółami implementacji.

BMAD Method

Drugim alternatywnym frameworkiem w tym nurcie jest BMAD. Build More Architect Dreams, bo tak rozwija się ten skrót, to trochę bardziej rozbudowana i usztywniona wersja Spec Kit. Zakładam, że adresowana do większych rozwiązań. Również integruje się z Code i również polega na czatowaniu z użyciem poleceń (narzędzi). Więcej o BMAD napiszę w innym wpisie.

Linki

Spec Kit Jak zacząć ze Spec Kit BMAD Method Artykuł na temat SDD

Post scriptum

Tylko czekam, aż pojawi się SDD Alliance, a potem program certyfikacji SDD na poziomach Entry, Professional, Architect. A około roku 2035 nawet PMI zorientuje się, że warto włączyć SDD do PMBOK Guide 10.

Oprócz potwierdzenia roli analityka, SDD potwierdza jeszcze jedną moją tezę, że centralnym interfejsem użytkownika będzie czat z narzędziami i pamięcią. Żadnych tablic Kanban, Ganttów, budżetów, backlogów, CR. Tylko czat i ciągle żyjące repozytorium specyfikacji!

Zobaczcie też, że znika w ogóle idea Scrum Mastera, czyli kogoś, kto rozumie metodykę. To rolę w Spec Kit całkowicie przejmuje agent, który prowadzi człowieka przez kroki dialogu.

Wróć do wszystkich artykułów