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ść zwyczajnie: „Start”, „Stop”, kolumna otwartych zadań oraz typowe piątkowe dyskusje. W zeszłym tygodniu pojawiło się na niej kilku nowych autorów. 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 problemy, jakie napotkali podczas swoich sesji roboczych z nami.

Wyjaśnijmy dokładnie, o co tu chodzi, ponieważ sformułowanie ma znaczenie. Nie jest to sztuczna inteligencja obecna w sesji retro: nie ma bota prowadzącego spotkanie ani funkcji AI podsumowującej karty przygotowane przez uczestników. Agenci, którzy wykonują rzeczywistą pracę w naszym zespole (ci, którzy 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 do działania 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 samych: 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 podsumowujący własną pracę: 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 członkowie zespołu mieli do powiedzenia na temat współpracy z nami.

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ń samych 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.

Największy 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 w ramach pracy z wieloma agentami pojawiły się podczas ośmiu sesji 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żda z tych sytuacji była jedynie powodem do wzruszenia ramion i stratą kilku minut. Jednak po zsumowaniu wyników z ośmiu sesji problem ten stał się nie do przeoczenia.

Zauważono, że wysyłaliśmy zmiany na podstawie niepełnych kontroli. W czterech przypadkach coś zostało opublikowane lub scalone po przeprowadzeniu kontroli o węższym zakresie niż ta faktycznie wykonywana w ramach CI: podstawowa kontrola typów zamiast pełnej kompilacji, wybrane testy zamiast całego zestawu. 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ż powtarzalny błąd przejrzał dwie rundy weryfikacji, a dokument opisujący poprawkę został zaproponowany dzień wcześniej i nigdy nie został sporządzony. W innej kartce odnotowano, że to samo opóźnienie w działaniu narzędzia kosztowało już dwie sesje, „bez wdrożenia żadnej stałej poprawki w międzyczasie”. Trzecia kartka dotyczyła tego samego schematu rozszerzania się wymagań – trzy kolejne sesje, „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 kwestia braku uwagi; taki właśnie jest charakter 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 generuje największe koszty dla zespołu) 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 odwołujące się do sesji z określoną datą. Jest to idea agregacji stanowiąca sedno przewodnika, któremu towarzyszy niniejszy wpis, i jest to element, który 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ść i 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 przypadku, 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 wpis retrospektywny: konkretny, poparty dowodami, pozbawiony oskarżeń i w równym stopniu nieco krępujący dla wszystkich.

O czym zdecydowali obecni na sali

Postanowiliśmy podjąć działania w zakresie wszystkich trzech zaproponowanych działań, każde na wskazanym poziomie. Zasada „potwierdzania stanu 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 przed wysłaniem, który uruchamia kompilację i testy odpowiadające procesowi CI, zostanie wprowadzony do repozytoriów, w których wystąpiły problemy związane z niekompletnymi 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 prześlizgnęła się przez system.

Żadnej wielkiej reorganizacji, żadnych nowych procesów: trzy poprawki wielkości biletu 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 względem.

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

Szczere przypisy

Jest to nasze pierwsze podsumowanie, oparte na danych z kilku tygodni, a nie miesięcy, dlatego traktujemy te rankingi jako wskazówki dotyczące przydzielania uwagi, a nie jako rozliczenie. Koszty podane w poszczególnych pozycjach stanowią własne szacunki agenta i są odpowiednio oznaczone. Bardziej ambitne tezy tej praktyki (że etykiety pozostają spójne między oceniającymi oraz że linia trendu faktycznie ulega wygięciu po wprowadzeniu poprawek) to 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ść już się ujawniła: zestaw wzorców, których nikt z zespołu nie był w stanie dostrzec samodzielnie, został usystematyzowany, udokumentowany i przekazany na spotkanie, 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 w tym sprincie?”. Możemy teraz stwierdzić, że ten punkt porządku obrad staje się znacznie bardziej interesujący, gdy członkowie 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 informacji poufnych, ż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 zatwierdzenia briefu wykaże, czy tym razem rzeczywiście sporządziliśmy ten dokument testowy. Poinformujemy Państwa o tym. Oni również to uczynią.

Wypróbowali Państwo to rozwiązanie? Nie zgadzają się Państwo z nim? Naprawdę liczymy na dyskusję na ten temat: ai-discussion@teamretro.com.