Samlet af systemet. - konvergens i en XP-organisation baseret på løsarbejdere

inger tilrådighed indsixp opdatering kode kunde tracker coach parprogrammering k ommunikation feedback awareness beslutn flad organis ation flexibilitet adfærdsmønstre simpelt analyse platformsuafhængigt informati n leder koordination rkonvergens system løsarbejdere Kresten vidensdeling kvalitet udviklere fuldtid divergens administratio GROUPWARE EXPLICIT FORSTÅELSE WYSIWYG ENKELHED SAMHØRIGHED WYSIWYG TEST JONAS DATA FLEKSIBILiTET BRUGER MEDBESTEMMELSE LARS DREAMHOUSE TACIT JAVA SOFTWARE REFLEKSIV LATEX Samlet af systemet - konvergens i en XP-organisation baseret på løsarbejdere NIKOLAJ OOAD MØNSTRE FORMALISERING MULIGGØRELSE CSCW INTERPERSONEL FORSTÅELSE LÆRING STRUKTUR PLANLÆGNING igid 2 m i3d tpg proje kt home ikt ipk kit gt ensomhed samarbejde kendskab tea mfølelse praksisfællesskab social viden facilitering visdom iterationer aktiviteter praksis mod XP MEDIERET INFORMATION KOORDINATION KOHERENS M2I3D NINA RELATION DENNIS

Dennis Nørgaard Jonas Dinesen Lars Byrialsen Nikolaj Dam Østergaard Nina Lilholt 29. maj 2004

2 Forord Tak til Kresten ThomsenѾi3D for stor samarbejdsvillighed, samt for at skabe bevæggrundene til dette projekt. Tak til vejleder Per Hasle for gennemført og veldokumenteret vejledning. Tak til Louise for gennemlæsning og feedback. Tak til Michael og Nicolai for svar.

Indhold I Introduktion 7 1 Indledning 9 1.1 Extreme Programming......................... 10 1.2 Overordnet undren........................... 11 1.3 Problemformulering........................... 13 2 Metode 14 2.1 Fokus.................................. 14 2.2 Rapportstruktur............................. 14 2.3 Vidensindsamling............................ 15 2.4 Objektorienteret analyse og design................... 16 2.5 Udviklingsperspektiv og udsigelseskraft................ 17 3 Temarammeredegørelse 19 II Kontekstbeskrivelse 22 4 Casebeskrivelse 24 4.1 Præsentation af firmaetñ¾i3d..................... 24 4.2Ѿi3Ds produkt............................. 27 4.3 Projektgruppens kontakt........................ 27 5 Extreme Programming 28 5.1 Værdier og principper.......................... 28 5.2 Relevante punkter vedñ¾i3d s brug af XP.............. 31 5.3 Opsamling Extreme Programming................... 34 INDHOLD

4 INDHOLD 6 Løsarbejdere 36 6.1 Fra studentermedhjælper til løsarbejder................ 36 6.2 Empiri - løsarbejdere.......................... 37 6.3 Empiri - workshop........................... 38 6.4 Tilhørsforhold.............................. 39 6.5 Opsamling løsarbejdere......................... 40 7 Vidensdeling 42 7.1 Facilitering af viden........................... 42 7.2 Viden.................................. 43 7.3 Fire former for vidensdeling...................... 45 7.4 Motivationen bag vidensdeling..................... 46 7.5 Opsamling vidensdeling........................ 47 8 IT 48 8.1 Groupware............................... 48 8.2 Otte udfordringer for Groupware.................... 49 8.3 Opsamling IT.............................. 50 9 Kontekstforståelse og -afgrænsning 52 9.1 Vidensdeling i organisationen...................... 52 9.2 Kondensat................................ 54 III Objekt-Orienteret Analyse 56 10 Systemvalg 58 10.1 Overvejelser............................... 58 10.2 Rige billeder............................... 59 10.3 Systemdefinition............................ 62 11 Hændelsestabel 65 11.1 Fra objekt til klasse........................... 65 11.2 Hændelser................................ 67 12 Klassediagram 69 INDHOLD

INDHOLD 5 12.1 Øvrige forslag til strukturer....................... 72 13 Tilstandsdiagram 74 13.1 Adfærdsmønstre og tilstandsdiagram.................. 74 13.2 Attributter................................ 78 14 Refleksioner over brug af OOA 80 14.1 Refleksioner i det små.......................... 80 14.2 Overordnede overvejelser........................ 82 IV Opsamling 84 15 Konklusion 86 15.1 Konklusion på første del af problemformuleringen........... 86 15.2 Konklusion på anden del af problemformuleringen.......... 87 16 Kritik 89 16.1 Fokus i projektet - og kritik af metodevalg............... 89 16.2 Kritik af analyse............................. 90 V Bilag 92 A XP-workshop 94 B Spørgsmål til løsarbejder i udviklingsorganisation 103 C Interview med Michael V. Rydtoft, 21.04.2004 104 D Interview med Nicolai Larsen, 22.04.2004 107 E Jonathan Grudins 8 udfordringer for en systemudvikler af Groupware 109 F Systemdefinition udkast 112 G Information med relevans for udvikler 115 H Fravalgte forslag til strukturer. 119 INDHOLD

6 INDHOLD I Klasse- og hændelseskandidater 121 J Ansvarliste 123 Litteraturliste 124 INDHOLD

Del I Introduktion

Kapitel 1 Indledning Gennem et semesterforløb præsenteres den studerende for helt nye teorier og får samtidig udbygget kendskabet til allerede kendte. Deltageren i en sådan læringsproces kan få forskellige aha-oplevelser ; når man pludselig får overblikket over de forskellige teorier, og dermed kan se en sammenhæng, både mellem forskellige teorier, men også på tværs af forelæsninger og semestre. Disse aha-oplevelser afføder næsten per automatik en reaktion, hvor den studerende forsøger at kombinere den nye viden med den allerede tilegnede og anvende den nye kombination til at besvare forskellige problemstillinger. Denne proces er ofte præget af en eklektisk tilgang, hvor der zappes rundt imellem de forskellige teorier, mens man forsøger at skrue et teoriapparat sammen, som tager højde for alle de forskellige problemstillinger i den aktuelle kontekst, der kan generere et nyt og anderledes løsningsforslag på disse. Stor er derfor frustrationen, når det endelig er lykkedes at opstille et sådan teoriapparat, og man efterfølgende kan konstatere, at det indeholder nogle spændingsfelter, som gør at teorierne ikke umiddelbart er kompatible til løsning af den aktuelle problemstilling. Et andet forhold, der kan spille ind, er den latente konflikt mellem teori og praksis. Et opstillet teori- og begrebsapperat fungerer umiddelbart indenfor universitetets kunstige verden, men når det skal operationaliseres, eller afprøves i praksis, afdækkes forhold, som det ikke er nødvendigt at medtænke, når man udelukkende arbejder på det teoretiske plan. Pludselig opdager man, at et forhold, som f.eks. økonomi, kan bevirke, at det ikke er det optimale løsningsforslag, der bliver valgt, og at man derfor skal være i stand til at acceptere kompromiser, som ville blive afvist i teorilokalet. Vi har i projektgruppen anet en risiko for den sidstnævnte konflikt i forbindelse med en konkret case og vil i det følgende præsentere denne, samt den deraf følgende undren. Casen, som anvendes til at besvare problemstillingen, er baseret på et igangværende 10. semesters speciale, hvis formål det er at opbygge en organisation, der, udover at være bæredygtig, skal imødekomme igangsætterens ønske om en flad og smidig organisationsstruktur, der er bygget op omkring en udstrakt brug af studentermedhjælpere (en mere detaljeret gennemgang af casen finde i kapitel 4). Brugen af studentermedhjælpere udspringer netop af en økonomisk begrænsning, hvor igangsætteren bliver nødt til at indgå et kompromis for at kunne få sin case operationaliseret. Det ideelle ville have

10 Indledning været at ansætte fuldtidsmedarbejdere, men det ville sprænge de økonomiske rammer for opstarten af firmaet. Formålet med opbygningen af organisationen er at udvikle software til grundplanstegning i en ejendomsmæglerkæde 1. Organisationen er stadig i opstartsfasen og er derfor p.t. uden ansatte. Det beskrevne firmas navn erñ¾i3d, og projektgruppens samarbejde med firmaet vil være rettet mod de organisatoriske overvejelser, og - hvilket er vores antagelse - det paradoks, der opstår som følge af den valgte systemudviklingsmetode, Extreme Programming, og den måde hvorpå igangsætteren ønsker at strukturere sin organisation ved at ansætte studentermedhjælpere. Samarbejdet vil også udmønte sig i et reelt designforslag, som har til formål at afhjælpe nogle af de paradokser, som projektgruppen mener kan opstå, hvilket vi uddyber nærmere efter en kort introduktion til Extreme Programming. 1.1 Extreme Programming Extreme Programming (XP) 2 er en systemudviklingsmetode der først og fremmest udspringer af behovene hos udviklerne på projekter og derfor fokuserer herpå. Det kan man sætte i modsætning til mere traditionelle udviklingsmetoder, der ofte tager udgangspunkt i projektledelsens behov.[mcbreen 2003:25] Introduktionen tager udganspunkt i Beck [2002]. Ifølge Beck [2002] giver udviklingen af et system ved anvendelse af XP-metoden mulighed for en fleksibilitet, der minimerer risici 3 ved ændringer sammenlignet med andre metoder. Dermed er der en forskel på XP og andre metoder, og meget generelt ligger forskellen i, at man i XP ikke vælger at lave en detaljeret planlægning af såvel hele systemet, som hele projektforløbet, men arbejder i iterationer, hvor der kun fokuseres på det, der af kunden er vurderet som allermest nødvendigt. I den forbindelse fravælger man at udvikle på opgaveløsninger og problematikker, der ikke har en umiddelbar relevans. Man kan dermed tale om, at man udvikler på det enklest mulige system, når der udvikles efter XPs retningslinier, og enkelheden skal afpejles i opgaveløsningerne, således at de er så letforståelige som muligt, også på kodeniveau. Det vil derfor være forholdsvis smeretefrit at gennemføre ændringer, hvis der opstår en fejl undervejs, eller hvis kundens feedback viser, at designet ikke opfylder deres ønsker. Dette har betydning både økonomisk og tidsmæssigt. Det, at man ikke planlægger hele udviklingsforløbet og systemdesignet, sammenholdt med, at man nedbryder udviklingsforløbet i små iterationer 4, er med til at give mulighed for den førnævnte fleksibilitet, der er hensigtsmæssig i tilfælde af ændringer. I den forbindelse spiller test en stor rolle i XP. Tests er omdrejningspunktet for al opgaveløsningen og skal gøres hyppigt og både med og uden kunden. Test sikrer at løsningerne fungerer, at de er kompatible med de øvrige løsninger, hvormed de udgør et system og at de rent faktisk løser den opgave kunden har stillet. Udover at kunden er en del af evalueringen af løsningsforslag, er kunden også generelt en integreret part i hele udviklingsforløbet, som udviklerne løbende kan kommunikere med, og man bestræber 1 Casen og organisationens opbygning gennemgås i Casebeskrivelse, kap. 4. 2 En gennemgang af XP som metode sker i kapitel 5 3 Risici kan her være forbundet med økonomomi, softwarekvalitet, kundetilfredshed mv., se kapitel 5 4 Metoden gennemgåes i kapitel 5 1.1 Extreme Programming

Indledning 11 sig derudover på at implementere systemet hos kunden, så snart det kan lade sig gøre for derved også at få feedback. Den sikkerhed og det overblik der kommer af at have et gennemtestet, og så vidt muligt enkelt og letforståeligt system, er medvirkende til, at udviklerne er trygge ved og bliver motiveret til at foretage ændringer i systemet, om det skulle være nødvendigt. Det være sig ændringer, der er påkrævet pga. ændrede opgaver eller forkerte løsninger, såvel som ændringer der udspringer af interne krav om så enkle løsninger som muligt. Alle har adgang til samtlige dele af systemet og deler ansvaret for, at det lever op til kravene, så alle har lige ret og mulighed for at gennemføre ændringer. Udover at koden i sig selv hjælper med til, at udvikleren opnår den nødvendige indsigt i det der udvikles på, er ansigt-til-ansigt kommunikation udviklerne imellem den centrale måde til at formidle hensigt med løsninger, få hjælp osv. En retningslinie i XP er derfor, at udviklerne arbejder i samme lokale og altid er til rådighed for hinanden. Dertil kommer, at ingen udvikler arbejder alene i XP, men altid danner par med en anden omkring løsningen af en opgave. Opgaverne vælger udviklerne selv blandt de tilgængelige, og XPs fortalere påpeger, at metoden har en forholdsvis lille grad af styring og faciliterer en flad struktur i en udviklingsorganisation. Kommunikation er en vigtig del af flere af aktiviterne i XP, såsom planlægningsaktiviteten, og som skitseret tidligere er kunden en løbende og vigtig del af udviklingen. Endda så vigtig at XP anbefaler, at en repræsentant for kunden altid er tilstede i lokalet sammen med udviklerne. Kommunikationen mellem parterne i et XP udviklingsforløb er meget vigtigt, og kommunikation kaldes da også for den første værdi i Extreme Programming (værdierne bliver gennemgået i kapitel 5). I den aktuelle case er denne systemudviklingsmetode valgt både fordi iværksætteren, som tidligere nævnt, ønsker en smidig og flad organisationsstruktur, men også fordi han ønsker en høj grad af uddelegering af beslutningskompetence på alle niveauer i organisationen med det formål at kunne leve op til CMM modellens 5 krav til kvalitetssikring på de første tre niveauer. 1.2 Overordnet undren Vores antagelse om, at brugen af studentermedhjælpere iñ¾i3d vil konflikte med anvendelsen af XP-metoden, udspringer af to omstændigheder. Dels har vi en formodning om, at studentermedhjælpere, såsom demñ¾i3d vil ansætte, ikke kan forventes at kunne arbejde samtidigt med resten afñ¾i3d og på faste tidspunkter 6. Dels er det planlagt, at udviklingen iñ¾i3d skal foregå i henhold til XPs retningslinier. Som beskrevet i det foregående afsnit, lægger XP meget stor vægt på, at projektets parter, herunder udviklerne, arbejder på samme tid og sted og derved let kan kommunikere. Alene af den grund ser vi et paradoks i koblingen af både studentermedhjælpere og Extreme Programming. Derudover stiller vi os generelt undrende overfor, om XP i sin beskrevne form ikke er for idealistisk og vanskelig at realisere i sin fulde udstrækning. I den forbindelse ser vi XPs retningslinier for udviklernes og kunderepræsentantens løbende og samtidige tilstedeværelse i arbejdsmiljøet som værende de mest iøjnefaldende 5 Modellen og anvendelsen af denne gennemgås i kapitel 4 6 Problemstillinger forbundet med at arbejde som studentermedhjælper, såvel i forbindelse med XP som generelt, vil blive behandlet yderligere i kapitel 6. 1.2 Overordnet undren

12 Indledning idealer; idealer der kan være vanskelige at realisere fuldt ud. Dog sætter casen det præg på vores projekt, at kunderepræsentanten ikke er involveret i casens udviklingsforløb. Igangsætteren af firmaet vil forsøge at varetage kunderollen og fungere som bindeled mellem udviklere og kunde. Dette forhold vil blive uddybet i case-beskrivelsen (Kapitel 4). En systemudviklingsmetode skal altid tilpasses den organisation, den skal benyttes i, og som det allerede nu fremgår, vil vi sætte spørgsmålstegn ved aspekter af XP, hvis tilstedeværelse er så centrale for gennemførelsen af den ideelle brug af XP, at vort tilpasningsforslag evt. vil kunne anses som en del af en variation over XP og ikke kan forsvares at lade indgå som en del af det ægte og ideelle XP. Selvom det måske snarere bliver et udviklingsmiljø, der fungerer efter en variation end ren XP, som vores projekt beskæftiger sig med, skal fordelene ved XP naturligvis stadig så vidt muligt holdes i hævd. I den forbindelse ser vi specielt ét argument for brugen af XP, som vi vil tage op senere i projektrapporten for at vurdere, om det stadig gælder efter vore eventuelle ændringer af XP. Det drejer sig om, at vi anser flere af retningslinierne i XP som værende faciliterende for, at udviklernes forståelse af systemet konvergerer. Vi har en antagelse om, at brugen af studentermedhjælpere kan konflikte med XPs værdier og principper om tætte samarbejdsformer, der sikrer konvergens i systemudviklingen. Det er mennesker og deres indbyrdes relationer, der skaber paradokset. Som beskrevet i ovenstående afsnit fordrer XP løbende dialog blandt udviklerne, og dermed eksplicitering af status, problemer, beslutninger etc. Denne konstante eksplicitte erfaringsudveksling kan vi dække ind under det lidt brede begreb vidensdeling. Hvilken del af vidensdeling vi vil fokusere på vil blive indsnævret igennem en foranalyse (uddybes i kapitel 2), hvor vi undersøger hvilke områder af vidensdeling, der er problematiske ved anvendelsen af løsarbejdere. Desuden vil vi i forundersøgelsen afklare vores syn på vidensdeling og dets elementer (kapitel 7). Andet fokus for vores projekt bliver hvilke dele af vidensdelingsproblematikkerne vi kan støtte via et edb-system. Afdækningen af dette sker dels igennem løbende refleksioner over it-systemers kunnen i foranalysen, dels igennem Objekt-Orienteret Analyse og Design (OOA&D) systemudviklingsmetoden 7, hvor vi arbejder med at formalisere konteksten og danner en mening om hvilke funktionaliteter, der skal vægtes. Valget af OOA&D-metoden skyldes forskellige faktorer. Den beskrevne fremgangsmåde i [Mathiassen et al. 2001] er håndgribelig og derved umiddelbart nem operationaliserbar. De anvendte teknikker i metoden, mener vi, giver hurtigt et overblik over strukturen i et design. Pga. af denne håndgribelighed har vi en formodning om, at metoden er effektiv til at strukturere og designe et løsningsforslag. OOA&D er en metode, der bl.a. egner sig til at udvikle administrative systemer, hvilke vi har en hypotese om skyldes, at metoden, idet den baserer sig på at systematisere virkeligheden, egner sig til at skabe overblik i komplekse arbejdspraksisser. Metoden bliver desuden udnyttet i stor udstrækning i reel systemudvikling. Desto mere motiverende har det været at kunne fordybe os i metoden og danne en mening om dens muligheder og svagheder. For at besvare de problemstillinger vi har skitseret ovenfor, tager vi, som nævnt udgangspunkt i casenñ¾i3d om udvikling og opbygning af en organisation baseret på XPs principper og en overvægt af studentermedhjælpere som ansatte. 7 OOA&D-metoden forstår vi udfra Mathiassen et al. [2001]. 1.2 Overordnet undren

Indledning 13 1.3 Problemformulering Med udgangspunkt i ovenstående spørgsmål opstilles en problemformulering med følgende ordlyd: Hvilke funktionaliteter 8 skal et system indeholde for at sikre vidensdeling i en organisation baseret på XP-principperne, når organisationen er bygget op omkring brugen af løsarbejdere, og hvordan og i hvilken udstrækning understøtter OOA&D analyse specificeringen og struktureringen af disse funktionaliteter? 8 Med begrebet funktionaliteter forstår vi redskaber, der kan medvirke til at facilitere information på tværs af organisationen, og som derfor kan inddrages i vores designforslag. 1.3 Problemformulering

Kapitel 2 Metode Dette kapitel redegør for rapportens elementer og giver en oversigt over de enkelte deles indhold og formål. Ligeledes argumenterer vi her for den overordnede metodiske fremgangsmåde til besvarelse af problemformuleringen. 2.1 Fokus Foki for dette projekt er: Problematikken ved anvendelse af XP som udviklingsmetode i en organisation, der i vid udstrækning anvender løsarbejdere 1 samt afdække hvilke vidensdelingsproblematikker, der med fordel kan afhjælpes af et it-system. Hvorledes og i hvilken udstrækning objektorienteret analyse kan benyttes til udformning af ovennævnte it-system. Projektet tager udgangspunkt i en specifik case (se kapitel 4), og på baggrund af denne vil arbejdet med at besvare problemformuleringen tage afsæt i de interne processer udviklerne imellem, hvorved processer i forhold til eksterne aktører, eks. kunder 2, fravælges. 2.2 Rapportstruktur Rapporten består af fire dele, hvoraf del I og IV henholdsvis introducerer projektet og samler op på dets resultater, medens del II og III behandler projektets to overordnede foki: 1 Begrebet løsarbejder defineres/uddybes i afsnit 6. 2 Sædvanligvis spiller kunden en væsentlig rolle i forbindelse med den interne udvikling, jf. princippet om kundetilstedeværelse [Beck 2002:61], men i casen, der er grundlaget for dette projekt, har kunden ingen indflydelse på dette, og derfor ser vi i dette projekt kunden som værende en ekstern aktør.

Metode 15 Identificer funktionaliteter: (delii) Målet er her, set i lyset af XP, at identificere funktionaliteter for et edb-system, der understøtter vidensdeling og dermed udvikling på trods af ovennævnte problematik. Eftersom casen bygger på en udviklingsorganisation, der endnu er uden ansatte, kan denne kun i ringe grad bidrage med empiri, og tilgangen i projektet er derfor, at førnævnte organisation udstikker rammer, indenfor hvilke vi forsøger at afdække problematikker. Vores viden dannes primært på baggrund af følgende områder - empirisk såvel som teoretisk: XP (kapitel 5) Løsarbejdere (kapitel 6) Teori Vidensdeling (kapitel 7) IT (kapitel 8) Områderne XP og Løsarbejdere springer direkte ud af casen, og afdækker problematikkerne for organisationen, både teoretisk og empirisk. Vidensdeling er gennem afdækningen af XP blevet et nøglebegreb, og er derfor trukket frem. Mens IT-kapitlet stiller yderligere krav til systemets indhold. Indledende vil vi studere, hvad der kendetegner en løsarbejder i forhold til en organisatorisk kontekst, dernæst vil vi se på vidensdeling, og hvordan det kan kobles i forhold til løsarbejderen, og til slut vil vi i kapitlet afdække vidensdeling og it-redskaber. Hvert kapitel vil blive afsluttet med en opsamling. Udfra de afdækkede problematikker opstilles en række fokuspunkter, der tjener som udgangspunkt for rapportens del III. Specificer og strukturer funktionaliteter: (del III) På baggrund af resultaterne fra del II laves en objekt-orienteret analyse for et vidensdelingsværktøj, der skal støtte løsarbejdere i en organisation, som beskrevet i casen. 2.3 Vidensindsamling På baggrund af vores case har det været vanskeligt at indsamle viden 3 om problematikker ved XP kombineret med løsarbejdere, og vi har derfor baseret denne viden på litteratur samt anden empiri. I nedenstående afsnit redegør vi for valg af disse og beskriver, hvorledes teori og empiri har bidraget til at afdække problematikkerne. 2.3.1 XP I vores forståelse af XP som udviklingsmetode, har vi taget udgangspunkt i Beck [2002]. Dette valg skal ses i lyset af, at virksomheden i casen skal opbygges efter principperne i netop denne bog, og det kan således forventes at de problematikker, vi identificerer vha. bogen i rapportens del II, vil være relevante for denne virksomhed. 3 Brugen af ordet indsamle i forbindelse med viden kan problematiseres, specielt ud fra den forståelse af viden som vi fremlægger i kapitel 7. Det benyttes her i en common sense forståelse. 2.3 Vidensindsamling

16 Metode Vi har således benyttet denne bog til dels at få forståelse af filosofien bag metoden, dels til at få overblik over de redskaber og aktiviteter, som den foreslår. Vi har endvidere benyttet Michele Marchesi and Williams [2002] til at afdække aspekter af fænomenet distribueret XP. Endelig har vi gennemført en workshop hosñ¾i3d. Formålet hermed var at få erfaring med XP; på trods af at denne fremgangsmetode ville have en begrænset udsigelseskraft i forhold til vores problemformulering, mente vi, at den alligevel vil kunne give os et førstehåndsindtryk af nogle af metodens væsentligste principper. 2.3.2 Løsarbejdere Opbygningen i dette kapitel er todelt, en teoretisk og en praktisk del. Vi undersøger, hvad der kendetegner løsarbejdere, deres arbejdsforhold og derudfra vil vi opstille vores forståelse og definition af begrebet. Til at afdække hvad der kan stimulere medarbejdere til at knytte sig til og involvere sig i en organisation, har vi taget afsæt i Wenger [1999]. Den praktiske del har bestået i, at vi har foretaget interviews med løsarbejdere med det formål at afdække problemer, der opstår i forbindelse med koordinering mellem disse og den omgivende organisation. Disse interviews er gennemført, fordi der endnu ikke er ansat udviklere iñ¾i3d s organisation. Formålet var at afdække eventuelle problemstillinger i det at være deltidsansat udvikler i en organisation. 2.3.3 Vidensdeling Begreberne Viden og Vidensdeling er centrale begreber i dette projekt, og vi har derfor brug for konsensus både om deres definition, og om brugen af dem. Et formål med dette kapitel vil derfor være en indsnævring af disse begreber, samt identificering af faktorer/principper, der kan understøtte vidensdeling i organisationer. Til en definition af vidensbegrebet anvender vi indledende Bellinger [2004] og de fire begreber, han opstiller i forbindelse med viden, og bearbejder derefter viden gennem Nonaka et al. [2000] og dennes tanker om hvorledes, der skabes incitament for at den enkelte tager del i vidensdeling. Kapitlet vil vi anvende til at beskrive, hvordan vidensdeling finder sted i organisationer. 2.3.4 IT Formålet med dette kapitel er at inddrage et perspektiv på it. Gennem Grudin [1994b] får vi en kategorisering af software, som tager afsæt i, hvem softwaren supporterer i en organisation. Specifikt tager Grudin fat på software til støtte af gruppe-arbejde, hvor han påpeger en række udfordringer, som udvikleren af gruppe-software vil møde. 2.4 Objektorienteret analyse og design I et forsøg på at specificere og strukturere de funktionaliteter, der identificeres i rapportens del II, tager vi udgangspunkt i objektorienteret analyse og design som beskrevet 2.4 Objektorienteret analyse og design

Metode 17 af Mathiassen et al. [2001]. Vi vil således gennemføre de indledende aktiviteter i et udviklingsforløb, det vil specifikt sige de aktiviteter der beskrives under analysefaserne i førnævnte. Formålet er at beskrive systemet set udefra [Mathiassen et al. 1998:4], og vi vil i formidlingen af aktiviteterne fra analysefaserne vægte processen højt, hvorfor denne del af rapporten ikke blot vil indeholde resultater, men også argumenter for valg og fravalg. 2.5 Udviklingsperspektiv og udsigelseskraft Vi afklarer i dette afsnit vores syn på udvikling, system, brugere og udviklere, for at danne en mening om vores udsigelseskraft for projektet. Med udsigelseskraft mener vi, i hvilken grad vi har belæg for og dermed pondus bag de resultater, vi kommer frem til. Først og fremmest mener vi, at det er en væsentlig del af en udviklers opgave at sætte sig ind i den arbejdspraksis, som systemet skal understøtte. Vi tror ikke på, at en udvikler kan forudse problemer og behov i en fremmed arbejdskontekst uden at have beskæftiget sig med den mangfoldighed af faktorer, der skaber konteksten. Optimalt skal udvikleren i kontakt med de egentlig brugere (observation, interview etc.), for at få udfordret hans/hendes forståelseshorisont og få indsigt i de egentlige mønstre. Dvs. vi mener, at systemet skal designes til en kontekst, og at konteksten rummer kravene for systemets indhold. Derudover ser vi systemudvikling som organisationsudvikling. Det vil sige, at systemet påvirker organisationen og ikke kun understøtter en arbejdspraksis, men også ændrer på den. Integrationen foregår ved en løbende dialog mellem brugere og system, og systemet må ikke blive et påklistret element. Inddragelse af brugeren kan desuden være med til at hindre divergens mellem de fra udviklerens tiltænkte brugsmønstre og brugerens egentlige brug af systemet. Brugerinddragelse, mener vi, kan skabe indsigt både i de behov, som systemet skal understøtte, men også ift. hvilke forudsætninger, der skal være opfyldt før brugerne tager systemet i anvendelse. I vores tilfælde hvor organisationen endnu ikke har nogle ansatte skaber dette nogle problemer for vores empiri. Løsningen har været at søge inspiration i lignende kontekster, med en bred vifte af indgangsvinkler, teoretisk såvel som empirisk. På den måde mener vi stadig at få dannet indblik i arbejdskonteksten, selvom det får nogle problemer for vores udsigelseskraft, hvilket vi præsenterer sidst i metoden. Da vores brugere er ikke-eksisterende, kommer vi i højere grad til at træffe beslutninger på deres vegne, og hvor identifikationen af kritiske faktorer bliver skabt gennem indsigt i lignende kontekster, baserer vi primært afdækningen af specifikke forhold forñ¾i3d gennem Kresten Thomsens 4 visioner for hans organisation Ved at lægge den endelige beslutning på Kresten, og samtidig påtage os den opgave at lave et system, der stemmer overens med organisationens krav, lægger vi os op af Professionel systemudvikling. Inden for denne tradition fravælges politiske beslutninger, som f.eks. hvorvidt systemet gør medarbejdere overflødige. Vi bevæger os dog alligevel på grænsen, fordi vi får indflydelse på Krestens beslutninger for hans virksomhed, 4 Kresten Thomsen er opstarter af virksomhedenñ¾i3d 2.5 Udviklingsperspektiv og udsigelseskraft

18 Metode idet den stadig er ikke-eksisterende. I arbejdet med at opbygge casen, har vi været i dialog med Kresten. Heraf er der naturligt opstået nogle kritiske diskussioner. Dvs. at vi i dialogen ikke kun har forholdt os lyttende til hans visioner, men også aktivt kritiske. Vi mener, at udvikleren ikke kan skabe et system til en arbejdskontekst, han/hun ikke kender, da udvikleren vil mangle forudsætninger for at kunne afdække og reagere på de forhold, der eksisterer i og for virksomheden. Derudover fungerer vi som udviklere, der, selvom vi reagerer på ledelsens visioner, stræber imod at varetage brugernes interesse og skabe et system til gavn for hele organisationen. Grundet udgangspunkt i en endnu ikke etableret organisation er hovedparten af projektets resultater teoretisk funderet, og vi kan derfor ikke evaluere, hvorvidt de identificerede funktionaliteter, endsige specificeringen og struktureringen af disse, er relevante for organisationens problemstillinger, førend denne bliver etableret. 2.5 Udviklingsperspektiv og udsigelseskraft

Kapitel 3 Temarammeredegørelse Temarammen for 6. semester Humanistisk Datalogi er Systemdesign, hvor system er et computerstøttet informations- eller kommunikationssystem (ikt). I semesterplanen står der, at systemdesign skal ses i et udviklingsperspektiv, hvilket betyder, at vi som studerende ikke kun skal styrke vores analytiske, refleksive og kritiske evner, men også de konstruktive. Til dette formål introducerede kurserne på 6. semester os til et bredt spektre af traditioner og metoder, men også til specifikke metoder som f.eks. OOA&Dog MUST-metoden. Kurser der blev afholdt på 6. semester: Systemer i organisationer Metoder i systemdesign Praktisk systemdesign Programmeringsmetoder Interessen for at styrke vores konstruktive evner, samt ikke kun at få overblik, men også specifikt indblik ligger til grund for vores anvendelse af OOA&D-metoden i projektet. 3.0.1 Systemer i organisationer Kurset havde til formål at give os, de studerende, en forståelse for organisationer og deres anvendelse af ikt, for derved at styrke vores evner til at opdage og behandle problemstillinger vedrørende ikt i organisationer. I kursets første del blev vi introduceret til de mest kendte syn på organisationer igennem historien, til deres oprindelse, deres betydning og indflydelse på nutiden. I den anden del diskuterede vi problemstillinger omkring ikt og organisation, som f.eks. sikrer systemet glade medarbejdere? Gør systemet medarbejderes arbejde overflødigt? Er ikt-systemer aflastende eller effektiviserende? Igennem denne viden og disse diskussioner var det hensigten at give os en viden om organisationer, som kan bruges refleksivt i en systemudviklingsproces.

20 Temarammeredegørelse Det interessante vedñ¾i3d er, at de på nytænkende vis organiserer sig på principper fra XP-metoden. Kresten Thomsens 1 tese er, at XP s principper på forholdsvis kort tid kan bære en organisation frem mod CMM-niveau 3 2. ForѾi3D skal dette realiseres ved at gøre kommunikation, beslutningstagen og projektorganisering til det bæredygtige fundament. Herved er virksomheden organiseret omkring nogle principper, som vi ser som moderne og udtryk for en voksende tendens. I en rapport fra PLS Rambøll er en moderne virksomhed karakteriseret ved...en høj eller meget høj grad af delegeret ansvarsfordeling, ansvar på eget initiativ, uformel omgangsform, projektorganisering, ledelse gennem værdier, aktiv professionel bestyrelse, hurtige beslutninger, investering i kompetenceudvikling... (...)...lav grad af hierarkisk organisation og ved det forhold at omstillinger ikke giver problemer. [Management 2004:7] Selvom vi i dette projekt ikke har fokus på organisationsteori, er en del af vores interesse forñ¾i3d alligevel udsprunget af, at organisationen placerer sig i et nyt og dynamisk felt. Vi mener, at den viden, vi vil erfare ved samarbejdet medñ¾i3d vil vise sig nyttig i fremtidige projekter, da vi ikke tror, det er sidste gang, vi vil støde på organisationer baseret på ovennævnte principper. Vi finder det givtigt at få indsigt i udviklingen af en moderne organisation somñ¾i3d og dens organisationsstruktur; heriblandt især principper om kommunikation, koordinering og beslutningsansvar. Refleksion over organisationernes struktur, heriblandt hvad der holder en organisation sammen, mener vi er relevant, når vi beskæftiger os med løsarbejdere og deres tilknytning tilñ¾i3d. 3.0.2 Metoder i systemdesign Metoder i systemdesign var et todelt kursus. I første del gav kursusholder et metodisk overblik over retninger inden for systemudvikling. Kursusholderen påpegede relevansen af at vide, hvilken retning man som systemudvikler placerer sig inden for. Igennem denne øgede refleksion skulle vi styrkes i at træffe kompetente valg. Vi redegør i kapitel 2 for vores placering. I kursets første del havde vi diskussioner om de forskellige retningers værdier og validitet. Meget karikeret f.eks. hvordan fremgangsmåder som vandfaldsmodellen kan konkretisere systemudviklingsprocessen og give noget målbart for kunden i form af eksempelvis en kravsspecifikation. Men på den anden side gør fremgangsmåden det vanskeligt, i kraft af sin rigide form, at følge op på de ændringsbehov, der kan opstå i løbet af en systemudviklingsproces, som følge af at systemudvikleren opnår større forståelse for hvert niveau i processen. Omvendt kan mere fleksible og iterative metoder konflikte med realistiske faktorer som økonomi, ressourcer, estimater, etc. 1 Kresten Thomsen er leder afñ¾i3d 2 CMM er en kvalitetssikringsmodel for organisationer. Den spænder fra niveau 1 til 5, hvor 5 er det højeste, og for hvert niveau er der en række krav som organisationen skal efterleve. Der er omkring 50 organisationer på verdensplan der er på niveau 5 (se endvidere casebeskrivelsen i kap. 4 for uddybning af CMM)

Temarammeredegørelse 21 I kursets anden del blev vi introduceret til OOA&D-metoden, forløb, principper osv. Introduktionen skulle give os et seriøst og konkret redskab i systemudviklingsprocessen. Det ligger i vores interesse at prøve kræfter med OOA&D-metoden. Vi udnytter den chance, der er på 6. semester til at lære om den formaliserende del af systemudvikling. Vi har på tidligere semestre haft fokus på brug og indledende undersøgelser i forhold til systemdesign. Dette semester ser vi giver os mulighed for at tage det næste skridt i en systemudviklingsproces vha. OOA&D-metoden. Metoden betragter vi som en mere konkret og struktureret tilgang til systemudvikling end de metoder, vi hidtil har arbejdet med. 3.0.3 Praktisk systemdesign I dette kursus gennemløb vi en forundersøgelse med MUST-metoden. Herigennem oparbejdede vi nogle praktiske erfaringer og stødte på problemstillinger og forhindringer, som ikke nødvendigvis kan forstås til fulde igennem teori, f.eks. say-do-problematikken (brugeren kan/vil ikke udtrykke deres behov). Kurset blev afløst af en forundersøgelsesrapport. Pga. omfanget blev det anbefalet at arbejde videre med forundersøgelsescasen i projektarbejdet. Vi fandt dog ikke en relevant problemstilling hos den virksomhed vi havde kontakt til i, og vi tog derfor fat på Ѿi3D, som vi samarbejdede med igennem forundersøgelsen. På trods af at organisationen på nuværende tidspunkt er på tegnebordet, vil vi alligevel igennem del II i dette projekt skitsere de behov, som systemet skal understøtte. Vi foretager altså en forundersøgelse, som ikke er baseret på MUST-metoden, men vil trække på erfaringer fra forløbet; eksempelvis en forståelse af arbejdspraksis, en forståelse af behovs-undersøgelse og -afdækning, samt at vi trækker på de både eksplicitte og implicitte erfaringer, vi har erhvervet gennem forløbet. 3.0.4 Programmeringsmetoder Kurset introducerede til OOA&D og java, dels på specifikt kode-niveau, men også til klassediagrammer, konstruktionsmuligheder og OOA&D-paradigmet. Vores kendskab til java rummede altså både den praktiske, metodiske og teoretiske dimension. I sidstnævnte blev OOA&D sat i større begrebsmæssig filosofisk sammenhæng, hvor kursusholder påviste den natursproglighed der lå i OOA&D s grundtanke. På hermeneutisk vis var pointen med at præsentere OOA&D og java fra så mange vinkler, at give de studerende en dybere og mere præcis forståelse heraf. Der trækkes i høj grad på dette kursus i vores projektarbejde, da vi har valgt at gøre brug af OOA&D-metoden.

Del II Kontekstbeskrivelse

Kapitel 4 Casebeskrivelse Dette kapitel har dels som formål at beskrive grundlaget for projekt rapportens tilblivelse samt at konkretisere omstændighederne for organisationen. I dette kapitel præsenteres den case, hvoraf den overordnede undren udspringer, og som derfor både danner grundlag for projektrapportens tilblivelse, og besvarelse af rapportens problemformulering. 4.1 Præsentation af firmaetñ¾i3d Formålet med firmaetñ¾i3d er dels at udvikle software til plantegning, og samtidig fungere som case for grundlæggeren, Kresten Thomsens (herefter Kresten), speciale på 10. semester Humanistisk Datalogi på AAU. Problemformuleringen for specialet lyder: I hvilken udstrækning kan grundideen i XP teoretisk og operationelt understøtte og supportere de organisatoriske beslutninger, der er medvirkende til at konstituere softwareorganisationen på CMM niveau 3 Opbygningen af firmaet, og den heraf følgende organisations opbygning giver Kresten mulighed for at teste hvorvidt de teoretiske ideer kan operationaliseres i praksis. Capability Maturity Model (CMM) er en model indført af det amerikanske militær til at måle kvaliteten af en softwareorganisations produkter. Formålet med modellen er at sikre, at der kun indledes samarbejde med softwareorganisationer, som kan leve op til metodens standarder og dermed udøve kvalitetssikring. 1 Kort beskrevet består CMM modellen af fem niveauer. Niveau 1 er det første af de fem og også det laveste. En organisation skal opfylde og verificere en række Key Proces Areas (KPA) for, at den kan befinde sig på et niveau. Modellen er opbygget som et 1 Beskrivelsen af CMM metoden er baseret på Krestens speciale og http://www.sei.cmu.edu/cmm/. Modellen er operationaliseret og videreudviklet af Software Engineering Institute (SEI); (SEI)http://www.sei.cmu.edu/.

Casebeskrivelse 25 inklusionssystem, hvor hvert niveaus KPA automatisk er indlejret i det næste. Krestens speciale vil kun beskæftige sig med de tre første niveauer, idet både niveau 4 og 5 kræver en organisation hvor der er sket en differentiering af arbejdsområder, og dermed en fordeling af kompetencer og roller blandt de ansatte. Kresten mener ikke, at det er realistisk for en nystartet organisation somñ¾i3d at forsøge at nå op på disse niveauer i opstartsfasen. 4.1.1 Dreamhouse Kresten Thomsen er i forbindelse med udarbejdelsen af sit speciale blevet tildelt et legat af Aalborg Erhvervsråd til at udvikle og opbygge en organisation baseret på systemudviklingsmetoden Extreme Programming 2. Organisationen udvikler software til plantegning i forskellige typer af virksomheder. I specialets case er samarbejdspartneren ejendomsmæglerkæden home i Aalborg. Det tildelte legat anvendes udelukkende til at betale lokaleleje hos institutionen Dreamhouse 3, i en periode på seks måneder startende 1. januar 2004. Øvrig fremskaffelse af kapital til løn og betaling af patenter er igangsætter selv ansvarlig for. 4.1.2 Medarbejdere og roller Firmaet befinder sig opstartsfasen (juni 2004), dog forventes de første medarbejdere ansat ultimo 2004. Ifølge budget og forretningsplan forventesñ¾i3ds organisation indenfor et år at komme til at bestå af Kresten Thomsen, Én fuldtidsansat primært til Javaprogrammering og udvikling af software, samt op til fire udviklere/studentermedhjælpere 4, som rekrutteres i universitetsmiljøet. Ansættelse af medarbejdere og videre udvikling af firmaet er afhængigt af, at de forskellige patenter til design bliver godkendt og finansieret. Hvis udviklingen og implementeringen af softwaren forløber tilfredsstillende hos home Aalborg, harñ¾i3d forhåbninger om, at deres produkt kan tilbydes hele home kæden og på sigt andre mæglerkæder i Danmark. Andre potentielle kunder kan, ifølge Kresten Thomsen, eksempelvis være landinspektører, ingeniørfirmaer eller andre firmaer, der anvender tegninger i deres arbejdsgang. home Aalborg har en eksklusiv aftale på ni måneder for anvendelse af produktet i Aalborg området. Denne aftale er brugs-afhængig, idet home skal garantere et vist brug af produktet, da eksklusiv-aftalen ellers bortfalder. Som udgangspunkt skal den fuldtidsansatte varetage arbejdet af de tunge dele af produktet. Det vil sige, at han bliver ansvarlig for den bærende struktur i produktet, som for eksempel databaseløsninger, og sikkerhed. Samtidig skal han varetage en rolle som coach, hvor han skal supervisere løsarbejderne i deres oplæring og daglige arbejde 5. Da løsarbejderne har andre forpligtigelser udover arbejdet hosñ¾i3d, kan det forven- 2 Metoden beskrives i kapitel 5. 3 Dreamhouse er en institution under Nordjyllands Amt, hvis filosofi er: overordnet at styrke selvstændighedskulturen i Nordjylland samt at skabe en fysisk såvel som virtuel krumtap for nyetablering af vidensvirksomheder i Aalborg......sikre en effektiv og målrettet opstart af disse virksomheder, medvirke til at udvikle, fastholde og videregive viden. Citat fra hjemmeside www.dreamhouse.dk 4 Brugen af begrebet studentermedhjælpere vil fremadrettet i projektet blive erstattet af begrebet løsarbejdere. Vores forståelse af dette vil blive defineret i kapitel 6 5 Coach rollen er en del af XP. 4.1 Præsentation af firmaetñ¾i3d

26 Casebeskrivelse tes at deres arbejdstid kan blive placeret udenfor normal arbejdstid. Den valgte systemudviklingsmetode fordrer, at studentermedhjælperne kontinuerligt møder op til briefing på Dreamhouse. Denne briefing bliver iñ¾i3d holdt på ugentlige møder, kaldet tirsdagsmøder. Tirsdagsmødet vil indeholde punkter som Kresten ideelt så forekomme på daglige morgenmøder, såsom at udviklerne sammen danner sig et overblik over den hidtidige og fremtidige udvikling, vælger opgaver udfra XPs principper, samt vælger deres samarbejdspartner, med hvem de skal arbejde i par. Plantid for løsarbejderne vil være mellem 8-16 timer pr. uge. Planlægning af opgaver og mødetider ser Kresten ske via tavler i lokalerne hosñ¾i3d. Derpå registreres de enkelte opgaver for hver iteration, de ansvarlige og tids-estimater. Det er desuden via tavlerne, at Kresten vil håndtere, det der i XP-jargon hedder tracker-rollen (se XP kapitel 5). I den indledende fase skal alle medarbejderne være tilstede samtidig på Dreamhouse for at fremme de personlige relationer mellem medarbejdere, fremme brugen af XP principperne, samt sikre konsensus i udviklingen. Hvor lang tid denne fase skal strækkes over, er ikke fastsat, men den skal forløbe indtil XP metodens værdier og principper er blevet indlejret hos alle medarbejdere, og de er blevet fortrolige med anvendelsen af denne arbejdsform. Grunden til at de personlige relationer vægtes højt er, ifølge XP, at den interpersonelle kommunikation derved får bedre vilkår. Kresten ønsker at en høj grad af uddelegering af både ansvar og kompetencer, til alle medarbejdere, skal være et grundlæggende princip i opbygningen afñ¾i3d. 4.1.3 Brud med metode I den beskrevne case har Kresten valgt ikke at indgå i så tæt en interaktion med kundesiden, som XP metoden lægger op til 6. Dette fravalg grunder i, at homekæden ikke ønsker at afse ressourcer til så kraftig en involvering. Endvidere er det softwareprodukt som ønskes udviklet ikke kun rettet mod en specifik kunde, og dennes behov, men mere en kundegruppe; i dette tilfælde virksomheder der er afhængige af plantegneprogrammer for at udføre deres opgaver. Man kan i dette tilfælde sige atñ¾i3d ønsker at udvikle en hyldevare, som henvender sig til en bredere målgruppe, hvor home så repræsenterer det potentielle kundesegment. Derfor er behovet for den tætte interaktionen mellem kunde og udvikler ikke så udtalt, som ellers når man anvender XP som metode. For at kompensere for dette brud med XP metoden har Kresten, før udviklingsfasen, gennemført en række aktiviteter, som metoden ligger op til skal gennemføres i planlægningsfasen. Endvidere har vi i projektgruppen gennemført en MUST forundersøgelse hos home forñ¾i3d. Resultaterne af denne vil blive anvendt afñ¾i3d i deres udvikling. Dette brud med metoden fra casens side betyder, at projektrapporten ikke fokuserer på interaktion mellem organisationen og deres samarbejdspartner, men udelukkende beskæftiger sig med vidensdeling internt. Løsningsforslaget vil derfor heller ikke fremkomme med forslag til, hvordan den tætte kommunikation, som metoden fordrer mellem kunde og udviklere, kan struktureres eller designes. Istedet vægtes den interne vidensdeling iñ¾i3d. 6 Bliver nærmere beskrevet i kapitel 5 4.1 Præsentation af firmaetñ¾i3d

Casebeskrivelse 27 4.2Ѿi3Ds produkt Som anført ovenfor ønskerñ¾i3d at udvikle et nyt plantegningsprogram, som skal forenkle arbejdsprocessen hos slutbrugeren samtidig med, at det skal tilbyde yderligere funktionalitet end lignende produkter uden at øge kompleksiteten i produktet. Produktet skal kunne leve op til home-kædens overordnede it-strategi. En mere uddybende produktbeskrivelse kan ikke forekomme da projektgruppen er underlagt en fortrolighedserklæring frañ¾i3ds side. For at lette implementeringen i organisationen skal produktet være platforms uafhængigt og udvikles derfor som en web-baseret Java-applikation, hvilket medfører at der ikke umiddelbart skal installeres programmer lokalt. Fordelen ved webapplikationen er endvidere, at det er muligt at indføre pay per use, derved sikresñ¾i3d en løbende indtægt og mindsker samtidig muligheden for ulovlig kopiering lokalt. Selve produktet er ikke en del af projektets fokus, og vil derfor ikke blive beskrevet yderligere i dette. Beskrivelsen er kun tænkt til at lette forståelsen for casen. 4.3 Projektgruppens kontakt Den første kontakt mellem firmaetñ¾i3d og projektgruppen blev etableret i forbindelse med projektgruppens udarbejdelse af en MUST-Forundersøgelse 7 forñ¾i3d hos deres samarbejdspartner home ejendomsmæglerkæden i Aalborg. Formålet med forundersøgelsen var dels at analysere det eksisterende produkt, som skal afløses afñ¾i3d s, samt at afdække arbejdsgangen og brugen af teknologi for derved at kunne fremkomme med løsningsforslag til forenkling af arbejdsprocessen. Det var under udarbejdelsen af forundersøgelsen, at projektgruppen blev opmærksomme på det potentielle spændingsfelt mellem den valgte systemudviklingsmetode og den ønskede organisatoriske opbygning med brugen af løsarbejdere. Dette medførte at projektgruppen fravalgte at føre forundersøgelsens resultater omkring produktet videre over i projektet, og for eksempel fremkomme med en analyse og et designforslag til dette produkt. I stedet er fokus blevet rettet mod den anvendte udviklingsmetode - Extreme Programming. 7 MUST står for: Metode til forundersøgelse i Systemudvikling - og Teori herom; Forundersøgelse betegner de tidlige analyse- og designaktiviteter i et systemudviklingsprojekt [Bødker et al. 2000] 4.2Ѿi3Ds produkt

Kapitel 5 Extreme Programming Dette afsnit vil kort præsentere hovedtrækkene i Extreme Programming og derefter nærmere præsentere de træk i metoden, der er interessante i dette projekts kontekst. Vores forståelse af Extreme Programming er hovedsagligt hentet fra bøgerne En Introduktion til Extreme Programming [Beck 2002] 1, og Extreme Programming Perspectives [Michele Marchesi and Williams 2002] 2. 5.1 Værdier og principper Kort fortalt er XP en systemudviklingsmetode, der vægter kommunikation, enkelhed, feedback og mod med det overordnede argument, at det gør udviklingen effektiv, mindre risikabel, mere fleksibel, og vedkommende[beck 2002:xviii]. Prioriteringerne i XP gør, at metoden adskiller sig fra traditionelle metoder på en række punkter. Den måske største differens findes i XP s insisteren på, at det ikke kan betale sig at planlægge for mulige fremtidige problemer, og man i stedet bør udvikle på det i øjeblikket mest nødvendige og stole på, at evt. risici kan, og først bør, håndteres, når de opstår. Denne fleksible holdning til hvor fuldstændig en planlægning der udvikles ud fra, og den løbende planlægning og styring det kræver, står i kontrast til f.eks. vandfaldsmodellen, hvor der tidligt laves en detaljeret planlægning og derefter styres strengt efter denne i løbet af processen eller til den iterative spiralmodels opfordren til løbende at overveje mulige alternativer[et al 2002:188]. Et eksempel er, at man ved benyttelse af vandfaldsmodellen laver en detaljeret og tidskrævende afdækning og gennemgang af krav førend den egentlige design aktivitet, for at undgå at skulle ændre i designet senere hen pga. nye eller ændrede krav, mens man i XP langt tidligere vil bevæge sig over i design og programmering, da man mener at være omstillingsklar i tilfælde af ændringer [McBreen 2003:31-33]. Spiralmodellen har som vandfaldsmodellen en lang proces, hvor man gennem en udstrakt brug af prototyper løbende laver risiko vurdering, 1 Forfattet af Kent Beck, der gennem sit arbejde som programmør har udviklet XP metoden, og som han selv beskriver metoden i forordet, er den udviklet for små og mellemstore grupper, der udvikler software mod vage og hyppigt skiftende krav. 2 Denne bog er en artikelsamling med forskellige forfattere. Den er resultatet af den første konference om XP metoden, afholdt i Italien juni måned 2000. Da der er forskellige forfattere til artiklerne, har vi valgt at indsætte sidehenvisninger, når der refereres til denne bog.