IT

Værdierne er de mest grundlæggende og centrale dele af XP, og danner derved grundlaget for et succesfuldt udviklingsforløb. I den første version af XP var der kun 4 værdier, men i den næste version var der tilføjet en 5. værdi (Respekt).

Denne artikel giver en kort gennemgang af de 5 værdier i XP (Communication, Feedback, Simplicity, Courage og Respect.)

Communication (kommunikation)

Den første værdi i XP er kommunikation. Og det er ikke helt tilfældigt at det står som den første værdi, da de fleste problemer i IT systemudviklings projekter, og uden tvivl også projekter generelt, kan spores tilbage til problemer med kommunikationen eller fraværet af brugbar kommunikation.
Det kan eksempelvis være at en udvikler ikke stiller kunden de rigtige spørgsmål, og at kravene til systemet derfor er forkerte. Eller en udvikler undlader at fortælle de andre udviklere om vigtige ændringer i designet, således at de andre udviklere arbejder på noget der ikke er anvendeligt i sidste ende. Eller blot dårlig kommunikation mellem projektledere og udviklerholdet, som kan føre til fejlvurderinger og fejlagtig kommunikation videre op i virksomhedens hierarki.

Der kan være mange årsager til brud på eller fraværet af konstruktiv kommunikation. Et af XP’s hovedformål er derfor, i første omgang at sørge for at der findes et godt flow af kommunikation, og dernæst at denne kommunikation foregår på en funktionel og nyttig måde. Måden dette gøres på i XP er via såkaldte praksisser, som ikke kan gennemføres uden kommunikation. Disse praksisser tæller blandt andre Pair Programming, Unit Testing og Estimering. Dette er praksisser der kun giver mening på kort sigt, men formålet er også primært at påtvinge en kommunikation mellem kunder, udviklere og ledere. Ikke blot disse grupper imellem, men også blandt de respektive gruppers medlemmer.

Simplicity (Enkelthed)

Enkelthed er i XP defineret som ”gør den enklest mulige ting, der måske ville kunne fungere”. Ideen med enkeltheden er, at man kun forsøger at løse de problemer man står med i dag, og stoler på at problemerne i morgen også kan løses.
De fleste systemudviklingsmetoder lægger op til at man altid, til en vis grad, skal tænke forud, hurtigt gennemskue afhængigheder m.m. Men derved begynder man også at blive bange for de ting man foretager sig; ”Hvad nu hvis det ikke passer sammen med et krav, som vi ved kommer på et senere tidspunkt?”. Så XP er også om at turde satse og have tillid til at morgendagens problemer også kan løses på en enkelt måde. Det kunne jo tænkes, at kundens krav eller forventninger til systemet var radikalt ændret dagen efter.

I sidste ende er det bedre at gøre det enkelt i dag, og risikere at skulle yde lidt mere i morgen for at ændre det, hvis det viser sig at være nødvendigt, end at gøre noget indviklet og tidskrævende i dag, som der måske alligevel ikke er brug for i morgen.

YAGNI er et XP begreb og det står for ”You Ain't Gonna Need It”. Formålet er, at man udelukkende implementerer det som kunden i bund og grund har brug for, og ikke det som kunden tror han har brug for, eller måske vil få brug for på et senere tidspunkt.

Dog kan man ikke altid forvente at kunne opnå absolut enkelthed, eller forvente at den enkleste løsning nødvendigvis er den bedste løsning. Nogen gange kræver et komplekst problem en kompleks løsning, på trods af at bestræbelsen altid bør være enkelte løsninger til komplekse problemer.
Et apparatur til medicinering af patienter bør eksempelvis være enkelt at betjene og ville uden tvivl fungere i al sin enkelthed. Men det ville i den grad være ønskværdigt, at der også implementeres noget sikkerhed og monitorering med det samme.

Feedback (Tilbagemelding)

Ethverts projekts succes rate afhænger i høj grad af kvaliteten af feedback. Derfor er feedback en af de grundlæggende værdier i XP, og lægger XP derfor op til at systemudviklingsforløbet konstant vurderes via konkret feedback.
I praksissen ”The Planning Game”, får udviklerne eksempelvis feedback fra kunderne, når kunderne skriver historier ned. Både kunden og udviklerne vil så få feedback når der skal laves acceptance tests, og kunden får igen feedback fra udviklerne, når udviklerne laver estimering af opgaverne, (vurderer hvor lang tid det tager at implementere en given opgave).

Men også andre praksisser så som Test-First Metoden, Continous Integration og Small Releases producerer store mængder af konstruktiv feedback. Så feedback er også noget der sker over forskellige tidsintervaller.

Ved at skrive tests før du koder en metode, vil du få feedback hver gang du kører testen for at se om metoden klarer testen. Men for at få den nye metode til at passere testen, var det måske nødvendigt at justere i koden, således at to ældre tests nu ikke kan blive godkendt. Den feedback vil så være behjælpelig med at overholde en kontinuerlig integration af alle metoder m.m. i hele systemet.

Jo mere feedback du får, jo mere kompleks bliver opgaven, men derimod giver det noget at kommunikere med og formindsker usikkerheden hos udviklerne. Når udviklerne eksempelvis præsenterer en tidlig udgave af systemet for kunden (Small Releases), så vil mængden af feedback naturligvis øges og kompleksiteten derved stige, men til gengæld formindskes udviklernes usikkerhed. Man kan derefter indlede en analytisk indgangsvinkel for at reducere kompleksiteten, eksempelvis ved at strukturere og nedbryde informationerne på historiekort (krav), for igen at reducere kompleksiteten. Men igen skaber det usikkerhed hos udviklerne, i form af nye historier (krav) fra kunden.

Courage (Mod)

Mod i XP skal ses i forhold til de 3 førnævnte værdier kommunikation, enkelthed og feedback. Mod kan i XP blive defineret som ”selvsikkerhed til at arbejde hurtigt og mod til at rekonstruere om nødvendigt”. Uden de 3 første værdier vil sådan et mod unægteligt lede til kaos og uoverskuelig kompleksitet.

Forestil dig et system på 50.000 linjers kode, som indeholder tests der garanterer hver enkelt metodes funktionalitet. Og du bliver som udvikler nødt til at tilføje en ny metode, som resulterer i at halvdelen af alle tests vil mislykkes. Det vil uden tvivl kræve meget mod at gennemføre denne ændring. Men da du samtidig får oplyst nøjagtigt hvor i koden der vil opstå konflikter, da du jo har fulgt Test-First Metoden, må man forvente at det ville kræve mindre mod at gennemføre handlingen, da du ved at du undgår uoverskuelige konflikter.

Respect (Respekt)

Denne femte værdi var ikke med blandt Kent Beck’s første værdier, men han indså at en god udførelse af de første fire værdier alle var afhængige af respekt, og har derfor senere tilføjet denne værdi. I virkeligheden drejer det sig vel bare om at have en sund fornuft, god attitude og være høflig.
Alle på udviklerholdet skal respektere og interessere sig for hinanden, projektet som en helhed og for organisationerne der er i berøring med projektet, samt hvad andre bidrager med. Hvis folk ikke gør dette, vil udvikling med XP ikke fungere optimalt, hvis det overhoved vil fungere.