eXtreme Programming

eXtreme Programming — obvykle jen XP — je nejnáročnějším členem agilní rodiny. East Agile Tracker je vytvořen primárně pro XP; všechno ostatní z toho vyplývá.

Tato stránka popisuje, co XP je, proč funguje a jak ho praktikovat s trackerem jako vaší plánovací plochou.

Co je XP

XP vytvořil Kent Beck na konci 90. let. První kniha — Extreme Programming Explained: Embrace Change — vyšla v roce 1999. Začalo to, jako mnoho věcí, frustrovaným týmem, který se snažil dodat mzdový systém ve společnosti Chrysler.

Sázka XP spočívá v tom, že správný způsob, jak zvládnout nejistotu v softwaru, je dělat věci, které fungují, a dělat je častěji. Testovat? Testovat pořád. Integrovat? Integrovat každou hodinu. Mluvit? Mluvit neustále. Plánovat? Plánovat každou iteraci a přeplánovávat, jak se učíte.

„XP je odlehčená metodologie pro malé až středně velké týmy vyvíjející software tváří v tvář vágním nebo rychle se měnícím požadavkům.” — Kent Beck

Pět hodnot

XP pojmenovává pět hodnot, na kterých visí všechno ostatní:

1. Komunikace — Tým mluví. Denně. O práci, o návrhu, o překážkách. Tváří v tvář, kdykoli je to možné. Sila jsou nepřítel.
2. Jednoduchost — Dělejte tu nejjednodušší věc, která by mohla fungovat. Složitost můžete přidat později, pokud ji skutečně potřebujete. Pravděpodobně nebudete.
3. Zpětná vazba — Z kódu (testy), od týmu (párové programování, recenze), od uživatele (časté releases). Získejte ji rychle.
4. Odvaha — Říkejte pravdu o pokroku, odhadech a návrhu. Zahoďte kód, který nefunguje. Refaktorujte to, co vás drží zpět.
5. Respekt — Každý člen týmu — a nyní každý agent v týmu — přispívá hodnotou. Chovejte se k sobě podle toho.

Praktiky

XP je proslulý svými dvanácti původními praktikami, uspořádanými do čtyř oblastí:

Plánování

• Plánovací hra — Tým a zákazník plánují společně: co přijde příště, v jakém pořadí, jak velký je každý kus.
• Malé releases — Dodávejte často. Dny, ne měsíce. Získejte zpětnou vazbu na něco konkrétního.
• Uživatelské příběhy — Požadavky jsou rozhovory, zachycené jako krátké příběhy z pohledu uživatele. „Jako uživatel chci X, abych Y.”

Návrh

• Jednoduchý design — Nejjednodušší návrh, který projde testy a vyjadřuje každý potřebný koncept. Nic víc.
• Refaktoring — Vylepšujte návrh kódu, který už funguje. Neustále.
• Systémová metafora — Sdílený příběh o tom, jak systém funguje, používaný k tomu, aby návrhová rozhodnutí byla konzistentní.

Kódování

• Párové programování — Dva vývojáři, jedna klávesnice. Jeden řídí, druhý naviguje. Často se střídejte.
• Kolektivní vlastnictví kódu — Kdokoli může vylepšit jakýkoli kód. Žádná léna.
• Kontinuální integrace — Integrujte a testujte kód mnohokrát denně. Zachyťte rozbití okamžitě.
• Kódovací standardy — Dohodnutý styl, aby se kód četl, jako by ho napsal jeden člověk.

Testování

• Test-Driven Development (TDD) — Nejprve napište selhávající test, poté kód, který ho zprůchodní.
• Akceptační testy — Zákazník definuje, v kódu nebo ve spustitelné formě, co znamená „hotovo” pro každou story.

Proč XP funguje

XP je nepohodlné. Párové programování vás nutí přemýšlet nahlas. TDD vás nutí vědět, jak úspěch vypadá, dříve než napíšete kód. Kontinuální integrace zabíjí vaše oblíbené dlouhožijící větve. Malé releases znamenají, že se nemůžete schovat za šestiměsíční plán.

Funguje to, protože všechny tyto věci zkracují zpětnovazební smyčky. Čím rychleji zjistíte, že jste se mýlili, tím levnější je oprava. XP je v základu o tom, aby zpětnovazební smyčka byla co nejtěsnější.

Je to také o odvaze a respektu. XP můžete dělat jen v týmu, který si navzájem dost důvěřuje na to, aby se nahlas mýlil.

Disciplinovaný model story

East Agile Tracker zakódovává konkrétní teorii plánování. Berte tuto sekci jako provozní příručku k tomu, proč datový model vypadá tak, jak vypadá — a jako terénního průvodce tím, co dělat (a nedělat) v praxi.

Proč na čtyřech typech story záleží

Všechno je story, ale existují čtyři druhy, a právě v tom rozdílu spočívá celý smysl:

• Features nesou body a jsou jediné, co se „počítá” do rychlosti. To vás nutí krájet práci na hodnotu pozorovatelnou uživatelem.
• Bugs jsou bez bodů (nula). Vady nezískávají kredit, což činí náklady na přepracování viditelnými, místo aby byly odměňovány.
• Chores jsou také bez bodů — nezbytná práce bez přímé uživatelské hodnoty (infrastruktura, refaktory, nastavení). Jejich udržování na nule tlačí tým k tomu, aby je kdekoli je to možné spojoval s features, aby zůstal rámec hodnoty poctivý.
• Releases jsou značky s nulou bodů používané k ukotvení milníků a k tomu, aby nástroj mohl projektovat datum.

Důležitý je behaviorální efekt: když bugs a chores nedávají body, tým přirozeně tlačí na to, aby práci vyjadřoval jako funkcionalitu orientovanou na uživatele, a začne si akutně uvědomovat náklady na vady. To je plánovací disciplína zakódovaná v datovém modelu.

Jediný seřazený backlog

Tři zóny, jedno pravidlo.

• Icebox je bazén neprioritizovaných nápadů.
• Backlog je striktně seřazený seznam s jedinou prioritou — žádné shody, žádné „P1/P1/P1.”
• Zóna Current drží aktivní iteraci(e).

Produktový vlastník vlastní pořadí shora dolů a invariant je, že vrchol backlogu je vždy nejdůležitější a nejlépe specifikovaný, přičemž jasnost legitimně klesá, jak postupujete dolů. Story blízko vrcholu s vágními akceptačními kritérii je plánovací chyba. Icebox smí být hřbitovem; Backlog ne.

Automatické plánování řízené rychlostí

Tohle je část, kterou většina týmů jinde špatně reimplementuje. Plánování ve stylu trackeru počítá klouzavý průměr rychlosti z nedávno akceptovaných bodů a automaticky natáhne tolik bodů stories do další iterace — ručně se ke sprintu „nezavazujete”, empirická data to dělají za vás. Dva důsledky stojí za zachování:

• Odhadujete pouze features, pomocí relativních bodů (Fibonacci 1/2/3/5/8 nebo naše těsnější 0/1/2/3), ne hodin. Odhadování je rozhovor o velikosti, ne slib.
• Nemanipulujete s rychlostí. Nafukování bodů, aby to „vypadalo rychle”, nebo bodování chores rozbíjí projekci, která činí celý systém poctivým. Rychlost je měřicí přístroj a do vlastního přístroje nezasahujete.

Odměnou je, že projekce data vydání se stává výpočtem, a ne vyjednáváním, a rozhovor se zúčastněnými stranami se posune od „dokážeš se zavázat k X do pátku” k „při současné rychlosti tento release přistane kolem data Y — tady je kompromis rozsah/datum.”

Životní cyklus story a akceptační smyčka

Stavový automat je Start → Finish → Deliver → Accept / Reject. Kritickým stavem je Deliver: inženýr označí story jako doručenou, ale ta není hotová, dokud ji produktový vlastník výslovně neakceptuje vůči jejím akceptačním kritériím — nebo neodmítne, čímž ji vrátí zpět. Tím se do každé jednotlivé story zabuduje zpětnovazební smyčka se zákazníkem, místo aby se akceptace odkládala na demo na konci sprintu.

Akceptační kritéria patří na story dříve, než se začne pracovat, ideálně ve formě Given/When/Then, aby se přímo mapovala na akceptační testy. INVEST je kontrola zdravého rozumu, zda je story dobře utvořená:

• Independent (Nezávislá) — může být vydána bez ostatních stories.
• Negotiable (Vyjednatelná) — zachycuje záměr, ne zmrazenou specifikaci.
• Valuable (Hodnotná) — pro uživatele nebo zúčastněnou stranu.
• Estimable (Odhadnutelná) — tým ji dokáže ocenit.
• Small (Malá) — pohodlně se vejde do iterace.
• Testable (Testovatelná) — má akceptační kritéria, která lze procvičit.

Kadence

Plánovací ceremonie jsou lehké a pravidelné:

• Týdenní schůzka pro plánování iterace k obodování nových stories a upevnění akceptačních kritérií na vrcholu backlogu.
• Krátký denní standup zaměřený na tok a blokátory.
• Retrospektiva za iteraci k úpravě procesu.

Iterace jsou obvykle jeden nebo dva týdny — dost krátké na to, aby bylo objevení špatného odhadu levné.

Inženýrské praktiky, které plánování zprovozňují

Plánování ve stylu trackeru je viditelná polovina XP; bez inženýrské poloviny se hroutí.

• Test-first / TDD a skutečná sada akceptačních testů jsou tím, co dává „delivered” smysl.
• Kontinuální integrace a malé, časté releases udržují dobu cyklu krátkou, takže rychlost je stabilní, a ne hrudkovitá.
• Párové programování (nebo silná recenze) udržuje rozpracovanou práci nízkou — dokonči, než začneš — což je největší jediná páka na dobu cyklu.
• Dostupný produktový vlastník je to, co brání akceptační smyčce v zaseknutí.

Anti-vzory, na které si dát pozor

Opakovaná selhání:

• Zacházení s Backlogem jako s parkovištěm namísto skutečného prioritního pořadí.
• Odhadování bugs a chores, aby rychlost vypadala lépe.
• Tahání obrovských stories, které nelze dokončit v iteraci. Rozdělujte, dokud nebude každá nezávisle doručitelná.
• Hromadění stories v Delivered, protože je nikdo neakceptuje.

Kterékoli z nich tiše přeměňuje empirický systém zpět na zbožné plánování. Tracker vám v tom nemůže zabránit; může je jen zviditelnit. Podívejte se na svůj sloupec Delivered na konci každé iterace — pokud roste, to je váš signál.

XP s East Agile Tracker

Tracker je plánovací plocha, kterou XP týmy chtěly už od dob Pivotal Tracker. Každý koncept se přímo mapuje:

Uživatelské příběhy → Stories

XP uživatelské příběhy jsou stories v East Agile Tracker. Pište je v typu Feature. Popis použijte pro rozhovor; komentáře použijte pro průběžnou diskuzi. Akceptační kritéria patří do popisu.

Plánovací hra → Tabule

Plánovací hra v XP je rozhovor mezi byznysem a týmem o prioritě a velikosti. V East Agile Tracker:

1. Produktová osoba píše stories v Backlogu a řadí je podle priority.
2. Tým odhaduje features v bodech (Fibonacci nebo East Agile škála).
3. Systém automaticky plánuje iterace podle rychlosti.
4. Tým začíná stories z vrcholu sloupce Current.

To je celé. „Hra” žije v rozhovoru; tracker jen drží skóre.

Malé releases → Releases (typ story)

XP říká vydávejte často. Release je jeden ze čtyř typů story v East Agile Tracker. Vytvořte release pro každý dodací milník; přetáhněte jej do iterace, kde se dodává. Releases přeskakují Started/Finished/Delivered a jdou přímo do Accepted, když dodáte.

Kontinuální integrace → Stavový automat story

Stavový automat není CI jako takové — to je váš sestavovací systém — ale cesta Finished → Delivered → Accepted zrcadlí akceptační smyčku zákazníka, kterou XP popisuje. Dokončete práci, doručte ji zákazníkovi, akceptujte, když je potvrzeno, že funguje.

Rychlost → „Včerejší počasí”

XP tomu říká včerejší počasí: kolik jste toho udělali minulou iteraci, je nejlepší předpovědí toho, kolik toho uděláte tuto. East Agile Tracker počítá rychlost automaticky — průměr nedávných iterací, konfigurovatelná strategie — a používá ji k automatickému naplánování kapacity další iterace.

Akceptační testy → Recenze

Recenze story v trackeru se mapují na akceptaci. Přiřaďte recenzenta (zákazníka, produktového vlastníka, nebo i agenta jednajícího jako jeden z nich). Ten schválí nebo zamítne. Zamítnutí pošle story zpět do Started.

Párové programování → Spoluvlastnictví

XP týmy párují na kódu. V trackeru se to projevuje jako více vlastníků na story. Přiřaďte oba členy páru k story; oba názvy se objeví na kartě.

XP s agenty — nová praktika

XP bylo napsáno dříve, než mohli AI agenti smysluplně přispívat k softwaru. Myslíme si, že je to nejdůležitější aktualizace XP za pětadvacet let.

V naší praxi — a k tomu je tracker vytvořen — je agent pojmenovaným členem XP týmu. Má vlastní roli, vlastního párového partnera (člověka nebo agenta) a vlastní auditní stopu. Může dělat cokoli, co může lidský člen týmu v plánovací ploše: odhadovat, vlastnit stories, komentovat, měnit stavy, akceptovat recenze.

Hodnoty XP stále platí. Komunikace: agenti komunikují čtením proudu událostí a psaním komentářů. Jednoduchost: agenti jsou omezeni na role, které jim udělíte. Zpětná vazba: každá akce agenta je v auditním logu, okamžitě kontrolovatelná. Odvaha: buďte upřímní o tom, co vaši agenti udělali správně a co ne. Respekt: agentští kolegové přispívají hodnotou — uznejte to.

Nedáváme agenty dovnitř trackeru, aby kódovali. Dáváme plánovací plochu lidem a agentům, kteří pracují společně. Vy přinesete kódovacího agenta — Claude Code, Codex, svého vlastního — a připojíte ho k trackeru přes API. Agent si bere stories, dělá práci, komentuje, mění stavy. Vy zkontrolujete stopu a akceptujete.

Tohle je Inkluzivní agilní plánování. Je to XP s týmem, který skutečně má.

Další četba

• Extreme Programming Explained — Zakladatelská kniha Kenta Becka, 1999.
• Agilní manifest — Kde rodina začala.
• Agilní vývoj — Širší obraz.
• Provozní pokyny — Praktický průvodce trackerem.
• Průvodce API — Připojení vašeho kódovacího agenta.