Vad är XP?
XP är en nischmetod om man kan uttrycka det så, en metod som ställer höga krav på projektledningen men framförallt på kunden eftersom XP kräver att kunden är delaktig under hela utvecklingsprocessen. XP har både för- och nackdelar, det gäller således att använda XP där det passar bäst. Generellt lämpar sig XP bäst till utveckling av små system i projekt med få deltagare.

I XP har man skalat bort eller förenklat många av de faser som vanligtvis ingår i ett systemutvecklingsprojekt, som till exempel behovsanalys, kravanalys, arkitektur och design. Istället har man komprimerat utvecklingscykeln så att delmålen kan uppnås betydligt snabbare än i ett vanligt utvecklingsprojekt, till och med snabbare än i ett RAD-projekt. Genom att komprimera en utvecklingscykel till mellan en och fyra veckor kan man uppnå extremt snabba resultat vilket även reducerar behovet av en mer detaljerad systemdesign, eftersom fel i systemet kan upptäckas tidigare än i ett vanligt utvecklingsprojekt, där det färdiga systemet kanske acceptanstestas först efter flera månader. Det designarbete som väl utförs integreras som en del av utvecklingscykeln. Inom varje utvecklingscykel har man sedan iterationer med design, programmering och test av programkoden. Iterationerna är extremt korta, ibland minuter eller timmar.

De stora skillnaderna
En annan viktig skillnad mellan ett vanligt utvecklingsprojekt och ett XP-projekt är att man, i ett XP-projekt, lägger ned betydligt mindre resurser på en grundlig projektplanering i början av projektet. Inom XP betonar man istället flexibilitet och förmågan att snabbt kunna planera om inom projektet, ibland varje dag om så behövs. Motståndarna till XP hävdar att planeringen i ett XP-projekt blir väldigt adhoc-mässig och lite oseriös medans XPs anhängare menar att för stora och detaljerade projektplaner i början av utvecklingsprojekt tenderar att låsa projektets resurser i en orealistisk plan som projektledaren, av rädsla för att bryta tidplanen, riskerar att hålla fast vid trots att planen skulle behöva revideras och planeras om.

En förutsättning för att XP skall fungera är att kunden eller beställaren av systemet arbetar tillsammans med utvecklarna i utvecklingsprojektetet, helst heltid och fullt dedikerad till projektet. Kunden skall representera sin organisation och kunna ta både affärsbeslut och tekniska beslut för att driva projektet framåt samt besvara frågor som kan uppstå under utvecklingens gång. Kundens konstanta närvaro gör även att tolkningsfel av kraven och så kallad Gold Plating (se avsnitt om RAD) kan undvikas.

Ett annat av kundens ansvarsområden är att avgränsa systemet vid behov.
I XP är det planerade releasedatumet alltid konstant dvs man skjuter aldrig på en tidplan för att hinna få med all funktionalitet i releasen. En vanlig mening i utvecklingsprojekt är ’Jag har inte tillräckligt med tid’. Att inte ha tillräckligt med tid är enligt XP en faktor som ej går att påverka, så bara tanken representerar en negativ inställning. Man har ju endast ett fast antal timmar per dygn att arbeta på. Om man istället säger ’Jag har för mycket att göra’ så har man istället vänt på problematiken, för man kan ju alltid avgränsa sig i sina aktiviteter.

Detta är en av XPs grundtankar, att avgränsa projektet hårt, att stryka funktionalitet för att hinna med att leverera i tid. Fördelarna är att man faktiskt håller tidplanen vilket är psykologiskt viktigt både för kunden och utvecklarna samtidigt som vissa avgränsningar faktiskt blir lättare att göra under tidspress vilket optimerar systemet. Väldigt ofta visar det sig att den avgränsade funktionaliteten ej kommer att saknas i den releasade versionen.

Nackdelen är förstås att för många avgränsningar resulterar i ett ofärdigt system eller i värsta fall ett system som inte fungerar. Det finns förstås gränsvärden för hur mycket funktionalitet som kan strykas innan projektets kvalité påverkas. Om restlistan blir allt för stor måste en mer drastisk omplanering av projektet göras.

Kravhantering
Även begreppen inom kravhanteringen är något annorlunda i XP. Man väljer till exempel att kalla en grupp av sammansatta krav för Story. En Story skall helst bara bestå av en eller ett par meningar som beskriver ett önskat händelseförlopp i klartext.

Exempel på Story:
Systemet skall göra en stavningskontroll i adressfältet då användaren klickar på Submit. Resultatet av stavningskontrollen skall visas i programmets statusrad.

En mer detaljerad specifikation är ej nödvändig då kunden arbetar så tätt med utvecklarna. Eventuella frågor kan alltså tas direkt innan fortsatt utveckling och testarbete. Kravet på en Story är att den är oberoende, testbar och att den tillför ett tydligt värde. Stories skall göras så pass små och lättbegripliga att ett flertal kan utvecklas och testas inom varje iteration. Ett tecken på att en Story är för stor eller svårbegriplig är att utvecklaren har svårt att räkna ut tidsåtgången för utvecklingen, han måste då bryta ned den för att lättare kunna räkna ut tidsåtgången.

Parprogrammering
Den metoden som man starkast förknippar med XP är dock par-programmeringen. Genom att alltid låta två programmerare sitta tillsammans kan man höja kvalitén genom att både kodning och granskning sker samtidigt av fyra ögon istället för två. Tekniska frågor kan alltid tas upp med kollegan som sitter bredvid istället för att behöva vänta till nästa utvecklingsmöte. En annan fördel med att sitta parvis är att koden blir mindre personlig. Ett vanligt fenomen bland programmerare är att de anser att koden är deras personliga egendom och att de på ett nästan artistiskt sätt har utvecklat koden. Följderna blir ofta att all kritik mot koden blir en personlig kritik mot programmeraren, vilket i sin tur kan bidra till att försämra stämningen i ett utvecklingsprojekt. Detta fenomen blir tydligt då programmeraren får sitta och arbeta själv med sin kod under längre perioder.
Genom att sitta parvis i väldigt korta utvecklingsiterationer undviker man alltså att programmeraren får ett känslomässigt band till koden.

Sammanfattning
Sammanfattningsvis är XP en utvecklingsmetod som långt ifrån passar alla. XP kräver mycket av beställaren och man måste vara beredd att arbeta väldigt annorlunda från ett vanligt utvecklingsprojekt. Fördelarna är dock tydliga med extremt korta utvecklingscykler och en mycket snabb omsättning från idé till verklighet, exempelvis vid produktutveckling.
Mandrillo Consulting erbjuder projektledning med XP som utvecklingsmetod för kunder som känner att de vill ta steget mot ett nytt sätt att utveckla programvara, med en mer person- och relationsorienterad metod.