Scrum w erze AI: przetrwa to, co niedopowiedziane

AI radykalnie obniża koszt pisania kodu, a spec-driven development zmienia sam punkt wyjścia procesu wytwórczego. Czy framework zaprojektowany w czasach, gdy implementacja była wąskim gardłem, ma jeszcze rację bytu? Zanim napiszemy nekrolog Scruma, warto sprawdzić, co dokładnie miałoby umrzeć.

Co właściwie analizujemy

Na wstępie musimy trochę doprecyzować, co tak właściwie będziemy analizować. Oba przywołane w tytule elementy – Scrum i AI – mogą mieć bardzo szeroki zakres, jeśli chodzi o procesy wspomagające wytwarzanie oprogramowania. Po stronie Scruma interesuje nas nie tyle sam framework z podręcznika, ile to, jak realnie funkcjonuje w zespołach: zestaw ceremonii, metryk i ról, które przez lata obrosły praktyką. Po stronie AI nie chodzi o generowanie pojedynczych podpowiedzi w edytorze, lecz o zmianę, która sięga sposobu, w jaki w ogóle powstaje kod. Podejściem, które zyskuje ostatnio na popularności i porządkuje tę zmianę jest spec-driven development: proces, w którym punktem wyjścia i źródłem prawdy staje się specyfikacja, a implementacja jest z niej wyprowadzana, a nie pisana ręcznie od zera.

To rozróżnienie jest istotne, bo dopiero ono pozwala zapytać nie „czy AI pomaga programistom szybciej pisać”, lecz „co się dzieje z procesem, gdy pisanie przestaje być wąskim gardłem”. W Erli wdrażamy to podejście dokładnie rozważając jego implikacje – głównie dla jakości oprogramowania, ale też dla organizacji samej pracy zespołów developerskich.

Działające oprogramowanie ponad dokumentację – ale dlaczego?

Agile uczył nas przedkładać działające oprogramowanie nad wyczerpującą dokumentację. Warto jednak zapytać, dlaczego ta zasada w ogóle powstała – bo nie była prawdą objawioną, lecz odpowiedzią na konkretny stan rzeczy. Dokumentacja była mniej istotna dlatego, że była niewykonywalna: opisywała kod, którego nie potrafiła uruchomić, więc natychmiast się z nim rozjeżdżała i dawała fałszywe poczucie pewności. Działające oprogramowanie wygrywało, bo było jedyną rzeczą, którą dało się skonfrontować z rzeczywistością. Sama dokumentacja nie ruszała naszego biznesu naprzód.

I tu pojawia się pytanie, które spec-driven development stawia wprost: co, jeśli opis da się uczynić wykonywalnym? Jeśli ze specyfikacji generujemy implementację, to specyfikacja przestaje być dokumentacją w starym sensie i staje się źródłem, a kod – artefaktem, który można odtworzyć. Sama opozycja tych elementów z manifestu zaczyna się wtedy zacierać, bo każe wybierać między dwiema rzeczami, które może nie są tym samym, ale są bliżej siebie niż kiedykolwiek wcześniej.

Nie jest to jednak powrót do wyczerpującej dokumentacji sprzed adaptacji Agile. Wykonywalna specyfikacja jest cały czas żywa i ciągle walidowana, a nie zamrożona w setkach stron podpisanych raz na początku projektu. W pewnym sensie wymusza na developerach jej utrzymanie. Zmienia się nie tyle waga zasady, ile jej przedmiot.

Za wcześnie na nekrolog

Za wcześnie, by określać Scrum mianem przestarzałego. To, co decydowało o jego sile przez lata, nadal obowiązuje – a decydowała, paradoksalnie, jego niekompletność.

Scrum nigdy nie był pełną receptą. Nie mówi, jak estymować – każe estymować „jakoś”. Nie definiuje, czym jest ukończona praca – każe zespołowi ustalić własne Definition of Done. Nie rozstrzyga, co jest wartością – oddaje tę decyzję Product Ownerowi. Łatwo uznać te luki za wadę, za coś, co framework powinien był dopowiedzieć. Ale to właśnie one przez trzy dekady pozwalały Scrumowi przetrwać kolejne zwroty w branży.

Kompletny framework jest sztywny: każde założenie zaszyte na twardo to miejsce, w którym rzeczywistość może go złamać. Waterfall był kompletny – precyzyjnie definiował fazy, bramki i kolejność – i właśnie dlatego przestał się sprawdzać, gdy świat przestał pasować do jego założeń. Scrum przetrwał nie mimo dziur, lecz dzięki nim. Tam, gdzie niczego nie narzuca, zespół wkłada to, czego wymaga jego własny kontekst, a framework dostraja się, zamiast łamać swoje własne zasady i tworzyć nowe odnogi i warianty.

Historia zna zresztą ten scenariusz. Extreme Programming było frameworkiem znacznie bardziej kompletnym od Scruma – definiowało konkretne praktyki inżynierskie, od pair programmingu po TDD – i to właśnie ono przegrało jako ruch, a jego praktyki zostały wchłonięte w luki, których Scrum celowo nie wypełnił. Najbardziej ciekawy jest tu przypadek DevOps i continuous delivery, bo ma identyczny kształt jak obecna zmiana: technologia radykalnie obniżyła koszt czegoś (deploymentu), wokół czego zbudowana była ceremonia (sprint jako granica wydania). Gdy wdrażasz kilkadziesiąt razy dziennie, sprint przestaje być granicą release’u – i faktycznie nią być przestał. Zespoły zachowały sprinty jako rytm planowania, odcinając je od wydawania. Konkretna część ceremonii – granica wydania – została zapomniana; ta niedopowiedziana – planowanie, priorytetyzacja, osąd – przetrwała bez szwanku. AI nie jest pierwszym takim testem. Jest kolejną iteracją eksperymentu, którego wynik już raz widzieliśmy.

Ciemna strona niekompletności

Trzeba jednak uczciwie przyznać, że ten argument ma swoją ciemną stronę – i to niejedną.

• Niekompletność czyni Scrum wygodnie niefalsyfikowalnym. „Scrum nie zawiódł, wy go źle wdrożyliście” – każdy, kto pracuje w branży dłużej niż kilka lat, słyszał to zdanie. Framework, który za sukces bierze odpowiedzialność, a porażkę oddaje wdrażającym, jest strukturalnie niemożliwy do obalenia. Trudno taką cechę nazywać siłą frameworku bez mrugnięcia okiem do rozmówcy.

• Nie każda luka w Scrumie jest 'eleganckim niedopowiedzeniem’, niektóre po prostu zostawiają ważne problemy nierozwiązanymi. Scrum milczy o koordynacji wielu zespołów. Ta cisza nie zaowocowała elastycznym dostrojeniem do kontekstu, tylko zrodziła cały przemysł frameworków skalujących, z SAFe na czele – a spora część branży uważa go za zaprzeczenie zwinności.

• Przetrwanie to nie to samo co szerokie stosowanie. Framework może przejść przez rewolucję, opróżniając się po drodze ze znaczenia: ceremonie/eventy zostają w kalendarzu, bo nikt ich nie odwołał, estymacja odbywa się, choć nikt już nie pamięta, czemu miała służyć. Scrum ma udokumentowaną skłonność do przeżywania właśnie w ten sposób – tzw. zombie scrum.

To, co Scrum mówi wprost, jest tym bardziej użyteczne

Jeśli siłą Scruma jest to o czym milczy, to rzeczy, o których mówi wprost, zdają się mieć jeszcze większe znaczenie – skoro jest ich tak niewiele, to znaczy, że przetrwały rygorystyczną selekcję. Framework, który celowo tak wiele zostawia otwarte, a mimo to upiera się przy garstce konkretów, sygnalizuje tym samym, że te konkrety uważa za nieredukowalne. Regularny rytm iteracji, przejrzystość postępu, domknięta pętla informacji zwrotnej, jawny przegląd tego, co powstało – to nie są arbitralne rytuały, lecz minimum, bez którego empiryczna kontrola procesu przestaje działać.

Co istotne, żaden z tych elementów nie zależy od tego, kto – czy co – pisze kod. Można wygenerować implementację w kilka minut i nadal potrzebować rytmu, w którym zespół konfrontuje wynik z oczekiwaniem, przegląda go i koryguje kierunek. AI zmienia koszt wytworzenia tego, co poddajemy inspekcji; nie znosi potrzeby samej inspekcji.

Filary pozostają niezmienne – a empiryzm staniał

Filary Scruma również wydają się nienaruszone. Nadal potrzebujemy transparencji, inspekcji i adaptacji, niezależnie od tego jak powstaje kod.

• Przejrzystość: wynik musi być widoczny, żeby dało się go ocenić – a im więcej pracy wykonuje AI, tym ważniejsze staje się to, że człowiek naprawdę widzi, co powstało, zamiast zakładać, że „pewnie jest ok”.

• Inspekcja: ktoś musi zweryfikować rezultat względem intencji – a gdy implementacja tanieje, ciężar procesu przesuwa się właśnie ku weryfikacji, więc ten filar nie słabnie, lecz zyskuje na znaczeniu.

• Adaptacja: na podstawie tego, co zobaczyliśmy, korygujemy kierunek – i to również jest (nadal) domena człowieka, nie generatora

Wszystkie trzy filary opisują osąd nad wynikiem, a nie wytworzenie wyniku. AI odpowiada właśnie za wytworzenie, a osąd może co najwyżej wspierać.

Co więcej, empiryzm – fundament, na którym te filary stoją – stał się teraz o wiele łatwiejszy. Eksperyment, który kiedyś kosztował sprint pracy zespołu, dziś kosztuje jedno popołudnie. Hipotezę można sprawdzić prototypem zamiast dyskusją, a pętla „zbuduj, zmierz, wyciągnij wnioski” domyka się w skali godzin. W Erli widzimy to na co dzień: nietechniczny product owner może dziś samodzielnie przeprowadzać analizy i tworzyć porównania, o które wcześniej musiał prosić zespół zajmujący się analityką. Bariera między pytaniem a odpowiedzią, która kiedyś wymagała ustawienia się w kolejce po cudze zasoby godzinowe, teraz po prostu znika. AI nie podważa empirycznego rdzenia Scruma – obniża próg wejścia do niego.

Zamiast nekrologu

Pytanie nie brzmi więc, czy Scrum przetrwa. Przetrwał już starcie z XP i rewolucję DevOps. Wszystko to, co framework celowo oddał ludzkiemu osądowi, jest nadal tak samo istotne: priorytetyzacja wartości, definiowanie „done”, konfrontacja wyniku z rzeczywistością. Natomiast sprint jako jednostka rozliczenia z inkrementu, estymacje, velocity – te elementy mogą przeżyć zmianę jakościową i zacząć odpowiadać na inne pytania lub rozwiązywać inne problemy.

Prawdziwe pytanie to: jak bardzo świadomie podejdą do tego poszczególne zespoły i czy będą potrafiły wskazać, które elementy ich procesu faktycznie służą inspekcji i adaptacji, a które praktykują z przyzwyczajenia. A także: czy skorzystają z tego, że eksperymentowanie nigdy nie było tańsze.

Oferty pracy z