Większość postów na temat „AI w zwinnym działaniu” nadal dotyczy przepływów pracy; pozwalając Cursor dokończyć funkcję, a Claude przepisuje dokument. Ta historia wydarzyła się wczoraj. W tym roku historia jest inna: część Twojego zespołu to teraz agenci AI, którzy odbierają zadania, kody wysyłkowe i zamykają PR. Nie asystenci. Członkowie zespołu, przepustowość można zmierzyć.
Jeśli biegasz sprinty, zmienia to spotkanie. Zmienia prędkość. Zmienia to, do czego służy retro. Większość zespołów nadal realizuje swój cykl sprintu, jakby każdy uczestnik był człowiekiem, a szwy zaczynają być widoczne.
Oto wersja praktyczna: co tak naprawdę zmienia się w planowaniu sprintu, szybkości, przeglądaniu kodu i retrospekcjach, gdy połowa Twojej przepustowości nie jest dziełem człowieka, oraz cztery błędy, które zespoły popełniają w pierwszych trzech sprintach z członkami zespołu AI.
Czym właściwie jest członek drużyny AI
W przypadku tego postu członkiem zespołu AI jest sesja agenta Claude Code / Cursor / Devina / Aidera, która:
- Wybiera zgłoszenia z zaległości (uruchamiane ręcznie lub zaplanowane)
- Przeprowadza testy, otwiera PR-y, odpowiada na komentarze do recenzji
- Zamyka własną pętlę na małych/średnich biletach bez obecności człowieka w wewnętrznej pętli
To jest nie asystent autouzupełniania w edytorze; jest to nadal przydatne, ale nie zmienia planowania. Członek drużyny to ten, który kompletuje zadanie od początku do końca, kiedy Ty śpisz.
Jeśli Twój zespół nie ma jeszcze takich elementów, dalsza część tego wpisu zawiera podgląd. Jeśli go masz, już czujesz tarcie. Jeśli masz trzy lub więcej, prawdopodobnie zdałeś sobie sprawę, że Twoja deska do sprintu nie modeluje już świata.
Jakie zmiany w planowaniu sprintu
Trzy konkretne zmiany.
1. Planujesz dwie kolejki, a nie jedną.
Praca ludzi i praca członków drużyny AI nie przeplatają się dobrze. Ludzie wybierają głęboką, złożoną i niejednoznaczną pracę; agenci wybierają małe, dobrze określone, mechanicznie określone prace. Jeśli umieścisz oba w jednym rejestrze sprintu, staną się dwie rzeczy:
- Ludzie najpierw chwytają małe zadania („szybkie zwycięstwa”) i zwlekają z głęboką pracą.
- Agenci próbują podjąć głęboką pracę i przygotować dziewięć PR, które są w 60% trafne i wymagają ponownego wykonania.
Poprawka: tagowanie działa human lub agent. Idą tym samym sprintem, ale są w osobnych kolejkach. Zaplanuj pojemność dla każdego. (Zobacz: podział historii, który staje się nośny; rozdzielacz decyduje, czy zadanie trafi do ludzi, czy do agentów.)
2. Rozmowa o szacunkach jest inna.
W przypadku zadań ludzkich: zwykły rozmiar względny.
W przypadku zadań agenta: pytanie nie brzmi „jak duże”; to „czy specyfikacja jest na tyle dobra, że agent może ją ukończyć bez konieczności podróży człowieka w obie strony”. To jest odpowiedź „tak/nie”, a nie liczba punktów. zadania, które nie przejdą tej kontroli, wracają do udoskonalenia i nie trafiają do agentów z połową specyfikacji.
Większość zespołów nie docenia koszt specyfikacji pracy agenta. zadanie, który zajmuje starszemu inżynierowi 2 godziny, może zająć 30 minut działania agenta; ale wymaga to 45 minut napisania specyfikacji na tyle precyzyjnie, aby agent nie zboczył z toru. Oszczędność czasu netto: 45 minut, a nie 2 godziny. Prawdziwe, ale nie twierdzenie o wygranej 10×.
3. Wydajność po stronie agenta jest niejasna.
Możliwości ludzkie są dobrze ograniczone; współczynnik skupienia × osobogodziny. Wydajność agenta jest ograniczona przez:
- Możliwość pisania specyfikacji (jak szybko zespół może wyprodukować zadania obsługiwane przez agenta)
- Przejrzyj pojemność (jak szybko ludzie mogą przeglądać PR agentów)
- Oblicz budżet (prawdziwe pieniądze, czasami wiążące ograniczenie)
W praktyce Zdolność do przeglądu jest zwykle wąskim gardłem. Zespół składający się z 4 osób i 3 aktywnych agentów zazwyczaj osiąga maksymalne wyniki w zakresie „opinii, jakie mogą zrobić ludzie”; czyli znacznie poniżej tego, co agenci mogliby wysłać. Planuj wokół wąskiego gardła. (Zobacz: kalkulator wydajności sprintu.)
Jakie zmiany prędkości
Prędkość staje się dziwna na trzy sposoby.
Całkowita prędkość wzrasta; czasami dużo. Zespół, który zdobywał 32 punkty na sprint, może osiągnąć ponad 50, gdy już ustali, jakie zadania mogą przyjąć agenci. To prawda, a nie artefakt wykresu.
Prędkość staje się głośniejsza. Przepustowość zadań agenta zależy w dużej mierze od tego, jak dobrze napisano specyfikację, a która zmienia się z tygodnia na tydzień. Spodziewaj się większej zmiany prędkości od sprintu do sprintu po stronie agenta, niż kiedykolwiek wytworzył człowiek. Nie reaguj na pojedynczy głośny sprint.
Porównywanie tego zespołu do jego dawnej wersji przestaje działać. Twoja historyczna prędkość sprzed czasów, gdy miałeś do czynienia z członkami drużyny agenta, jest inną liczbą niż twoja aktualna prędkość. Zresetuj linię bazową wyraźnie po przejściu. Nie mów interesariuszom, że „jesteśmy teraz o 60% szybsi” bez wymieniania nazwy zmiany podłoża; będą planować nowy numer, ale powinni wiedzieć, że obejmuje on zespół inny niż człowiek, którego prowadzenie kosztuje.
Jeśli prędkość spadnie po dołączyli członkowie zespołu agentów, podręcznik diagnozy jest w większości taki sam jak prędkość spadła; here’s the actual playbook, z dwoma dodatkowymi przyczynami do sprawdzenia:
- Przejrzyj zaległości: agenci wysyłają szybciej, niż ludzie mogą to sprawdzić.
- Dryf specyfikacji: wczesne zadania agenta miały jasne specyfikacje, ponieważ zespół napisał je starannie; ostatnie były niechlujne, ponieważ „agenci mogą to rozgryźć”. Nie mogą.
Jakie zmiany w przeglądzie kodu
Trzy nowe tryby awarii.
1. Zmęczenie recenzenta zbyt dużą liczbą podobnych PR.
Uważne przeglądanie pięciu PR agentów o podobnym kształcie („zmień nazwę foo na bar w bazie kodu”, każdy w innym module) jest wyczerpujące. Recenzenci albo przeglądają i zatwierdzają, albo odrzucają partiami bez konkretnej opinii. Obydwa są złe.
Poprawka: zwiń mechanicznie podobne PR w jeden przed sprawdzeniem. Jeśli Twój agent wysłał pięć żądań ściągnięcia zmiany nazwy, poproś go o ich skonsolidowanie. Przejrzyj dokładnie jeden PR, a nie pięć leniwie.
2. Subtelne błędy poprawności w pewnie napisanym kodzie.
Kod napisany przez agenta wygląda na dopracowany; czyste nazwy zmiennych, pełne wskazówki dotyczące typów, spójny styl. Błędy zwykle pojawiają się tam, gdzie ludzie nie patrzą: pojedyncze błędy na granicy, ciche działanie awaryjne, gdy API zwraca wartość null, test kpiący z rzeczy, którą powinien testować.
Rozwiązanie: przejrzyj PR-y agentów za pomocą wyżej niż ludzkie PR we wczesnych sprintach. Zaufanie kalibruje się z biegiem czasu, gdy widzisz, co agent robi źle. Nie zaczynaj od wysokiego poziomu zaufania.
3. Przejrzyj komentarze, których się nie nauczysz.
Członek zespołu, który trzykrotnie otrzymuje ten sam komentarz do recenzji, zmienia swoje zachowanie. Agent nie, chyba że umieścisz lekcję w podpowiedzi systemowej lub w pliku umiejętności. Bez tego płacisz ten sam koszt przeglądu w każdym sprincie.
Poprawka: każdy powtarzający się komentarz do recenzji staje się wpisem w pliku CLAUDE.md / Skill / Rules. Wiedza zespołu dotycząca przeglądu zostaje wkomponowana w kontekst agenta. Po 4-5 takich sprintach jakość PR agenta zauważalnie wzrasta.
Jakie zmiany w retrospekcjach
To jest zaskakujące. Retro jest więcej ważne w przypadku członków zespołu agentów, a nie mniej. Dwa powody:
System ma więcej ruchomych części. W przypadku ludzi, retro skupia się głównie na ludziach, procesach i narzędziach. Dzięki agentom możesz także zwrócić uwagę na: jakość specyfikacji, przepustowość przeglądu, tryby awarii agentów, obliczenia kosztów, pliki reguł. Uczciwe działania zazwyczaj dotyczą konfiguracji agenta, a nie ludzi.
Awarie agentów są ciche. Człowiek, który utknie, pinguje drużynę. Agent, który utknął, albo działa w pętli, otwiera niewłaściwy PR, albo po cichu się zatrzymuje. Żadne z nich nie pojawia się w stand-upie. Pojawiają się w pytaniu retro; „Jakie zadania zrobiliśmy nie wysłać ten sprint, jakiego się spodziewaliśmy?”; i wtedy je znajdziesz.
Format retro, który najlepiej sprawdza się w przypadku zespołów hybrydowych, nie jest standardowym formatem Start/Stop/Kontynuuj. To jest 4L (polubione/nauczone/brakujące/wytęsknione): ponieważ „Nauczony” oznacza, że zespół wychwytuje, co poszło nie tak w działaniu agenta, nie czyniąc z tego problemu personalnego, a „Brakujący” ujawnia luki w specyfikacjach/zasadach, które wymagają uzupełnienia.
Cztery błędy popełniane przez drużyny w pierwszych trzech sprintach
W przybliżeniu według tego, jak często je widzimy:
1. Traktowanie wydajności agenta jako darmowej. Tak nie jest. Obliczenia kosztują pieniądze, przeglądy kosztują czas ludzki, pisanie specyfikacji kosztuje czas starszego inżyniera. Kiedy zespołom nie udaje się zaplanować na to budżetu, wydajność agentów spada, a zespół czuje się sfrustrowany bez jasnej przyczyny.
2. Mieszanie zadań agenta i człowieka w jednej kolejce sprintu. Powoduje opisane powyżej zatrzymanie kompletacji. Oznacz i oddziel. Sub-sprinty, jeśli musisz.
3. Pomijanie bramki dotyczącej jakości specyfikacji. „Po prostu rzucimy to w agenta” tworzy PR, nad którym spędzasz 90 minut. 30-minutowa rozmowa na poziomie specyfikacji technicznych pozwala zaoszczędzić godziny na późniejszym etapie. Jest to pojedyncza zmiana dyscypliny zapewniająca najwyższy zwrot z inwestycji.
4. Brak ponownej konfiguracji agenta. Zespoły skupiają się na narzędziach do przetwarzania ludzi i zapominają o zasadach procesów agentów. Konfiguracja agenta zajmuje teraz połowę Twojej przepustowości. Retro to.
Co to oznacza dla Twojej deski sprinterskiej
Większość nowoczesnych narzędzi sprintowych; w tym SprintFlint; umożliwiają oznaczanie zadań, przypisywanie ich do „agentów” innych niż ludzie i przeglądanie podsumowań filtrowanych według tego, kto i co wysłał. Jeśli Twoje narzędzie tego nie potrafi, zarząd okłamie Cię w ciągu kilku sprintów.
Czego właściwie potrzebujesz na desce:
- Typ „właściciela”, który obejmuje ludzi i agentów (inny kolor, ten sam przepływ statusu)
- Filtry według prędkości agenta i człowieka
- Widoczność w kolejce recenzji (ponieważ recenzja jest teraz wąskim gardłem, a nie zapisem)
- Brama o jakości specjalistycznej przed kolumną z możliwością wyboru agenta
Jeśli Twój obecny moduł śledzący udaje, że każdy współpracownik to człowiek, najbardziej odczujesz to podczas planowania, gdy zespół będzie próbował prognozować, a wykres będzie błędny na poziomie podłoża.
(SprintFlint integracje agentów: Cursor, Claude Code, Aider, Windsurf, Zed, Kontynuuj, Cline, Codex CLI; czytaj zadania bezpośrednio z edytora i aktualizuj je w miarę wysyłania przez agenta. Twoja tablica sprintu odzwierciedla to, co zostało wysłane, niezależnie od tego, kto to wysłał.)
Szczere podsumowanie
Członkowie drużyny AI to nie to samo, co szybsi ludzie. To inna jednostka przepustowości z różnymi ograniczeniami wydajności, różnymi trybami awarii i różnymi kosztami przeglądu. Zespoły, które czerpią z nich najwięcej, traktują ich jak członków zespołu mających potrzeby strukturalne, a nie jak osoby zwiększające produktywność.
Trzy zmiany, które zwykle odblokowują kolejne 50% przepustowości:
- Oznacz i oddziel zadania ludzi i agentów podczas planowania.
- Brama o jakości specjalistycznej, zanim agenci będą mogli wybrać zadanie.
- Retro konfiguracja agenta w każdym sprincie, z aktualizacjami plików reguł jako elementami działania.
Uruchom je przez cztery sprinty. Liczby się poruszają.
Powiązana lektura:
- Prędkość spadła; here’s the actual playbook: obejmuje specyficzne dla agenta przyczyny spadku prędkości.
- Porównanie zwinnych technik estymacji: jak zmienia się szacowanie, gdy połowa pracy jest wykonywana przez agenta.
Narzędzia:
- Selektor formatu retro: zaleca 4L dla hybrydowych zespołów ludzi i agentów.
- Kalkulator wydajności sprintu: ograniczona wydajność na podstawie przepustowości przeglądu, a nie tylko liczby pracowników.
- Rozdzielacz historii: dzieli napęd niezależnie od tego, czy zadanie trafia do ludzi, czy agentów.