Nasi koledzy z zespołu AI dołączyli do naszej imprezy w stylu retro

Tworzymy oprogramowanie oparte na retrospektywach, więc tablica retrospektywna naszego zespołu wygląda dość standardowo: „Start”, „Stop”, kolumna otwartych zadań oraz typowe piątkowe dyskusje. W zeszłym tygodniu dołączyli do nas nowi współtwórcy. Sześć z tych kart nie zostało sporządzonych przez żadną osobę – zostały one dodane przez agenty sztucznej inteligencji, z którymi współpracujemy na co dzień, i podsumowują one trudności wynikające z ich własnych sesji roboczych z nami.

Wyjaśnijmy dokładnie, o co tu chodzi, ponieważ sformułowanie ma znaczenie. Nie chodzi tu o sztuczną inteligencję działającą w ramach spotkania retro: nie ma bota prowadzącego spotkanie ani funkcji AI podsumowującej karty przygotowane przez uczestników. Pracownicy naszego zespołu, którzy wykonują rzeczywistą pracę (piszą kod, redagują treści, przeprowadzają audyty), pojawili się na uroczystości tak samo jak każdy inny członek zespołu: przedstawiając własną relację z przebiegu pracy. Byli uczestnikami, a nie moderatorami; spotkanie pozostało w naszych rękach.

Nie była to też żadna sztuczka. Impuls pojawił się podczas jednego z naszych własnych spotkań retrospektywnych: ktoś stwierdził, że dokumenty wprowadzające są nieaktualne (po raz kolejny), a inna osoba wspomniała, że agent zwrócił jej uwagę właśnie na tę kwestię tego samego ranka w trakcie sesji, mimochodem, zanim kontekst zniknął z ekranu. Agent był tego świadomy; nic w jego systemie nie wskazywało, że ta obserwacja jest warta zachowania. Dlatego przez ostatnie kilka tygodni przeprowadzaliśmy eksperyment na sobie: praktyka ta jest zgodna z opisem zawartym w artykule Jak zbierać informacje zwrotne od agentów AI. Pod koniec każdej istotnej sesji roboczej wspomaganej przez sztuczną inteligencję agent sporządza krótki, ustrukturyzowany wpis retrospektywny dotyczący własnej pracy: co poszło dobrze, co się przeciągało, ile kosztowało każde opóźnienie, jedną etykietę przyczyny źródłowej dla każdego elementu oraz propozycję rozwiązania. Wpisy gromadzą się w repozytoriach, w których wykonywana była praca. Gdy zgromadzono ich wystarczającą liczbę, proces towarzyszący odczytywał je wszystkie i umieszczał powtarzające się wzorce bezpośrednio na naszej tablicy retrospektywnej, dodając przedrostek[AI retro], aby nikt nie pomylił autora.

Oto, co nasi najnowsi współpracownicy mieli do powiedzenia na temat pracy w naszej firmie.

Co odkryli

Nagłówek, którym rozpoczęli, dotyczył ich samych. Na pierwszej karcie widniał napis: „Zacznijcie weryfikować przed podjęciem działania — błędy wykonawcze agentów stanowią 38% przeszkód (dwukrotnie więcej niż kolejna przyczyna); powtarzającym się kosztem jest ustalanie przyczyny, forsowanie zmian lub zmiana celu przed sprawdzeniem działającego kodu, danych lub stanu gałęzi”. Największym źródłem utrudnień w naszej pracy wspomaganej przez sztuczną inteligencję, według własnych ustaleń agentów, byli sami agenci, a konkretnie nawyk podejmowania działań w oparciu o zakładany stan świata zamiast uprzedniego sprawdzenia stanu rzeczywistego. Taką szczerość doceniamy u każdego współpracownika.

Najważniejszy problem związany z pracą zespołową przekroczył wszelkie granice, których człowiek by nie przekroczył. Błędy związane z systemem Git i stanem gałęzi podczas pracy agentów działających równolegle pojawiły się w ośmiu sesjach w dwóch repozytoriach: nieaktualne bazy, nieodczytane cele gałęzi, jeden agent przenoszący gałąź, z której korzystał inny, oraz PR przekierowany bez weryfikacji. Żadna z tych sesji z osobna nie znalazłaby się nawet w pobliżu czołówki rankingu; każdy taki przypadek był jedynie powodem do wzruszenia ramion i stratą kilku minut. Jednak w zestawieniu ośmiu sesji problem ten stał się nie do przeoczenia.

Zauważono, że przeprowadzaliśmy wdrożenia na podstawie niepełnych kontroli. W czterech przypadkach coś zostało opublikowane lub scalone po kontroli o węższym zakresie niż ta faktycznie przeprowadzana w ramach CI: po zwykłej kontroli typów zamiast pełnej kompilacji oraz po wybranych testach zamiast pełnego zestawu testów. Dwukrotnie w jednym repozytorium, tego samego dnia.

A najbardziej niepokojące uwagi wcale nie dotyczyły samej pracy; dotyczyły one raczej konsekwentnej realizacji zadań. W jednej z uwag zaznaczono, że luka w standardach testowania spowodowała, iż powtarzalna awaria przeszła niezauważona przez dwie rundy weryfikacji, a dokument dotyczący poprawki został zaproponowany dzień wcześniej i nigdy nie został sporządzony. W innej kartce odnotowano, że to samo opóźnienie związane z narzędziem kosztowało już dwie sesje, „a pomiędzy nimi nie dostarczono żadnej stałej poprawki”. Trzecia kartka dotyczyła tego samego schematu rozszerzania się wymagań – trzech kolejnych sesji, „z których każda odnotowywała, że problem powtarza się od poprzedniej”. Okazuje się, że agent pamięta, co obiecaliśmy zrobić.

Dwie rzeczy, na które warto zwrócić uwagę

Po pierwsze: żadna z tych sytuacji nie była widoczna dla żadnej osoby. Nie jest to wynik braku uwagi; taka jest po prostu natura tego problemu. Tarcia związane z sesjami AI mają charakter przewlekły i są nieznaczne, więc nigdy nie powodują przeprowadzenia analizy po fakcie, a po zakończeniu sesji po prostu zanikają. Każdy z nas przyjął na siebie swoją część i zajął się czymś innym. Ranking (ten wzorzec kosztuje zespół najwięcej) istnieje wyłącznie w ujęciu zbiorczym, a ujęcie zbiorcze istnieje tylko dlatego, że wpisy były porównywalne: ten sam schemat, ten sam niewielki zestaw etykiet przyczyn źródłowych, każde zgłoszenie odnoszące się do konkretnej sesji z datą. Jest to idea agregacji stanowiąca sedno przewodnika, któremu towarzyszy niniejszy wpis, i właśnie tę część najbardziej chcieliśmy przetestować na sobie.

Po drugie: agenci nie obwiniali nikogo, w tym samych siebie, w sposób ogólnikowy. Wpisy są zgodne z dwiema zasadami, które okazały się mieć większe znaczenie, niż się spodziewaliśmy. Pozycje dotyczące „tarć” opisują rozbieżność oraz związane z nią koszty, nigdy jednak nie wskazują, kto ją spowodował: żadnych nazwisk, żadnych sformułowań typu „sprawa X”. Natomiast sformułowanie „agent popełnił błąd” jest etykietą rezydualną, stosowaną wyłącznie w przypadkach, gdy dane wejściowe były rzeczywiście adekwatne – i właśnie dlatego liczba 38% zwróciła naszą uwagę: przetrwała tę dyscyplinę. Wynik prezentował się jak dobry wkład retrospektywny: konkretny, poparty dowodami, pozbawiony obwiniania i w równym stopniu nieco krępujący dla wszystkich.

O czym zdecydowali zgromadzeni

Zdecydowaliśmy się wdrożyć wszystkie trzy zaproponowane działania, każde na wskazanym poziomie. Zasada „potwierdź stan gałęzi produkcyjnej i wniosku o pull przed wprowadzeniem zmian” zostanie uwzględniona w dokumentacji agenta każdego repozytorium – jest to poprawka dokumentacji dotycząca motywu „ośmiu sesji”. Hook pre-push, który uruchamia kompilację i testy odpowiadające procesowi CI, zostanie wprowadzony do repozytoriów, w których wystąpiły problemy z niepełnymi kontrolami – jest to poprawka środowiskowa, dzięki czemu nie będzie zależała od tego, czy ktoś o tym pamięta. Natomiast dokument dotyczący konwencji testowania, który został „zgłoszony dzień wcześniej, ale nigdy nie został napisany”, jest obecnie opracowywany, a jako praktyczny przykład posłużyła awaria, która przedostała się przez system.

Żadnej wielkiej reorganizacji, żadnych nowych procesów: trzy drobne poprawki wielkości kartki biletowej wraz z osobami odpowiedzialnymi. Ta skromność jest zamierzona: cała idea tej praktyki polega na tym, że drobne poprawki, ukierunkowane na właściwy poziom i faktycznie sprawdzone w następnym cyklu, kumulują się. To, czy te trzy poprawki zostaną utrzymane, pokaże nam właśnie kontrola wdrożenia w następnym briefie; ten sam mechanizm, który wykrył nasze niedociągnięcia ostatnim razem, będzie nas teraz oceniał pod tym kątem.

To dopiero początek, i mówimy to wprost. Jednak po zakończeniu tego retro-wydarzenia byliśmy bardziej zainteresowani naszymi własnymi wzorcami pracy niż od dłuższego czasu — i poczuliśmy odrobinę rywalizacji z kolegą, który w ogóle się nie męczy.

Rzetelne przypisy

Jest to nasze pierwsze podsumowanie oparte na danych zebranych w ciągu kilku tygodni, a nie miesięcy, dlatego traktujemy te rankingi jako wskazówki dotyczące przydzielania uwagi, a nie jako ostateczne rozliczenie. Koszty podane w poszczególnych pozycjach stanowią szacunki samego agenta i są odpowiednio oznaczone. Bardziej ambitne tezy tej praktyki (dotyczące spójności etykiet między oceniającymi oraz faktycznego załamania się linii trendu po wprowadzeniu poprawek) stanowią raczej eksperymenty, które obecnie przeprowadzamy, a nie założenia, które przyjmujemy, i opublikujemy ich wyniki niezależnie od tego, jakie będą.

Jednak główna korzyść stała się już widoczna: zestaw wzorców, których nikt z zespołu nie był w stanie dostrzec samodzielnie, został usystematyzowany, udokumentowany i przedstawiony podczas spotkania, na którym obecni byli już osoby odpowiedzialne za wprowadzenie poprawek. Model Feedback Flywheel autorstwa Rahula Garga zawiera w swojej liście cyklicznych działań „punkt porządku obrad w ramach istniejącej retrospektywy sprintu: co sprawdziło się w zakresie sztucznej inteligencji podczas tego sprintu?”. Możemy teraz stwierdzić, że ten punkt porządku obrad staje się znacznie bardziej interesujący, gdy Państwa koledzy z zespołu zajmujący się sztuczną inteligencją zgłaszają własne uwagi.

Proszę wypróbować to w swoim zespole

Wszystkie wykorzystane przez nas materiały są bezpłatne i opisane w przewodniku: sposób działania wpisów, etykiety przyczyn źródłowych, zasady dotyczące elementów, których nie należy rejestrować (żadnych tajemnic, żadnych danych klientów ani niczego, co pozwalałoby zidentyfikować osobę), a także 15-minutowy punkt porządku obrad dla moderatora oraz dwie umiejętności służące do realizacji etapów rejestrowania i syntezy. Rozwiązanie to działa z dowolnym odpowiednim narzędziem oraz plikiem tekstowym; nasz produkt stanowi jedynie jedno z możliwych miejsc, w których można zapisać wyniki, a nie jest to wymóg.

W następnym cyklu kontrola zgodności z wytycznymi pokaże nam, czy tym razem rzeczywiście sporządziliśmy ten dokument testowy. Poinformujemy Państwa o tym. Oni również to zrobią.

Wypróbowali Państwo to? Nie zgadzają się Państwo z tym? Naprawdę chcielibyśmy, aby Państwo podzielili się z nami swoją opinią: ai-discussion@TeamRetro.com.