Hva er XP?
XP blir av Beck definert som en lettvektsmetodologi for små til mellomstore utviklingsprosjekt. Metoden legger særlig vekt på testing og samspillet mellom mennesker. Ett Xp prosjekt starter med drøftinger som materaliserer seg i form av historiekort. Formålet er å kunne være i stand til å identifisere, prioritere og estimere krav. Når nok krav har blitt identifisert til at ett system kan tilføre kunden verdi, blir en release planlagt. Over tid vil flere undersøkelser avdekke nye krav til systemet og neste release vil bli planlagt. Hver release blir delt opp i mindre iterasjoner og hver iterasjon har en avlevering av verdi til kunden.
De fire sentrale verdiene i XP er
- Kommunikasjon
- Enkelthet
- Tilbakemelding
- Mot
Selve gjennomføringen støttes av tolv samarbeidende praksiser, definert av Beck. Dette skillet, altså at de er sammarbeidende kan illustreres med en metafor. XP er som ett puslespill med mange små biter. Hver for seg har de ingen mening, men satt sammen gir de ett bilde. Dette er en vesentlig forskjell i forhold til hvordan tradisjonell systemutvikling foregår. Der søker man å lage et helhetsbilde før en har alle bitene i puslespillet.
Programmerer jobber i par og roterer så ofte som mulig. Alle har ett felles eierskap til systemet og har på forhånd blitt enige om en kodestandard.
Ett team starter arbeidet med en funksjon ved å utarbeide en test. Dette er en kontrast til andre utviklingsmetoder der testene foretas etter at systemet er ferdigstilt. Når funksjonen er ferdig vil den bli implementert og testet i sammen med systemet forøvrig. Kunden er tilstede under hele utviklingen og skriver egne tester for å verifisere at foretningskrav blir tilfredstilt.
Hva er kriteriet for at det skal være et paradigmeskifte ?
Kriteriet for at det skal være et paradigmeskifte er at man endrer tankesett.
Det å forandre tankesett har vi sett i forhold til ”praksistrekanten”.
Paradigmeskifte vil si å få tilført noe på P3 nivå noe som forandrer hele det grunnleggende tankesettet. Dette ”noe” kan vi konkretisere med den viten som ble tilført forskere, noe som gjorde at de endret syn fra f.eks det geosentriske til det heliosentriske syn.
Som modellen viser kommer XP inn på P2 nivå som en metode/ lære. Grunnen til denne påstanden er at XP er en organisert og dokumentert modell på hvordan gå frem for å løse et prosjekt.
Det nye med metoden sett i forhold til tidligere presenterte metoder er at den i større grad fokuserer på kommunikasjon og prøver å utnytte relasjonene mellom to eller flere utviklere. Denne dialogen mellom dem kan tilføre prosjektet noe av verdi.
Metoden krever disiplin og kan samtidig bidra til at en del av de klassiske feilene kan unngås. Med klassiske feil menes de 36 McConnell beskriver i boken ”Rapid Development”. Disse er kategoriseres i ; mennesker, prosesesser, produkt og teknologi. Disse kategoriene henspeiler på McConnels diamant, der han illustrerer de fire dimensjonene (ikke retninger).
Med det mener han at ett prosjekt har fire dimensjoner som må sees i sammenheng i forhold til prosjektets fremgang.
McConnel prøver å beskrive hvordan man skal greie å utvikle raskere uten at det skal mislykkes. Boken gir oversikt over 36 klassiske feil systemutviklere stadig repeterer og legger videre vekt på estimering. For å drive rask utvikling mener McConnel at en skjemaorientert utvikling er det optimale og at SDLC velges ut i fra prosjektets natur. Estimering gjennom hele prosjektet skal kunne gi indikasjoner på om rett fremgangsmåte er valgt.
McConnel har definert 27 praksiser som er frittstående i motsetning til XP som har samarbeidenede. Ser vi på de 27 BP’ene til McConnel og Becks 12 praksiser, er det forbausende få som sammenfaller. Dette gir grunn til ettertanke og da særlig på om dette skillet vil ha noen effekt på 20-80 statestikken.
XP legger vekt på korte intervaller, forenklinger av problemstillinger og at det blir satt realistiske mål. Videre jobber man i team og kan da lettere hjelpe hverandre over eventuelle kneiker. (to hoder tenker bedre en ett hode.)
Som nevnt har McConnel definert 36 klassiske feil. Jeg vil fokusere på noen av de og se om de kan påvirkes av XP som metode.
- Motivasjonsproblemer
- Svakt faglig personell
- Bråkete og forstyrrende kontor
- Urealistiske forventninger
- Manglende forankring hos involverte
- Mangel på brukermedvirkning
Hvis en da ser på McConnell sine problem, ser man at punkt 1, motivasjonsproblemer, kan letter unngås ved at XP fokuserer på korte intervaller og hurtige avleveringer. Teamet opplever tilfredstillelse ved å kunne legge bak seg oppgaver.
Punkt 2, svakt faglig personell, kan letterer unngås, fordi gjensidig kommunikasjon/ opplæring fører til ny kunnskap. I løpet av prosjektet er det nærliggende å tro at utviklerene vil ligge på samme faglige nivå fordi man sammarbeider så tett i par og i team.
XP legger vekt på de ytre forhold som utstyr, hardware og arbeidsmiljø, noe McConnell ser på i punkt 3, bråkete og forstyrrende kontorer.
Videre vil punkt 4, urealistiske forventninger, bli sterkt redusert, nettopp på grunn av metodens bruk av korte intervaller.
Dette at teamet på forhånd er blitt enige om en standard kan være en medvirkende årsak til at punkt 5, manglende forankring hos involverte, og punkt 11, mangel på brukermedvirkning, blir redusert da metoden her fokuserer på delt eierskap av systemet. Det kan i større grad gi medbestemmelsesrett. Det er flere punkter som blir berørt av XP, men velger å ikke gå nærmere inn på dette i denne besvarelsen.
Årsaken til det er at vi enda ikke har erfaringsdata som kan underbygge en slik tankegang. Det er likevell interessant og bør belyses.