Jak pracujemy

To pełna droga, dla produktu na produkcji albo takiego, który ma już użytkowników. MVP lub pierwsza wersja idzie lżejszą i szybszą drogą, dzięki czemu szybciej widzisz działające wersje: planowanie, agenci, pull requesty z dowodem działania oraz automatyczne sprawdzenia i recenzje zostają; każdą zmianę zatwierdza osoba, która kierowała agentami, testy end-to-end, wizualne i dostępności czekają na pierwszych użytkowników, a wdrożeń podglądowych nie ma. Gdy produkt ma użytkowników, zaczyna się pełna droga.

1. 1 · Planowanie

   Każde zgłoszenie trafia do jednej kolejki: wiadomość od klienta, przetarg, nasz własny pomysł. Agent planujący przegląda kolejkę: każde zgłoszenie staje się zadaniem w projekcie albo zostaje odrzucone, a powód zostaje zapisany.

2. 2 · Orkiestrator dla każdego obszaru

   Projekt ma osobnego agenta orkiestrującego dla każdego obszaru pracy, takiego jak interfejs, serwer, testy czy proces wydawania. Każdy dzieli swój obszar na elementy do dostarczenia, zleca każdy z nich osobnej sesji agenta i prowadzi pisemny stan obszaru. Sam nigdy niczego nie edytuje, nie commituje ani nie wysyła.

3. 3 · Sesja na każdy element

   Element do dostarczenia to zmiana w kodzie, dokument albo analiza. Każdy dostaje własną sesję agenta na własnej gałęzi, a kilka sesji pracuje jednocześnie.

4. 4 · Pull request

   Każda zmiana kończy się pull requestem z dowodem rezultatu: zrzutami ekranu tego, co widać, i diagramem dla reszty. Odpowiedź na maila pozostaje szkicem, dopóki człowiek jej nie wyśle.

5. 5 · Ciągła integracja

   W projektach klientów każdy pull request przechodzi build, linting, sprawdzanie typów i testy jednostkowe, narzędziami właściwymi dla danej technologii, a gdy trzeba, także testy end-to-end, wizualne i dostępności według WCAG 2.2 AA; na tej stronie walidację HTML, sprawdzenie linków i sprawdzenie dostępności. Gdy któreś sprawdzenie nie przejdzie, agent poprawia błąd na podstawie logu.

   W MVP: build, linting, sprawdzanie typów i testy jednostkowe; testy end-to-end, wizualne i dostępności przychodzą z pierwszymi użytkownikami.

6. 6 · Automatyczne recenzje

   W projektach klientów automatyczna usługa recenzji kodu czyta każdy pull request, a agent, który go przygotował, poprawia kod lub odpowiada na każdy komentarz. Druga recenzja, wykonywana przez jeden z najnowszych modeli AI z wysokim poziomem rozumowania, ponownie szuka tego, co umknęło pierwszej recenzji: zasad projektowych i konwencji projektu.

7. 7 · Zatwierdzenie przez człowieka

   Człowiek czyta i zatwierdza każdą naszą zmianę, zanim trafi ona do kodu projektu, w każdym projekcie. Gdy produkt klienta ma już użytkowników, jest to osoba inna niż ta, która kierowała agentami.

   W MVP: zmianę czyta i zatwierdza osoba, która kierowała agentami.

8. 8 · Testy każdego wydania

   Jedna osoba w zespole zajmuje się zapewnianiem jakości i testuje każde wydanie, zanim trafi do użytkowników.

9. 9 · Wdrożenie

   W projektach klientów każdy pull request ma własne wdrożenie podglądowe, na którym ty i nasz zespół możecie wypróbować zmianę przed jej scaleniem; po scaleniu automatycznie trafia na produkcję. Inna osoba w zespole odpowiada za operacje i wsparcie tego, co działa na produkcji.

   W MVP: bez kroku podglądu: po scaleniu każda zmiana trafia prosto do wersji, którą testujesz.

10. 10 · Spisane wnioski

    Gdy projekt czegoś nas uczy, zapisujemy to jako regułę wraz ze sposobem jej sprawdzenia. Agenci czytają reguły, zanim zaczną, więc kolejne zadanie zaczyna się od tego miejsca.