eXtreme Programming

eXtreme Programming — meestal gewoon XP — is het meest veeleisende lid van de agile-familie. East Agile Tracker is in de eerste plaats voor XP gebouwd; al het andere vloeit daaruit voort.

Deze pagina behandelt wat XP is, waarom het werkt, en hoe je het beoefent met de tracker als je planningsoppervlak.

Wat XP is

XP werd eind jaren negentig bedacht door Kent Beck. Het eerste boek — Extreme Programming Explained: Embrace Change — werd in 1999 gepubliceerd. Het begon, zoals veel dingen, met een gefrustreerd team dat probeerde een salarissysteem op te leveren bij Chrysler.

XP’s weddenschap is dat de juiste manier om onzekerheid in software aan te pakken is om de dingen te doen die werken, en ze vaker te doen. Testen? Test de hele tijd. Integreren? Integreer per uur. Praten? Praat voortdurend. Plannen? Plan elke iteratie, en plan opnieuw naarmate je leert.

“XP is een lichtgewicht methodiek voor kleine tot middelgrote teams die software ontwikkelen in het aangezicht van vage of snel veranderende eisen.” — Kent Beck

De vijf waarden

XP benoemt vijf waarden waar al het andere aan ophangt:

Communicatie — Het team praat. Dagelijks. Over het werk, het ontwerp, de obstakels. Van persoon tot persoon wanneer mogelijk. Silo’s zijn de vijand.
Eenvoud — Doe het eenvoudigste dat zou kunnen werken. Je kunt later complexiteit toevoegen als je die echt nodig hebt. Waarschijnlijk niet.
Feedback — Van de code (tests), van het team (pair programming, reviews), van de gebruiker (frequente releases). Krijg het snel.
Moed — Vertel de waarheid over voortgang, schattingen en ontwerp. Gooi code weg die niet werkt. Refactor wat je tegenhoudt.
Respect — Iedereen in het team — en nu, elke agent in het team — draagt waarde bij. Behandel elkaar dienovereenkomstig.

De praktijken

XP is beroemd om zijn twaalf oorspronkelijke praktijken, georganiseerd in vier gebieden:

Plannen

Planning Game — Het team en de klant plannen samen: wat komt er als volgende, in welke volgorde, hoe groot is elk stuk.
Small Releases — Lever vaak op. Dagen, geen maanden. Krijg feedback op iets concreets.
User Stories — Eisen zijn gesprekken, vastgelegd als korte stories vanuit het perspectief van de gebruiker. “Als gebruiker wil ik X, zodat Y.”

Ontwerpen

Simple Design — Het eenvoudigste ontwerp dat de tests doorstaat en elk benodigd concept uitdrukt. Niet meer.
Refactoring — Verbeter het ontwerp van code die al werkt. Voortdurend.
System Metaphor — Een gedeeld verhaal over hoe het systeem werkt, gebruikt om ontwerpbeslissingen consistent te maken.

Coderen

Pair Programming — Twee ontwikkelaars, één toetsenbord. De een stuurt, de ander navigeert. Wissel vaak.
Collective Code Ownership — Iedereen kan elke code verbeteren. Geen leengoederen.
Continuous Integration — Integreer en test code vele keren per dag. Vang breuken onmiddellijk op.
Coding Standards — Een overeengekomen stijl zodat de code leest alsof één persoon hem heeft geschreven.

Testen

Test-Driven Development (TDD) — Schrijf eerst de falende test, daarna de code die deze laat slagen.
Acceptance Tests — De klant definieert, in code of uitvoerbare vorm, wat “klaar” betekent voor elke story.

Waarom XP werkt

XP is ongemakkelijk. Pair programming dwingt je hardop te denken. TDD dwingt je te weten hoe succes eruitziet voordat je de code schrijft. Continuous integration doodt je geliefde langlevende branches. Kleine releases betekenen dat je je niet kunt verschuilen achter een roadmap van zes maanden.

Het werkt omdat al deze dingen feedbacklussen verkorten. Hoe sneller je erachter komt dat je het mis had, hoe goedkoper de correctie. XP gaat fundamenteel over het zo strak mogelijk maken van de feedbacklus.

Het gaat ook over moed en respect. Je kunt XP alleen doen in een team dat elkaar genoeg vertrouwt om hardop fout te zijn.

Het gedisciplineerde story-model

East Agile Tracker codeert een specifieke theorie van planning. Behandel deze sectie als de bedieningshandleiding voor waarom het datamodel eruitziet zoals het doet — en als de veldgids voor wat je in de praktijk wel (en niet) moet doen.

Waarom de vier story-types ertoe doen

Alles is een story, maar er zijn vier soorten, en het onderscheid is de hele kern:

Features dragen punten en zijn het enige dat “meetelt” voor velocity. Dit dwingt je om werk op te delen in waarde die voor de gebruiker waarneembaar is.
Bugs zijn zonder punten (nul). Defecten verdienen geen krediet, wat de kosten van herwerk zichtbaar maakt in plaats van belonen.
Chores zijn ook zonder punten — noodzakelijk werk zonder directe gebruikerswaarde (infra, refactors, setup). Ze op nul houden zet het team onder druk om ze waar mogelijk in features te bundelen, zodat de waardeframing eerlijk blijft.
Releases zijn nulpunts-markeringen die worden gebruikt om mijlpalen te verankeren en de tool een datum te laten projecteren.

Het gedragseffect is wat ertoe doet: wanneer bugs en chores niet scoren, gaat een team van nature druk uitoefenen om werk uit te drukken als gebruikersgerichte functionaliteit, en het wordt zich scherp bewust van de kosten van defecten. Dat is een planningsdiscipline die in het datamodel is verankerd.

De enkele geordende backlog

Drie zones, één regel.

De Icebox is de ongeprioriteerde ideeënpool.
De Backlog is een strikt geordende lijst met één prioriteit — geen gelijkspel, geen “P1/P1/P1.”
De Current-zone bevat de actieve iteratie(s).

De product owner bezit de volgorde van boven naar beneden, en de invariant is dat de bovenkant van de backlog altijd het belangrijkst en best gespecificeerd is, waarbij de helderheid legitiem afneemt naarmate je naar beneden gaat. Een story bovenaan met vage acceptatiecriteria is een planningsbug. De Icebox mag een kerkhof zijn; de Backlog niet.

Velocity-gestuurde automatische planning

Dit is het deel dat de meeste teams elders slecht herimplementeren. Tracker-achtige planning berekent een voortschrijdend gemiddelde van de velocity uit recent geaccepteerde punten en trekt automatisch dat aantal punten aan stories in de volgende iteratie — je “committeert” je niet handmatig aan een sprint, de empirische data doet het voor je. Twee gevolgen die het waard zijn om te behouden:

Je schat alleen features, met relatieve punten (Fibonacci 1/2/3/5/8 of onze strakkere 0/1/2/3), geen uren. Schatten is een formaatgesprek, geen belofte.
Je manipuleert velocity niet. Punten opblazen om “snel te lijken”, of chores van punten voorzien, breekt de projectie die het hele systeem eerlijk maakt. Velocity is een meetinstrument, en je knoeit niet met je eigen instrument.

De opbrengst is dat de projectie van de releasedatum een berekening wordt in plaats van een onderhandeling, en het gesprek met belanghebbenden verschuift van “kun je je committeren aan X vóór vrijdag” naar “bij de huidige velocity landt deze release rond datum Y — hier is de scope/datum-afweging.”

De story-levenscyclus en de acceptatielus

De toestandsmachine is Start → Finish → Deliver → Accept / Reject. De cruciale toestand is Deliver: een engineer markeert een story als delivered, maar het is pas klaar wanneer de product owner het expliciet accepteert ten opzichte van de acceptatiecriteria — of het afwijst, waarmee het teruggaat. Dit bakt een klant-feedbacklus in elke afzonderlijke story in plaats van acceptatie uit te stellen tot een demo aan het einde van de sprint.

Acceptatiecriteria horen op de story te staan voordat deze wordt gestart, bij voorkeur in Given/When/Then-vorm zodat ze direct toewijsbaar zijn op acceptatietests. INVEST is de toets of een story goed gevormd is:

Independent — kan worden opgeleverd zonder andere stories.
Negotiable — legt intentie vast, geen bevroren specificatie.
Valuable — voor een gebruiker of belanghebbende.
Estimable — het team kan het inschatten.
Small — past comfortabel in een iteratie.
Testable — heeft acceptatiecriteria die kunnen worden uitgeoefend.

Cadans

De planningsceremonies zijn licht en regelmatig:

Een wekelijkse Iteration Planning Meeting om nieuwe stories van punten te voorzien en de acceptatiecriteria bovenaan de backlog vast te pinnen.
Een korte dagelijkse standup gericht op flow en blockers.
Een retrospective per iteratie om het proces bij te stellen.

Iteraties zijn meestal één of twee weken — kort genoeg dat een slechte schatting goedkoop te ontdekken is.

De engineeringpraktijken die planning laten werken

Tracker-achtige planning is de zichtbare helft van XP; het stort in zonder de engineeringhelft.

Test-first / TDD en een echte acceptatietest-suite zijn wat “delivered” iets laat betekenen.
Continuous integration en kleine, frequente releases houden de cyclustijd kort zodat velocity stabiel is in plaats van hobbelig.
Pair programming (of sterke review) houdt werk in uitvoering laag — maak af voordat je start — wat de allergrootste hefboom op cyclustijd is.
Een beschikbare product owner is wat de accept/reject-lus van vastlopen weerhoudt.

Antipatronen om op te letten

De terugkerende fouten:

De Backlog als parkeerplaats behandelen in plaats van als een echte prioriteitsvolgorde.
Bugs en chores schatten om velocity er beter uit te laten zien.
Enorme stories meeslepen die niet binnen een iteratie kunnen worden afgerond. Splits totdat elk onafhankelijk opleverbaar is.
Stories laten opstapelen in Delivered omdat niemand accepteert.

Elk van deze verandert stilletjes een empirisch systeem terug in wensdenken-planning. De tracker kan je niet beletten ze te doen; hij kan ze alleen zichtbaar maken. Bekijk je Delivered-kolom aan het einde van elke iteratie — als deze groeit, is dat je signaal.

XP met East Agile Tracker

De tracker is het planningsoppervlak dat XP-teams al sinds de Pivotal Tracker-dagen willen. Elk concept wordt direct toegewezen:

User Stories → Stories

XP-user-stories zijn East Agile Tracker-stories. Schrijf ze in het type Feature. Gebruik de beschrijving voor het gesprek; gebruik reacties voor doorlopende discussie. De acceptatiecriteria horen in de beschrijving.

Planning Game → Het bord

De Planning Game in XP is een gesprek tussen business en team over prioriteit en omvang. In East Agile Tracker:

De productpersoon schrijft stories in de Backlog en ordent ze op prioriteit.
Het team schat features in punten (Fibonacci- of East Agile-schaal).
Het systeem plant iteraties automatisch op basis van velocity.
Het team start stories vanaf de bovenkant van de Current-kolom.

Dat is het. De “game” leeft in het gesprek; de tracker houdt alleen de stand bij.

Small Releases → Releases (het story-type)

XP zegt: lever vaak op. Release is een van de vier story-types in East Agile Tracker. Maak een release voor elke leveringsmijlpaal; sleep deze in de iteratie waarin het wordt geleverd. Releases slaan Started/Finished/Delivered over en gaan rechtstreeks naar Accepted wanneer je levert.

Continuous Integration → Story-toestandsmachine

De toestandsmachine is niet CI op zichzelf — dat is je buildsysteem — maar het pad Finished → Delivered → Accepted weerspiegelt de klant-acceptatielus die XP beschrijft. Maak het werk af, lever het aan de klant, accepteer wanneer het bevestigd werkend is.

Velocity → “Yesterday’s weather”

XP noemt het yesterday’s weather: hoeveel je vorige iteratie hebt gedaan is de beste voorspelling van hoeveel je deze gaat doen. East Agile Tracker berekent velocity automatisch — gemiddelde van recente iteraties, configureerbare strategie — en gebruikt het om de capaciteit van de volgende iteratie automatisch te plannen.

Acceptance Tests → Reviews

Story-reviews in de tracker komen overeen met acceptatie. Wijs een reviewer toe (de klant, de product owner, of zelfs een agent die als zodanig handelt). Zij keuren goed of af. Afgewezen stuurt de story terug naar Started.

Pair Programming → Mede-eigendom

XP-teams pairen op code. In de tracker komt dit naar voren als meerdere owners op een story. Wijs beide pair-leden toe aan de story; beide namen verschijnen op de kaart.

XP met agents — de nieuwe praktijk

XP werd geschreven voordat AI-agents zinvol konden bijdragen aan software. Wij denken dat dit de belangrijkste update van XP in vijfentwintig jaar is.

In onze praktijk — en waar de tracker voor gebouwd is — is een agent een benoemd XP-teamlid. Het heeft een eigen rol, een eigen pair-partner (mens of agent) en een eigen auditspoor. Het kan alles doen wat een menselijk teamlid kan doen in het planningsoppervlak: schatten, stories bezitten, reageren, laten overgaan, reviews accepteren.

De XP-waarden blijven overeind. Communicatie: agents communiceren door de eventstream te lezen en reacties te plaatsen. Eenvoud: agents zijn beperkt tot de rollen die je ze toekent. Feedback: elke agent-actie staat in het auditlog, onmiddellijk beoordeelbaar. Moed: wees eerlijk over wat je agents goed deden en wat niet. Respect: agent-teamgenoten dragen waarde bij — erken het.

We zetten de agents niet in de tracker om het coderen te doen. We geven het planningsoppervlak aan mensen en agents die samenwerken. Jij brengt de coding agent — Claude Code, Codex, je eigen — en verbindt deze met de tracker via de API. De agent pakt stories op, doet het werk, reageert, laat overgaan. Jij beoordeelt het spoor en accepteert.

Dit is Inclusieve Agile-planning. Het is XP, met het team dat het werkelijk heeft.

Verder lezen

Extreme Programming Explained — Kent Becks fundamentele boek, 1999.
Het Agile Manifesto — Waar de familie begon.
Agile-ontwikkeling — Het bredere plaatje.
Gebruiksinstructies — Praktische gids voor de tracker.
API-gids — Je coding agent aansluiten.