Pytanie „czy Agile umarł?” powraca regularnie — w artykułach branżowych, na konferencjach, w rozmowach między menedżerami. Wydaje się, że pytanie jest źle postawione. Istotniejsze jest inne: jaki problem próbujemy rozwiązać i czy nasz sposób pracy faktycznie pomaga go rozwiązać? Agile jako etykieta rynkowa może tracić blask — bo każda moda w końcu traci — ale potrzeba zwinności, rozumianej jako zdolność do adaptacji w warunkach niepewności, nie zniknie nigdy. To nie jest cecha żadnego frameworka. To cecha dojrzałej organizacji.
Warto więc przestać pytać o nazwę procesu i zacząć pytać o to, czy nasz proces — jakkolwiek go nazywamy — naprawdę działa. Czy redukuje ryzyko? Czy buduje wiedzę? Czy pozwala podejmować dobre decyzje? Czy dostarcza wartość? Jeśli odpowiedź na którekolwiek z tych pytań brzmi „nie wiem” albo „raczej nie”, to problem nie leży w wyborze między Scrumem a V-Modelem. Leży głębiej.
Różne problemy, różne podejścia — ale wspólne fundamenty
Zacznijmy od tego, że nie wszystkie problemy mają tę samą naturę. W środowisku przewidywalnym sprawdzają się procedury, plany i powtarzalne kroki. W środowisku złożonym — a większość wytwarzania oprogramowania do takiego należy — plan jest jedynie hipotezą, którą trzeba weryfikować w trakcie realizacji. Im więcej punktów decyzyjnych, im więcej niewiadomych, tym mniej realistyczne staje się stworzenie kompletnego planu z góry. To nie jest ideologia. To arytmetyka kosztów przewidywania.
Nie oznacza to jednak, że każdy zespół powinien pracować tak samo. Projekt integracyjny w dużej instytucji finansowej to inny rodzaj wyzwania niż budowa nowego produktu cyfrowego w startupie. Problemem wielu organizacji jest właśnie próba narzucenia jednego modelu wszystkim zespołom — albo klasycznej kaskady, albo „zwinności” rozumianej jako dwa tygodnie sprintu i codzienny stand-up. Tymczasem wybór metody powinien wynikać z natury problemu, poziomu niepewności i kontekstu organizacyjnego, a nie z aktualnej mody zarządczej.
By nie popadać w relatywizm warto wspomnieć, że istnieje zbiór zasad, które powinny obowiązywać niezależnie od wybranego podejścia. To nie są zasady żadnego konkretnego frameworka. To są zasady zdrowego rozsądku inżynierskiego, potwierdzone przez dekady praktyki. I warto o nich mówić wprost, bo w ferworze dyskusji o nazwach łatwo je zgubić.
Sześć fundamentów dobrego procesu
Pierwszym takim fundamentem jest iteracyjność. Nie dlatego, że „tak mówi Agile”, ale dlatego, że iteracyjne podejście jest najprostszym sposobem na ograniczenie ryzyka w warunkach niepewności. Planowanie powinno być wystarczające — czyli takie, które daje zespołowi kierunek i pozwala podejmować decyzje — ale nie iluzoryczne, czyli udające, że wiemy więcej, niż wiemy. Kolejne iteracje nie są celem samym w sobie. Służą weryfikacji założeń: czy dobrze zrozumieliśmy potrzebę, czy architektura wytrzymuje obciążenie, czy użytkownik faktycznie korzysta z funkcji tak, jak zakładaliśmy. Bez tego mechanizmu każdy błąd popełniony na początku kumuluje się aż do końca, gdzie jego koszt naprawy jest najwyższy.
Drugim fundamentem jest jedno źródło prawdy o produkcie. Każdy proces wytwórczy generuje ogromną ilość wiedzy: wymagania, decyzje projektowe, ograniczenia techniczne, ustalenia z biznesem, modele danych, reguły walidacji, zależności między komponentami. Jeśli ta wiedza jest rozproszona po głowach, czatach, mailach i slajdach, organizacja nie ma repozytorium — ma zbiór rozbieżnych interpretacji. A rozbieżne interpretacje prowadzą do rozbieżnych implementacji. Utrzymywanie spójnego, dostępnego źródła wiedzy — w jakiejkolwiek formie, która działa w danym kontekście — nie jest biurokracją. Jest warunkiem koniecznym do tego, by zespół budował jedno rozwiązanie, a nie kilka wzajemnie sprzecznych.
Trzeci fundament dotyczy pracy koncepcyjnej przed implementacją i jest chyba najczęściej lekceważony. Sens dokumentacji, modeli, scenariuszy, przypadków użycia, opisów procesów biznesowych czy szkiców architektury nie polega na „produkowaniu papieru”. Polega na redukcji niejednoznaczności. Na wykrywaniu luk, sprzeczności i błędnych założeń zanim trafią do kodu. Dobrze napisany przypadek użycia potrafi ujawnić brakującą regułę biznesową. Dobrze narysowany model architektury potrafi pokazać, że planowana integracja nie zadziała w wymaganym czasie odpowiedzi. Te artefakty nie zastępują implementacji — one ją poprzedzają i chronią. Każdy doświadczony inżynier wie, że najtańszy błąd to ten wykryty przed napisaniem pierwszej linii kodu. Modele i dokumentacja są narzędziem właśnie takiego wczesnego wykrywania.
Czwarty fundament to jasne kryteria podejmowania decyzji. Proces wytwórczy, który nie pomaga rozstrzygać priorytetów, zakresu i kompromisów, jest w istocie tylko kalendarzem spotkań. W każdym projekcie pojawiają się pytania: czy ta funkcja wchodzi do tego wydania? Czy poświęcamy czas na refaktor, czy na nową funkcjonalność? Czy akceptujemy ten kompromis w wydajności? Odpowiedzi na te pytania nie powinny zależeć wyłącznie od tego, kto głośniej krzyknie na spotkaniu. Powinny wynikać z uzgodnionych kryteriów: wartości biznesowej, ryzyka, kosztu, wpływu na architekturę, zobowiązań wobec użytkowników. Dobrze zaprojektowany proces daje ramy do takich decyzji. Źle zaprojektowany — organizuje ceremonie i liczy, że decyzje jakoś się same podejmą.
Piąty fundament to pętla informacji zwrotnej. Regularny, rzeczywisty feedback — od użytkowników, od biznesu, od architektów, od zespołu technicznego — jest ważniejszy niż nazwa metody, którą stosujemy. Retrospektywy, które nie prowadzą do zmian, review, na których nikt nie podejmuje decyzji, demo, które nikogo nie interesuje — to wszystko formy bez treści. Pętla zwrotna działa tylko wtedy, gdy jej wynik faktycznie wpływa na kolejne kroki.
Szósty fundament to jakość techniczna i spójność architektoniczna. Bez kontroli jakości kodu, bez świadomego zarządzania długiem technicznym, bez konsekwencji w decyzjach architektonicznych nawet najbardziej „zwinny” proces degeneruje się w chaos. Zwinność nie jest wymówką od standardów inżynierskich — jest raczej ich warunkiem wstępnym. Zespół, który nie ma czystej bazy kodu, nie ma zautomatyzowanych testów i nie ma spójnej architektury, nie jest zwinny. Jest po prostu szybki w produkowaniu bałaganu. A bałagan, niezależnie od tego, jak szybko powstaje, prędzej czy później zatrzymuje cały proces.
AI w procesie jako nowy siódmy fundament
Rozwój dużych modeli językowych otwiera nowe możliwości wspierania pracy koncepcyjnej w procesie wytwórczym, ale warto zachować odrobinę rozsądku. Rozwiązania AI mogą wyglądać na szybsze i tańsze, ale pomijać czynnik ludzki: zgodę, relacje, kontekst i ocenę poprawności.
LLM może realnie pomagać w porządkowaniu wiedzy rozproszonej po wielu źródłach, streszczaniu długich ustaleń, wykrywaniu niespójności w wymaganiach, generowaniu wariantów dokumentacji czy doprecyzowywaniu pytań analitycznych. Może przygotowywać szkice modeli, wspierać refinement wymagań, analizować wpływ zmian na istniejące funkcjonalności, tworzyć robocze wersje scenariuszy testowych. To są zadania, w których AI działa jako wzmacniacz ludzkiej pracy koncepcyjnej — przyspiesza, systematyzuje, podpowiada warianty.
Ale AI nie zastępuje myślenia, odpowiedzialności ani rozumienia domeny. Generatywna sztuczna inteligencja opiera się na rekombinacji wcześniejszych danych — nie jest źródłem autentycznie nowych idei i bywa zawodna szczególnie tam, gdzie potrzeba głębokiego kontekstu biznesowego, oceny poprawności i podejmowania decyzji obarczonych konsekwencjami. Człowiek nadal musi weryfikować rezultaty, nadawać im sens i rozstrzygać, co jest trafne. AI najlepiej działa jako narzędzie wspierające człowieka w pracy analitycznej i komunikacyjnej, a nie jako bezrefleksyjny substytut projektowania.
Jest jeszcze jedno ostrzeżenie, które warto wypowiedzieć wprost: automatyzowanie chaosu prowadzi jedynie do szybszego wytwarzania chaosu. Jeśli organizacja nie ma spójnego źródła wiedzy, nie prowadzi pracy koncepcyjnej przed implementacją i nie potrafi podejmować decyzji, to dodanie AI do tego procesu nie naprawi problemu. Przyspieszy jedynie produkcję niespójnych artefaktów, które nikt nie weryfikuje.
Podsumowując
Spór „Agile kontra klasyka” jest często źle postawiony, bo sensownie zaprojektowany proces — niezależnie od nazwy — i tak musi zawierać te same mechanizmy: iteracyjną weryfikację założeń, spójne źródło wiedzy, pracę koncepcyjną przed implementacją, jasne kryteria decyzyjne, rzeczywistą pętlę zwrotną i kontrolę jakości technicznej. Frameworki, metodyki i certyfikaty są wtórne wobec tego, czy organizacja faktycznie potrafi ograniczać ryzyko, budować wiedzę, podejmować decyzje i dostarczać wartość.
Dojrzałość procesu wytwórczego nie mierzy się tym, jak go nazywamy. Mierzy się tym, czy potrafimy odpowiedzieć na proste pytania: skąd wiemy, że budujemy właściwą rzecz? Skąd wiemy, że budujemy ją właściwie? I co robimy, gdy okazuje się, że się myliliśmy? Jeśli nasz proces — obojętnie czy nazywamy go Scrumem, Kanbanem, SAFe, RUP-em czy po prostu „naszym sposobem pracy” — pomaga na te pytania odpowiadać, to działa. Jeśli nie pomaga, żadna nazwa go nie uratuje.
