Extrem programmering

Från Wikipedia
Hoppa till: navigering, sök

Extrem programmering (XP) är en systemutvecklingsmetodik skapad av Kent Beck.

XP är en kodcentrerad process som utvecklades på grund av att många mjukvaruprojekt avbröts eller att projektplanen inte kunde hållas. XP är en av de mer populära lättviktsprocesserna idag och nyttjas flitigt i olika projekt runt om i världen.

Värderingar[redigera | redigera wikitext]

XP baseras på fem värderingar: kommunikation, enkelhet, återkoppling, mod och respekt. Det är viktigt att ha en kund på plats så att kontinuerlig kommunikation mellan utvecklarna och kunden är möjlig. Kunden som är på plats har möjlighet att bestämma vad som ska uppfyllas av systemet (krav på systemet) och i vilken ordning dessa ska prioriteras (så att de viktigaste kraven hanteras först).

Enkelhet fås genom kontinuerlig omstrukturering av kod (refaktorering) samt att skapa minimalt med dokument och annat som inte är kod eller en del av det slutgiltiga systemet. Kontinuerliga enhetstester och många delleveranser av systemet ger god återkoppling. Kommunikation är viktigt för återkopplingen då kunden på plats löpande ger synpunkter (feedback) på systemet. När något inte är speciellt populärt, men ändå mest rätt att göra krävs det mod. Det innebär egentligen att alla inblandade projektmedlemmar ska vara ärliga med vad de kan och inte kan göra. Respekt tillkom i 2:a upplagan av Kent Becks bok Extreme Programming Explained. Respekt innebär bland annat att visa respekt för medarbetare såväl som sig själv. Man skall visa respekt för andra medarbetares kod och inte göra ändringar om man inte genomfört goda tester.

Tillämpningar[redigera | redigera wikitext]

Precis som utvecklingsprocessen RUP har XP ett antal så kallade "tillämpningar" som stöttar de fyra värderingarna. Det finns 12 tillämpningar i XP:

  • Planeringsspelet - Funktionalitet i nästa leverans bestäms genom prioriterade verksamhetsberättelser och tekniska bedömningar.
  • Små leveranser - Systemet levereras i små inkrementella versioner.
  • Metafor - En enkel beskrivning av hur systemet ska fungera.
  • Enkel design - Genom att hålla koden enkel blir även designen enkel. Ta bort komplexitet från koden kontinuerligt när den upptäcks.
  • Testning - Tester skrivs innan koden utvecklas. Programmerare skriver tester som testar och validerar koden medan kunden skriver tester som testar och validerar verksamhetsberättelser.
  • Omstrukturering av kod - Ta kontinuerligt bort identiska (dubbletter) och komplexa kodbitar.
  • Parprogrammering - Programmerare arbetar i par vid en dator. En skriver koden medan den andre granskar koden.
  • Gemensamt ägarskap - Alla har rätt att ändra i all kod, skriven av dem själva eller någon annan.
  • Kontinuerlig integration - När en implementationsuppgift är utförd byggs systemet och integereras med den redan färdiga koden. Detta kan ske flera gånger per dag.
  • 40-timmars arbetsvecka - Programmerare tänker och därmed arbetar bättre utvilade. Övertid tillåts inte i två veckor i rad.
  • Kund på plats - Kunden arbetar med utvecklarna på heltid för att kunna svara på frågor, definiera systemet och skriva tester.
  • Kodstandard - Konsekvent kodstandard som alla programmerare följer.

Kravhantering[redigera | redigera wikitext]

Kravhantering i XP kontrolleras genom verksamhetsberättelser (funktionsbeskrivningar). Verksamhetsberättelser liknar användningsfall men är mindre detaljerade. Wake (2000) beskriver en verksamhetsberättelse som en kort beskrivning av systemet utifrån användarens synvinkel. Hela systemet specificeras genom verksamhetsberättelser och de skrivs ofta på ett informellt sätt vilket leder till ökad kommunikation mellan kunden och utvecklarna.

Verksamhetsberättelserna delas vidare upp i uppgifter som sedan normalt sett genomförs av en programmerare. Uppgifter är aktiviteter som måste utföras av programmeraren för att färdigställa implementationen av verksamhetsberättelsen.

Testdriven utveckling[redigera | redigera wikitext]

En av de grundläggande metoderna i XP är testdriven utveckling av kod. Det innebär att så kallade enhetstester skrivs (kodas) innan själva koden som ska testas. Kent Beck, XP:s grundare, har utvecklat ett enhetstestramverk som kan användas för testning av kod. Ramverket kallas xUnit, där x byts ut mot det programspråk som utvecklas i, t ex ramverket för Java kallas JUnit.

När en uppgift är klar körs alla tester för att kontrollera och validera den nyskrivna koden. Om alla enhetstester går igenom byggs koden och integreras i systemet. Om fel uppstår ska de programmerare som upptäcker dem rätta till dem.

Enkel design[redigera | redigera wikitext]

Enkel design är en annan teknik i XP. Försök alltid att hålla designen och koden enkel. En enkel regel är att om kommentering i koden behövs finns det ofta ett enklare sätt att programmera på. Ta kontinuerligt bort komplexa och identiska kodbitar för att hålla designen och koden enkel.

Slagord[redigera | redigera wikitext]

Det finns några slagord eller motton som XP-utvecklare arbetar efter:

  • Gör det så enkelt som möjligt - Funktioner bör implementeras på det enklaste sättet som är möjligt för en programmerare. Ingen fräsig eller fräck kod, utan få endast koden att fungera som den ska. Mottot "en och endast en gång" bör följas då koden hålls enkel.
  • Du kommer inte att behöva det - Detta är en praxis i XP som säger att utveckla endast det som behövs för tillfället, med andra ord utveckla inte för framtiden utan endast för idag.
  • En och endast en gång - Information om hur en del av mjukvaran fungerar bör endast finnas på ett ställe. Dubbletter av kod bör refaktoriseras direkt.

Källor[redigera | redigera wikitext]

  • Beck, Kent (1999): Extreme Programming Explained: Embrace Change (ISBN 0-201-61641-6)
  • Succi, Giancarlo, Marchesi, Michele (2001): Extreme Programming Examined (ISBN 0-201-71040-4)
  • Wake, William C. (2000): Extreme Programming Explored [1]

Externa länkar[redigera | redigera wikitext]