Od potrzeby do demo

U nas zadanie zaczyna się od realnych użytkowników. Product Owner (PO), czyli osoba odpowiedzialna za produkt, zbiera zapotrzebowanie na funkcje i słucha, z czym ludzie mają problem. Zanim przekaże zmianę do wykonania, razem z ekspertem dziedzinowym i z pomocą brAIn analizuje, jak dany obszar działa i jak powinien działać.

PO rozpoznaje potrzebę i przekazuje zadanie

Z tej analizy powstaje zadanie w Jira, na tablicy kanbanowej — tablicy pokazującej przepływ pracy. PO przypisuje je osobie, która może mieć najwięcej wiedzy o obszarze objętym zmianą. Znajomość reguł i zależności przydaje się także wtedy, gdy kod piszą agenci.

Zadania biznesowe odbiera PO. Potrzeby techniczne prowadzi AI Engineer, czyli osoba realizująca zmianę z pomocą agentów. W obu przypadkach człowiek odpowiada za to, co powstaje.

AI Engineer prowadzi zmianę z agentami

AI Engineer bierze zadanie i realizuje je z agentami. Prowadzi funkcję przez potrzebne ekrany, logikę i dane. Kiedy większa zmiana jest już na tyle gotowa, żeby przejść jej scenariusz, robimy Live Demo i zbieramy uwagi. Mniejsze zadanie może szybciej trafić do sprawdzenia na QA, a potem na UAT — środowiska testów i odbioru opisuję w kolejnym rozdziale.

Wielkość zadania zmienia zakres pokazu, ale człowiek zawsze powinien zobaczyć, co zrobiło AI. To dotyczy zarówno pracy samodzielnej w One Man Army, jak i AI Engineera w zespole. Nie chcę pracować z agentem na autopilocie: jego komunikat „gotowe” nie jest jeszcze moim sprawdzeniem wyniku.

Jak prowadzę Live Demo

Proszę agenta, żeby przez Playwright pokazał mi przejście przez aplikację. W Codexie prowadzę taki pokaz głosowo. Widzę działanie i mogę zatrzymać się dokładnie tam, gdzie coś mi nie pasuje.

Mówię na przykład: „Stój, tutaj mam uwagę. Dodaj ją do dziennika uwag” albo „To popraw już teraz”. Nie każda uwaga musi przerywać cały pokaz. Część zapisujemy, część poprawiamy od razu i wracamy do tego samego miejsca.

Po demo zostaje lista uwag. Agent wprowadza poprawki porządnie i sprawdza ich działanie. Przy drobnych zmianach robię jeszcze szybki przegląd. Przy większych proszę o ponowne demo, z naciskiem na to, co poprawiliśmy. Chcę zobaczyć rezultat, zanim uznam temat za zakończony.

Zobacz pełny przebieg demo i prompt w One Man Army.

Przy pracy równoległej sprawdźcie, gdzie się spotykacie

Dzielcie się całymi funkcjami, możliwie daleko od siebie w aplikacji. Przed uruchomieniem agentów sprawdźcie, czy zadania nie zmieniają tego samego formularza, reguły lub danych. Gdy zakresy się spotykają, ustalcie, kto prowadzi wspólny fragment i w jakiej kolejności druga osoba uwzględni wynik.

Każda osoba potrzebuje osobnej gałęzi — roboczej wersji kodu — i katalogu pracy agenta. Osobne miejsca pracy chronią przed edytowaniem sobie plików, ale zgodność zmian trzeba jeszcze sprawdzić. Po połączeniu przejdźcie scenariusz obejmujący obie części. Szerszy wzór ustaleń jest w karcie zadania poniżej.

Demo uzupełnijcie testami i niezależnym przeglądem

Oglądanie działania i sprawdzenie kodu dają różne informacje. Po większym etapie i na końcu przekażcie zmianę do niezależnego przeglądu, ze świeżym kontekstem, wymaganiami i wynikami testów. Opis i prompt przeglądu są wspólne z One Man Army.

Uwagi CodeRabbit lub drugiego modelu wymagają sprawdzenia. Agent powinien wskazać kod i skutek problemu, a po poprawce ponowić potrzebne testy. Jeśli uwaga jest nietrafna, wyjaśnijcie dlaczego na podstawie kodu. Osoba wymagana przez wasz playbook nadal odbiera wynik.

Co ma zostać przy zadaniu

Uzupełnijcie istniejące zadanie i plan: co działa, kto obejrzał wynik, które uwagi poprawiono oraz co pozostaje otwarte. Jeśli zmiana wpływa na opis systemu, zaktualizujcie też właściwą dokumentację. Karta pomaga zebrać te informacje bez zakładania drugiego rejestru.

Podsumuj realizację zadania [link] na podstawie dozwolonych źródeł.
Wskaż potrzebę użytkownika, ustalenia z analizy, osobę prowadzącą i odbiorcę.
Zapisz, co człowiek obejrzał na demo, jakie uwagi zgłosił, co poprawiono
oraz co wymaga ponownego pokazu. Podaj wersję, wyniki testów i niezależnego
przeglądu, a także pozostałe problemy i stan dokumentacji.
Skorzystaj z dołączonej karty i istniejącego planu; nie twórz drugiego rejestru.
Nie dopisuj akceptacji ani wyników bez potwierdzenia. Pokaż podsumowanie
bez zapisywania w zewnętrznych usługach i bez wdrażania.

Odebrane zadanie trafia dalej do procesu wydania. W następnym rozdziale pokazuję, jak przechodzi u nas przez wspólne środowiska i odbiór całej wersji.