Thin Vertical Slice vs. Component Slicing w erze AI

Mój znajomy widzi system, patrząc w kod. Ja widzę go dopiero wtedy, gdy zobaczę, co dostaje użytkownik.

Przez długi czas uważałem, że to po prostu różnica stylu pracy – kosmetyczna, bez większego znaczenia dla tego, jak pracujemy razem. Dopiero rozwój AI pokazał nam, że te różnice mają dużo większe znaczenie niż przypuszczaliśmy.

Bo kiedy do procesu wchodzą „agenty”, sposób, w jaki kroisz pracę, przestaje być prywatną preferencją. Zaczyna decydować o tym, czy panujesz nad produktem, czy tylko obserwujesz, jak rośnie kod. Ten artykuł jest o tym, jak odkryliśmy to na własnej skórze podczas wewnętrznego hackathonu – i co z tego wynikło.

Słowem wstępu

Warto, żebyście wiedzieli, z jakiej pozycji to piszę. Przez całą karierę byłem Scrum Masterem. Mój znajomy odpowiadał za security. Żaden z nas nie jest „klasycznym” deweloperem – i przez długi czas to był nasz sufit: mieliśmy pomysły na produkty dla naszego NGO, ale brakowało nam rąk do ich zbudowania.

Zmieniło się to, gdy oboje na poważnie weszliśmy w AI. Okazało się, że „agenty” potrafią uzupełnić dokładnie te kompetencje, których nam brakowało – i że we dwójkę, z Claude Code i agentic workflow, jesteśmy w stanie realnie dowozić produkty IT dla naszej fundacji, a nie tylko o nich rozmawiać. Po kilku własnych projektach stwierdziliśmy, że zamiast kolejnego toy projectu zrobimy coś bardziej praktycznego – zbudujemy realny system dla naszej organizacji.

Mój znajomy zaproponował, żebyśmy poszli bardziej w kierunku enterprise-style workflow. Dużo security, quality gates, jasno rozpisane issue, agentowe review, ASVS, porządne CI. Brzmiało sensownie.

I początek faktycznie szedł gładko.

Upstream workflow działał świetnie. Bardzo szybko przeszliśmy od pomysłu do:

• EPIC-ów,
• User Stories,
• Issues,
• zależności,
• acceptance criteria,
• security constraints.

Miałem poczucie, że wreszcie pracujemy „jak duży zespół”.

Problem pojawił się chwilę później.

Po dwóch issue kompletnie przestałem rozumieć, co właściwie buduję.

Kiedy issue przestają opisywać produkt

To nie były złe issue – wręcz przeciwnie. Były bardzo dobrze przygotowane:

• poprawne technicznie,
• dobrze opisane,
• logicznie podzielone,
• sensownie odseparowane architektonicznie.

Problem polegał na tym, że nie potrafiłem już połączyć ich z realnym outcome’em.

Jednym z pierwszych momentów, które mocno mnie uderzyły, był issue dotyczący orchestracji live quizu przez WebSockety.

Technicznie wszystko miało sens:

• state machine,
• Redis pub/sub,
• scoring engine,
• broadcast eventów,
• synchronizacja participantów.

Tylko że po przeczytaniu taska nie potrafiłem odpowiedzieć sobie na bardzo proste pytanie:

Co dokładnie zobaczy użytkownik, kiedy to skończymy?

Po zamknięciu issue nadal nie umiałem tego ocenić.

Kod powstawał. CI było zielone. Security gate’y przechodziły. Agent mówił, że wszystko jest poprawne.

A ja nadal nie widziałem produktu.

I tu muszę doprecyzować, bo „nie widziałem produktu” brzmi jak problem estetyczny – a nie o to chodziło. Problemem nie było to, że nie miałem ładnego ekranu do obejrzenia. Problemem było to, że bez perspektywy końcowego użytkownika nie potrafiłem odpowiedzieć na jedyne pytanie, które naprawdę mnie interesowało: czy to, co powstaje, działa tak, jak zakładaliśmy w naszej wizji.

Zielone CI mówiło, że kod jest poprawny. Nie mówiło, że produkt jest dobry. A to dwie zupełnie różne rzeczy.

Problem nie był techniczny

Dopiero po kilku dniach dotarło do mnie, że problem wygląda zupełnie inaczej.

Nie chodziło o to, że system jest zbyt trudny.

Problem polegał na tym, że ja i mój znajomy patrzymy na produkt IT z dwóch zupełnie różnych perspektyw. I żadna z nich nie jest gorsza.

• On „widzi” system przez kod. Potrafi spojrzeć na endpoint, migrację, event, kontrakt czy osobny subsystem i z tych elementów złożyć w głowie cały produkt. Komponentowy backlog jest dla niego naturalny, bo myśli dokładnie w tych jednostkach.
• Ja „widzę” system przez outcome. Potrzebuję zobaczyć flow użytkownika, ekran, zmianę zachowania – to, co realnie dostaje końcowy użytkownik. Dopiero z tego składam sobie architekturę, a nie odwrotnie. Dla mnie kod jest skutkiem produktu, nie produkt skutkiem kodu.

To nie jest podział na „lepszego” i „gorszego”. To dwa prawomocne sposoby rozumienia tego samego systemu – i większość zespołów ma ludzi po obu stronach. Problem zaczyna się dopiero wtedy, gdy organizacja pracy obsługuje tylko jedną z tych perspektyw.

Bo komponentowy backlog karmił perspektywę mojego znajomego i głodził moją. A AI tę różnicę mocno uwypukliło: skoro nie widziałem outcome’u, to nie wiedziałem, czy system idzie w stronę naszej wizji, czy się od niej oddala. A więc nie miałem jak go korygować. Zamiast sterować produktem, zaczynałem tylko obserwować, jak rośnie kod.

Moment przełomowy

Przełom przyszedł przy zwykłym stand-upie. Mówiłem koledze, gdzie jesteśmy z projektem, i w pewnym momencie usłyszałem sam siebie: „Nie wiem, czy to już działa, bo nie wiem, co właściwie miałby zobaczyć user”. To zdanie zawisło w powietrzu.

Kolega, który przy tych samych issue czuł się świetnie, najpierw nie rozumiał, w czym jest problem. Dopiero gdy pokazałem mu, że potrafię zrecenzować jego endpoint, ale nie potrafię powiedzieć, czy quiz w ogóle się odpala, dotarło do nas obu, że nie patrzymy na ten sam produkt.

Powiedzieliśmy sobie wprost:

Dobra, spróbujmy inaczej.

Nie zmieniliśmy architektury. Nie wyrzuciliśmy quality gates. Nie zrezygnowaliśmy z security.

Zmienił się tylko sposób organizacji pracy.

Mój znajomy został przy component slicing. Ja przeszedłem na thin vertical slicing.

I praktycznie natychmiast poczułem różnicę. Nagle po każdym issue:

• widziałem zmianę w UI,
• potrafiłem kliknąć flow użytkownika,
• mogłem ocenić outcome,
• szybciej poprawiałem agentów,
• lepiej rozumiałem progres.

Najważniejsze: znów miałem poczucie kontroli nad produktem.

I to nie było tylko poczucie komfortu. Kiedy znów widziałem outcome po każdym issue, mogłem na bieżąco wyłapywać błędy w założeniach i korygować kierunek, zanim urosły. Mogłem dostosować produkt do tego, co naprawdę chcieliśmy zbudować, a nie do tego, co wynikło z dosłownie zinterpretowanego taska.

Bo to jest sedno pracy z agentami: AI robi dokładnie to, o co prosimy – niekoniecznie to, czego potrzebujemy. Żeby w ogóle zobaczyć tę różnicę, musiałem najpierw wrócić do swojej perspektywy – tej od strony użytkownika.

To nie jest artykuł przeciw component slicing

Component slicing w wielu miejscach realnie wygrywał. Szczególnie tam, gdzie liczyły się:

• bezpieczeństwo,
• izolacja odpowiedzialności,
• migracje,
• atomowość,
• kontrakty,
• event-driven architecture.

Niektóre taski wręcz powinny pozostać komponentowe.

Dobrym przykładem były migracje bazy danych albo security review endpointów. Rozbijanie tego na TVS tylko po to, żeby szybciej zobaczyć ekran, mogłoby bardziej zaszkodzić niż pomóc.

Problem nie polegał więc na tym, że jedno podejście było lepsze. Polegał na tym, że różne modele pracy optymalizują różne feedback loopy, a AI bardzo mocno wzmacnia tę różnicę.

U nas był to mały setup: dwie osoby i jeden projekt. Ale ten sam rozjazd skaluje się wprost z zespołem: im więcej ludzi pracuje na komponentowym backlogu i im szybciej „agenty” dowożą kod, tym więcej osób naraz traci kontakt z outcome’em. W dużym delivery to już nie prywatny dyskomfort jednej osoby, tylko koszt rozłożony na cały zespół. Tym droższy, im dłużej nikt go nie nazwie.

Enabler, feature i pytanie, komu pokazać demo

Jest jeszcze jedno rozróżnienie, które przez pierwsze issue kompletnie mi umykało: nie każda praca ma bezpośrednio dowieźć coś użytkownikowi. Część z niej buduje drogę pod to, co użytkownik dostanie później: infrastrukturę, kontrakty, warstwę bezpieczeństwa.

W języku, którego zaczęliśmy używać, podział jest taki:

• feature (coś, co zobaczy użytkownik), 
• enabler (coś, co dopiero feature umożliwia).

I tu wracał nasz stały spór: co pokazać na demo, skoro przez cały dzień robiło się enabler? Bo enabler nie ma ekranu.

Nauczyliśmy się, że enabler też się demonstruje, tylko inaczej: pokazujesz, co teraz stało się możliwe, jaki artefakt powstał, jaki test bezpieczeństwa przeszedł. Nie „oto ekran”, tylko „oto dlaczego następny ekran w ogóle da się zbudować”. A biznesowo enabler broni się dopiero wtedy, gdy potrafisz go przypiąć do konkretnego feature’u, który odblokowuje: „zbudowaliśmy warstwę WebSocketów” nikogo nie interesuje, ale „bez tego live quiz się nie odpali, a to sedno produktu” – już tak. Jeśli takiej linii do wartości nie umiesz pociągnąć, to sygnał, że enabler może wcale nie być teraz potrzebny.

Ale najważniejsze okazało się inne pytanie, zadawane przed każdym demem: dla kogo to pokazujemy? Bo od perspektywy odbiorcy zależy, czy w ogóle dostaniemy wartościowy feedback.

Kiedy demo enablera trafiało do mnie – osoby patrzącej przez outcome – nie miałem czego dotknąć, a mój feedback sprowadzał się do „no dobra, wierzę ci”. Zmarnowany czas po obu stronach. Ten sam enabler, pokazany koledze, który myśli w kontraktach i subsystemach, generował konkretne uwagi – bo miał czym operować.

Przy feature’ach było odwrotnie: to ja byłem właściwym odbiorcą, bo potrafiłem kliknąć flow i powiedzieć: „to nie idzie w stronę naszej wizji”. Wniosek, który sobie zapisaliśmy, jest prosty: dobierz odbiorcę demo do tego, co pokazujesz – inaczej dostaniesz uprzejme „ok” zamiast realnej weryfikacji, a o problemie dowiesz się dużo później, niż mogłeś.

Wspólne DoD okazało się ważniejsze niż wspólny backlog

Najciekawsze jest chyba to, że finalnie nie skończyliśmy na jednym workflow. Skończyliśmy na dwóch różnych workflow z jednym wspólnym DoD.

Każdy merge musiał przejść:

• CI,
• security gate’y,
• quality review,
• acceptance scenario w staging.

Nieważne czy issue było:

• komponentowe,
• vertical slice,
• backendowe,
• UX-oriented.

Definition of Done pozostawało wspólne.

I być może to był najważniejszy insight z całego eksperymentu.

Nie potrzebowaliśmy identycznego sposobu pracy. Potrzebowaliśmy wspólnej definicji jakości.

Agile

Nasi eksperci przeprowadzą zwinną transformację Twojej organizacji, co pozwoli Ci na szybsze wprowadzanie produktów na rynek i przyspieszy realizację projektów.

Oferta Agile

Co z tego wynika dla Ciebie

Gdybym miał zostawić Wam kilka rzeczy na wynos – bez wracania do całej historii – wybrałbym te:

• Sposób krojenia backlogu to nie kosmetyka. Component slicing daje izolację i atomowość, a thin vertical slicing – widoczność outcome’u. Żaden nie jest „lepszy” w oderwaniu od człowieka, który po nim pracuje i od tego, jak ten człowiek widzi produkt: przez kod czy przez to, co dostaje użytkownik.
• AI wzmacnia każdy mismatch. To, co przed agentami było drobnym dyskomfortem, przy agentic development zamienia się w realny koszt, bo kodu przybywa szybciej, niż jesteś w stanie zbudować jego mentalny model.
• Jeśli tracisz orientację w produkcie, zmień sposób krojenia pracy, zanim zmienisz architekturę. Często to wystarczy, żeby odzyskać poczucie kontroli.
• Nie musicie pracować tak samo. Musicie mieć wspólny Definition of Done. To DoD, nie wspólny backlog, trzyma jakość, gdy każdy tnie pracę po swojemu.
• Ale ten wspólny DoD musi być egzekwowalny, nie deklaratywny. U nas trzymały go CI, security gate’y, quality review i acceptance na stagingu, a nie zapis w Confluence. Dwa workflow bez twardego, wymuszanego DoD to nie elastyczność, tylko powolny dryf w dwie różne strony.
• Zanim pokażesz demo, ustal, kto będzie jego odbiorcą. Enabler oceni sensownie tylko ktoś patrzący przez kod; feature – ktoś patrzący przez outcome. Pokazanie enablera „outcome’owcowi” da ci uprzejme „ok” zamiast feedbacku i przesunie wykrycie problemu w czasie.

Najprostszy test, jaki sobie zostawiliśmy: jeśli zamykasz issue i wciąż nie umiesz powiedzieć, czy produkt jest bliżej Waszej wizji – to nie problem agenta. To sygnał, że Twój sposób krojenia pracy rozjechał się z tym, jak budujesz produkt w swojej głowie.

A jaka jest Wasza percepcja na ten temat? Spotkaliście się z podobnym rozjazdem w swoich zespołach. Jak sobie z nim poradziliście? Chętnie poczytam w komentarzach.