Extreme Programming

Fra Wikipedia, den frie encyklopedi
Gå til: navigasjon, søk

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.

Verdier[rediger | rediger kilde]

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[rediger | rediger kilde]

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 utviklerene 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[rediger | rediger kilde]

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[rediger | rediger kilde]

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[rediger | rediger kilde]

Xpdiacopy.gif

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

Xpdia2.gif

Viktige elementer i XP er:

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