IT

I XP eksisterer praksisserne som en integreret måde at overholde principperne og værdierne i XP på.
Eksempelvis kan man med hjælp af praksissen Pair Programming opnå simplicitet og kvalitet på et højere niveau end hvis én enkelt programmør sidder og nørder med en indviklet klasse, som ingen anden umiddelbart kan forstå formålet med.

I anden udgave af XP er der fjernet 2 af de 14 ligestillede praksisser fra første version. Men tilgengæld er der nu hele 24 praksisser i anden version, 13 primære og 11 udledte.

I denne artikel gennemgås 12 udvalgte praksisser fra både den første og anden version af XP.

Forskellen på første og anden version af Extreme Programming gennemgås i flere detaljer i en denne artikel. (Fra 1. version til 2. version af XP)

Praksisser:

Whole Team (2. version)

Denne praksis blev oprindeligt kaldt ”On-site Customer” og med denne praksis forsøger XP at bryde barrieren imellem kunden og resten af udviklingsholdet. Kunden gøres til en del af holdet, med ansvar for og autoritet til at tage afgørende beslutninger, og derved styre udviklingen. Samtidig vil kunden også være nemt tilgængelig til at besvare spørgsmål, og løse eventuelle konflikter.
Kunden er i dette tilfælde, en person der repræsenterer en bruger af systemet, en person som rent faktisk kommer til at anvende det udviklede system, når det er implementeret.

Sådan blev denne praksis oprindeligt præsenteret af Kent Beck under navnet On-site Customer. Kent Beck har efterfølgende fortrudt denne beslutning, nærmere bestemt det at kunden skulle være én enkelt person, og anbefaler nu, i forordet til Pete McBreen’s bog ”Questioning Extreme Programming, et hold af repræsentanter i stedet for. Helst lige så stort eller større end selve udvikler holdet. Dog fremhæves vigtigheden af at holdet af repræsentanter kun har ét talerør, så resten af udviklingsholdet får ren og klar besked.

Metaphor (1. version, slettet i 2. version)

For at skabe en fælles forståelse af det system man skal udvikle, anvendte man i den første version af XP en enkelt og overordnet metafor. Denne metafor var blot en simpel fælles historie om hvordan systemet fungerer. Al navngivning og design egenskaber m.m. stammede fra denne metafor, og efterhånden som udviklingen skred frem bidrog metaforen også med ny inspiration. Af samme årsag ansås metaforen ofte for at være en erstatning for en egentlig arkitektur.

En metafor kunne eksempelvis være den lokale købmand, hvis projektet var at udvikle en online e-handelsløsning. Købmanden har varer, der lægges i en indkøbsvogn, hvor efter man går over til kassen for at betale.

Denne praksis er helt fjernet i 2. version af XP.

The Planning Game (1. version)

Formålet med The Planning Game er at bryde projektet ned i små 1-3 uger lange iterationer. Og at holde sig til den angivne deadline for iterationen. Dernæst at forudsige hvor meget der kan nås frem til den givne deadline i den givne iteration, og derefter at fastlægge det næste skridt i udviklingen. Kunden, eller rettere sagt kunderepræsentanterne, udfylder såkaldte historiekort (user stories) med de krav der stilles til det ønskede system. Dette er korte historier og et eksempel på sådan en historie kunne være ”Man skal kunne oprette nye varer i butikken”.

Udviklerne vil så lave en estimering af denne historie. Med andre ord vil de komme med en vurdering af hvad der skal til for at implementere dette krav. Historiekortet afleveres så igen til kunden, og kunden vil nu prioritere denne historie, og derved kontrollere udviklingens retning.

Simple Design (1. version)

Et systems overordnede design skal aldrig være mere avanceret end kravene til systemet på det givne tidspunkt. Ingen unødig kompleksitet eller duplikering af logik er tilladt, og koden skal være så simpel opbygget som det nu kan lade sig gøre. Alle tests skal kunne passere, og koden skal udtrykke alle de hensigter som er vigtige for udvikleren.
Hver enkelt del af systemet som ikke kan retfærdiggøre sin eksistens under disse forhold, må enten skrives om eller tilpasses disse forhold.

Small Releases (1. version, også kaldet Short Releases)

XP lægger op til hyppige afleveringer af fungerende og testet kode. Ved hver iterations afslutning bliver kunden præsenteret for nyt software. Der er ikke tale om omfattende eller halvfærdige moduler, men eksempelvis små fungerende historier der opfylder kundens behov. Det kunne eksempelvis være den anvendte historie ovenfor ”Man skal kunne oprette nye varer i butikken”.
Herefter afprøver og vurderer kunden det frigivne software, og ud fra det frigivne software planlægges indholdet af den næste aflevering, en iteration længere fremme.

Pair Programming (1. & 2. version)

Hver linje af kode, som afleveres til kunden i et XP projekt, bliver skrevet af udviklere som arbejder i par. Disse to udviklere sidder foran én enkelt arbejdsstation med ét tastatur og én mus. Personen der har kontrol over tastaturet er føreren, og vedkommende har også kontrol over musen og skriver al produktionskode. Den anden person fungerer som Anden Pilot, og vedkommendes rolle er at bistå føreren med forskellige opgaver, alt efter hvad der kan anses for at være passende i det givne øjeblik. Det kan være påpegning af små syntaksfejl, forslag til implementeringen, strategiske overvejelser eller lignende.

Anden piloten kan også overtage tastaturet til enhver tid, og der er ingen fastlagde regler for hvordan man danner par. Sidder man eksempelvis med en opgave indenfor et område, som man ikke har nogle erfaringer indenfor, kan man med fordel invitere en person med erfaring på området om at blive ens makker. Om man så danner par i 2 timer eller hele formiddagen beror på en individuel vurdering. Men et af hovedformålene med parprogrammering er, at hver person i gruppen skal kunne fungere som makker.

Test-First Programming (2. version)

Test-First udvikling dikterer at man først skriver testen, og derefter koden indtil testen kan kører igennem fejlfrit. Men dette gælder kun for produktionskode og det er naturligvis tilladt at afprøve nogle ideer, uden at man behøver at skrive en test først. Finder man ud af at det godt kan gennemføres, så sletter man koden og starter forfra og begynder med at skrive testen.
Det første udviklerne gør, er at blive enige om et delmål, ved at nedbryde problemstillingen i mindre bidder. Dernæst skriver man en test, hvis eneste formål er at sørge for at den kode man snart vil gå i gang med, kan opfylde delmålets krav.

Incremental Design (2. version)

Denne praksis er en sammenlægning af 2 praksisser fra 1. version af XP, Refactoring og Simple Design. Formålet med denne praksis er, at forbedre designet af eksisterende kode. XP dikterer at man skal stræbe efter et simpelt design. Og en af måderne at overholde denne praksis er, at man hele tiden er på udkig efter måder at forenkle designet af eksisterende kode, og stadigvæk kunne køre alle tests igennem.

Det at koden skal være ”eksisterende kode”, er ikke ensbetydende med at det er kode der er skrevet for lang tid siden. Koden behøver ikke at være mere end nogle få sekunder gammel, nemlig den kode du selv lige har skrevet. Hele ideen er, at denne refactorering bliver en integreret del af programmeringen. Ved hele tiden at overveje hvordan det kan gøres endnu mere enkelt, ender du teoretisk set med et bedre design af produktionskode.

Shared Code (1. & 2. version)

Denne praksis eksisterede også i den første version af XP med navnet Collective Code Ownership.

Idéen med denne praksis er, at alle på holdet bærer et fælles ansvar for hele koden. Hvis en udvikler får øje på noget vedkommende mener kan gøres på en mere enkel måde, står det frit for vedkommende at ændre koden til enhver tid. Hvem der oprindeligt skrev lige præcis disse linjers kode er irrelevant og formodentligt også glemt væk.
På grund af rotationerne i parprogrammering, kender de fleste udviklere noget til alle dele af systemet, og de har sikkert også arbejdet på den pågældende kode, eller kode der ligger tæt op ad den pågældende kode.

Med dette fælles ansvar følger der også nogle nye problemstillinger. Man kommer eksempelvis ikke udenom versionsstyring, da to par risikerer at sidde og arbejde på den samme kode. Og man bliver nødt til at acceptere, at den kode man forlod i går måske slet ikke eksisterer i dag.

Continuous Integration (1. version)

Grundet praksissen small releases, har man altid et fungerende system, på nær i den tidlige start af projektet. Dette system skal til en hver tid kunne compile, køre og bestå alle sine test. Hver gang et nyt stykke kode er skrevet, er det et kriterium at dette også skal kunne compile, køre og bestå sine test, før det må integreres i systemet. Når den nye kode så er integreret i systemet skal der igen laves kontrol på systemet, for at se om alt fungerer med den nye kode implementeret.

Dette er fremgangsmåden hver gang man har fuldført et stykke kode, og det sikre en høj grad af stabilitet, og giver også udviklerholdet en god følelse af fremskridt.

Continuous intergration betyder kort sagt, at systemet skal bygges hver gang en passende mængde kode, i form af funktionalitet, er kodet færdig – eller så ofte som muligt. Hvilket i professionelle XP teams ofte vil betyde flere gange om dagen. De tre føromtalte regler, skal compile, skal køre og skal bestå alle test, gør at det samlede system hele tiden fungere fejlfrit.

Sustainable Pace (1. & 2. version)

Praksissens formål er at et XP team kan holde en stabil (høj) arbejdsindsats over et helt projektforløb, at forbedre kvaliteten af arbejdet, samt holde moralen høj i udvikler holdet.

Arbejdsindsatsen er generel stor, men den skal ikke være større end at hele udvikler holdet kan holde den kørende i det uendelige. Man stiler mod at have samme arbejdsindsats i hver iteration for at få denne stabile rytme.

Med samme tanke i baghovedet er det også kun ”lovligt” at have overarbejde hvis det er effektivt at have det, dog ikke i længere perioder ad gangen. I XP’s tidlige stadie blev denne praksis da også kaldt for ”40-hour-week”.

Ved at bruge denne praksis, kommer man ikke ud i en ond cirkel. Overarbejde medfører trætte og udbrændte programmører, hvilket medfører at de laver flere fejl som igen resultere i mere overarbejde. Denne onde cirkel vil skade ethvert projektforløb og er ikke ligefrem med til at skabe kvalitetssoftware eller god moral i teamet. I sidste ende vil meget overarbejde, og/eller uregelmæssige arbejdstider sandsynligvis også føre til stressede deltagere på udvikler holdet.

Coding Standards (1. version, slettet i 2. version)

Formålet med denne praksis var, at alt kode skulle ligne noget der var skrevet af en og samme person, selvom der måske havde været 10 eller 20 forskellige programmører til at skrive den. Så ekstremt behøver det dog ikke at være, men alt kode skulle være nemt for en hvilken som helst programmør i teamet at læse. Dette fordi alle der skriver koden var blevet enige om en fælles kode standard, lige fra skrift størrelsen, over navngivning og konvention af klasser, metoder og variabler, til indrykning og placering af væltede Tuborg parenteser.

Når alle programmører i teamet var blevet enige om en fælles kode standard, var der ingen der kunne tillade sig at blive irriteret og bruge unødvendige ressourcer over småting, som for eksempel at rette på en indrykning af en væltet Tuborg parentes. Uden en fælles kode standard og med rotationsprincippet, parprogrammering og refactoring, kunne det udvikle sig til en hel formateringskrig – en masse formaterings refactoring.

I sidste ende var det underordnet hvilke beslutninger man tog for gruppens kode standard, bare man overholder det man var blevet enige om.

Denne praksis er dog fjernet fra 2. version af XP, da man nu anser det for at være mere indlysende end essientielt at opretholde en standard formatering af ens kode.