Refinement z AI: jak przygotować wymagania do Spec Driven Development
AI potrafi przyspieszyć implementację, ale jakość rezultatu nadal zależy od tego, co zespół poda mu na wejściu. Jeśli wymagania są niejasne, kontekst jest rozproszony, a oczekiwany efekt istnieje głównie „w głowie” Product Ownera lub programisty, model zacznie uzupełniać luki własnymi założeniami.
Dlatego przy pracy w podejściu Spec Driven Development coraz większego znaczenia nabiera refinement. To właśnie na tym etapie zespół powinien doprowadzić wymagania do takiego poziomu, żeby dało się z nich zbudować jednoznaczną specyfikację, a następnie sprawdzić, czy wszyscy rozumieją ją tak samo.
W jednym z naszych zespołów refinement zaczął zajmować około 30% czasu sprintu. Pojawiła się też hipoteza, że z czasem może zająć nawet połowę pracy zespołu. Nie dlatego, że implementacja stała się trudniejsza. Wręcz przeciwnie. Im szybciej AI potrafi przejść od specyfikacji do działającego rozwiązania, tym większą część pracy warto przenieść wcześniej, do przygotowania właściwego problemu, kontekstu i oczekiwanego zachowania systemu.
Czym refinement różni się przy Spec Driven Development?
W klasycznym procesie refinement często służy doprecyzowaniu backlogu przed rozpoczęciem implementacji. Zespół omawia zakres zadania, zależności, kryteria akceptacji i potencjalne ryzyka.
Przy Spec Driven Development dochodzi dodatkowy cel: trzeba przygotować taki opis problemu i rozwiązania, który może stać się wiarygodnym wejściem dla AI.
To zmienia charakter refinementu. Nie wystarczy ustalić, że „wiadomo mniej więcej, o co chodzi”. Specyfikacja musi ograniczyć przestrzeń interpretacji na tyle, żeby model nie musiał zgadywać:
- jakie zachowanie biznesowe jest oczekiwane,
- jakie przypadki należy obsłużyć,
- z jakich istniejących komponentów można korzystać,
- które decyzje zostały już podjęte,
- jakie ograniczenia techniczne obowiązują,
- jak ma wyglądać efekt końcowy.
Dobra specyfikacja nie powstaje jednak z jednego promptu. Potrzebuje uporządkowanego kontekstu, rozmowy zespołu i kilku etapów weryfikacji.
Poniżej proces, który można potraktować jako punkt wyjścia.
1. Zacznij od wiedzy o produkcie, nie od user story
Najpierw warto upewnić się, że informacje potrzebne do przygotowania zadania istnieją w miejscu, do którego można wrócić.
Może to być baza wiedzy, dokumentacja produktu, wiki albo graf wiedzy. Narzędzie ma drugorzędne znaczenie. Ważne, żeby wiedza była:
- aktualna,
- możliwa do powiązania z konkretnymi funkcjami,
- dostępna dla zespołu,
- wystarczająco granularna, żeby można było pobrać tylko potrzebny fragment kontekstu.
W jednym z naszych zespołów taki zasób był prowadzony w Obsidianie. Zawierał informacje o istniejącym systemie, planowanych zmianach, rozmowach z użytkownikami i decyzjach produktowych. Początkowo opiekowała się nim jedna osoba, ale wraz ze wzrostem projektu okazało się, że utrzymywanie go przez pojedynczego „kustosza” nie skaluje się. Odpowiedzialność zaczęła więc przechodzić na cały zespół.
To ważne także z perspektywy AI. W tym samym projekcie samo załadowanie grafu wiedzy potrafiło zajmować około jednej czwartej lub jednej trzeciej dostępnego kontekstu sesji. Zespół zaczął więc porządkować informacje na mniejszych, powiązanych ze sobą stronach i bardziej świadomie decydować, co rzeczywiście powinno trafić do modelu.
Co sprawdzić u siebie?
Zanim przygotujesz zadanie, odpowiedz na trzy pytania:
- Gdzie znajduje się źródło prawdy o tej części produktu?
- Czy informacje są aktualne i niesprzeczne?
- Czy AI musi dostać całą dokumentację, czy tylko jej konkretny fragment?
Im więcej zbędnego kontekstu trafia do modelu, tym większe ryzyko, że zacznie opierać odpowiedź na informacjach, które nie mają znaczenia dla zadania.
2. Opisz zachowanie biznesowe w scenariuszach
Kolejny krok to przełożenie wiedzy o produkcie na konkretne zachowania.
Zamiast od razu pisać długi opis funkcji, warto opisać scenariusze: co robi użytkownik, w jakiej sytuacji i jaki efekt powinien otrzymać.
Jednym ze sposobów jest Gherkin, czyli format oparty na strukturze typu:
- Given
- When
- Then
Jego wartość polega na tym, że jest czytelny dla człowieka, a jednocześnie łatwo można przełożyć go na testy automatyczne.
W analizowanym przez nas procesie scenariusze biznesowe były jednym z podstawowych artefaktów. Dzięki temu ta sama reprezentacja pomagała utrzymywać wspólne zrozumienie funkcji, dokumentować zachowanie systemu i później tworzyć testy.
Przykładowo:
Given użytkownik należy do kilku grup
When otrzymuje powiadomienie mailowe
Then powinien od razu rozpoznać, która grupa jest nadawcą wiadomości
Taki zapis nie rozwiązuje jeszcze wszystkich szczegółów. Daje jednak zespołowi dużo lepszy punkt wyjścia niż ogólne „oznaczmy nadawcę powiadomienia”.
Co sprawdzić u siebie?
Dla każdego scenariusza zadajcie pytania:
- Jaki problem użytkownika rozwiązujemy?
- Jakie jest oczekiwane zachowanie?
- Jakie wyjątki mogą się pojawić?
- Co musi pozostać bez zmian?
- Jak rozpoznamy, że funkcja działa poprawnie?
Jeśli na część z tych pytań nie ma odpowiedzi, właśnie tam znajduje się materiał do refinementu.
3. Zamień kontekst biznesowy w prostą historyjkę
Po uporządkowaniu scenariuszy można przygotować zadanie w backlogu.
Warto opierać je na jak najmniejszej liczbie informacji, które są potrzebne do zrozumienia celu, a resztę kontekstu linkować do źródeł wiedzy.
W jednym z naszych zespołów do Jiry trafiała stosunkowo krótka user story wraz z linkami do bazy wiedzy. Dzięki temu backlog nie stawał się kolejną kopią całej dokumentacji. Zadanie wskazywało, co należy osiągnąć, a szczegółowy kontekst był dostępny w powiązanych materiałach.
To ważne także przy pracy z agentami. Im lepiej oddzielisz:
- cel zadania,
- kontekst biznesowy,
- ograniczenia,
- specyfikację rozwiązania,
tym łatwiej kontrolować, który fragment informacji powinien zostać użyty w danym kroku.
Co sprawdzić u siebie?
Dobra historyjka powinna pozwolić odpowiedzieć na pytania:
- kto ma problem,
- co chce osiągnąć,
- dlaczego to jest ważne,
- gdzie znaleźć potrzebny kontekst,
- co jest poza zakresem.
Jeśli historyjka próbuje pomieścić całą wiedzę o funkcji, prawdopodobnie zaczyna mieszać poziomy informacji.
4. Sprawdź historyjkę z kilku perspektyw
To jeden z bardziej praktycznych sposobów wykorzystania AI przed właściwą implementacją.
Zamiast pytać model wyłącznie „czy ta user story jest dobra?”, można oceniać ją z perspektywy konkretnych odbiorców.
W jednym z naszych procesów przed wysłaniem zadania do Jiry uruchamiani byli dodatkowi agenci sprawdzający, czy opis jest zrozumiały z kilku punktów widzenia. Jedna perspektywa odpowiadała programiście, inna osobie wspierającej refinement, kolejna stakeholderowi biznesowemu, a jeszcze inna osobie przygotowującej wymagania.
Czasem potrzeba było dwóch lub trzech iteracji, zanim zadanie zostało zaakceptowane przez wszystkie perspektywy.
To ciekawy przykład wykorzystania agentów jako adwersarzy. Ich rolą nie jest generowanie większej ilości treści. Mają znaleźć luki.
Można zadawać im pytania takie jak:
- Czego nie zrozumie programista, który nie uczestniczył w rozmowie z klientem?
- Jakie decyzje pozostają domyślne?
- Które kryterium może zostać zinterpretowane na więcej niż jeden sposób?
- Jakiej informacji potrzebuje stakeholder, żeby zrozumieć biznesowy efekt zmiany?
- Czy opis zawiera informacje spoza specyfikacji?
Co sprawdzić u siebie?
Spróbujcie przepuścić jedno zadanie przez trzy role:
Programista: Czy wiem, co mam zbudować i czego nie wiem?
Product Owner: Czy rezultat odpowiada potrzebie biznesowej?
Stakeholder: Czy rozumiem, jaką wartość daje ta zmiana?
Jeśli każda rola identyfikuje inne luki, refinement zaczyna pełnić właściwą funkcję.
5. Wygeneruj makiety przed rozpoczęciem implementacji
Jednym z najskuteczniejszych sposobów sprawdzania wspólnego zrozumienia jest pokazanie rozwiązania.
Opis tekstowy może zostać odczytany na kilka sposobów. Makieta szybko ujawnia różnice w interpretacji.
W jednym z naszych projektów programista podczas refinementu przygotowywał z pomocą AI makiety high-fidelity. Powstawały one na podstawie istniejącego kodu i design systemu. Model korzystał z komponentów aplikacji oraz danych z Figmy, dzięki czemu makieta była możliwie bliska rzeczywistemu interfejsowi. W jednym z omawianych przykładów powstało 12 wariantów desktopowych i mobilnych.
Takie podejście ma kilka zalet.
Po pierwsze, Product Owner może szybciej zauważyć, że jego intencja została zrozumiana inaczej.
Po drugie, programista musi skonfrontować opis wymagania z konkretnym interfejsem i zachowaniem.
Po trzecie, AI otrzymuje później dodatkową reprezentację oczekiwanego rezultatu.
Makieta pełni więc funkcję narzędzia komunikacji i walidacji.
Co sprawdzić u siebie?
Nie pytajcie wyłącznie: „Czy ten ekran wygląda dobrze?”.
Sprawdźcie:
- czy pokazuje właściwy stan systemu,
- czy uwzględnia najważniejsze scenariusze,
- czy wykorzystuje istniejące komponenty,
- czy zachowanie odpowiada wymaganiom,
- czy nie wprowadza przypadkiem nowych decyzji produktowych.
Makieta nie powinna samodzielnie rozszerzać zakresu zadania.
6. Zbuduj specyfikację w repozytorium
W Spec Driven Development specyfikacja jest centralnym artefaktem.
Powinna znaleźć się możliwie blisko kodu, tak aby można było ją wersjonować, reviewować i powiązać z konkretną zmianą.
W omawianym przez nas procesie specyfikacja była zapisywana w repozytorium na branchu powiązanym z zadaniem. Dzięki temu zespół wiedział:
- gdzie ją znaleźć,
- z jaką zmianą jest związana,
- kto nad nią pracował,
- jaka wersja specyfikacji odpowiada konkretnej implementacji.
To daje sporą przewagę nad specyfikacją trzymaną wyłącznie w narzędziu do zarządzania zadaniami. Repozytorium pozwala objąć ją tym samym procesem kontroli zmian co kod.
Co powinna zawierać dobra specyfikacja?
Zakres zależy od projektu, ale zazwyczaj warto uwzględnić:
- cel biznesowy,
- oczekiwane zachowania,
- scenariusze,
- ograniczenia,
- komponenty, które należy wykorzystać,
- interfejsy i zależności,
- makiety lub odnośniki do nich,
- wymagania niefunkcjonalne,
- przypadki brzegowe,
- sposób weryfikacji.
Jeśli model ma podejmować decyzję samodzielnie, dobrze określić jej granice.
Przykład:
Użyj istniejącego komponentu powiadomień.
Nie twórz nowego wariantu komponentu, jeśli obecny spełnia wymagania.
Zachowaj istniejące API.
Dodaj jedynie informację o nazwie grupy.
To znacznie ogranicza ryzyko, że AI „ulepszy” system poza zakresem zadania.
7. Poproś programistę, żeby wyjaśnił rozwiązanie własnymi słowami
To jeden z najważniejszych etapów całego procesu.
Można mieć dobrą user story, makiety i specyfikację wygenerowaną przez AI, a nadal nie mieć pewności, czy osoba odpowiedzialna za zadanie rzeczywiście rozumie rezultat.
Dlatego podczas refinementu programista powinien własnymi słowami opowiedzieć:
- jaki problem rozwiązuje,
- jak ma zachować się system,
- jak zamierza to zbudować,
- gdzie widzi ryzyka,
- jakie decyzje już zostały podjęte.
W jednym z naszych zespołów to właśnie ten moment stał się podstawą refinementu. Programista pokazywał makiety i opowiadał o rozwiązaniu. Osoba odpowiedzialna za produkt mogła wtedy od razu sprawdzić, czy proponowana zmiana odpowiada jej intencji.
Ta rozmowa pełni dodatkową funkcję: ogranicza ryzyko, że programista stanie się jedynie pośrednikiem między kolejnymi agentami AI.
Nie da się przekonująco mówić ze zrozumieniem o czymś, czego się nie rozumie. Refinement daje więc przestrzeń do sprawdzenia, czy człowiek nadal kontroluje rozwiązanie, za które bierze odpowiedzialność.
8. Dopiero wtedy uruchom implementację
Jeśli wcześniejsze etapy zostały wykonane dobrze, implementacja powinna stać się znacznie bardziej przewidywalna.
Model otrzymuje:
- potrzebny kontekst,
- konkretne scenariusze,
- zweryfikowaną user story,
- ograniczenia,
- makiety,
- specyfikację,
- wskazanie istniejących komponentów,
- kryteria sprawdzenia rezultatu.
Dzięki temu zamiast „wymyślać rozwiązanie” może wykonać znacznie bardziej ograniczone zadanie.
To jest jedna z podstawowych różnic między chaotycznym vibe codingiem a inżynierskim wykorzystaniem AI. W pierwszym przypadku model dostaje ogólny cel i dużą swobodę. W drugim jego pole działania jest kontrolowane przez specyfikację, architekturę, standardy i proces review.
Dlaczego refinement może zajmować więcej czasu niż wcześniej?
To może wydawać się paradoksalne.
AI ma przyspieszać pracę, a zespół zaczyna poświęcać więcej czasu na spotkania i przygotowanie?
W jednym z naszych zespołów refinement zajmował już około 30% czasu sprintu. Pojawiło się założenie, że z czasem może dojść nawet do około 50%. Co ciekawe, sami programiści zaczęli zgłaszać potrzebę większej liczby takich spotkań, mimo że kilka miesięcy wcześniej narzekali na ich nadmiar.
Powód jest prosty.
Jeśli implementacja wymagała kilku dni, a refinement kilku godzin, główny koszt pracy znajdował się po stronie kodowania.
Jeśli AI skraca implementację do kilku godzin, relacja się zmienia. Przygotowanie właściwego zadania zaczyna zajmować proporcjonalnie większą część całego cyklu.
To nie oznacza, że każdy zespół powinien dążyć do 50% czasu na refinement. Ta liczba pochodzi z konkretnego projektu i była przewidywaniem dotyczącym jego dalszego sposobu pracy.
Warto natomiast obserwować inną rzecz: ile czasu traci zespół przez niewystarczająco przygotowane zadania?
Jeśli po rozpoczęciu implementacji regularnie trzeba wracać do Product Ownera, poprawiać specyfikację, zmieniać makiety albo prostować założenia modelu, część tej pracy prawdopodobnie warto przesunąć wcześniej.
Jak może wyglądać cały refinement z AI?
W praktyce proces można sprowadzić do takiego przepływu:
Wiedza o produkcie → scenariusze biznesowe → user story → weryfikacja przez agentów → makiety → specyfikacja → wspólny refinement → implementacja
Każdy etap ma inne zadanie.
Wiedza o produkcie dostarcza kontekstu.
Scenariusze opisują oczekiwane zachowanie.
User story wyznacza cel zmiany.
Agenci weryfikujący szukają luk i niejasności.
Makiety pozwalają szybko zobaczyć rezultat.
Specyfikacja zamienia ustalenia na precyzyjne wejście dla AI.
Refinement zespołowy sprawdza wspólne zrozumienie.
Implementacja wykorzystuje przygotowane wcześniej ograniczenia.
To ważne, ponieważ każdy z tych artefaktów powinien pełnić inną funkcję. Jeśli jeden dokument próbuje być jednocześnie wymaganiem biznesowym, instrukcją techniczną, specyfikacją UI i historią decyzji produktowych, szybko staje się trudny do utrzymania.
Od czego zacząć we własnym zespole?
Nie trzeba od razu budować całego procesu z grafem wiedzy, agentami i automatycznym generowaniem makiet.
Na początek można wprowadzić trzy proste zasady:
- Przed implementacją opisujcie oczekiwane zachowanie w konkretnych scenariuszach.
- Poproście programistę o przygotowanie specyfikacji i pokazanie jej podczas refinementu.
- Nie rozpoczynajcie implementacji, dopóki osoba odpowiedzialna za zadanie nie potrafi własnymi słowami wyjaśnić, co ma powstać i dlaczego.
Dopiero później warto automatyzować kolejne elementy: generowanie makiet, sprawdzanie historyjek przez agentów, pobieranie właściwego kontekstu czy tworzenie specyfikacji w repozytorium.
Najważniejsze jest zachowanie właściwej kolejności. AI może przyspieszyć wykonanie decyzji, ale zespół nadal musi świadomie przygotować tę decyzję i sprawdzić jej zrozumienie.
Właśnie dlatego w Spec Driven Development refinement zaczyna być jednym z najważniejszych etapów pracy. Im szybciej można zbudować rozwiązanie, tym bardziej opłaca się upewnić wcześniej, że budujemy dokładnie to, czego potrzebujemy.
Chcesz zobaczyć ten proces na konkretnym przykładzie?
W webinarze „Dlaczego AI nie zwiększyło efektywności IT w Twojej firmie?” pokazujemy między innymi graf wiedzy, scenariusze Gherkin, user stories w Jirze, makiety generowane na podstawie istniejących komponentów oraz sposób pracy ze specyfikacją w repozytorium. Opowiadamy też o problemach, które pojawiły się podczas wdrażania tego procesu i zmianach, które wprowadzaliśmy po kolejnych iteracjach.
Sprawdź, czy Twój proces przygotowania produktu jest gotowy na pracę z AI
Dobra specyfikacja zaczyna się wcześniej niż w repozytorium. Znaczenie ma także to, jak zespół przygotowuje backlog, waliduje rozwiązania i wykorzystuje informacje od klientów.
Przejdź z zespołem przez Product Health Checklist i sprawdź, które elementy procesu produktowego warto uporządkować przed dalszym rozwijaniem Spec Driven Development.
POBIERZ PRODUCT HEALTH CHECKLIST
