IT

For at et XP hold skal kunne fungere, er det nødvendigt at nogle særlige roller bliver udfyldt. Nogle af rollerne, så som Programmer, Customer og Coach er meget vigtige, og der bør ikke være nogen tvivl om disse rollers indehavere.

Denne artikel giver en hurtig introduktion af samtlige roller i XP.

Introduktion til Roller i XP

For at et XP hold skal kunne fungere, er det nødvendigt at nogle særlige roller bliver udfyldt. Det er mindre vigtigt hvem der udfylder de fleste roller, og det behøver ikke nødvendigvis at være den samme person hele tiden, faktisk vil det i de fleste tilfælde være en fordel at nogle af rollerne skifter person, da man derved opnår et større fællesansvar.
Nogle af rollerne, så som Programmer, Customer og Coach er meget vigtige, og der bør ikke være nogen tvivl om disse rollers indehavere. Men en Programmer og en Coach vil i de fleste tilfælde være en og samme person, og sådan skal det også være. De øvrige roller, som også bliver nævnt i XP sammenhæng, er Tester, Tracker, Consultant og Big Boss. Men her bør man være opmærksom på, at nogle af disse roller meget ofte vil være besat af en og samme person. Eksempelvis indgår både Tracker, Big Boss og Coach i ledelsen af et XP projekt.

Programmer

The Programmer, herefter kaldet udvikleren, er den der ved hvordan softwaren skal produceres og udgør derfor kernen i et XP hold. Udviklerens daglige aktivitet bør være fokuseret på at skrive kode af høj kvalitet, og at samarbejde med alle på XP holdet for at opnå dette.
For at udvikleren kan være i stand til at skrive kode af høj kvalitet, må udvikleren vide hvad der skal kodes, og hvad formålet med softwaren er. Så på trods af at udviklerne udgør kernen i et XP hold, er de ikke stærkere end kædens svageste led. Kommunikation er også udviklernes vigtigste egenskab og en forudsætning for et godt resultat.

Det at være en XP udvikler, er ikke helt det samme som de fleste normalt forbinder med en hvilken som helst software udvikler. Der stilles store krav til en XP udvikler, og ikke kun på et rent fagligt niveau. Ud over de rent tekniske færdigheder, man som XP udvikler må besidde, stilles der store krav til udviklerens evne til at præsentere enkle løsninger, frasige sig retten til ens kode, acceptere at man ikke får lov til at kode alene, da al programmering i XP foregår i form af par programmering.

Customer

The Customer, herefter kaldet kunden, er den der styrer udviklingens retning, og skal fortælle de øvrige rolleindehavere hvad der skal produceres i udviklingsforløbet og hvornår det skal produceres. Kunden behøver ikke nødvendigvis at være en enkelt person, eller en rigtig bruger, eller køber af slutproduktet. Men det er af afgørende betydning at kunden er repræsentativ, har en stor forståelse for hvad der ønskes af slutproduktet, og har en forståelse for hvad slutbrugeren ønsker at anvende slutproduktet til. Derfor er det i de fleste tilfælde en fordel hvis kunden består af et hold af slutbrugere, købere eller personer med ekspertviden på området. Skal man udvikle softwaren til et kasseapparat i det lokale supermarked, så vil kassedamen naturligvis være en bedre kunde i XP sammenhæng, end koncernchefen der rent faktisk betaler for softwaren. Men de overordnede krav til selve softwaren, så som integration i et lagersystem eller lignende, vil igen falde udenfor kassedamens ekspertviden.

Men det er ikke let at være kunde i et XP projekt. Der stilles store krav til kunden, både hvad angår mod til at tage de nødvendige beslutninger og vilje til at lære nye ting. Der stilles også store krav til kundens indstilling til projektet, og kundens evne og vilje til at være en del af XP holdet. Kunden må lære at skrive gode historiekort (små dagligdags historier der afspejler krav til systemet), og kunden må også lære at prioritere de vigtigste egenskaber ved systemet, frem for de egenskaber kunden personligt helst så implementeret. Hvilket kan være meget svært, og stiller store krav til kundens forståelse for hele systemet.

Coach

Coach, som herefter vil blive kaldt facilitator, må være en person som er god til mennesker, og som kan afhjælpe evt. blokeringer der forhindrer holdet i at opnå fremskridt. En XP facilitator må have en god forståelse for de praksisser der findes i XP, praksisser såsom Pair Programming, The Planning Game m.fl., for at kunne være i stand til at hjælpe resten af holdet til at gøre brug af praksisserne. Facilitatoren er nemlig ansvarlig for den overordnede proces, og må være i stand til at vejlede holdets øvrige medlemmer i den rigtige retning, som holdet bevæger sig imod. Med andre ord, er det facilitatorens opgave at bevare overblikket, uanset om resten af holdet går i panik.

Facilitatoren er også en XP udvikler, som vil arbejde med koden side om side med resten af holdet. For at kunne fungere som en god facilitator, forudsættes der altså en vis grad af erfaring med XP og software udvikling. Men facilitatoren behøver ikke nødvendigvis at være den mest erfarne på holdet.
Ud over at være en udvikler, på linje med de andre udviklere, fungerer facilitatoren også som en slags projektleder. Men ledelsesansvaret er mere rettet imod selve XP processen end det man normalt forstår ved en projektleder. En XP facilitators opgave er primært at vejlede holdet indenfor rammerne i XP, og derved indirekte lede holdet i den rigtige retning. Når resten af holdet modnes i takt med at projektet skrider frem, vil facilitatorens rolle langsomt glide endnu mere i baggrunden. I sidste ende er det jo hele holdets ansvar, at processen bliver gennemført med succes.

Tracker

Tracker, eller registranten som det vil blive kaldt herefter, er en af de roller som også indgår i den overordnede ledelse af et XP Projekt. Registranten, som ofte vil være en del af facilitator rollen, har til opgave at sørge for at samle op på alle de områder der bliver foretaget nogen estimering og registrering på, samt sørge for at hele holdet rent faktisk ved hvad der måles og registreres på, og komme med påmindelse af hvad der blev forudsagt eller forventet inden man gik i gang.

Udførelsen af praksissen ”The Planning Game”, hvor blandt andet historiekort, iterationer m.m. skabes, er et eksempel på registrering. Her indsamler man oplysninger om hvad man ønsker gennemført, og hvornår det skal være gennemført. Man laver estimater som man efterfølgende vil forsøge at leve op til.

Consultant

XP lægger, med sine mange praksisser, op til at man undgår specialister på holdet. Hele formålet med praksisser så som Pair Programming, hvor to programmører sidder sammen og programmerer, er at alle kan påtage sig ansvaret for stort set hver detalje i projektet, og at man derved ikke bliver afhængig af enkelte personer, som er de eneste der kender til en del af systemet.
Dette skaber en meget stor fleksibilitet iblandt holdets medlemmer, da man ikke risikerer at miste en dags arbejde på grund af sygdom m.m. Men de fleste projekter kan ikke gennemføres uden en smule ekspertise på visse områder. Man kan eksempelvis ikke forvente at alle på holdet kender til samtlige databasekomponenter på markedet, eller kender til samtlige biblioteks klasser i .NET frameworket. Så fra tid til anden vil der opstå et behov for ekspertise, og her adskiller XP sig ikke fra de fleste andre projektforløb. Man indkalder ganske enkelt en konsulent, med den nødvendige ekspertise på området.

Men som med alt andet er en XP konsulent ikke bare en hvilken som helst konsulent. En XP konsulent må stå model til meget mere end en almindelig konsulent, da det forventes at man køber konsulentens viden i bogstaveligste forstand.
En konsulent der bliver indkaldt til at bistå et XP hold, må forvente at holdets medlemmer vil suge al viden til sig, forsøge at forenkle vedkommendes arbejde og i sidste ende formodentligt smide hele arbejdet væk for selv at gentage konsulentens arbejde, sandsynligvis på en lidt anderledes måde.

Tester

Rollen som tester må ikke forveksles med en egentlig personlig rolle der skal udfyldes. Meget af testen vil foregå imens udviklerne sidder og koder, såkaldte unit tests, men en stor del af testene i XP bliver også lagt ovenpå kunderne. Sammen med kunden vil man udfærdige såkaldte Acceptance Tests, hvor kunden og udvikleren bliver enige om nøjagtigt hvad der skal til for at et historiekort, små dagligdags historier der afspejler krav til systemet, er opfyldt.

Big Boss

The Big Boss, som nogen gange også går under betegnelsen Manager, er lidt svær at skelne fra rollen som Coach. Denne rolle udfyldes af en person som tør være modig, når holdet har brug for mod, og som gruppen kan have tillid til vil insistere på at holdet holder sig til planen.

Når holdet ikke kan redegøre for sine gøremål, eller hvorfor man ikke kan se det ønskede resultat tage sin form. Da er det dennes opgave at standse processen, og mane til selvransagelse m.h.t. projektets formål. Kort sagt er der mest brug for denne rolle, hvis der er opstået problemer eller stagnation i processen. Og slet ikke brug for rollen når alt kører på skinner.