Ekstrem programmering

Ekstrem programmering (engelsk: extreme programming, forkortet XP) er en systemutviklingsmetode som er utformet for å være så fleksibel som mulig. I tradisjonell systemutvikling (for eksempel fossefallmodellen) setter man gjerne kravspesifikasjoner og lignende grunnlag på forhånd, og dermed blir også utgiftene store når en mot slutten av arbeidsfasen blir nødt til å mer eller mindre starte på nytt fordi noen av systemkravene er blitt endret.

Metoden ble først formulert av Kent Beck, Ward Cunningham og Ron Jeffries, og den første boken om metoden var Extreme Programming Explained av Kent Beck, ble publisert i 1999.

Verdier

XP baserer seg på fem «verdier» som de ansatte må holde seg til og jobbe opp mot. Disse verdiene er:

• Kommunikasjon
• Enkelhet
• Tilbakemelding
• Mot
• Respekt

I utgangspunktet var det fire verdier, men respekt ble ført på listen i en senere utgave. Kommunikasjon og tilbakemeldinger er uunnværlige som hovedverdier i XP, og en viktig del av fremgangsmetoden er testing. Intensiv testing av produktet blir gjort kontinuerlig hele veien gjennom prosjektet, og tilbakemeldingene derfra blir kontinuerlig ført tilbake til programmererne.

Egenskaper

En av de mer spesielle aspektene ved XP er at utviklerne hele tiden skal være åpne for å endre på produktet. Kunden er konstant i dialog med utviklerne og kan komme med endringskrav når som helst. XP kan ofte virke mindre strukturert enn tradisjonelle systemutviklingsmetoder, siden XP-utviklere setter i gang med programmeringen fra dag 1, der hvor man inne i andre utviklingsmiljøer først legger opp en «businessmodell» og planlegger hele arbeidsprosessen i alle ledd.

Prototyping i XP

Prototyper benyttes for å redusere risker og for å få en bedre forståelse av produktet og kravene til produktet. I XP bruker man prototyping på en annen måte enn i andre utviklingsmetoder. I stedet for å bruke uker på å lage en «Ferdig» prototyp med brukergrensesnitt, bruker man heller en dag eller to på å lage en enkel prototyp som en går gjennom sammen med kunde/interessent, som da kan komme med endringsforslag og sammen med utvikleren jobbe frem det ferdige produktet.

Architectural spike / spike solution

Lag flere enkle program (spikes) når du møter et teknisk problem, der hver av «spike»-ene skal være en mulig løsning på problemet for å utforske mulige løsninger på problemet. De fleste «spikes» er som regel for dårlige til å bli beholdt som en permanent del av systemet. Målet med en «spike» er å redusere risikoen for feil, ved å fokusere på et problem om gangen. Hver ny «spike» setter i gang en ny utviklersyklus, som i grove trekk består av:

• Spike → implementasjon → testing → godkjenning av kunde → utgivelse.

Arbeidsflyt ved hjelp av XP

Dette diagrammet beskriver hva som skjer i «Gjentagelse»-steget i forrige diagram:

Viktige elementer i XP er:

• Inkrementell og iterativ utvikling – gjentatte små forbedringer.
• Kontinuerlig og ofte gjentatt automatisk enhetstesting.
• Parprogrammering.
• Brukerinteraksjon under utviklingen.
• Refaktorering av kode.
• Delt eierskap av kode.
• Enkelhet.
• Testing
• Tilbakemeldinger.
• Organisering av systemet etter en metafor.