eXtreme Programming

eXtreme Programming — zwykle po prostu XP — to najbardziej wymagający członek rodziny agile. East Agile Tracker jest zbudowany przede wszystkim z myślą o XP; wszystko inne z tego wynika.

Ta strona omawia, czym jest XP, dlaczego działa i jak praktykować je z trackerem jako powierzchnią planistyczną.

Czym jest XP

XP zostało stworzone przez Kenta Becka pod koniec lat 90. Pierwsza książka — Extreme Programming Explained: Embrace Change — została opublikowana w 1999 roku. Zaczęło się, jak wiele rzeczy, od sfrustrowanego zespołu próbującego dostarczyć system płacowy w Chryslerze.

Założeniem XP jest to, że właściwym sposobem radzenia sobie z niepewnością w oprogramowaniu jest robienie rzeczy, które działają, i robienie ich częściej. Testować? Testuj cały czas. Integrować? Integruj co godzinę. Rozmawiać? Rozmawiaj nieustannie. Planować? Planuj każdą iterację i przeplanowuj w miarę uczenia się.

„XP to lekka metodologia dla małych i średnich zespołów tworzących oprogramowanie w obliczu niejasnych lub szybko zmieniających się wymagań.” — Kent Beck

Pięć wartości

XP nazywa pięć wartości, na których wisi wszystko inne:

1. Komunikacja — Zespół rozmawia. Codziennie. O pracy, projekcie, przeszkodach. Twarzą w twarz, gdy to możliwe. Silosy są wrogiem.
2. Prostota — Rób najprostszą rzecz, która mogłaby zadziałać. Złożoność możesz dodać później, jeśli faktycznie będzie potrzebna. Prawdopodobnie nie będzie.
3. Informacja zwrotna — Od kodu (testy), od zespołu (programowanie w parach, recenzje), od użytkownika (częste wydania). Uzyskuj ją szybko.
4. Odwaga — Mów prawdę o postępie, estymacjach i projekcie. Wyrzucaj kod, który nie działa. Refaktoryzuj to, co Cię hamuje.
5. Szacunek — Każdy w zespole — a teraz każdy agent w zespole — wnosi wartość. Traktujcie się odpowiednio.

Praktyki

XP jest słynne ze swoich dwunastu oryginalnych praktyk, zorganizowanych w czterech obszarach:

Planowanie

• Planning Game — Zespół i klient planują razem: co dalej, w jakiej kolejności, jak duży jest każdy kawałek.
• Small Releases — Wydawaj często. Dni, nie miesiące. Uzyskaj informację zwrotną na temat czegoś konkretnego.
• User Stories — Wymagania to rozmowy, ujęte jako krótkie historie z punktu widzenia użytkownika. „Jako użytkownik chcę X, aby Y.”

Projektowanie

• Simple Design — Najprostszy projekt, który przechodzi testy i wyraża każde potrzebne pojęcie. Nic więcej.
• Refactoring — Ulepszaj projekt kodu, który już działa. Nieustannie.
• System Metaphor — Wspólna opowieść o tym, jak działa system, używana do utrzymania spójności decyzji projektowych.

Kodowanie

• Pair Programming — Dwóch deweloperów, jedna klawiatura. Jeden prowadzi, jeden nawiguje. Zmieniaj się często.
• Collective Code Ownership — Każdy może ulepszyć dowolny kod. Żadnych lenn.
• Continuous Integration — Integruj i testuj kod wiele razy dziennie. Wychwytuj usterki natychmiast.
• Coding Standards — Uzgodniony styl, aby kod czytał się tak, jakby napisała go jedna osoba.

Testowanie

• Test-Driven Development (TDD) — Najpierw napisz nieprzechodzący test, potem kod, który sprawi, że przejdzie.
• Acceptance Tests — Klient definiuje, w kodzie lub formie wykonywalnej, co oznacza „ukończone” dla każdej historii.

Dlaczego XP działa

XP jest niewygodne. Programowanie w parach zmusza Cię do myślenia na głos. TDD zmusza Cię do wiedzy, jak wygląda sukces, zanim napiszesz kod. Ciągła integracja zabija Twoje ulubione długowieczne gałęzie. Małe wydania oznaczają, że nie możesz schować się za sześciomiesięczną mapą drogową.

Działa, ponieważ wszystkie te rzeczy skracają pętle informacji zwrotnej. Im szybciej dowiesz się, że się myliłeś, tym tańsza korekta. XP jest, w swej istocie, o uczynieniu pętli informacji zwrotnej tak ciasną, jak to tylko możliwe.

Chodzi w nim także o odwagę i szacunek. XP można uprawiać tylko w zespole, który ufa sobie na tyle, by mylić się na głos.

Zdyscyplinowany model historii

East Agile Tracker koduje konkretną teorię planowania. Potraktuj tę sekcję jako instrukcję obsługi tego, dlaczego model danych wygląda tak, jak wygląda — oraz jako przewodnik terenowy, co robić (a czego nie) w praktyce.

Dlaczego cztery typy historii mają znaczenie

Wszystko jest historią, ale są cztery rodzaje, a samo rozróżnienie jest tu istotą rzeczy:

• Features niosą punkty i są jedyną rzeczą, która „liczy się” do prędkości. To zmusza Cię do dzielenia pracy na obserwowalną dla użytkownika wartość.
• Bugs są niepunktowane (zero). Defekty nie zarabiają punktów, co czyni koszt poprawek widocznym, a nie nagradzanym.
• Chores są również niepunktowane — konieczna praca bez bezpośredniej wartości dla użytkownika (infrastruktura, refaktoryzacje, konfiguracja). Trzymanie ich na zerze motywuje zespół do łączenia ich z features wszędzie tam, gdzie to możliwe, aby ujęcie wartości pozostawało uczciwe.
• Releases to znaczniki o zerowej liczbie punktów, używane do zakotwiczania kamieni milowych i umożliwienia narzędziu prognozowania daty.

Liczy się efekt behawioralny: gdy bugs i chores nie zdobywają punktów, zespół naturalnie dąży do wyrażania pracy jako funkcjonalności zorientowanej na użytkownika i staje się dotkliwie świadomy kosztu defektów. To dyscyplina planistyczna zakodowana w modelu danych.

Jeden uporządkowany backlog

Trzy strefy, jedna zasada.

• Icebox to pula nieuporządkowanych pomysłów.
• Backlog to ściśle uporządkowana lista o jednym priorytecie — bez remisów, bez „P1/P1/P1”.
• Strefa Current mieści aktywną iterację (lub iteracje).

Właściciel produktu jest odpowiedzialny za kolejność od góry do dołu, a niezmiennikiem jest, że szczyt backlogu jest zawsze najważniejszy i najlepiej dookreślony, a klarowność maleje, w uzasadniony sposób, w miarę schodzenia w dół. Historia blisko szczytu z niejasnymi kryteriami akceptacji to błąd planistyczny. Icebox ma prawo być cmentarzyskiem; Backlog nie.

Automatyczne planowanie oparte na prędkości

To część, którą większość zespołów źle reimplementuje gdzie indziej. Planowanie w stylu trackera oblicza kroczącą średnią prędkość na podstawie ostatnio zaakceptowanych punktów i automatycznie zaciąga taką liczbę punktów historii do następnej iteracji — nie „zobowiązujesz się” ręcznie do sprintu, robią to za Ciebie dane empiryczne. Dwie konsekwencje warte zachowania:

• Estymujesz wyłącznie features, używając względnych punktów (Fibonacci 1/2/3/5/8 lub nasze ciaśniejsze 0/1/2/3), a nie godzin. Estymacja to rozmowa o rozmiarze, a nie obietnica.
• Nie oszukujesz prędkości. Zawyżanie punktów, by „wyglądać szybko”, albo punktowanie chores rozbija prognozę, która czyni cały system uczciwym. Prędkość jest instrumentem pomiarowym, a Ty nie majstrujesz przy własnym instrumencie.

Korzyść jest taka, że prognoza daty wydania staje się obliczeniem, a nie negocjacją, a rozmowa z interesariuszami przesuwa się z „czy możesz zobowiązać się do X do piątku” na „przy bieżącej prędkości to wydanie wypada w okolicach daty Y — oto kompromis zakres/data”.

Cykl życia historii i pętla akceptacji

Maszyna stanów to Start → Finish → Deliver → Accept / Reject. Kluczowym stanem jest Deliver: inżynier oznacza historię jako dostarczoną, ale nie jest ona ukończona, dopóki właściciel produktu jawnie nie zaakceptuje jej względem jej kryteriów akceptacji — albo nie odrzuci, cofając ją z powrotem. To wbudowuje pętlę informacji zwrotnej od klienta w każdą pojedynczą historię, zamiast odkładać akceptację do demonstracji na koniec sprintu.

Kryteria akceptacji powinny znaleźć się na historii przed jej rozpoczęciem, najlepiej w formie Given/When/Then, aby przekładały się bezpośrednio na testy akceptacyjne. INVEST to test zdroworozsądkowy sprawdzający, czy historia jest dobrze sformułowana:

• Independent (niezależna) — może zostać wydana bez innych historii.
• Negotiable (negocjowalna) — ujmuje intencję, a nie zamrożoną specyfikację.
• Valuable (wartościowa) — dla użytkownika lub interesariusza.
• Estimable (estymowalna) — zespół potrafi określić jej rozmiar.
• Small (mała) — komfortowo mieści się w iteracji.
• Testable (testowalna) — ma kryteria akceptacji, które można sprawdzić.

Rytm

Ceremonie planistyczne są lekkie i regularne:

• Cotygodniowe Iteration Planning Meeting, aby wypunktować nowe historie i ustalić kryteria akceptacji na szczycie backlogu.
• Krótki codzienny standup skupiony na przepływie i blokerach.
• Retrospektywa per iteracja, aby dostosować proces.

Iteracje zwykle trwają jeden lub dwa tygodnie — na tyle krótko, że odkrycie złej estymacji jest tanie.

Praktyki inżynierskie, które sprawiają, że planowanie działa

Planowanie w stylu trackera to widoczna połowa XP; rozpada się bez połowy inżynierskiej.

• Test-first / TDD oraz prawdziwy zestaw testów akceptacyjnych to to, co sprawia, że „delivered” coś znaczy.
• Ciągła integracja oraz małe, częste wydania utrzymują krótki czas cyklu, dzięki czemu prędkość jest stabilna, a nie nierówna.
• Programowanie w parach (lub solidna recenzja) utrzymuje niski poziom pracy w toku — kończ, zanim zaczniesz — co jest największą pojedynczą dźwignią czasu cyklu.
• Dostępny właściciel produktu to to, co powstrzymuje pętlę accept/reject przed utknięciem.

Antywzorce, na które warto uważać

Powtarzające się porażki:

• Traktowanie Backlogu jako parkingu zamiast prawdziwego porządku priorytetów.
• Estymowanie bugs i chores, aby prędkość wyglądała lepiej.
• Niesienie ogromnych historii, których nie da się ukończyć w iteracji. Dziel, aż każda będzie niezależnie dostarczalna.
• Pozwalanie, by historie piętrzyły się w Delivered, ponieważ nikt nie akceptuje.

Każdy z nich po cichu zamienia system empiryczny z powrotem w planowanie życzeniowe. Tracker nie może powstrzymać Cię przed ich robieniem; może je tylko uczynić widocznymi. Patrz na swoją kolumnę Delivered na koniec każdej iteracji — jeśli rośnie, to Twój sygnał.

XP z East Agile Tracker

Tracker to powierzchnia planistyczna, której zespoły XP chciały od czasów Pivotal Tracker. Każde pojęcie odwzorowuje się bezpośrednio:

User Stories → Stories

Historie użytkownika XP to historie East Agile Tracker. Pisz je w typie Feature. Użyj opisu do rozmowy; użyj komentarzy do bieżącej dyskusji. Kryteria akceptacji należą do opisu.

Planning Game → Tablica

Planning Game w XP to rozmowa między biznesem a zespołem o priorytecie i rozmiarze. W East Agile Tracker:

1. Osoba produktowa pisze historie w Backlogu i porządkuje je według priorytetu.
2. Zespół estymuje features w punktach (skala Fibonacci lub East Agile).
3. System automatycznie planuje iteracje na podstawie prędkości.
4. Zespół rozpoczyna historie ze szczytu kolumny Current.

To wszystko. „Gra” żyje w rozmowie; tracker po prostu prowadzi punktację.

Small Releases → Releases (typ historii)

XP mówi: wydawaj często. Release to jeden z czterech typów historii w East Agile Tracker. Utwórz wydanie dla każdego kamienia milowego dostawy; przeciągnij je do iteracji, w której zostanie wypuszczone. Wydania pomijają Started/Finished/Delivered i przechodzą prosto do Accepted, gdy je wypuszczasz.

Continuous Integration → Maszyna stanów historii

Maszyna stanów nie jest CI jako takim — to Twój system budowania — ale ścieżka Finished → Delivered → Accepted odzwierciedla pętlę akceptacji klienta, którą opisuje XP. Zakończ pracę, dostarcz ją klientowi, zaakceptuj, gdy potwierdzono, że działa.

Velocity → „Pogoda z wczoraj”

XP nazywa to pogodą z wczoraj: ile zrobiłeś w ostatniej iteracji jest najlepszą prognozą tego, ile zrobisz w tej. East Agile Tracker oblicza prędkość automatycznie — średnia z ostatnich iteracji, konfigurowalna strategia — i używa jej do automatycznego planowania pojemności następnej iteracji.

Acceptance Tests → Reviews

Recenzje historii w trackerze odwzorowują akceptację. Przypisz recenzenta (klienta, właściciela produktu lub nawet agenta działającego jako jeden z nich). Zatwierdza lub odrzuca. Odrzucenie odsyła historię z powrotem do Started.

Pair Programming → Współwłasność

Zespoły XP pracują w parach nad kodem. W trackerze przejawia się to jako wielu właścicieli historii. Przypisz obie osoby z pary do historii; oba imiona pojawią się na karcie.

XP z agentami — nowa praktyka

XP zostało napisane, zanim agenci AI mogli znacząco przyczyniać się do tworzenia oprogramowania. Uważamy, że to najważniejsza aktualizacja XP od dwudziestu pięciu lat.

W naszej praktyce — i do tego tracker jest zbudowany — agent jest wymienionym z imienia członkiem zespołu XP. Ma własną rolę, własnego partnera z pary (człowieka lub agenta) oraz własną ścieżkę audytową. Może robić wszystko, co ludzki członek zespołu na powierzchni planistycznej: estymować, posiadać historie, komentować, przechodzić stanami, akceptować recenzje.

Wartości XP wciąż obowiązują. Komunikacja: agenci komunikują się, czytając strumień zdarzeń i zamieszczając komentarze. Prostota: agenci są ograniczeni do ról, które im nadasz. Informacja zwrotna: każda akcja agenta jest w dzienniku audytu, natychmiast możliwa do zrecenzowania. Odwaga: bądź uczciwy co do tego, co Twoi agenci zrobili dobrze, a czego nie. Szacunek: członkowie zespołu będący agentami wnoszą wartość — doceń to.

Nie umieszczamy agentów wewnątrz trackera, żeby kodowali. Dajemy powierzchnię planistyczną ludziom i agentom współpracującym razem. Ty dostarczasz agenta kodującego — Claude Code, Codex, własnego — i łączysz go z trackerem przez API. Agent podejmuje historie, wykonuje pracę, komentuje, przechodzi stanami. Ty recenzujesz ślad i akceptujesz.

To Inkluzywne Planowanie Zwinne. To XP, z zespołem, który faktycznie masz.

Dalsza lektura

• Extreme Programming Explained — Fundamentalna książka Kenta Becka, 1999.
• Manifest Agile — Gdzie zaczęła się rodzina.
• Rozwój zwinny — Szerszy obraz.
• Instrukcja obsługi — Praktyczny przewodnik po trackerze.
• Przewodnik po API — Podłączanie Twojego agenta kodującego.