Między kodem, a kulturą

Archetyp CRM Activity — wzorzec, który znajdziesz (prawie) wszędzie

2026-03-21T00:00:00.000Z

Niezależnie od branży, w której budujesz oprogramowanie, pewne schematy wracają jak bumerang. Nowy projekt, nowa domena, nowy zespół — a na tablicy po dwóch dniach analizy znowu rysuje się ten sam kształt.

Weźmy cztery zupełnie różne projekty.

Pierwszy — platforma fintechowa. Klient zakłada konto, przechodzi weryfikację tożsamości, podpisuje umowę, aktywuje kartę. Na każdym etapie system zapisuje: kto, co zrobił, kiedy i jaki był efekt. Dział compliance potrzebuje pełnej historii, żeby w razie audytu odtworzyć ścieżkę klienta co do minuty.

Drugi — system lojalnościowy dużej sieci handlowej. Klient zbiera punkty za zakupy, wymienia je na nagrody, dostaje spersonalizowane kampanie. Za każdą z tych interakcji stoi wpis: jaki typ aktywności, kto był uczestnikiem, co było przedmiotem, jaki wynik.

Trzeci — CRM w firmie ubezpieczeniowej. Konsultant dzwoni do klienta, wysyła ofertę, umawia spotkanie, odnotowuje reklamację. Każdy kontakt to rekord z datą, typem, uczestnikami i rezultatem.

Czwarty — system helpdesku. Klient zgłasza problem, agent odpowiada, eskaluje do drugiej linii, zamyka zgłoszenie. Historia interakcji jest kluczowa dla jakości obsługi.

Cztery różne branże, cztery różne zespoły, cztery różne zestawy wymagań. A pod spodem — ten sam schemat. Te same pytania: kto, co zrobił, z kim lub czym, kiedy i jaki był efekt.

To nie przypadek. To archetyp.

Czym jest archetyp (i dlaczego to nie design pattern)

Jeśli pracujesz w IT dłużej niż kilka lat, prawdopodobnie znasz wzorce projektowe — klasyczne Gang of Four, może wzorce taktyczne z DDD jak Aggregate, Repository czy Value Object. Archetyp to coś zupełnie innego. Działa na wyższym poziomie abstrakcji.

Koncepcję archetypów biznesowych opisali Jim Arlow i Ilan Neustadt w książce „Enterprise Patterns and MDA" [1]. Ich teza jest prosta: w każdej domenie biznesowej powtarzają się te same fundamentalne schematy; nie na poziomie kodu — na poziomie pojęć biznesowych. Nieważne czy budujesz system bankowy, sklep internetowy czy platformę medyczną — natrafisz na te same struktury: Party (kto uczestniczy w systemie), Product (co oferujesz), Order (co klient zamawia) — i właśnie Activity (co się wydarzyło). Te wzorce nie powstały wczoraj — były wielokrotnie testowane i dopracowywane w różnych kontekstach, zanim ktokolwiek z nas napisał swój pierwszy CRUD.

Szukając analogii poza IT — Joseph Campbell opisał „podróż bohatera", schemat fabularny obecny w starożytnych mitach, filmach Lucasa i grach indie. Za każdym razem wygląda inaczej, ale struktura jest ta sama. Archetyp biznesowy działa dokładnie tak samo: konkretna implementacja różni się między domenami, ale szkielet jest uniwersalny.

I tu tkwi kluczowa różnica wobec design patternów. Wzorzec Strategy mówi jak zorganizować kod, archetyp Activity mówi jak zorganizować myślenie o domenie. Jeden żyje w warstwie implementacji, drugi — w warstwie modelu biznesowego. Rozpoznanie archetypu następuje podczas rozmów z biznesem, a nie podczas code review.

Activity pod lupą — anatomia wzorca

Archetyp Activity składa się z kilku elementów, które powtarzają się niezależnie od domeny:

Case – Konkretny proces biznesowy np Onboarding klienta, zgłoszenie serwisowe. Zawiera wiele aktywności.
Activity — samo zdarzenie, fakt że coś się wydarzyło. Ma swój moment w czasie (lub przedział czasowy), status i wynik.
Activity Type — klasyfikacja tego, co się stało. „Telefon wychodzący", „weryfikacja tożsamości", „naliczenie punktów" — to różne typy tej samej struktury.
Party (uczestnik) — kto był zaangażowany. Klient, konsultant, system automatyczny. Często wielu uczestników w jednej aktywności, każdy w innej roli.
Subject (przedmiot) — czego dotyczyła aktywność. Zamówienie, konto, zgłoszenie, kampania.
Outcome (rezultat) — jaki był efekt. Sukces, odmowa, eskalacja, brak odpowiedzi.

Ważna myśl, którą łatwo przegapić: Activity to nie log techniczny. To główny element w domenie — byt, na podstawie którego biznes podejmuje decyzje. Menedżer sprzedaży analizuje historię kontaktów, żeby ocenić skuteczność kampanii. Dział compliance przegląda ścieżkę onboardingu, żeby spełnić wymogi regulatora. Program lojalnościowy nalicza punkty na podstawie zarejestrowanych aktywności zakupowych.

Jest jeszcze jedna subtelność, która często umyka: Activity jest niemutowalne. Coś, co się wydarzyło, nie może się „od-wydarzyć". Możesz zarejestrować nową aktywność korygującą (np. anulowanie poprzedniej), ale sam fakt pierwotnej aktywności pozostaje w historii. Jeśli kiedykolwiek pracowałeś z event sourcingiem, poczujesz tu znajomy schemat. Activity to w pewnym sensie domenowy odpowiednik domain event, tyle że żyjący na poziomie modelu biznesowego, nie technicznej infrastruktury.

Gdzie go spotkasz w praktyce

Teoria jest fajna, ale archetypy pokazują swoją wartość dopiero wtedy, gdy rozpoznasz je w żywym projekcie.

Onboarding w fintechu

Wyobraź sobie platformę finansową, gdzie nowy klient musi przejść kilkanaście kroków: rejestracja, weryfikacja dokumentów, scoring kredytowy, podpisanie umowy, aktywacja produktu. Każdy krok to osobna aktywność z uczestnikami (klient, system OCR, analityk ryzyka), przedmiotem (wniosek, dokument, umowa) i wynikiem (zatwierdzony, odrzucony, wymaga uzupełnienia).

Intuicyjnie, można by to zaimplementować jako sekwencję stanów wniosku — klasyczny state machine. Wniosek przechodzi ze stanu „nowy" przez „w weryfikacji" do „zatwierdzony". Na pierwszy rzut oka eleganckie rozwiązanie.

Problem pojawia się, kiedy biznes zaczyna pytać o rzeczy, których state machine nie umie wyrazić:

„Ile średnio trwa krok weryfikacji dokumentów?"
„Który analityk obsłużył najwięcej wniosków w tym miesiącu?"
„Na którym etapie najczęściej klienci rezygnują?"
„Pokaż mi pełną historię tego konkretnego wniosku ze wszystkimi interwencjami."

State machine przechowuje gdzie jest wniosek teraz. Activity przechowuje co się z nim działo. To fundamentalna różnica. Wniosek w stanie „odrzucony" nie mówi Ci, że był dwukrotnie cofany do uzupełnienia, raz eskalowany do managera i finalnie odrzucony po trzeciej próbie — Activity tak.

Co ciekawe, state machine nie musi znikać — może nadal pełnić rolę orkiestratora procesu. Ale sam stan przestaje być jedynym źródłem prawdy. Ogólny stan wniosku mówi „gdzie jesteśmy teraz", Activity mówi „jak tu dotarliśmy".

Program lojalnościowy w retail

Weźmy duży system lojalnościowy w sieci handlowej z wieloma markami. Klient zbiera punkty, ale „zbieranie punktów" to tak naprawdę cały wachlarz aktywności: zakup w sklepie stacjonarnym, zakup online, udział w kampanii, polecenie znajomego, urodzinowy bonus.

Klasyczne podejście — osobny serwis per typ interakcji. Zakupy obsługuje moduł transakcyjny, kampanie — moduł marketingowy, polecenia — moduł referralowy. Każdy trzyma dane w swoim formacie, każdy po swojemu rozumie „historię klienta".

I wszystko działa, dopóki biznes nie poprosi o zunifikowany widok aktywności klienta — „pokaż mi wszystko, co ten klient zrobił w ostatnim roku". Wtedy okazuje się, że dane są rozproszone, niespójne w strukturze, trudne do zagregowania.

Rozpoznanie archetypu Activity pozwala zaproponować wspólny model: każda interakcja klienta z programem to Activity o określonym typie, z uczestnikiem (klient + opcjonalnie marka/sklep), przedmiotem (transakcja, kampania, kod polecenia) i wynikiem (naliczone punkty, status realizacji). Poszczególne bounded contexty nadal żyją własnym życiem — ale eksponują swoje zdarzenia w zunifikowanej strukturze Activity, którą widok historii klienta może konsumować.

Ważne zastrzeżenie: zunifikowanie struktury Activity nie musi oznaczać centralizacji danych w jednej bazie. Każdy bounded context nadal może być właścicielem swoich aktywności. Wspólny jest kontrakt — format, w jakim konteksty publikują informacje na zewnątrz. Centralizacja modelu i centralizacja danych to dwie zupełnie różne decyzje architektoniczne.

Konfiguracja zamiast kodu — serce wzorca

Rozpoznanie archetypu daje jeszcze jedną, bardzo praktyczną korzyść: możliwość budowania systemów opartych na konfiguracji zamiast na hardkodowaniu każdego przypadku.

Jeśli nie widzisz wspólnego schematu, każdy nowy typ interakcji to nowy feature: osobna tabela, osobne endpointy, osobna logika walidacji. Backlog rośnie, a każdy nowy pomysł biznesu to sprint pracy deweloperskiej.

Jeśli widzisz archetyp, budujesz raz mechanizm obsługujący Activity — i nowy typ interakcji dodajesz jako konfigurację:

Bez archetypu — dodanie nowego typu kontaktu w CRM:

→ nowa tabela w bazie
→ nowe DTO / encja
→ nowe endpointy API
→ nowe walidatory
→ nowe testy
→ code review, deploy
→ 1-2 tygodnie pracy

Z archetypem — dodanie nowego typu kontaktu:

→ nowy wpis w rejestrze Activity Type
→ definicja wymaganych pól (metadata schema)
→ konfiguracja reguł walidacji
→ gotowe
→ godziny, nie tygodnie

Jak to może wyglądać w praktyce? Wyobraź sobie prosty rejestr typów aktywności w programie lojalnościowym:

yamlactivity_types:
  purchase_in_store:
    participants: [customer, store]
    subject: transaction
    outcomes: [points_earned, points_rejected]
    metadata_schema:
      required: [transaction_id, amount, currency]
      optional: [product_categories, payment_method]
    rules:
      - "points = amount * 1.0"
      - "min_amount: 10 PLN"

  referral_signup:
    participants: [referrer, referee]
    subject: referral_code
    outcomes: [bonus_granted, bonus_rejected]
    metadata_schema:
      required: [referral_code, referee_email]
    rules:
      - "bonus = 500 points"
      - "max_referrals_per_month: 5"

Kiedy biznes powie „chcemy dodać punkty za zostawienie opinii o produkcie", deweloper nie pisze nowego serwisu — definiuje nowy typ aktywności z odpowiednimi uczestnikami, przedmiotem, wynikami i regułami. Silnik Activity obsłuży resztę.

To nie znaczy oczywiście, że system staje się magicznym „no-code". Złożone typy aktywności nadal mogą wymagać dedykowanej logiki. Ale 80% nowych typów to warianty istniejącego schematu — i te 80% obsłużysz konfiguracją, jeśli masz dobrze rozpoznany archetyp. Diabeł oczywiście tkwi w szczegółach — schemat metadanych musi być wystarczająco elastyczny, a jednocześnie nie możesz skończyć z własnym językiem programowania ukrytym w YAML-u.

Kluczowe pytanie: co się zmienia między typami aktywności, a co zostaje takie samo? To, co zostaje takie samo — to Twój archetyp. To, co się zmienia — to parametry konfiguracji.

Kiedy to NIE jest Activity

Trzeba powiedzieć uczciwie: nie wszystko co ma timestamp to Activity. Czasem warto się zatrzymać i pomyśleć, czy tego archetypu faktycznie potrzebujemy.

Logi techniczne — wpis „serwer odpowiedział w 230ms" to metryka infrastrukturalna, nie aktywność biznesowa. Nikt z biznesu nie podejmuje decyzji na podstawie czasu odpowiedzi serwera (a jeśli podejmuje — to prawdopodobnie masz inny problem).

Surowe eventy systemowe — „użytkownik kliknął przycisk X" to zdarzenie UI, nie Activity w sensie archetypu. Activity pojawia się wtedy, kiedy zdarzenie ma znaczenie biznesowe: nie „kliknął wyślij", ale „złożył wniosek".

Dane z sensorów i IoT — odczyt temperatury co sekundę to strumień danych, nie seria aktywności. Ale uwaga: alarm temperaturowy, który wywołał interwencję technika — to już Activity.

Dobra reguła kciuka: jeśli biznes nie potrzebuje historii tego zdarzenia do podejmowania decyzji, to nie jest Activity. Jeśli nikt nigdy nie zapyta „pokaż mi wszystkie X tego klienta z ostatniego kwartału" — prawdopodobnie nie potrzebujesz tu archetypu.

I jeszcze jedna pułapka — over-engineering przez nadmierne uogólnianie. Fakt, że dwa byty mają datę, typ i uczestnika, nie oznacza automatycznie, że to ten sam archetyp. Zamówienie w sklepie i sesja logowania do systemu technicznie pasują do schematu Activity — ale ich semantyka biznesowa jest zupełnie inna. Próba wciśnięcia obu w jeden model to droga do generycznego potworka, który nie służy dobrze nikomu.

Linki do źródeł:

[1] Jim Arlow, Ilan Neustadt — „Enterprise Patterns and MDA: Building Better Software with Archetype Patterns and UML" (2004)

Dopasuj rozwiązania do fazy rozwoju zespołu

2026-03-10T00:00:00.000Z

Czasem trudno zidentyfikować problem w projekcie. Na pierwszy rzut oka winowajcą jest kod i zaciągnięty dług — przegląd kodu przestał działać, komentarze są albo zbyt ostre, albo zbyt grzeczne, decyzje architektoniczne zapadają w kuluarach zamiast na tablicy, ktoś przepisuje moduł, który ktoś inny właśnie skończył. Dokładasz procesy, narzędzia, ceremonie; nic nie pomaga.

Problem może być gdzie indziej.

Developmental Sequence in Small Groups

Bruce Tuckman opisał to w 1965 roku w artykule "Developmental Sequence in Small Groups" — fazy rozwoju zespołów – forming, storming, norming, performing. Model powstał na podstawie pięćdziesięciu badań nad małymi grupami, głównie terapeutycznych i laboratoryjnych, nie zespołów scrumowych, nie zespołów produktowych, nie jednostek w skalowanym Agile. Jest opisowy, nie przepisujący — Tuckman nie mówił jak przez te fazy przejść, mówił że grupy przez nie przechodzą.

Czytając te badania, zacząłem zastanawiać się, jak znajomość tych faz może zmienić sposób, w jaki diagnozujemy problemy w kodzie i dobieramy do nich narzędzia.

Storming wygląda jak problem techniczny

Drugie, poważniejsze odkrycie z badań Tuckmana: tylko połowa grup wykazała wyraźną fazę storming. Reszta albo ją pomijała, albo zamiatała pod dywan — co nie oznaczało, że konfliktu nie było, oznaczało, że nie był na tyle bezpieczny, żeby się ujawnić.

W IT storming rzadko wygląda jak otwarty konflikt. Wygląda jak nieskończone dyskusje o wyborze biblioteki. Jak pull requesty, które wiszą tygodniami bez recenzji. Jak "tymczasowe" rozwiązania, które nikt nie chce ruszać, bo nie wiadomo czyje są. Jak decyzje architektoniczne, które zapadają nie na podstawie argumentów, ale na podstawie tego kto ma więcej autorytetu w pokoju.

Jeśli widzisz te symptomy w kodzie — zanim zaczniesz szukać rozwiązania technicznego, zastanów się, w której fazie jest Twój zespół.

Każda zmiana personalna resetuje zegar!

Model Tuckmana nie jest liniowy. Każda znacząca zmiana — nowy członek, odejście kluczowej osoby, scalenie dwóch zespołów, zmiana tech leada — resetuje dynamikę grupy z powrotem do forming. Nie o jedną fazę wstecz. Do początku.

Brooks poniekąd wyjaśnił mechanikę tego zjawiska w 1975 roku w The Mythical Man-Month: przy pięciu osobach masz dziesięć par komunikacyjnych, przy dziesięciu — czterdzieści pięć. Każdy nowy człowiek to nowe kanały do zbudowania, nowy kontekst do przekazania, nowa dynamika do wypracowania.

To ma bezpośrednie przełożenie na to, co widzisz w kodzie po dołączeniu nowej osoby do zespołu. Nagle pojawiają się pull requesty, które łamią ustalone konwencje — nie ze złej woli, ale dlatego że nowa osoba nie zna kontekstu, który reszta ma w głowie. Nagle wracają dyskusje, które zespół miał już rozstrzygnięte. Nagle ADR-y, które leżały spokojnie w repozytorium, okazują się niewystarczające, bo opisują co zdecydowano, ale nie dlaczego.

Team Topologies daje strukturę, Tuckman daje kontekst

Skelton i Pais w Team Topologies traktują obciążenie kognitywne jako pierwsze ograniczenie projektowania organizacji. Cztery typy zespołów i trzy tryby interakcji dają precyzyjny język do opisywania granic — kto jest stream-aligned team, kto jest zespołem platformowym, kiedy zespoły powinny współpracować, a kiedy działać przez interfejs usługowy.

To bardzo użyteczny język. Ale Team Topologies nie powie ci, co robić, gdy Twój stream-aligned team jest w burzliwej faxie storming i doświadczony programista blokuje każdą decyzję, bo czuje, że traci wpływ po reorganizacji. Model jest mocny na projektowaniu struktury, milczy na temat dynamiki ludzi wewnątrz tej struktury.

Tuckman z kolei opisuje dynamikę — ale nie mówi nic o tym, jak strategia pracy z kodem powinna się zmieniać w zależności od fazy.

Pozwoliłem sobie na zbiorczą reinterpretację obu tych narzędzi i doszedłem do wniosku, że dopiero ich połączenie może dać coś naprawdę użytecznego: język do diagnozowania tego, co widzisz w projekcie, i praktyki dopasowane do etapu, na którym zespół faktycznie jest — nie do tego, na którym chciałbyś żeby był.

Co faza zespołu mówi o tym, jak pracować z kodem

Moja analiza wyciągniętą z doświadczenia, w zderzeniu z teorią o zespołach.

Forming

Nowy kontekst, brak wspólnych konwencji, każdy ma inne przyzwyczajenia z poprzednich miejsc. Przegląd kodu w tej fazie jest drogi — bo każdy komentarz wymaga wyjaśnienia założeń, które w dojrzałym zespole są oczywiste.

Praktyki, które tutaj pomagają: zasady przeglądu kodu zapisane jawnie, nie przekazywane ustnie — bo ustna tradycja nie istnieje, gdy zespół ma dwa tygodnie. ADR-y dokumentujące nie tylko decyzje, ale ich uzasadnienie — bo "dlaczego" jest ważniejsze niż "co", gdy ktoś właśnie dołączył. Programowanie w parach jako najszybszy mechanizm przekazywania kontekstu: godzina wspólnego kodowania zastępuje tygodnie dokumentacji, której nikt nie czyta. Linting i formatowanie zautomatyzowane — żeby przegląd kodu nie zużywał energii na spacje i przecinki zamiast na architekturę.

Storming

Najniebezpieczniejsza faza z perspektywy jakości kodu. Konflikty personalne i techniczne nakładają się i trudno je rozdzielić — "nie zgadzam się z tym podejściem do walidacji" może być uzasadnionym sporem technicznym, może też być przykrywką dla "nie akceptuję tego, że nowy tech lead ma więcej autorytetu ode mnie."

Przegląd kodu w tej fazie staje się polem bitwy albo odwrotnie — zamienia się w grzeczne klepanie po plecach, bo nikt nie chce zaogniać atmosfery. W obu przypadkach traci kod.

Co pomaga: ADR z numerowanymi opcjami i jawnymi kryteriami wyboru — decyzja przestaje być zdaniem Marka kontra zdaniem Ani, staje się oceną opcji A kontra opcja B według ustalonych kryteriów. Spike'i zamiast debat: dwa dni prototypu dają dane, których nie ma żaden argument teoretyczny. Definition of Done uzgodniona przed startem sprintu, nie negocjowana przy każdym pull requeście.

Norming

Pojawia się wspólne poczucie własności kodu i zaufanie. To moment, w którym dług techniczny przestaje być tematem tabu — jest dość bezpieczeństwa, żeby powiedzieć głośno "ten kawałek jest zepsuty i powinniśmy to naprawić," bez obawy, że zostanie to odebrane jako atak na autora.

Testy przestają być walką, stają się normą. Właściciele modułów dla krytycznych obszarów kodu — nie po to, żeby zablokować dostęp innym, ale żeby mieć kogoś odpowiedzialnego za jakość. ADR-y pisane prospektywnie, przed decyzją, nie post factum. I właśnie tutaj prawo Conwaya zaczyna działać w drugą stronę — granice kodu i granice odpowiedzialności zespołu zaczynają się pokrywać w sposób, który można świadomie kształtować.

Performing

Rzadkie, cenne, kruche. Wspólny model mentalny sprawia, że decyzje są szybkie, a refaktoryzacja jest możliwa, bo jest zaufanie. Architektoniczne testy fitness — automatyczne sprawdzenia, czy architektura nie dryfuje od założeń — mają sens dopiero tutaj, bo jest dojrzałość, żeby reagować na alarmy zamiast je wyciszać albo ignorować.

I właśnie dlatego każda niepotrzebna rotacja na tym etapie boli nieproporcjonalnie do tego, co widać na powierzchni. Nie tracisz człowieka. Tracisz performing.

Prawo Conwaya domyka pętlę

Conway napisał w 1968 roku: "organizacje produkują projekty będące kopiami ich struktur komunikacyjnych." Brzmiało to jak obserwacja. Badania Microsoftu z 2008 roku pokazały, że metryki organizacyjne — kto z kim rozmawia, jak wyglądają granice zespołów — przewidywały moduły kodu podatne na błędy lepiej niż metryki samego kodu.

Jeśli zespół, w którym jesteś, jest w storming i ma rozmyte granice odpowiedzialności, Twój kod będzie miał rozmyte granice modułów. Jeśli masz trzy podsystemy i dwa i pół zespołu, które "jakoś to ogarniają," Twój kod będzie miał dwa i pół naturalnej granicy — a przy próbie wydzielenia mikroserwisów wyjdzie to boleśnie.

Odwrócony manewr Conwaya — świadome projektowanie struktury zespołów pod architekturę, którą chcesz osiągnąć — działa. Ale działa tylko wtedy, gdy zespół jest dość unormowany, żeby tę strukturę utrzymać. W storming każda granica jest negocjowana na nowo przy każdej zmianie, bo nie ma jeszcze wspólnego rozumienia tego, co do kogo należy.

Jedno pytanie diagnostyczne

Zanim zaczniesz wdrażać DDD, Event Storming inne ceremonię lub narzędzia — sprawdź, czy masz dość bezpieczeństwa psychologicznego w zespole, żeby te praktyki w ogóle zadziałały. Narzędzia działają tylko w rękach ludzi, którzy mogą się mylić bez strachu.

Źródła:

Tuckman, B.W. (1965). Developmental Sequence in Small Groups. Psychological Bulletin, 63(6), 384–399.
Skelton, M., Pais, M. (2019). Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution Press. ISBN: 978-1942788812
Brooks, F.P. (1975/1995). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley. ISBN: 978-0201835953
Conway, M.E. (1968). How Do Committees Invent? Datamation, 14(4), 28–31.
Nagappan, N., Murphy, B., Basili, V. (2008). The Influence of Organizational Structure on Software Quality. ICSE 2008.

Extreme Programming jest potrzebny bardziej niż kiedykolwiek wcześniej

2026-03-05T00:00:00.000Z

Przywitajmy się dzisiaj z Kentem Beckiem. W 1999 roku opublikował Extreme Programming Explained [1] z dwunastoma praktykami, które miały jedno wspólne DNA: skracanie pętli zwrotnej.

Ten sam człowiek wraz z siedemnastoma sygnatariuszami podpisali, genialny w swojej prostocie, Manifest Agile [2]. Warto wspomnieć, że w sumie trzech z tych siedemnastu "ojców" manifestu było także twórcami XP – Kent Beck, Ward Cunningham i Ron Jeffries.

XP a Agile

Manifest Agile nie powstał obok XP. Powstał z XP. Chronologia jest taka: XP (1999) → Manifest Agile (2001) → Scrum Guide (formalizacja 2010+). Agile miał być parasolem nad praktykami inżynieryjnymi. Scrum [3] natomiast celowo nie definiuje praktyk technicznych — i to jest jednocześnie jego siła (elastyczność) i jego słabość (łatwo pominąć inżynierię).

Problem zaczął się, kiedy organizacje potrzebowały czegoś "wdrażalnego." Scrum dał im ramy procesowe — role, eventy, artefakty, ale celowo nie zdefiniował praktyk technicznych; tu się otworzyła luka: łatwiej jest "wdrożyć Agile", robiąc standupy i planningi, niż ucząc zespół TDD i pair programmingu. Jedno wymaga zmiany kalendarza. Drugie wymaga zmiany kultury. Efekt? Organizacje robią Scruma bez XP. Mają ceremonie, ale nie mają dyscypliny. Mają velocity, ale nie mają testów. Dave Thomas wprost mówi, że Agile zostało "wywrócone do punktu, w którym jest praktycznie pozbawione znaczenia" [4].

Prawda jest taka, że porzucamy podstawowe narzędzia, skupiając się tylko na powierzchownej warstwie problemu. Agile/Scrum bez zasad Extreme Programmingu jest bezużyteczny, XP bez podstaw myślenia, jakie definiuje Agile, jest dłubaniem dłutem bez planu.

Dwanaście praktyk XP vs AI

Same zasady extreme programmingu są w mojej opinii jeszcze bardziej potrzebne w czasach agentów AI. Już tłumaczę, spójrzmy na kilka zasad XP pod kątem agent codingu/vibe codingu.

Test Driven Development

TDD jest praktyką, którą agent naprawdę jest w stanie wznieść na wyższy poziom, a jednocześnie praktyką bardzo często pomijaną przy programowaniu z agentami. Test first opiera się na pętli dwóch faz – Red/Green. Tylko tyle i aż tyle. Agenci są fenomenalni w Green, ale ma to sens kiedy test w fazie Red jest przemyślany i zrozumiany, ale w "red" — zdefiniuj, czego oczekujesz — agenci są bezradni bez kontekstu biznesowego.

Oczywiście, możemy przygotowywać opisy agentów, korzystać z narzędzi takich jak AutoGen od Microsoft [5], ale długofalowo TDD jest potęgą kiedy Ty definiujesz testy, zgłębiając przy tym domenę, a agent implementuje fazę Green. Odwrócenie tego procesu, lub pozostawienie AI pisania testów kodu, bez porządnego setupu pod pracę w trybie "AutoGen", to jakby student sam wystawiał sobie ocenę z egzaminu.

Pair Programming

W pewnym sensie Agent to idealny "nawigator" – nie nudzi się, nie ocenia, jest dostępny o trzeciej w nocy, ale nie powie Ci, że Twój pomysł architektoniczny jest głupi, nie zada pytania "a po co to w ogóle robimy?" — bo nie ma kontekstu organizacyjnego, który ludzie budują latami. Można minimalizować ten problem budując bazę wiedzy dla agentów, nagrywając refinementy, dając dostęp do dokumentacji. Jednak z podstaw LLM, będzie się zgadzał, nie ma tej ludzkiej przenikliwości i ciekawości.

Myślę, że skuteczne jest podejście hybrydowe – rutynowe zadania z agentem, bardziej złożone, wymagające decyzji architektonicznych z człowiekiem.

Simple design

Beck: "zrób najprostszą rzecz, która może zadziałać." Agent nie dąży do prostoty, dąży do tego, żeby kod się skompilował. Arlow i Neustadt w Enterprise Patterns [6] zauważyli, że simple design ma dwa wymiary: prostota kodu i prostota semantyki biznesowej, którą ten kod realizuje. Można mieć pięknie czysty kod, który implementuje błędne reguły biznesowe — bo sam kod jest kiepskim narzędziem do walidowania domeny, a refaktoryzacja pokręconej logiki biznesowej to zupełnie inna kategoria trudności niż refaktoryzacja kodu.

Refactoring

Istnieją dwa rodzaje refactoringu – malutkie optymalizacje, zmiana zagnieżdżeń pętli na podejście funkcyjne, wyniesienie czegoś do stałej, albo enuma i takie tam. Tego typu zmiany bez sensu klepać ręcznie; agent jest w stanie zlokalizować i zmienić taki kod w mgnieniu oka.

Problem w tym, że AI sam w sobie nie wie kiedy refaktoryzować, nie rozumie, że refactor to decyzja przede wszystkim ekonomiczna, nie estetyczna. Koszt zmiany rośnie wykładniczo (krzywa Boehma [7]!). Refactoring w złym momencie, będzie drogi. Dla agenta nie ma to znaczenia, ale długoterminowo może okazać się strzałem w kolano.

Coding standards

Agent pisze spójny kod, ale spójny z czym? Z danymi treningowymi. Nie z konwencjami Twojego zespołu. Nie z ADR-ami, które spisaliście pół roku temu. Chyba, że jesteś do tego dobrze przygotowany. Utrzymywanie ADRów w repozytorium, dbanie o instrukcje AGENTS, SKILLS itp. są w stanie znacząco poprawić ten element XP w pracy z AI.

Feedback cycle — serce XP, które agenci mogą złamać

Cały sekret XP: skracaj pętlę zwrotną.

TDD → minuty. Pair programming → sekundy. CI → godziny. Small releases → dni. On-site customer → tygodnie

Każda praktyka XP to inny mechanizm zmniejszania odległości między "napisałem kod" a "wiem, czy ten kod jest dobry." Boehm w 1981 pokazał wykładniczy wzrost kosztu naprawy [7]; Beck argumentował, że XP spłaszcza tę krzywą [1]; Ambler zniuansował: łagodzi się, ale nigdy nie jest płaska [8].

I tu jest sedno problemu z agentami. Agent przyspiesza pisanie – nie przyspiesza feedbacku, a w wielu przypadkach feedback się wydłuża, bo ilość kodu do zrozumienia rośnie szybciej niż zdolność zespołu do review.

XP, a ewolucja systemów

Zaprośmy do tej dyskusji jeszcze jedną osobę — Simona Wardleya [9]. Jego prace są istotne w kontekście Extreme Programming. Zdecydowanie za rzadko zwracamy uwagę na to, że różne praktyki nie mają jednakowej wartości na każdym etapie ewolucji, tak samo jest z praktykami XP:

Genesis (startup, MVP):

Agent + small releases + CI = idealny sojusz. Szybko prototypujesz, szybko walidujesz. TDD mniej krytyczne — kod jest tymczasowy.

Custom-Built (wzrost):

Prawdziwe TDD i pair programming stają się kluczowe. Bez testów i review kod staje się długiem, a Collective ownership nabiera sensu.

Product (dojrzałość):

Refactoring i coding standards dominują. Agent pomaga, ale jest niebezpieczny bez kontekstu historii decyzji. ADR-y i dokumentacja stają się kluczowe.

Commodity (legacy):

Agent najbardziej ograniczony. Problem to nie kod — to wyparowana wiedza. Tu wraca on-site customer i metaphor — trzeba odkryć domenę na nowo.

Praktyka nr 13: rozumiej to, co akceptujesz

Beck dał nam 12 praktyk. Era agentów wymaga trzynastej:

Rozumiej to, co akceptujesz.

Kiedy kolega pisał kod, mieliśmy code review. Ktoś czytał, pytał, sugerował. Kiedy agent pisze, pokusa jest inna: "działa? merge." I wtedy wracamy do kwadrantu Fowlera [10]:

→ Agent pisze, Ty rozumiesz i akceptujesz kompromisy → rozważny-świadomy. OK.

→ Agent pisze, Ty klikasz "accept all" → lekkomyślny-świadomy.

→ Agent pisze, nikt nie rozumie decyzji architektonicznych → lekkomyślny-nieświadomy – skali, jakiej Fowler nie przewidział.

Konkluzja

XP nie jest przestarzałe. Jest bardziej potrzebne niż kiedykolwiek.

Pair programming to nie "dwie osoby przy monitorze" — to zasada, że kod nigdy nie powinien powstawać bez drugiej pary oczu. Agent nie liczy się jako ta para, bo nie pyta "dlaczego."

TDD to nie "pisz testy przed kodem" — to zasada, że zanim napiszesz linijkę, musisz wiedzieć, czego oczekujesz.

Simple design to nie "mało kodu" — to minimalny kod, który poprawnie modeluje domenę.

Manifest Agile [2] miał być parasolem nad tymi praktykami. Scrum dał nam ramy procesowe, ale gdzieś po drodze porzuciliśmy substancję na rzecz ceremonii. I teraz, w 2026, kiedy agenci AI generują kod szybciej niż ktokolwiek jest w stanie go przeczytać — desperacko potrzebujemy dokładnie tych praktyk, które 25 lat temu uznaliśmy za "zbyt extreme."

Beck miał rację. Tylko partner się zmienił.

Źródła

[1] Beck, K. (1999). Extreme Programming Explained: Embrace Change. Addison-Wesley. Drugie wydanie: 2004. — goodreads.com/book/show/67833

[2] Beck, K. et al. (2001). Manifesto for Agile Software Development. — agilemanifesto.org

[3] Schwaber, K., Sutherland, J. (2020). The Scrum Guide. — scrumguides.org

[4] Thomas, D. (2014). Agile Is Dead (Long Live Agility). — pragdave.me/thoughts/active/2014-03-04-time-to-kill-agile.html

[5] Wu, Q. et al. (2023). AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation. Microsoft Research. — github.com/microsoft/autogen

[6] Arlow, J., Neustadt, I. (2003). Enterprise Patterns and MDA: Building Better Software with Archetype Patterns and UML. Addison-Wesley. ISBN: 978-0321112309

[7] Boehm, B.W. (1981). Software Engineering Economics. Prentice Hall. Patrz też: Boehm, B.W. (1988). "A Spiral Model of Software Development and Enhancement." IEEE Computer, 21(5). — doi.org/10.1109/2.59

[8] Ambler, S.W. Examining the Agile Cost of Change Curve. Ambysoft / Agile Modeling. — agilemodeling.com/essays/costOfChange.htm

[9] Wardley, S. (2016). Wardley Maps: The use of topographical intelligence in business strategy. — learnwardleymapping.com

[10] Fowler, M. (2009). Technical Debt Quadrant. — martinfowler.com/bliki/TechnicalDebtQuadrant.html

Dług techniczny — metafora, której prawie nikt nie rozumie poprawnie

2026-03-02T00:00:00.000Z

Ciąg dalszy wpisów z serii "Kolekcja klasyki" (Czy tylko ja nie umiem tego przeczytać inaczej niż głosem Piotra Fronczewskiego? :)). Dzisiejsi bohaterowie — Martin Fowler oraz Ward Cunningham — i metafora, która zdominowała nasze branżowe dyskusje, mimo że większość z nas rozumie ją błędnie.

"Mamy za dużo długu technicznego." To zdanie pada na każdym retro. Wszyscy kiwają głowami. Ale zapytaj pięć osób w pokoju, co dokładnie przez to rozumieją — i dostaniesz pięć różnych odpowiedzi. Brzydki kod. Brak testów. Stary framework. Obejścia na szybko. Wszystko, co powinniśmy byli zrobić inaczej. Każdy używa tej samej metafory, ale każdy mówi o czymś innym.

I tu jest problem — bo ta metafora ma bardzo konkretne znaczenie.

Cunningham nie mówił o złym kodzie

Ward Cunningham wprowadził pojęcie długu technicznego w 1992 roku, opisując system WyCash [1]. I to jest moment, w którym większość branży skręca w złą stronę — bo Cunningham nie mówił o bałaganie w kodzie. Mówił o czymś znacznie subtelniejszym.

Zespół napisał kod najlepiej, jak potrafił, na podstawie tego, co w danym momencie wiedział o domenie biznesowej. Potem nauczył się więcej — i ten sam kod, wcześniej dobry, stał się niedopasowany do aktualnego rozumienia problemu. Ta różnica — między kodem a obecną wiedzą o domenie — to jest dług techniczny w sensie Cunninghama.

Metafora finansowa jest celowa. Dług to nie zło samo w sobie. Firmy zaciągają kredyty, bo pozwalają im szybciej rosnąć — pod warunkiem, że mają plan spłaty. W wywiadzie z 2009 roku Cunningham powiedział to wprost: chodziło o świadomy kompromis, nie o pisanie byle jakiego kodu i nazywanie tego "długiem" [2].

Kwadrant Fowlera, czyli nie każdy "dług" jest długiem

Fowler w 2009 roku wziął tę rozjechaną terminologię i nałożył na nią porządek [3]. Dwie osie — rozważny/lekkomyślny i świadomy/nieświadomy — dają cztery zupełnie różne sytuacje. I dopiero kiedy się je rozróżni, rozmowa o "długu technicznym" zaczyna mieć sens.

Rozważny-świadomy: "Musimy wypuścić teraz i poradzić sobie z konsekwencjami." Zespół wie, co upraszcza, i ma plan spłaty. To jest dług w sensie Cunninghama — i to jest jedyny dług, który warto świadomie zaciągać.

Lekkomyślny-świadomy: "Nie mamy czasu na projektowanie." Zespół wie, że robi źle, ale i tak to robi. Planu spłaty brak. To nie jest dług — to niechlujstwo z premedytacją. Używanie słowa "dług" to tu eufemizm, który ułatwia życie z tym faktem.

Rozważny-nieświadomy: "Teraz wiemy, jak powinniśmy byli to zrobić." Zespół nauczył się czegoś nowego — o domenie, o wzorcach, o architekturze — i widzi, że wcześniejszy kod, choć pisany w dobrej wierze, nie pasuje do aktualnego rozumienia. Nieunikniony koszt uczenia się. Każdy system to ma.

Lekkomyślny-nieświadomy: "Co to jest warstwowanie?" Zespół nie wie, że robi źle, bo nie zna dobrych praktyk. To nie jest dług — to brak kompetencji. Leczy się edukacją i mentoringiem, nie "spłatą."

A potem przyszło AI

Odnoszę wrażenie, że era agentów AI komplikuje każdy z tych kwadrantów na nowe sposoby.

Agent generujący kod nie przechodzi przez fazę uczenia się domeny, nie buduje stopniowo intuicji o tym, dlaczego klient robi coś w określony sposób. Produkuje kod, który formalnie spełnia wymagania — ale nie niesie w sobie pełnego zrozumienia domeny, które Cunningham uważał za sedno świadomego kompromisu. Dług rozważny-nieświadomy pojawia się natychmiast, bo kod od pierwszego dnia odzwierciedla powierzchowne zrozumienie problemu.

Dług lekkomyślny-świadomy — "nie mamy czasu na projektowanie" — nabiera nowego wymiaru, gdy generowanie kodu jest natychmiastowe. Skoro "wystarczy poprosić agenta," pokus żeby nie inwestować w architekturę jest więcej niż kiedykolwiek. Mam wrażenie, że właśnie to obserwujemy — nikt nie planuje architektonicznych kompromisów, bo kompromis implikuje, że w ogóle myślisz o architekturze.

A dług lekkomyślny-nieświadomy? Tutaj AI tworzy dynamikę, której wcześniej nie było. Osoba, która nie rozumie wzorców projektowych, dostaje narzędzie generujące kod wyglądający profesjonalnie — ale nie potrafi ocenić, czy ten kod jest dobry. Agent reprodukuje wzorce z repozytorium ze stuprocentową konsekwencją, bez momentu refleksji. Jeśli repozytorium jest pełne rozbitych okien, agent uzna to za normę i dołoży kolejne.

Dlaczego warto o tym mówić precyzyjnie

McKinsey szacuje, że dług techniczny stanowi ok. 40% bilansów IT [4]. Besker, Martini i Bosch policzyli, że 25% wysiłku deweloperskiego jest marnowane na problemy wynikające z długu technicznego [5]. Jedna czwarta czasu zespołu — nie na budowanie nowych rzeczy, ale na poruszanie się po labiryncie złożoności, którą sami stworzyliśmy.

W erze, w której kod powstaje szybciej niż kiedykolwiek, te liczby mogą tylko rosnąć. Chyba że zaczniemy używać języka, który Cunningham i Fowler nam dali — nie jako akademickiej ciekawostki, ale jako codziennego narzędzia. Kiedy w dyskusji padnie "mamy za dużo długu technicznego," prawidłowa odpowiedź to nie "zaplanujmy sprint na refaktoring."; prawidłowa odpowiedź to: "Co to za dług? Czy go planowaliśmy? Czy mamy po prostu bałagan?"

Linki do źródeł:

Co jeśli AI nie zmienił zasad gry, tylko po prostu ją przyspieszył?

2026-02-26T00:00:00.000Z

Boehm pokazał dekady temu, że koszt zmiany rośnie wykładniczo wraz z fazą projektu [1]. Fowler dokumentował, jak architektura rozpada się wtedy, kiedy nie patrzysz — powoli, niezauważalnie, jak rzeka podmywająca brzeg [2]. Wardley rysował mapy ewolucji komponentów od eksperymentu Pioniera przez dojrzały Produkt do Commodity [3]. Każdy z nich mówił coś innego, ale wszyscy wskazywali na jedno: ewolucja jest nieuchronna. Pytanie tylko, czy będziesz ją prowadzić świadomie.

Dziś obserwujemy coś niepokojącego. Większość deweloperów korzystających z AI staje się, mimowolnie, Pionierami w rozumieniu Wardleya — budujemy custom rozwiązania do problemów, które mają już produktowe odpowiedzi, bo AI generuje kod szybciej, niż zdążymy zapytać: "czy to już gdzieś istnieje?"

Na mapie Wardleya powinniśmy operować w strefie Product albo Commodity, a zachowujemy się jak startup w trybie permanentnego Genesis.

Mam też nieodparte wrażenie, że systemy przestają przechodzić przez fazę ewolucji. Normalny cykl życia to intensywny rozwój, potem refaktoring i dojrzewanie, potem stabilne utrzymanie. Projekty pisane przez agentów dojrzewają inaczej: intensywny rozwój, a zaraz po nim utrzymanie. Faza ewolucji znika — nie dlatego, że rozwiązaliśmy problem długu technicznego, ale dlatego, że kod narasta tak szybko, że nie ma kiedy go pielęgnować. System trafia na OIOM zanim skończy pierwsze urodziny.

Pytanie nie brzmi "czy używać AI". Brzmi: czy budujemy odpowiednią kulturę i procesy, które pomogą nam chronić się przed zagrożeniami, przed którymi, już dawno, przestrzegali nas mądrzy ludzie? Tempo w jakim powstają nowe funkcjonalności jest imponujące, ale tempo w jakim systemy erodują jest przerażające.

(Tak, używam długich pauz "—", bo robiłem to jeszcze przed LLMami)