eXtreme Programming

eXtreme Programming — som regel bare XP — er det mest krævende medlem af den agile familie. East Agile Tracker er bygget til XP først; alt andet falder ud af det.

Denne side dækker, hvad XP er, hvorfor det virker, og hvordan man praktiserer det med trackeren som sin planlægningsoverflade.

Hvad XP er

XP blev skabt af Kent Beck i slutningen af 1990’erne. Den første bog — Extreme Programming Explained: Embrace Change — udkom i 1999. Det startede, som mange ting, med et frustreret team, der forsøgte at levere et lønsystem hos Chrysler.

XP’s antagelse er, at den rigtige måde at håndtere usikkerhed i software på er at gøre de ting, der virker, og gøre dem oftere. Teste? Test hele tiden. Integrere? Integrer hver time. Tale? Tal konstant. Planlægge? Planlæg hver iteration, og omplanlæg, efterhånden som du lærer.

“XP er en letvægtsmetodologi til små til mellemstore teams, der udvikler software i mødet med vage eller hurtigt skiftende krav.” — Kent Beck

De fem værdier

XP navngiver fem værdier, som alt andet hænger på:

1. Kommunikation — Teamet taler. Dagligt. Om arbejdet, designet, forhindringerne. Ansigt til ansigt når muligt. Siloer er fjenden.
2. Enkelhed — Gør det enkleste, der overhovedet kunne virke. Du kan tilføje kompleksitet senere, hvis du faktisk har brug for det. Det får du sandsynligvis ikke.
3. Feedback — Fra koden (tests), fra teamet (parprogrammering, reviews), fra brugeren (hyppige releases). Få den hurtigt.
4. Mod — Sig sandheden om fremskridt, estimater og design. Smid kode væk, der ikke virker. Refaktorér det, der holder dig tilbage.
5. Respekt — Alle på teamet — og nu hver agent på teamet — bidrager med værdi. Behandl hinanden derefter.

Praksisserne

XP er berømt for sine tolv oprindelige praksisser, organiseret i fire områder:

Planlægning

• Planning Game — Teamet og kunden planlægger sammen: hvad kommer der næst, i hvilken rækkefølge, hvor stort er hvert stykke.
• Small Releases — Lever ofte. Dage, ikke måneder. Få feedback på noget konkret.
• User Stories — Krav er samtaler, fanget som korte stories fra brugerens synsvinkel. “Som en bruger vil jeg have X, så Y.”

Design

• Simple Design — Det enkleste design, der består testene og udtrykker hvert nødvendigt koncept. Ikke mere.
• Refactoring — Forbedr designet af kode, der allerede virker. Konstant.
• System Metaphor — En fælles fortælling om, hvordan systemet virker, brugt til at gøre designbeslutninger konsistente.

Kodning

• Pair Programming — To udviklere, ét tastatur. Den ene styrer, den anden navigerer. Skift ofte.
• Collective Code Ownership — Enhver kan forbedre enhver kode. Ingen len.
• Continuous Integration — Integrer og test kode mange gange om dagen. Fang nedbrud øjeblikkeligt.
• Coding Standards — En aftalt stil, så koden læses, som om én person skrev den.

Test

• Test-Driven Development (TDD) — Skriv den fejlende test først, derefter koden, der får den til at bestå.
• Acceptance Tests — Kunden definerer, i kode eller eksekverbar form, hvad “færdig” betyder for hver story.

Hvorfor XP virker

XP er ubehageligt. Parprogrammering tvinger dig til at tænke højt. TDD tvinger dig til at vide, hvordan succes ser ud, før du skriver koden. Kontinuerlig integration dræber dine yndlings-langtidslevende branches. Små releases betyder, at du ikke kan gemme dig bag en seks måneders roadmap.

Det virker, fordi alle disse ting forkorter feedback-loops. Jo hurtigere du finder ud af, at du tog fejl, jo billigere er rettelsen. XP handler grundlæggende om at gøre feedback-loopet så stramt, som det kan blive.

Det handler også om mod og respekt. Du kan kun lave XP på et team, der stoler nok på hinanden til at tage fejl højt.

Den disciplinerede story-model

East Agile Tracker indkoder en bestemt teori om planlægning. Behandl denne sektion som betjeningsmanualen for, hvorfor datamodellen ser ud, som den gør — og som feltguiden til, hvad man skal (og ikke skal) gøre i praksis.

Hvorfor de fire story-typer betyder noget

Alt er en story, men der er fire slags, og forskellen er hele pointen:

• Features bærer point og er det eneste, der “tæller” mod velocity. Dette tvinger dig til at skære arbejdet op i brugerobserverbar værdi.
• Bugs er upointede (nul). Defekter giver ikke kredit, hvilket gør omkostningen ved omarbejde synlig frem for belønnet.
• Chores er også upointede — nødvendigt arbejde uden direkte brugerværdi (infra, refaktoreringer, opsætning). At holde dem på nul presser teamet til at samle dem ind i features, hvor det er muligt, så værdiframingen forbliver ærlig.
• Releases er markører med nul point, brugt til at forankre milepæle og lade værktøjet prognosticere en dato.

Den adfærdsmæssige effekt er det, der betyder noget: når bugs og chores ikke scorer, presser et team naturligt på for at udtrykke arbejde som brugerorienteret funktionalitet, og det bliver akut bevidst om defektomkostninger. Det er en planlægningsdisciplin indkodet i datamodellen.

Den enkelte ordnede backlog

Tre zoner, én regel.

• Icebox er den uprioriterede idépulje.
• Backlog er en strengt ordnet liste med én enkelt prioritet — ingen uafgjorte, ingen “P1/P1/P1.”
• Current-zonen holder den eller de aktive iterationer.

Produktejeren ejer rækkefølgen fra top til bund, og invarianten er, at toppen af backloggen altid er den vigtigste og bedst specificerede, med klarhed der legitimt aftager, jo længere ned du kommer. En story nær toppen med vage acceptkriterier er en planlægningsfejl. Icebox må gerne være en kirkegård; Backlog må ikke.

Velocity-drevet automatisk planlægning

Dette er den del, de fleste teams genimplementerer dårligt andetsteds. Tracker-stil-planlægning beregner et rullende gennemsnit af velocity ud fra nyligt accepterede point og trækker automatisk det antal point af stories ind i den næste iteration — du “forpligter” dig ikke manuelt til et sprint, de empiriske data gør det for dig. To konsekvenser, det er værd at bevare:

• Du estimerer kun features, ved hjælp af relative point (Fibonacci 1/2/3/5/8 eller vores strammere 0/1/2/3), ikke timer. Estimering er en størrelsessamtale, ikke et løfte.
• Du manipulerer ikke velocity. At oppuste point for at “se hurtig ud” eller at pointgive chores bryder prognosen, der gør hele systemet ærligt. Velocity er et måleinstrument, og du pillder ikke ved dit eget instrument.

Gevinsten er, at prognosen for releasedato bliver en beregning frem for en forhandling, og samtalen med interessenter skifter fra “kan du forpligte dig til X inden fredag” til “ved den nuværende velocity lander denne release omkring dato Y — her er afvejningen mellem omfang og dato.”

Story-livscyklussen og accept-loopet

Tilstandsmaskinen er Start → Finish → Deliver → Accept / Reject. Den kritiske tilstand er Deliver: en ingeniør markerer en story som leveret, men den er ikke færdig, før produktejeren udtrykkeligt accepterer den mod dens acceptkriterier — eller afviser den, hvilket sparker den tilbage. Dette indbager et kundefeedback-loop i hver eneste story i stedet for at udskyde accept til en demo ved sprintens slutning.

Acceptkriterier hører hjemme på storyen før, den startes, ideelt set i Given/When/Then-form, så de afbilder direkte på accepttests. INVEST er fornuftskontrollen af, om en story er velformet:

• Independent — kan udgives uden andre stories.
• Negotiable — fanger intentionen, ikke en frossen specifikation.
• Valuable — for en bruger eller interessent.
• Estimable — teamet kan størrelsesvurdere den.
• Small — passer komfortabelt i en iteration.
• Testable — har acceptkriterier, der kan udøves.

Kadence

Planlægningsceremonierne er lette og regelmæssige:

• Et ugentligt iterationsplanlægningsmøde for at pointgive nye stories og fastlægge acceptkriterier i toppen af backloggen.
• En kort daglig standup med fokus på flow og blokkere.
• En retrospektiv pr. iteration for at justere processen.

Iterationer er normalt en eller to uger — kort nok til, at et dårligt estimat er billigt at opdage.

De tekniske praksisser, der får planlægning til at virke

Tracker-stil-planlægning er den synlige halvdel af XP; den kollapser uden den tekniske halvdel.

• Test-first / TDD og en rigtig accepttest-suite er det, der lader “delivered” betyde noget.
• Kontinuerlig integration og små, hyppige releases holder cyklustiden kort, så velocity er stabil frem for ujævn.
• Parprogrammering (eller stærk review) holder igangværende arbejde lavt — færdiggør før du starter — hvilket er den enkeltstående største løftestang på cyklustid.
• En tilgængelig produktejer er det, der holder accept-/afvisnings-loopet fra at gå i stå.

Antimønstre at holde øje med

De tilbagevendende fejl:

• At behandle Backloggen som en parkeringsplads i stedet for en ægte prioritetsrækkefølge.
• At estimere bugs og chores for at få velocity til at se bedre ud.
• At bære kæmpe stories, der ikke kan færdiggøres i en iteration. Split, indtil hver er uafhængigt leverbar.
• At lade stories hobe sig op i Delivered, fordi ingen accepterer.

Enhver af disse konverterer stille og roligt et empirisk system tilbage til ønsketænkende planlægning. Trackeren kan ikke stoppe dig fra at gøre dem; den kan kun gøre dem synlige. Se på din Delivered-kolonne ved slutningen af hver iteration — hvis den vokser, er det dit signal.

XP med East Agile Tracker

Trackeren er den planlægningsoverflade, XP-teams har ønsket sig siden Pivotal Tracker-dagene. Hvert koncept afbildes direkte:

User Stories → Stories

XP user stories er East Agile Tracker-stories. Skriv dem i Feature-typen. Brug beskrivelsen til samtalen; brug kommentarer til løbende diskussion. Acceptkriterierne hører hjemme i beskrivelsen.

Planning Game → Boardet

Planning Game i XP er en samtale mellem forretning og team om prioritet og størrelse. I East Agile Tracker:

1. Produktpersonen skriver stories i Backlog og ordner dem efter prioritet.
2. Teamet estimerer features i point (Fibonacci- eller East Agile-skala).
3. Systemet planlægger automatisk iterationer ud fra velocity.
4. Teamet starter stories fra toppen af Current-kolonnen.

Det er det. “Spillet” bor i samtalen; trackeren holder bare regnskabet.

Small Releases → Releases (story-typen)

XP siger lever ofte. Release er en af de fire story-typer i East Agile Tracker. Opret en release for hver leveringsmilepæl; træk den ind i den iteration, hvor den leveres. Releases springer Started/Finished/Delivered over og går direkte til Accepted, når du leverer.

Continuous Integration → Story-tilstandsmaskinen

Tilstandsmaskinen er ikke CI i sig selv — det er dit build-system — men stien Finished → Delivered → Accepted afspejler det kundeaccept-loop, XP beskriver. Færdiggør arbejdet, lever det til kunden, accepter når det er bekræftet velfungerende.

Velocity → “Yesterday’s weather”

XP kalder det yesterday’s weather: hvor meget du fik gjort sidste iteration er den bedste forudsigelse af, hvor meget du får gjort denne. East Agile Tracker beregner velocity automatisk — gennemsnit af nylige iterationer, konfigurerbar strategi — og bruger den til automatisk at planlægge den næste iterations kapacitet.

Acceptance Tests → Reviews

Story-reviews i trackeren afbildes på accept. Tildel en reviewer (kunden, produktejeren eller endda en agent, der fungerer som en). De godkender eller afviser. Afvist sender storyen tilbage til Started.

Pair Programming → Med-ejerskab

XP-teams parrer på kode. I trackeren viser dette sig som flere ejere på en story. Tildel begge par til storyen; begge navne optræder på kortet.

XP med agenter — den nye praksis

XP blev skrevet, før AI-agenter meningsfuldt kunne bidrage til software. Vi mener, at dette er den vigtigste opdatering til XP i femogtyve år.

I vores praksis — og det, trackeren er bygget til — er en agent et navngivet XP-teammedlem. Den har sin egen rolle, sin egen parpartner (menneske eller agent) og sit eget revisionsspor. Den kan gøre alt, hvad et menneskeligt teammedlem kan gøre på planlægningsoverfladen: estimere, eje stories, kommentere, skifte tilstand, acceptere reviews.

XP-værdierne holder stadig. Kommunikation: agenter kommunikerer ved at læse hændelsesstrømmen og poste kommentarer. Enkelhed: agenter er begrænset til de roller, du tildeler dem. Feedback: hver agent-handling er i revisionsloggen, øjeblikkeligt klar til review. Mod: vær ærlig om, hvad dine agenter fik rigtigt, og hvad de ikke gjorde. Respekt: agent-teammedlemmer bidrager med værdi — anerkend det.

Vi sætter ikke agenterne inde i trackeren til at lave kodningen. Vi giver planlægningsoverfladen til mennesker og agenter, der arbejder sammen. Du står for kodningsagenten — Claude Code, Codex, din egen — og forbinder den til trackeren via API’et. Agenten tager stories op, udfører arbejdet, kommenterer, skifter tilstand. Du reviewer sporet og accepterer.

Dette er inkluderende agil planlægning. Det er XP, med det team det faktisk har.

Yderligere læsning

• Extreme Programming Explained — Kent Becks grundlæggende bog, 1999.
• Agile Manifesto — Hvor familien startede.
• Agil udvikling — Det bredere billede.
• Betjeningsvejledning — Praktisk vejledning til trackeren.
• API-guide — Tilslutning af din kodningsagent.