Extrem programmering
Extrem programmering (XP) är systemutvecklingsmetodik utvecklad av Kent Beck.
XP är en kodcentrerad process som utvecklades p g a att många mjukvaruprojekt avbröts eller att projektplanen inte kunde hållas. XP är den mest populära lättviktsprocessen idag och har bevisats vara effektiv eftersom den har använts i flera projekt runt om i världen.
Värderingar
XP baseras på fyra stycken värderingar: kommunikation, enkelhet, återkoppling och mod. Det är viktigt att ha en kund på plats så att kontinuerlig kommunikation mellan utecklarna och kunden är möjlig. Kunden som är på plats har möjlighet att bestämma vad som ska konstrueras av systemet och vilken ordning.
Enkelhet fås genom att kontinuerligt refaktorera kod och ha en minimal production av artefakter som inte är kod. Kontinuerliga enhetstester och många dellevereringar av systemet ger god återkoppling. Kommunikation är viktig vid återkoppling då kunden på plats ger feedback (återkopplar) efter varje leverans av systemet. När det som är mest rätt att göra när det inte är speciellt populärt att göra det är modigt. Det innebär egentligen att alla inblandade projektmedlemmar ska vara ärliga med vad de kan och inte kan göra.
Tillämpningar
Precis som utvecklingsprocessen RUP har XP ett antal s k "tillämpningar" som stöttar de fyra värderingarna. Det finns 12 tillämpningar i XP:
- Planeringsspelet
- Små leveranser
- Metafor
- Enkel design
- Testning
- Refaktorering
- Parprogrammering
- Gemensamt ägarskap
- Kontinuerlig integration
- 40-timmars arbetsvecka
- Kund på plats
- Kodstandard
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 systemets 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 medans kunden skriver tester som testar och validerar verksamhetsberättelser.
Refaktorering - Ta kontinuerligt bort identiska (dubletter) och komplexa kodbitar.
Parprogrammering - Programmerare arbetar i par vid en dator. En skriver koden medans 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 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 - Konsistent kodstandard som alla programmerare följer.
Kravhantering
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 systemt specifieras 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
En av de grundläggande metoderna i XP är testdriven utveckling av kod. Det innebär att s k 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 programmeringssprå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 nyskivna 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
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
Det finns några slagord eller motton som XP-utevecklare arbetar efter:
- Gör det så enkelt som möjligt
- Du kommer inte att behöva det (kallas YAGNI på engelska - You aren't gonna need it)
- En och endast en gång
Gör det så enkelt som möjligt - Funktioner bör implmeneteras 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 nehö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 refaktoreras direkt.
Källor
- Beck, Kent (1999): Extreme Programming Explained: Embrace Change
- Succi, Giancarlo, Marchesi, Michele (2001): Extreme Programming Examined
- Wake, William C. (2000): Extreme Programming Explored [1]