eXtreme Programming

eXtreme Programming — vanligtvis bara XP — är den mest krävande medlemmen i den agila familjen. East Agile Tracker är byggt för XP först; allt annat faller ut ur det.

Den här sidan täcker vad XP är, varför det fungerar och hur man praktiserar det med trackern som planeringsyta.

Vad XP är

XP skapades av Kent Beck i slutet av 1990-talet. Den första boken — Extreme Programming Explained: Embrace Change — gavs ut 1999. Det började, som så mycket annat, med ett frustrerat team som försökte leverera ett lönesystem hos Chrysler.

XP:s satsning är att det rätta sättet att hantera osäkerhet i mjukvara är att göra det som fungerar, och göra det oftare. Testa? Testa hela tiden. Integrera? Integrera varje timme. Prata? Prata konstant. Planera? Planera varje iteration, och planera om allt eftersom du lär dig.

“XP är en lättviktig metodik för små till medelstora team som utvecklar programvara inför vaga eller snabbt förändrade krav.” — Kent Beck

De fem värdena

XP namnger fem värden som allt annat hänger på:

1. Kommunikation — Teamet pratar. Dagligen. Om arbetet, designen, hindren. Ansikte mot ansikte när det är möjligt. Silos är fienden.
2. Enkelhet — Gör det enklaste som möjligen skulle kunna fungera. Du kan lägga till komplexitet senare om du verkligen behöver det. Du kommer förmodligen inte att behöva det.
3. Feedback — Från koden (tester), från teamet (parprogrammering, granskningar), från användaren (frekventa releaser). Få den snabbt.
4. Mod — Berätta sanningen om framsteg, estimat och design. Släng kod som inte fungerar. Refaktorera det som håller dig tillbaka.
5. Respekt — Alla i teamet — och numera, varje agent i teamet — bidrar med värde. Behandla varandra därefter.

Praxisen

XP är känt för sina tolv ursprungliga praxis, organiserade i fyra områden:

Planering

• Planning Game — Teamet och kunden planerar tillsammans: vad som kommer härnäst, i vilken ordning, hur stor varje del är.
• Small Releases — Leverera ofta. Dagar, inte månader. Få feedback på något konkret.
• User Stories — Krav är samtal, fångade som korta berättelser ur användarens perspektiv. “Som användare vill jag X, så att Y.”

Design

• Simple Design — Den enklaste designen som klarar testerna och uttrycker varje nödvändigt koncept. Inte mer.
• Refactoring — Förbättra designen av kod som redan fungerar. Ständigt.
• System Metaphor — En delad berättelse om hur systemet fungerar, använd för att göra designbeslut konsekventa.

Kodning

• Pair Programming — Två utvecklare, ett tangentbord. En kör, en navigerar. Byt ofta.
• Collective Code Ownership — Vem som helst kan förbättra vilken kod som helst. Inga revir.
• Continuous Integration — Integrera och testa kod många gånger om dagen. Fånga brott omedelbart.
• Coding Standards — Överenskommen stil så att koden läses som om en person skrivit den.

Testning

• Test-Driven Development (TDD) — Skriv det misslyckade testet först, sedan koden som får det att passera.
• Acceptance Tests — Kunden definierar, i kod eller körbar form, vad “klart” betyder för varje story.

Varför XP fungerar

XP är obekvämt. Parprogrammering tvingar dig att tänka högt. TDD tvingar dig att veta hur framgång ser ut innan du skriver koden. Kontinuerlig integration dödar dina favoritlånglivade grenar. Små releaser betyder att du inte kan gömma dig bakom en sexmånaders roadmap.

Det fungerar för att alla dessa saker förkortar feedbackloopar. Ju snabbare du får reda på att du hade fel, desto billigare är korrigeringen. XP är, fundamentalt sett, om att göra feedbackloopen så stram som den kan bli.

Det handlar också om mod och respekt. Du kan bara göra XP i ett team som litar på varandra tillräckligt för att ha fel högt.

Den disciplinerade story-modellen

East Agile Tracker kodar in en specifik teori om planering. Behandla denna sektion som driftmanualen för varför datamodellen ser ut som den gör — och som fältguiden för vad man ska göra (och inte göra) i praktiken.

Varför de fyra story-typerna spelar roll

Allt är en story, men det finns fyra sorter, och skillnaden är hela poängen:

• Features bär poäng och är det enda som “räknas” mot velocity. Detta tvingar dig att skiva upp arbete i användarobserverbart värde.
• Bugs är opoängsatta (noll). Defekter ger ingen kredit, vilket gör kostnaden för omarbete synlig snarare än belönad.
• Chores är också opoängsatta — nödvändigt arbete utan direkt användarvärde (infra, refaktoreringar, uppsättning). Att hålla dem på noll pressar teamet att paketera dem in i features där det går så att värderamen förblir ärlig.
• Releases är markörer med noll poäng som används för att förankra milstolpar och låta verktyget projicera ett datum.

Den beteendemässiga effekten är det som betyder något: när bugs och chores inte ger poäng pressas ett team naturligt att uttrycka arbete som användarorienterad funktionalitet, och det blir akut medvetet om defektkostnaden. Det är en planeringsdisciplin inkodad i datamodellen.

Den enda ordnade backloggen

Tre zoner, en regel.

• Iceboxen är poolen av oprioriterade idéer.
• Backloggen är en strikt ordnad lista med en enda prioritet — inga delade platser, inget “P1/P1/P1.”
• Current-zonen håller den eller de aktiva iterationerna.

Produktägaren äger ordningen uppifrån och ner, och invarianten är att toppen av backloggen alltid är den viktigaste och bäst specificerade, med tydlighet som legitimt minskar ju längre ner du kommer. En story nära toppen med vaga acceptanskriterier är en planeringsbug. Iceboxen tillåts vara en kyrkogård; backloggen är det inte.

Velocity-driven automatisk planering

Detta är den del de flesta team implementerar om dåligt på andra håll. Tracker-stilad planering beräknar ett rullande medelvärde av velocity från nyligen accepterade poäng och drar automatiskt in så många poäng stories i nästa iteration — du “åtar dig” inte manuellt till en sprint, den empiriska datan gör det åt dig. Två konsekvenser värda att bevara:

• Du estimerar endast features, med relativa poäng (Fibonacci 1/2/3/5/8 eller vår tätare 0/1/2/3), inte timmar. Estimering är ett samtal om storlek, inte ett löfte.
• Du manipulerar inte velocity. Att blåsa upp poäng för att “se snabb ut”, eller att poängsätta chores, bryter prognosen som gör hela systemet ärligt. Velocity är ett mätinstrument, och man manipulerar inte sitt eget instrument.

Utdelningen är att prognos för releasedatum blir en beräkning snarare än en förhandling, och samtalet med intressenter skiftar från “kan du lova X till fredag” till “vid nuvarande velocity landar den här releasen runt datum Y — här är avvägningen mellan omfattning och datum.”

Story-livscykeln och acceptansloopen

Tillståndsmaskinen är Start → Finish → Deliver → Accept / Reject. Det kritiska tillståndet är Deliver: en ingenjör markerar en story som levererad, men den är inte klar förrän produktägaren uttryckligen accepterar den mot dess acceptanskriterier — eller avvisar den, vilket sparkar tillbaka den. Detta bakar in en kundåterkopplingsloop i varje enskild story snarare än att skjuta upp acceptansen till en demo i slutet av sprinten.

Acceptanskriterier hör hemma på storyn innan den startas, helst i Given/When/Then-form så att de mappar direkt mot acceptanstester. INVEST är förnuftskontrollen på om en story är välformad:

• Independent — kan släppas utan andra stories.
• Negotiable — fångar avsikt, inte en frusen spec.
• Valuable — för en användare eller intressent.
• Estimable — teamet kan storleksbestämma den.
• Small — får bekvämt plats i en iteration.
• Testable — har acceptanskriterier som kan utövas.

Kadens

Planeringsceremonierna är lätta och regelbundna:

• Ett veckovis Iteration Planning Meeting för att poängsätta nya stories och spika ner acceptanskriterier högst upp i backloggen.
• En kort daglig standup fokuserad på flöde och blockerare.
• En retrospektiv per iteration för att justera processen.

Iterationer är vanligtvis en eller två veckor — kort nog att ett dåligt estimat är billigt att upptäcka.

Ingenjörspraxisen som får planeringen att fungera

Tracker-stilad planering är den synliga halvan av XP; den kollapsar utan ingenjörshalvan.

• Test-first / TDD och en riktig acceptanstestsvit är vad som låter “levererad” betyda något.
• Kontinuerlig integration och små, frekventa releaser håller cykeltiden kort så att velocity är stabil snarare än ojämn.
• Parprogrammering (eller stark granskning) håller pågående arbete lågt — avsluta innan du startar — vilket är den enskilt största hävstången på cykeltid.
• En tillgänglig produktägare är vad som hindrar accept/reject-loopen från att stanna.

Antimönster att hålla utkik efter

De återkommande misslyckandena:

• Att behandla Backloggen som en parkeringsplats istället för en sann prioritetsordning.
• Att estimera bugs och chores för att få velocity att se bättre ut.
• Att bära enorma stories som inte kan avslutas i en iteration. Dela tills var och en är självständigt levererbar.
• Att låta stories hopa sig i Delivered för att ingen accepterar.

Vilket som helst av dessa förvandlar tyst ett empiriskt system tillbaka till önsketänkande planering. Trackern kan inte hindra dig från att göra dem; den kan bara göra dem synliga. Titta på din Delivered-kolumn i slutet av varje iteration — om den växer är det din signal.

XP med East Agile Tracker

Trackern är den planeringsyta XP-team har velat ha sedan Pivotal Tracker-dagarna. Varje koncept kartlägger direkt:

User Stories → Stories

XP user stories är East Agile Tracker-stories. Skriv dem i typen Feature. Använd beskrivningen för samtalet; använd kommentarer för pågående diskussion. Acceptanskriterierna hör hemma i beskrivningen.

Planning Game → Boarden

Planning Game i XP är ett samtal mellan verksamhet och team om prioritet och storlek. I East Agile Tracker:

1. Produktpersonen skriver stories i Backlog och ordnar dem efter prioritet.
2. Teamet estimerar features i poäng (Fibonacci- eller East Agile-skalan).
3. Systemet autoplanerar iterationer från velocity.
4. Teamet startar stories från toppen av kolumnen Current.

Det är allt. “Spelet” lever i samtalet; trackern håller bara koll på poängen.

Small Releases → Releases (story-typen)

XP säger leverera ofta. Release är en av de fyra story-typerna i East Agile Tracker. Skapa en release för varje leveransmilstolpe; dra in den i iterationen där den levereras. Releaser hoppar över Started/Finished/Delivered och går direkt till Accepted när du levererar.

Continuous Integration → Story-tillståndsmaskinen

Tillståndsmaskinen är inte CI i sig — det är ditt byggsystem — men vägen Finished → Delivered → Accepted speglar den kundacceptansloop XP beskriver. Avsluta arbetet, leverera till kunden, acceptera när det är bekräftat fungerande.

Velocity → “Yesterday’s weather”

XP kallar det yesterday’s weather: hur mycket du fick gjort förra iterationen är den bästa förutsägelsen för hur mycket du får gjort i den här. East Agile Tracker räknar velocity automatiskt — genomsnitt av senaste iterationerna, konfigurerbar strategi — och använder det för att autoplanera nästa iterations kapacitet.

Acceptance Tests → Granskningar

Story-granskningar i trackern kartlägger mot acceptans. Tilldela en granskare (kunden, produktägaren, eller även en agent som agerar som en). De godkänner eller avvisar. Avvisad skickar storyn tillbaka till Started.

Pair Programming → Sam-ägarskap

XP-team parar på kod. I trackern visar sig detta som flera ägare på en story. Tilldela båda i paret till storyn; båda namnen visas på kortet.

XP med agenter — den nya praxisen

XP skrevs innan AI-agenter meningsfullt kunde bidra till mjukvara. Vi tycker det är den viktigaste uppdateringen av XP på tjugofem år.

I vår praktik — och vad trackern är byggd för — är en agent en namngiven XP-teammedlem. Den har sin egen roll, sin egen par-partner (människa eller agent) och sitt eget granskningsspår. Den kan göra allt en mänsklig teammedlem kan göra på planeringsytan: estimera, äga stories, kommentera, byta tillstånd, acceptera granskningar.

XP-värdena håller fortfarande. Kommunikation: agenter kommunicerar genom att läsa händelseströmmen och posta kommentarer. Enkelhet: agenter är begränsade till de roller du beviljar dem. Feedback: varje agentåtgärd finns i granskningsloggen, omedelbart granskningsbar. Mod: var ärlig om vad dina agenter fick rätt och vad de inte fick rätt. Respekt: agentlagkamrater bidrar med värde — erkänn det.

Vi sätter inte agenterna inuti trackern för att utföra kodningen. Vi ger planeringsytan till människor och agenter som arbetar tillsammans. Du tar med kodningsagenten — Claude Code, Codex, din egen — och kopplar den till trackern via API:et. Agenten plockar upp stories, gör arbetet, kommenterar, byter tillstånd. Du granskar spåret och accepterar.

Detta är Inclusive Agile Planning. Det är XP, med det team det faktiskt har.

Vidare läsning

• Extreme Programming Explained — Kent Becks grundläggande bok, 1999.
• The Agile Manifesto — Där familjen började.
• Agil utveckling — Den bredare bilden.
• Bruksanvisning — Praktisk guide till trackern.
• API-guide — Koppla in din kodningsagent.