Ekstrem programmering

eXtreme Programming (XP) er en systemutviklingsmetode som er utformet for å være så fleksibel som mulig. I tradisjonell systemutvikling (for eksempel Fossefallsmodellen) 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, Extreme Programming Explained av Kent Beck, ble publisert i 1999.

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 utvikler syklus, 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 EXtreme Programming 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.
• Tilbakemeldinger.
• Organisering av systemet etter en metafor.