Synopsis: Tema: Design og vurdering af et edbsystem i samarbejde med brugere

Transkript

1 15pt0pt

2

3 Department of Computer Science Informatik Fredrik Bajers Vej 7E DK-9220 Aalborg Øst Titel: Workout & Fitnesss Tema: Design og vurdering af et edbsystem i samarbejde med brugere Projektperiode: INF2, Forårssemester 2006 Projektgruppe: i202a Deltagere: Mikkel Bundgaard Lars Holm Christiansen Brit Susan Jensen Kasper Wittrup Højris Jensen Mads Kristian Wallin Pedersen Alex Ranch Vejleder: Janne Jul Jensen Oplagstal: 8 Sidetal: 92 Afsluttet den 30. Maj 2006 Synopsis: Denne rapport behandler udvikling af software i samarbejde med brugere. Der anvendes extreme Programming(XP) som udviklingsmodel for processen. Samarbejdspartneren i dette projekt er en mindre virksomhed, der sælger samt udlejer diverse tness produkter til private samt rmaer. Virksomheden har ønske om at optimere deres arbejdsrutiner, ved hjælp af implementering af ny software løsninger, da de eksisterende systemer ikke længere opfylder virksomhedens krav. Gennem denne proces vil XP bliver evalueret som udviklingsmetode, hvorved vi vil specicere kritikpunkter og styrker. Programmet er udviklet i et Java udviklingsmiljø og efterfølgende er der udført en brugbarhedstest på programmet for at afdække og klassicere eventuelle brugbarhedsproblemer.

4

5 Forord. Vi ønsker at takke Thomas Storm fra Workout & Fitness, uden hans hjælp ville det ikke have været muligt at gennemføre dette projekt. Thomas formåede at tage tid ud af hans travle kalender gentagende dage, for at kunne arbejde sammen med os. Møderne har været yderst produktive og vi er sikre på, at vi alle har lært meget af disse. Læsevejledning Til rapporten er tilknyttet en CD indeholdende udarbejdet materiale i form af kildekode og færdigt prototype-program. Kildehenvisninger er angivet som (forfatter, årstal) og en kildeliste ndes i kildeliste - se indholdsfortegnelse. I rapporten igennem anvendes udtrykket vi, og er udtryk for gruppen som har udarbejdet denne rapport. Forkortelser vil forekomme, angives som følgende eksempel: ExtremeProgramming(herefter XP). Appendiks indeholder udarbejdet materiale fra gruppen og er materiale som er udarbejdet af gruppen, men som ikke er relevant i rapporten. Mikkel Bundgaard Lars H. Christiansen Mads Wallin Brit Susan Jensen Kasper Wittrup Alex Ranch

6

7 Indhold. 1 Indledning Problembeskrivelse Problemformulering Indledende virksomhedsbesøg Mål Overvejelser Resultat af mødet Virksomhedsbeskrivelse Lageret Bogføring Ønsker til et nyt system XP Metoder Introduktion til XP Case værktøjer til XP X-planner Test Driven Development og J-unit Fælles udvikling Design Udviklingsmetode Planning game Hyppige udgivelser Metaforer Enkelt design Test Refaktorering Fælles ejerskab timers arbejdsuge Kundetilstedeværelse

8 3.4 Programmering Kunden er tæt på Kode standarder Test Driven Development Par programmering Integrer ofte Alle skal være med til at kode Opsummering Iterationer Første iteration Brug af brugerhistorier Kravliste Release Kommunikation Brugermøde Feedback Forbedringer til kommunikation Konklusion Anden iteration Kravliste Release Kommunikation Feedback Konklusion Opsummering af processen Metode kritik af XP Krav ændres løbende Brugsmønster vs. Brugerhistorier Anvendelse af XP Refaktoring Test driven development Mangel på ansvarsdeling Jo simplere, jo bedre Koden er designet Koden er selv-dokumenterende Caseværktøjer Positive erfaringer med XP Universitetsprojekter Opsummering

9 6 Estimering og usikkerheder Estimering Opsummering Tanker vedrørende software udvikling Gidseltagning i Extreme Programming Orden i kaos Konsekvenser Acceptance test 55 9 Test Testformål Teori Opstilling af test Fremgangsmåde Resultater Test overvejelser Konklusion Diskussion Samme projekt, to fremgangsmåder Samme fremgangsmåde andet projekt Konklusion Fremtidig arbejde Fremtiden for vores program A Mødeprogram 75 B Brugerhistorier 77 B.1 Interview guide C Introduktion til test 81 C.1 Testspørgsmål C.2 Samtykkeerklæring C.3 Demogrask data af testpersoner D Essays fra Software loso 85 D.1 Gidseltagning i Extreme Programming? D.2 Orden i kaos

10 D.3 Konsekvenser

11 Figurer. 3.1 Screenshoot af X-planner Forskrifterne supplerer hinanden Forløb i udvikling af software gennem TDD Et system til at udføre løbende test Screenshoot fra første iteration Screenshoot fra anden iteration Godkendelseskriterier for test Skema til katagorisering af fundne problemer Opstilling i Usabilitylab Fundne og klassicerede problemer fra brugbarhedstesten C.1 Samtykkeerklæring C.2 Demogrask data

12 FIGURER FIGURER 10

13 . KAPITEL 1 Indledning Dette projekt er udarbejdet i forbindelse med semestret INF2 ved Aalborg Universitet med det overordnede tema: Design og vurdering af et edb-system i samarbejde med brugere Formålet med dette projekt er at opnå erfaring i metoder og teknikker til samarbejde med brugere i udviklingsarbejde baseret på design, realisering og evaluering af prototyper. Vi vil i denne rapport dokumentere processen og erfaringerne fra udviklingen af et stykke software til rmaet Workout & Fitness. Projektet vil forløbe efter udviklingsmetoden Extreme Programming (XP). Det er vores mål at softwaren til Workout & Fitness kan anvendes i almindelige arbejdsrutiner, hvorved virksomhedens arbejdsopgaver eektiviseres. 1.1 Problembeskrivelse I det daglige arbejde hos Workout & Fitness bruges forskellige applikationer til både administration, håndtering af salg samt lagerstatus. Således er den nuværende forretningsgang, at et salg registreres ved at rmaets webløsning sender en til salgsafdelingen, der efterfølgende ringer op til køberen, for at aftale betalingsform samt levering med mere. Sælgeren skriver derefter kundens personlige oplysninger ind i et dokument, der benyttes som faktura. Dernæst skrives oplysninger vedrørende handlen, manuelt ind i virksomhedens økonomisystem. Til sidst sendes der besked til lageret om, at den bestilte vare skal afsendes. Ligeledes når der opgøres status på lageret, foregår dette ved at optællingen foretages, hvorefter resultatet sendes via , for derefter at blive indført i et regneark. Systemerne der bruges til at udføre dette arbejde har altså ingen, eller ringe indbyrdes sammenhæng, hvilket betyder at de ansatte ofte skal skifte mellem ere applikationer, for at løse deres arbejdsopgave. Dette medfører at tidsforbruget ved gennem-

14 1.2 Problemformulering 1 Indledning førelse af en bestilling synes at være for stort samt at muligheden for fejl indtastninger øges, hvilket vi vil søge at eektivisere. 1.2 Problemformulering Vi ønsker vha. XP at udvikle en applikation der muliggør en forbindelse mellem disse forskellige applikationer i den centrale styring, med særlig fokus på optimering af arbejdsgangen omkring lagerarbejdet i Flensborg. I udviklingen af denne applikation ønskes brugerinddragelse jf. XP forskrifterne, for derigennem at sikre succesfuld kravbeskrivelse samt implementering. Ovenstående leder os frem til følgende problemformulering: Hvorledes udvikles der med brug af XP, en applikation der kan sammenkoble de forskellige systemer virksomheden benytter nu, og hvilke erfaringer kan vi danne ud fra denne proces? 12

15 . KAPITEL 2 Indledende virksomhedsbesøg Inden selve udviklingen begyndte havde vi et initierende møde med virksomheden Workout & Fitness for at danne os et indtryk virksomheden, som vi ønskede at skrive projekt med, og for at vi kunne mødes med den repræsentative gruppe fra virksomheden. Vores mål var her at beskrive vores projekt og hvorledes det skulle forløbe. Det er dette vi beskriver i dette kapitel. 2.1 Mål Som første led i vores samarbejde med virksomheden Workout & Fitness, besluttede vi at hele gruppen skulle deltage i det første møde med virksomheden. Formålet med vores indledende besøg var til dels ment som en introduktion til virksomheden, og vore fremtidige samarbejdspartner. En del af mødet skulle samtidig foregå som et kvalitativt interview, i form af det Kvale (Kvale, 1994) kalder et delvist struktureret, kvalitativt eksplorerende interview (Se bilag B.1 på side 80). På mødet præsenterede vi vore mål med projektet, samt undersøgte hvad virksomheden kunne opnå gennem dette samarbejde. Herefter gav vi en generel kort introduktion til software-udviklingsmodeller, dernæst specikt om brugen af XP, samt hvad udvikling efter XP betyder for virksomheden. Herunder et tæt samarbejde og gentagende møder med repræsentanter for virksomheden. 2.2 Overvejelser En del af vore overvejelser inden mødet omhandlede hvorledes vi kunne sikre et højt udbytte af mødet. Dette søgte vi at opnå gennem det delvist struktureret eksplorerende interview. Spørgeformen var åben og fulgte et naturligt ow. Interviewet og de indledende spørgsmål var stillet med henblik på, at få

16 2.3 Resultat af mødet 2 Indledende virksomhedsbesøg et overblik over organisationen som helhed, samt at få et detaljeret indblik i de daglige arbejdsopgaver. 2.3 Resultat af mødet Igennem mødet k vi klarlagt forretningsgangen i virksomheden, samt et detaljeret indblik i arbejdsgangen i form af daglige opgaver. Samtidig gav mødet også virksomheden en introduktion til vores forventninger og hvilke fremgangsmetoder de kunne forvente vi ville anvende. Dette har været med til at danne videre grundlag for samarbejdet med Workout & Fitness. 2.4 Virksomhedsbeskrivelse Samarbejdspartneren Workout & Fitness er et lille rma med under ti medarbejdere, oprettet i 1997, fordelt på 2 geograske lokationer henholdsvis; Århus, virksomhedens hovedsæde, samt Flensborg. Flensborg afdelingen fungerer som lager samt butik, og er placeret i Tyskland af konkurrencemæssige årsager. Produkterne består af diverse typer af tness udstyr, alt fra mindre vægtsæt til større motionsmaskiner, så som motionscykler, træningsbænke etc. Virksomheden sælger primært produkter til private personer, dog køber rmaer også større tness løsninger hos Workout & Fitness. Virksomhedens nuværende hjemmeside kan ndes på Kundesegmentet er typisk personer i alderen år hvilket virksomhedens web løsning afspejler, idet betalingen foregår ved almindelig bankoverførsel således kunden har en fast kontaktperson på kontoret i Århus. Ved modtaget betaling sendes varen direkte fra lageret i Flensborg til kunden. Det er endnu ikke muligt at betale via hjemmesiden, hvilket der dog arbejdes på Lageret Lageret har ikke nogen elektronisk lagerstyringsfunktion, hvilket medfører at resultater af vareoptællinger manuelt skal indføres i et regneark. Vareforsendelsen sker ved salgskontoret kontakter lageret og beder dem sende de bestilte varer. Elektronisk lagerstyring er derfor også et ønske, således salgsafdelingen er i stand til at se lagerstatus samt at sammenholde denne, med hjemmesiden. Levering af varer sker så vidt muligt, som dag til dag levering. Dog afhænger dette af valgte fragtmand. 14

17 2 Indledende virksomhedsbesøg 2.4 Virksomhedsbeskrivelse Bogføring Bogføring i virksomheden foretages i C5 Light, som er en ældre version med DOS brugerade. Der er et udpræget ønske om bogføring stadig skal foretages i et C5 miljø, men at bogføringssystemet bliver opdateret til C5, samt at det integreres med lagerstyring, bestilling og faktureringen fra hjemmesiden Ønsker til et nyt system De nuværende systemer er ikke i tilstrækkelig grad integreret med hinanden, hvorfor der foretages en del manuel gentagende arbejde. Eksempelvis indføres bestillinger fra hjemmesiden manuelt i bogføringssystemet, ligesom der manuelt skal sendes besked til lageret om at afsende produkter. Det er bl.a. disse arbejdsgange der ønskes optimeret og integreret i et samlet system, således en del af det administrative merarbejde minimeres betydeligt, jf. nedenstående punkter. Integration mellem web og bogførings systemer Elektronisk lagerstyring Betalingsgateway på hjemmeside Mindsket gentagende administrations overhead, som følge af gentaget arbejde 15

18 2.4 Virksomhedsbeskrivelse 2 Indledende virksomhedsbesøg 16

19 . KAPITEL 3 XP Metoder I dette afsnit vil vi beskrive grundelementerne i XP samt hvordan udviklingen bør foregå efter XP. Ydermere vil vi behandle de caseværktøjer der anbefales til udviklingen, samt hvordan udviklingsprocessen bør forløbe ifølge XP. 3.1 Introduktion til XP Extreme Programming (XP) is actually a deliberate and disciplined approach to software development (Wells, 1999). XP adskiller sig fra det traditionelle udvikling paradigme, som f.eks. vandfaldsmodellen, ved i langt større grad, at sætte kunden i fokus i sammenlignet med det traditionelle paradigme. Dette fokus på kunden gennem hele udviklingsprocessen er vigtigt i XP idet kunden derved får et bedre indblik idet software der er under udvikling. Dette sætter kunden bedre i stand til at træe rationelle beslutninger om mulige ændringer i softwaren, selv sent i udviklingsprocessen. I XP lægges der stor vægt på de re kerneværdier som er; kommunikation, enkelthed, feedback og mod. Samlet set er dette med til at sikre en agil udviklingsproces. Eksempelvis igennem praksisen omkring parprogramming, sætter XP stor fokus på kommunikation. Yderligere er XP opbygget efter en ad struktur hvor alle har et fælles ansvar, idet der ofte skiftes rundt blandt udviklerne. Således står en enkelt udvikler ikke til ansvar for en komplet del af systemet, men mange delelementer. Ved at lade udviklerne rotere inden for projektet, muliggøres det også at give feedback på program-stumper, hvilket er medvirkende til at skabe ensartet kode. Igennem hele processen holdes en tæt kundekontakt og udgivelser til kunden sker hurtigt i projekt forløbet.

20 3.2 Case værktøjer til XP 3 XP Metoder 3.2 Case værktøjer til XP Der ndes en række udviklingsværktøjer til brug i XP der understøtter projekteringen og udviklingen af softwaren. Nogle af disse værktøjer vi vil beskrive i de følgende afsnit X-planner X-planner er et tidsestimeringsværktøj til at understøtte udviklingen, ved at holde rede på brugerhistorier i udviklingsiterationerne. Efter nogen tids brug, kan udviklerne bruge X-planner til at hjælpe med at estimere tidskrævende iterationer, baseret på data indsamlet under tidligere iterationer. Yderligere hjælper værktøjet med at holde styr på hvilke udviklere der er tilknyttet hvilke brugerhistorier, samt hvor langt udviklingen af opgaverne er kommet. For illustration af X-planner se gur 3.1 Figur 3.1: Screenshoot af X-planner Test Driven Development og J-unit Teorien bag brugen af Test Driven Development(TDD) foreskriver at der på forhånd skrives unit tests til den kode der skal skrives. Dette gøres for at sikre at den kode der skrives, ikke indeholder unødvendige funktioner idet der kun skal skrives nok kode til at unit testen kan gennemføres uden fejl. 18

21 3 XP Metoder 3.3 Design Således fungerer unit testene som succeskriterier for udviklingen, og disse er med til at validere at softwaren er færdig udviklet. Til at skrive unit test, bliver frameworket J-unit anvendt, som kan integreres direkte med de este Java udviklingsmiljøer, hvilket i vores tilfælde er Borland JBuilder Fælles udvikling Til at styre kildekode lerne anvendes Subversion, hvilket er en forbedring af det ældre CVS, som versionsstyringsprogram. Til dette anvendes TortoiseSVN for at holde rede på opdateringer og nye tilføjelser fra gruppen. TortoiseSVN er en grask overbygning til SVN således det undgås at anvende en konsol. 3.3 Design Udviklingsmetode XP består af en række regler, hvor enten alle, eller ingen af disse regler skal anvendes. Disse regler understøtter ifølge XP hinanden i en symbiotisk eekt, som vist på gur 3.2. Pilene mellem reglerne (punkterne) indikerer hvordan de balancerer og forstærker hinanden. Figur 3.2: Forskrifterne supplerer hinanden Planning game For at få det meste ud af udviklingsperioden forskriver XP, at udviklerne fra starten planlægger forløbet i samarbejde med kunden. Dette sker både 19

22 3.3 Design 3 XP Metoder for lade kunden føle at teamet har tingene under kontrol, men samtidig også en mulighed for at se hvad teamet gennemgår på forskellige tidspunkter i forløbet. Da kunden er i stand til se hvornår teamet udvikler på bestemte arbejdsområder, vil det være nemmere at komme med spørgsmål og ideer på det rigtige tidspunkt. Det er således kunden der er i den bedste position til at vurdere hvilke dele af systemet der har den højeste prioritet. Derimod er det udviklerne der kan vurdere hvilke opgaver der har den største kompleksitet og hvilke opgaver der således bør påbegyndes først. Ved hjælp af gruppens erfaringer fra tidligere projekter skulle udviklerne således være i stand til at fastsætte et reelt udviklingsforløb for at sikre projektets succes Hyppige udgivelser Efter en nøje planlægning ligger XP op til der udgives udgivelser med mindre tidsintervaller, så kunden vha. Planning game samt de forskellige udgivelser vil være i stand til at komme med indskydninger i form af ideer, for på den måde få de mest nyttige funktioner udviklet på mindst tid. Således vil udviklerne selv fra starten af forløbet være i stand til at starte på selve udviklingen af softwaren, og vha. af hyppige aeveringer være i stand til at minimere omkostningerne ved ændringer. Minimeringen af omkostningerne sker i kraft af at kunden gennem de hyppige udgivelser kan nde fejl, og derved kan der korrigeres for disse, således der ikke videreudvikles på fejl. De hyppige udgivelser hjælper således kunden med at ændre retningen af udviklingen for derigennem at sikre enighed mellem kundens ønsker og det som udvikles Metaforer Metaforer benyttes til at hjælpe kunden for at give forståelse for udviklingen vha. noget genkendeligt for kunden, eksempelvis at omtale et databasesystem som et adressekatalog eller telefonbog. Metaforer kan ligeledes benyttes internt i udviklingsteamet, således at hvis en delgruppe ikke mestrer et delemne, kan en anden delgruppe forklare sammenhængen vha. en metafor Enkelt design XP foreskriver, at softwaren ikke må indeholde redundant kode og skal således kun være i stand til at fuldføre alle testcases. Dette kan minde om en øvelse (Tufte, 1992) beskriver for graske designere: Design en gur, fuldstændig som man vil. Fjern derefter elementer uden at fjerne noget information. Når der ikke er mere der kan slettes, står man tilbage med det rigtige design. 20

23 3 XP Metoder 3.3 Design Altså bør det undgås at implementere unødige og overkomplicerede metoder i bestræbelserne på at opnå et enkelt design Test I XP skrives testcasene først og efterfølgende skrives koden. Årsagen til dette er, at man derved anskueliggør de krav og formål, den efterfølgende kode skal kunne opfylde. Udviklerne opnår derved simplere kode og det overordnede mål fastholdes. Dette giver samtidig en mere stabil og funktionel kode, se: (Beck, 2002), da hver enkelt del bliver gennemtestet før den bliver tilføjet til den eksisterende kode. Består den nye kode ikke testen fejlfrit, refaktoreres denne indtil dette er tilfældet. Dette skaber mere tillid til koden, både for udviklerne og kunden. Se også afsnit på side Refaktorering Når et udviklingspar tilføjer ny kode til den samlede systemkode, er det vigtigt at de overvejer om der kan laves ændringer til den eksisterende kode, der kunne gøre deres implementering lettere. Hvis implementeringen lykkes og den gennemløber samtlige tests fejlfrit, kan udviklerne overveje om de kan se nye måder at forbedre koden på. Det er denne gennemgang og søgen efter forbedring af systemkoden der kaldes refaktorering. Måden udviklerne nder frem til, at det er nødvendigt med refaktorering, kan f.eks. være hvis der er redundant kode. Eksempelvis hvis metoder har næsten samme funktion, kan disse laves til en enkelt metode der opfylder begge krav, hvilket resulterer i en simplere og mere overskuelig kode Fælles ejerskab For at opnå det bedst mulige udbytte af de forskellige udvikleres erfaringer, opfordres disse til løbende at tilføje ændringer og opdatere kode igennem hele systemet. Udviklingen foregår ved at der programmeres i par og at der hyppigt roteres rundt, så alle programmører har haft del i alt kode i større eller mindre grad. Derved undgås at enkelte udviklere får ejerskab over en bestemt del af koden. Hvis et udviklingspar nder muligheder for at opdatere systemkoden, eller det er nødvendigt at ændre koden for, at implementere nye dele, så bør de foretage disse ændringer. Udviklernes kendskab til det samlede system afhjælper også de mulige fejl og problemer disse løbende opdateringer ville kunne skabe. 21

24 3.3 Design 3 XP Metoder timers arbejdsuge I XP udviklingsmetoden er kreative og oplagte udviklere et vigtigt element. Arbejdsopgaver i udviklingen bør være fastsat således udvikleren ikke overbelastes med arbejde, således de ikke kan møde udhvilet og oplagte op næste arbejdsdag. Et eksempel på dette kan være en 40 timers arbejdsuge. Dette betyder dog ikke, at der ikke er plads til overarbejde hvis uventede problemer opstår, dog vil der ikke komme noget godt ud af gentaget overarbejde. I sådanne tilfælde står projektgruppen overfor et dybereliggende problem, der ikke kan løses ved overarbejde Kundetilstedeværelse Kundetilstedeværelse er et vigtigt element i XP udviklingsmetoden, fordi den hjælper med at sikre udviklingens og systemets succes. Kunden er en repræsentant for virksomheden der udvikles til, der har forståelse for hvad der kræves af systemet, samt hvordan det skal anvendes. XP foreskriver at der gøres nytte af en onsite costumer, hvilket betyder at kunden ikke bare skal være et element man forhandler med og udvikler til. Men derimod ønskes det at kunden er en aktiv del af udviklingsholdet, så det derved er muligt at diskutere eventuelle tvivlsspørgsmål i selve udviklingsprocesen. Formålet med kundetilstedeværelsen er, at søge at sikre et bedre slutprodukt, ved at lade kunden besvare udviklernes spørgsmål samt træe beslutninger vedrørende udviklingen. Brugerhistorier Brugerhistorier minder lidt om brugsmønstre, dog er brugsmønstre mere proces orienterede samt skrevet af udvikleren. Brugerhistorier er små historier skrevet af brugerne af systemet. Disse historier skal kort fortælle hvad delelementer af systemet skal kunne. Eksempelvis kunne en brugerhistorie beskrive, hvorledes et salg forgår fra start til slut, hvorimod et brugsmønster for samme scenario ville beskrive den specikke proces. Brugerhistorier erstatter samtidig kravspecikationen. Idet en kravspecikation er et endegyldigt dokument, bruges en sådan specikation ikke ifølge XP idet et af kerne elementerne i XP er at kunden skal kunne ændre kravene til systemet løbende gennem projektet. Brugerhistorier er dog ikke endegyldige krav til delelementet, men lige så meget en indikator af sværhedsgraden af det ønskede element. Udvikleren kan således bruge disse brugerhistorier i planlægningsfasen, til estimering af hvor lang tid det vil tage at udvikle den specikke del af systemet. Under udfærdigelsen af brugerhistorierne er kundens opgave at forklare udvikleren 22

25 3 XP Metoder 3.4 Programmering problemstillingen, med henblik på at udvikleren skal få indsigt i problemstillingen samt have mulighed for at stille uddybende spørgsmål. Udgivelser Når brugerhistorierne er lavet, afholdes et udgivelsesmøde, hvori det bestemmes hvornår de forskellige udgivelser skal nde sted. Rækkefølgen af udgivelserne bestemmes i samarbejde med kunden. Møder XP foreskriver standup meetings som en måde at komme hurtigt i gang med dagens opgaver, samtidig med at hele holdet bliver sat ind i ændringer. Grunden til at møderne afholdes stående er for at sikre at de ikke trækker ud. Dette er ligeledes med til at holde diskussionerne små, samtidigt med at hele holdet bidrager til mødet. 3.4 Programmering Kunden er tæt på Et af kerne-elementerne i XP er, at have kunden tæt på under hele processen hvilket også gælder i programmeringsfasen. Hvis muligt tilrådes det ydermere, at kunden aktivt hjælper med til selve udviklingen af programmet. Kundens primære funktion er, at fungere som et værktøj til at sikre produktet lever op til egne forventninger og krav. Dette sikres ved at kunden, med hjælp fra udviklerne, skriver brugerhistorier og er med til at fastsætte deadlines for udgivelser, samt prioritering af de forskellige udgivelser. Kunden tilrådes også at være med til at teste de forskellige udgivelser, da disse test ligger til grund for vericering af udgivelsens modenhed Kode standarder Udviklerne skal indbyrdes aftale, hvordan koden opstilles og hvilken navngivningsstandard der benyttes. Dette gøres for at opnå ensartet kodelayout, hvorved alle udviklere bedre er i stand til at læse og forstå hinandens kode. Ifølge XP er ens kodelayout noget man stræber efter, dog er det opnå svært at opnå fuldstændig ensartethed. 23

26 3.4 Programmering 3 XP Metoder Test Driven Development Inden selve programmeringen påbegyndes, overvejes det hvilke test der skal udføres for koden er tilstrækkelig udviklet. Sideløbende med udviklingen skrives yderligere test. Først når koden består testcasene, er udviklingen færdig. Det er derfor vigtigt at tilføje alle tænkelige testcases. Test Driven Dvelopment,TDD, er også en fordel ved refaktorering af kode, da det bliver lettere at refaktorere kode, idet det hurtigt kan afgøres om den refaktorerende kode, lever op til kravene fastsat i testcasene. Inden en testcase skrives, overvejes det først hvad der er nødvendigt at teste. Derefter skrives testen, og testen udføres for at sikre at den fejler. Herefter skrives den kode som denne testcase har til formål at validere. Dette er illustreret i gur 3.3. Eksempler på testkode kan ses på den medfølgende CD. Figur 3.3: Forløb i udvikling af software gennem TDD Alle testcases bør så vidt muligt automatiseres, således det ikke kræver menneskelig fortolkning af testresultaterne. Hvis testene tager længere tid, kan der i stedet anvendes smoking tests (Larman, 2005), som betyder at de længerevarende test cases kun afvikles 4 gange om dagen. For at kunne udføre løbende test, kræves det at store dele af udviklingen automatiseres. Denne automatisering er illustreret på gur 3.4 på næste side. En server henter løbende opdateringer til kildekoden fra versionstyringsprogrammet(subversion/cvs). Herefter afvikles alle testcases, og når testcasene 24

27 3 XP Metoder 3.4 Programmering validerer korrekt, overføres de til webserveren. Figuren illustrere hvordan det kunne foregå ved et webudviklingsprogram. Figur 3.4: Et system til at udføre løbende test Par programmering Parprogrammeing er en programmeringsform hvor to programmører deles om en computer. Ideen med parprogrammeing er at trods tiden det tager at producere et stykke kode øges, bliver kvaliteten af koden samtidig højere, ifølge (Cockburn and Williams, 2001). Derved ender man med at spare tid og omkostninger senere i processen, da der ikke er nær så mange fejl og der skal rettes i programmet. Parprogramming besidder samtidig den fordel, at det er med til at uddanne udviklerne og give ensartet kode. XP foreskriver at der til et par af programmører hører ét tastatur, en mus, samt at de to udviklere bytter plads med jævne intervaller for at sikre kvaliteten. 25

28 3.5 Opsummering 3 XP Metoder Integrer ofte Udviklerne skal stræbe efter at udgive kode så ofte som muligt. Det er især vigtigt at et udviklingsteam ikke holder på et stykke kode i mere end en dag af gangen. Løbende udgivelse af kode medvirker til at undgå en afvigende og fragmenteret udvikling, idet alle har adgang til den sidste nye kode. Dermed kan udviklerne til stadighed holde sig opdaterede med både funktionalitet af kode, samt have overblik over processen som helhed. Ydermere er det vigtigt at integrationerne fra de forskellige programmerings grupper koordineres så der ikke forekommer konikter eller programmeres videre i forældet kode Alle skal være med til at kode XP tilråder at alle medvirker til at kode og dermed er med til at nde nye ideer i alle aspekter af projektet. Dette medfører at der ikke er enkelte udviklinghold der ejer et stykke kode, hvorved alle udviklere vil kunne ændre og optimere alle dele af systemet. Denne tankegang medfører også at der ikke er en chef arkitekt på hele systemet. Alle i projektgruppen vil derfor være lige ansvarlige for det samlede system. 3.5 Opsummering Vi har i dette kapitel gennemgået og beskrevet hvorledes XP-metoden er opbygget af en række forskrifter der, ifølge (Beck, 2002), understøtter og forstærker hinanden. Disse forskrifter bygger på XP-metodens ånd om teamwork, kommunikation, enkelthed og feedback. Teamwork gennemføres vha. parprogramming, omrokering af udviklerne, møder samt fælles ejerskab. Alt dette er med til at sikre at alle udviklere har kendskab til alle aspekter af udviklingen, samt friheden til at gennemføre ændringer i hele kildekoden. Kommunikation gennemføres via den tætte kundekontakt, understøttet af brugerhistorier samt metaforer. Enkeltheden bliver understøttet af de fælles kodestandarder, hyppige aeveringer og refaktorering. Feedback kommer i udviklingen igennem de hyppige iterationer, kundekontakten, test og integrationerne. Alle forskrifterne understøtter hinanden indbyrdes og er med til at sikre en produktiv udvikling, der ikke er underlagt de traditionelle udviklingsparadigmers stringente opdeling af analyse og design. Dermed giver det udviklerne og kunden mulighed for, at indgå et tæt samarbejde hvor der hurtigt kan implementeres nye ændringer og stadig sikre et resultat af høj kvalitet. 26

29 . KAPITEL 4 Iterationer I kraft af at udviklingen gennemgår ere iterationer, bliver udviklerne i samarbejde med kunden, mere og mere opmærksomme på dennes ønsker. Således opnås der med tiden et system, der er lever op til kundens ønsker. 4.1 Første iteration Efter udarbejdelse af brugerhistorier i samarbejde med kunden gik vi igang med at designe GUI'en. Efter første iteration resulterede det i følgende; se gur 4.1 på den følgende side. Vores udgangspunkt var at designe en brugerade med store knapper med ikoner som medarbejderne intuitivt kunne associere til deres dagligdag. Årsagen til at udvikle GUI'en allerede i første iteration var, at give kunden et bedre indtryk af et fungerende program tidligt i processen. På denne måde ønskede vi at gøre kunden mere tryg ved programmet, for således at minimere eventuelle problemer forbundet med ibrugtagningen af systemet. Samtidig fungerede GUI'en som en overordnet arkitektur for funktionaliteter der skulle laves i kommende iterationer. Endvidere valgte vi i slutningen af iterationen at begynde udviklingen af enkelte funktionaliteter i metodelaget af programmet. Dette betød at vi skabte kontakt imellem vores program og den SQL-database server der indeholder lagerstatus, varenumre, priser osv. Dette var for at opnå bedre indblik i hvordan programmet i fremtiden skulle håndtere dette data Brug af brugerhistorier Ud fra de brugerhistorier vi k fra kunden, se appendiks B på side 77, kunne vi fastlægge nogle specikke krav til systemet. F.eks. kunne historien om lageroptælling omsættes til kravet om mere automatisering. Dette er i overensstemmelse med kundens ønske om at systemet selv skal løse gentagende og trivielle opgaver. Ud fra disse informationer besluttede vi at designe systemet således, at når lagerstatusen på et givent produkt ændres, skrives dette

30 4.1 Første iteration 4 Iterationer Figur 4.1: Screenshoot fra første iteration automatisk til den database som hjemmesiden bruger til at vise lagerstatus for kunderne. Denne funktion gør hele den nuværende procedure fuldautomatisk, hvilket derfor sparer tid hos både lagermedarbejderne, ledelsen og kunden Kravliste Der er fra kundens side stillet forskellige krav til systemet; bl.a. skal det automatisere en del af det gentage arbejde, der på nuværende tidspunkt forekommer i virksomheden. Ydermere skal der automatisk sendes en ordrebekræftelse, når en kunde har foretaget et køb via hjemmesiden. Når der bliver lavet optælling, indkøb, salg etc. skal systemet og hjemmesiden automatisk opdateres, således lagerstatus altid stemmer overens. Systemet skal desuden have funktioner der kan lave produktbestillinger, således brug af ere forskellige applikationer overødiggøres. Ydermere skal systemet kunne holde rede på hvem der har lejet et givent produkt, samt hvor lang tid det har været udlejet. Nedskrivningen af dette produkt skal ligeledes beregnes af systemet. Disse krav er at nde i de brugerhistorier der er blev udarbejdet i samarbejde med kunden. Brugerhistorierne 28

31 4 Iterationer 4.1 Første iteration kan ndes i appendiks B på side Release Efter ca. 14 dages udvikling sendte vi første iteration til kunden som i løbet af et par dage skulle gennemgå første iteration og komme med kommentarer ved brugermødet. Formålet med dette var at få respons på hvordan udviklingen af programmet forløb i forhold til de krav og brugerhistorier som blev udarbejdet fra starten. Således ville der allerede kunne tages hånd om uforudsete problemer og krav, således disse føres videre til næste iteration Kommunikation Gennem første iteration har vi benyttet forskellige kommunikationsformer, i vores kontakt med kunden.vi har primært, grundet den fysiske afstand, benyttet os af telefonisk kommunikation, samt korrespondance. Ved større beslutninger og designvalg valgte vi at tage til Århus for at holde personlige møder med kunden. Ved det første møde med kunden, var formålet at igangsætte projektet, derfor var hele gruppe med til mødet i Aarhus. Dette gentog vi da der skulle udarbejdes brugerhistorier. Som substitut for kunden der, i kraft af virksomhedens begrænsede størrelse, til tider havde de nødvendige ressourcer at afsætte til projektet, rettede vi i stedet denne kommunikation mod et gruppemedlem. Dette gjorde vi da vedkommende har indsigt i virksomhedens arbejdsmåder i kraft af sit fritidsarbejde i virksomheden. Dette gruppemedlem kom derfor ofte til at fungere som både en del af udviklingsholdet samt som kunde, hvilket var en stor fordel da gruppemedlemmet havde stort kendskab til de tekniske sider af det eksisterende system. Dette havde en vital rolle i udviklingen, idet mange af de tekniske spørgsmål kunne besvares omgående af vedkommende, i kraft af dennes overblik over det eksisterende system Brugermøde Slutningen på første iteration skulle have været et brugermøde med kunden for at igangsætte anden iteration. Dog blev vores kontakt med kunden begrænset i forhold til hvad vi havde håbet på. Det var i denne del af første iteration, vi valgte at benytte os af gruppemedlemmet der havde tilknytning til kunden. Gruppemedlemmets erfaring inden for virksomheden, samt kontakt med kunden via MSN Messenger og , gjorde at vi k den nødvendige respons og kritik til at kunne afslutte første iteration og fortsætte til anden iteration. 29

32 4.1 Første iteration 4 Iterationer Feedback Da det primært var GUI'en der var udviklet, gav kunden ikke så meget feedback, da kundens fokus mere lå på funktionaliteten af programmet. Dog blev der noteret, at kunden ønskede bedre navigation i programmet, gerne ved hjælp af en tilbageknap, således det altid vil være muligt at komme tilbage til hovedmenuen. GUI'en gjorde det således muligt for kunden at se hvordan de forskellige funktioner var planlagt til at se ud i programmet, hvilket denne fandt tilfredsstillende Forbedringer til kommunikation Grundet de, til tider, lange svar tider på s valgte vi, som tidligere nævnt, i slutningen af første iteration at benytte MSN Messenger. Idet kommunikation i Messenger automatisk bliver gemt på computeren blev det således muligt for hele gruppen på et senere tidspunkt at gennemse denne kommunikationen med kunden, for vericering af vores implementeringsforslag. Ved denne opdatering af vores kommunikationsform håbede vi, at få en mere eektiv arbejdsgang samt forøge hastigheden i fremtidige iterationer. Det var ydermere et forsøg på i større grad at følge XP forskrifterne i forhold til hvad vi havde gjort i den første iteration. Grundet, vore samt kundens, begrænsede ressourcer kunne vi ikke leve op til det element i XP der foreskriver kunden skal være tæt på udviklerne. Vi håbede dog på MSN Messenger løsningen ville simulere en tættere kontakt med kunden igennem de næste iterationer Konklusion Gennem første iteration, har vi lært at projektplanlægningen skal fastholdes, idet det er nødvendigt følge op på opgavernes varighed og længde, for derigennem at søge at undgå spildtid og samtidig tracke retningen af udviklingen. Samtidig har vi gjort nogle erfaringer med brugerhistorier, samt opgaven med at udlede arbejdsopgaver fra brugerhistorier. Denne erfaring vil vi naturligvis bruge i anden iteration, samtidig vil vi forsøge at gøre mere ud af at anvende de roller som XP opstiller, samt og synliggøre disse. Disse tiltag skal være med til at forbedre udviklingen i anden iteration. Vores kommunikation i sidste del af første iteration har primært været MSN Messenger, kombineret med s. Mindre spørgsmål kunne stilles pr telefon hvis det ikke var muligt, at komme i kontakt med kunden via MSN Messenger. Vi vil i anden iteration forsætte med at anvende MSN Messenger 30

33 4 Iterationer 4.2 Anden iteration som et supplement til den eksisterende kommunikationen med kunden. 4.2 Anden iteration Efter gennemarbejdning af første iteration, samt dertilhørende feedback fra kunden, påbegyndte vi implementeringen af yderligere funktionalitet i programmet. Anden iteration indebar samtidig nogle udfordringer, idet virksomheden besluttede at omstrukturere deres database, hvilket resulterede i omfattende refaktorering, af alt der kommunikerede med databasen. Dette forsinkede vores udviklingsproces en del, idet dette viste sig at være mere kompliceret end først antaget. Årsagen til dette problem var til dels, at XP foreskriver at man altid skal kode til nu'et, og det derfor ikke er nødvendigt at fremtidssikre sit program, da man i tilfælde af ændringer bør refaktorerer. Derfor var store dele af koden opbygget omkring de antagelser vi i starten af første iteration havde gjort os. Da disse antagelser ikke længere var gyldige, resulterede dette som sagt i omfattende ændringer i koden, lignedende det (Rosenberg and Scott, 2000) kalder et kode Rip op Kravliste De generelle krav til programmet er stadig relevante for denne iteration, dog blev der fra kundes side fremsagt et ønske om en tilbage-funktion på brugeraden, der skulle muliggøre, at det altid var muligt for brugeren at komme tilbage til forsiden af programmet, vha. et museklik Release Efter cirka en uges udvikling på metodelaget, færdiggjorde vi anden iteration. Dette indebar en omfattende refaktorering af al koden der kommunikerer med SQL-databases, hvilket var nødvendigt for at kompensere for de ændringer der skete i opbygningen af det eksisterende system. Idet databasekontakten var etableret og vareoplysninger kunne hentes fra databasen samt behandles i programmet, forventede vi i dette release, respons fra kunden om hvordan disse levede op til dennes krav. Samtidig forventede vi også respons på implementeringen af præference-menuen i programmet, som indebar nye funktionaliteter kunden skulle tage stilling til. Dette var dog ikke muligt, så kommunikationen igennem denne iteration blev støttet op af antagelser om hvad kunden ønskede, baseret på inputs fra gruppemedlemmet der er ansat i virksomheden. Anden iteration resulterede således bl.a. i gur 4.2 på næste side der viser panelet Complete Order, hvilket 31

34 4.2 Anden iteration 4 Iterationer er et af de paneler der k tilføjet funktionalitet i anden iteration. Figur 4.2: Screenshoot fra anden iteration Kommunikation Vi har gennem anden iteration benyttet kommunikation via MSN Messenger, og telefon. De este af samtalerne er foregået over MSN messenger, da det umiddelbart var den nemmeste måde, hvorpå kunden kunne nde nogle tomme huller i sin tidsplan. Denne kommunikationsform er ikke ideel til brugermøder, men omstændighederne taget i betragtning, var det den mest eektive måde, hvorpå vi kunne få og opretholde kontakt med kunden. 32

35 4 Iterationer 4.3 Opsummering af processen Feedback Som følge af den manglende kommunikation med kunden, har det været svært at få noget konkret feedback på anden iteration. Vi har således været nødsagede til at benytte gruppemedlemmet ansat i virksomheden, som substitut for kunden. Da dette, i kraft af sit arbejde i virksomheden, samtidig havde en stor indsigt i virksomhedens arbejdsrutiner, var dette en oplagt, og samtidig den eneste, mulighed for feedback i denne iteration Konklusion I anden iteration erfarede vi, hvad det betyder når der i XP programmeres til nuet og ikke til fremtiden. Efter færdiggørelsen af første iteration skete der i virksomheden, en større omstrukturering af deres databasestruktur, hvilket medførte at der skulle foretages store ændringer, inden udviklingen kunne fortsætte. Dette medførte forsinkelser idet ere dele af koden skulle refaktoreres for at kunne anvendes med det nuværende system. Den kommunikation vi oplevede gennem anden iteration foregik meget ydende, dog står brugen af MSN Messenger ganske vist ikke i XP's metodebeskrivelse, men dette fungerede alligevel fornuftigt, idet kunden kunne svare tilbage når der var tiden til det, samt mindre spørgsmål kunne besvares med det samme via chat over MSN Messenger. 4.3 Opsummering af processen Et tilbagevendende problem har været kravene fra XP's side omkring tæt og konstant kundekontakt. Disse krav, kombineret med en forholdsvis lille virksomhed uden de nødvendige ressourcer til at frigive en større del af deres arbejdskraft gennem længere tid, har bevirket at vi ikke har kunnet opretholde den ønskede mængde kommunikation gennem processen. Dette har resulteret i stilstand i programmeringsfasen, samt tvunget os til at træe beslutninger vedrørende implementeringen, baseret på gruppemedlemmets, med arbejde i virksomheden, viden. For at kompensere for den manglende kommunikation samt være i stand til at fortsætte med udviklingen, benyttede vi os i større grad af det gruppemedlem som arbejder for rmaet. Således kom vedkommende til at fungere som stedfortræder for kunden, i kraft af dennes insider-viden om rmaet. XP foreskriver at det er vigtigt at have kunden tæt på i udviklingen og bedst muligt hvis kunden kan deltage aktivt i udviklingen. Ved at have et gruppemedlem i gruppen, som havde en dobbeltrolle som både udvikler og som kunde, stod 33

36 4.3 Opsummering af processen 4 Iterationer vi i en favorabel situation. En ulempe ved denne situation var dog at gruppemedlemmet kunne blive fanget i konikter mellem gruppens og kundens forventninger og derfor ville blive presset til at vælge side, hvilket strider med kundens sande rolle i XP metoden. Samtidig var gruppemedlemmets rolle i virksomheden, udvikler af virksomhedens eksisterende system. Dette betød at dette gruppemedlem ikke nødvendigvis havde de rette forudsætninger for at besvare spørgsmål omkring alle aspekter af rmaet, for eksempel salg. 34

37 . KAPITEL 5 Metode kritik af XP Ifølge (Rosenberg and Scott, 2000, side 16) kommer XP med en række brugbare idéer til systemudvikling, men også en række tvivlsomme påstande og, ifølge (Rosenberg and Scott, 2000), en åbenlys mangel på skalerbarhed, overskygger disse ideer. I det følgende afsnit vil vi præsentere en metode kritik af XP som udviklingsmetode, som vil tage udgangspunkt i (Rosenberg and Scott, 2000) og (Stephens, 2003), samt vores egne erfaringer fra udviklingsforløbet. 5.1 Krav ændres løbende Et af de centrale elementer i XP er fraværet af en grundig kravsanalyse som udgangspunkt for software udviklingen, hvilket står i kontrast til hvad XP tilhængere kal6der Big Design metoder se også (Rosenberg and Scott, 2000, s 16). Ifølge XP tilhængere skyldes dette at en analyse på forhånd søger at kontrollere forandringer. Dette gøres ved på forhånd at lægge krav og arkitektur fast, samt at de såkaldte Big Design metoder ser en hver form for forandring som værende noget negativt. Hovedårsagen til dette fravær af kravanalysen, skulle være at kunden efter sigende alligevel ikke har nogen chance for at have begreb for, hvad denne i virkeligheden ønsker. Som følge af dette ville sådanne krav ofte være udsat for ændringer, hvilket betyder at der ikke er noget formål med at forsøge at klarlægge dem, inden kode udviklingen startes. (Rosenberg and Scott, 2000) ser også dele af dette som en valid påstand, idet der hævdes at kravsanalysen er en svær og fejlbehæftet aære, om end nødvendig, for at på sigt at kunne spare tid, ved at have fastlagt blot nogle af kravene på forhånd. Ligeledes mener (Stephens, 2003) at brugen af en onsite kunde yderligere besværliggøres idet denne typisk ikke vil være en senior medarbejder fra virksomheden og således ikke er den mest egnede til at træe beslutninger. Et andet argument mod ikke at fastlægge kravene på forhånd er, at det til tider kan hjælpe på kundens forståelse, at tvinge dem til at reektere over deres forståelse af situationen, som et

38 5.1 Krav ændres løbende 5 Metode kritik af XP led i at identicere hvad kunden ønsker af systemet, inden der begyndes på udviklingen. Lignende mener (Stephens, 2003) at udviklerne bør påtage sig rollen som konsulent, og istedet for at lade kravene ændre sig konstant, bør selve årsagen til at kravene ændrer sig konstant behandles. Altså at man bør behandle sygdommen frem for symptomerne. Et andet af XP tilhængernes ankepunkter ved Big design er ifølge (Rosenberg and Scott, 2000), at hvis det sent i forløbet viser sig at man har misforstået kundens krav, vil dette muligvis kræve fundamentale ændringer i designet. (Rosenberg and Scott, 2000) mener at dette næsten aldrig nder sted, da man jo netop laver en så grundig kravanalyse netop for at ikke komme i den situation. (Stephens, 2003) mener samtidig at praksisen om at lade programmørerne overtage kundeforhandlingerne er en ricikabel aære, idet programmører måske ikke er de bedst egnede til dette. Egne erfaringer Vi mener at, for at arbejde med softwareudvikling bør der tages grundlæggende design beslutninger inden udviklingen påbegyndes. Det er ikke tilstrækkeligt hver eneste gang et problem opstår, at prøve og dele det ned i mindre problemer, indtil en udvikler selv kan kode problemstillingen færdig. Der er et behov blandt udviklerne for et fælles mål formuleret på skrift og diagrammer. Den tætte kundekontakt i XP er positiv omend det kan være svært for kunden, at skulle investere ekstra tid i dette, hvorved manglen på grundlæggende design beslutninger betyder at udviklingsarbejdet bliver mangelfuldt. For små virksomheder er dette en uløselig problematik som giver problemer for udviklingen. Ved udvikling i samarbejde med større virksomheder bør der afsættes medarbejdere, således at udviklerne kan få hurtig feedback fra kunden i form af deres kompetente medarbejder. I vores tilfælde, hvor vores kunde er en lille virksomhed og derfor har meget svært ved at afsætte tilstrækkelige ressourcer, har det, til tider, været svært at fortsætte udviklingen. Dette har været tilfældet da kunden ikke har været til rådighed i forbindelse med design beslutninger. Manglen på et design dokument har i disse tilfælde været særlig problematisk, idet vi ikke har haft de nødvendige forudsætninger for at forsætte udviklingen. For de tilfælde hvor kundekontakten er tilstrækkelig, har XP naturligvis større berettigelse. Det savnes alligevel at processerne indføres i diagrammer. Selvom om XP mener at kunden ikke er i stand til at forstå usecases, bør der som (Rosenberg and Scott, 2000) forklarer, alligevel forsøges. Evt. oplære kunden i at læse diagrammerne 36

39 5 Metode kritik af XP 5.2 Brugsmønster vs. Brugerhistorier fordi de ofte er lettere at præcisere end tekst, da sådanne tekst ofte fortolkes forskelligt mellem udviklerne og kunden. Planning game Til The Planning Game har vi anvendt X-planner som er udviklet specikt til formålet. Værktøjet giver et godt overblik over hvilke arbejdsopgaver der skal foretages løbende, og hvilke opgaver der er under udarbejdelse. Det giver samtidig mulighed for projektkoordinatoren at få et samlet overblik over opgavens omfang, tid og ressourcer. Vi ser X-planner som et positivt tiltag inden for udvikling, fordi det visualiserer arbejdsprocessen, samt viser essentielle problemer ved planlægningen. XP foreskriver netop, at udviklerne ikke bliver stresset, men Projektkoordinatoren kan bruge værktøjet som et instrument, enten til at presse udviklerne eller til at sikre sig, at der ikke arbejdes over. Vi hælder dog til, at op i mod afslutningen af et projekt, vil det blive anvendt som et værktøj til at presse medarbejderne, som dermed vil blive tvunget til at arbejde hurtigere. 5.2 Brugsmønster vs. Brugerhistorier XP anbefaler at der opstilles krav til udviklingen i såkaldte brugerhistorier, i modsætning til brugen af de mere komplekse usecases i Big Design metoder. Grunden hertil skulle være at usecases, i følge XP tilhængere, er unødig detaljerede og formelle. Denne grad af formalitet og detaljering skulle angiveligt medføre at kunden ikke er i stand til at bruge dem konstruktivt. Denne påstand er (Rosenberg and Scott, 2000) ikke enig i, idet usecases ifølge deres udsagn, blot er en sekvens af handlinger udført af en aktør for at opnå et bestemt mål. Dette er i deres mening ikke unødig detaljeret og formelt, og derfor er usecases ikke for komplicerede at bruge. Brugen af usecases kan, ifølge (Rosenberg and Scott, 2000) også hjælpe kunden til at få en klar forståelse af den sekvens af handlinger vedkommende bør følge. Dette gør at kunden er aktivt involveret i udarbejdelsen af use casene. Egne erfaringer Brugen af brugerhistorier, i form af små notater med tilhørende diskussion med kunden, som dokumentation fandt vi at være en for minimalistisk tilgang til kravsstyring. Under implementeringen af brugerhistorierne, var der ofte tvivlsspørgsmål idet brugerhistorierne ikke altid indeholdt den nødvendige 37

40 5.3 Anvendelse af XP 5 Metode kritik af XP mængde og detaljering af information om opgaven. Disse erfaringer stemmer således overens med (Rosenberg and Scott, 2000) kritik af brugen af brugerhistorier. Derfor blev det valgt at vi både udarbejdede skitser og program i første iteration, som så blev efterset af kunden. Dette er måske ikke den ideelle løsning på problemet, men som tidligere nævnt har kunden ikke forudsætninger for at designe et lagerstyringsprogram, så vi k frie tøjler i designfasen, da kunden fokuserer meget på funktionalitet frem for design. 5.3 Anvendelse af XP Udvikling af software efter XP modellen, kræver løbende kommunikation med kunden fra den virksomhed som softwaren udvikles til. Heri ndes de første begrænsninger inden for agil udvikling, hvis der udvikles til relativ små rmaer med relativ små ressourcer. Alle metoder har en indlæringsperiode, og denne viden bliver sværere, at nå inden for semestertidsrammen, fordi der ved XP skal bruges relativt meget tid sammen med virksomheden samt viderekommunikere viden og teori. Under udviklingen har gruppen været i kontakt med kunden, men som noget lidt unormalt er et gruppemedlem ansat hos kunden i fritiden, hvilket gruppen har benyttet sig af, idet tvivlsspørgsmål fra andre gruppemedlemmer i de este tilfælde har kunnet besvares af dette gruppemedlem, vedkommende har således til tider kunnet agere kunde. Endnu en problemstilling er at der i XP kodes til nu'et, og ikke til i morgen samt XP metoden postulerer, at kunden ikke selv ved hvad kunden ønsker. Beslutninger kommer derfor nemt til at lægge hos udvikleren ved at analysere brugerhistorier. Problemet viser sig i stor udstrækning ved, at hvis kunden ikke ved hvad denne ønsker, hvordan kan der så udarbejdes en acceptancetest som kunden er med til at godkende? Refaktoring Omkostningen ved at ændre i koden er i følge XP forfatter Kent Beck ikke større end omkostningen ved at ændre i analyse eller design dokumenterne i henhold til traditionel udvikling. For konstant at kunne overskue hele koden, mener Kent Beck at to personer altid er bedre end en. En hjørnesten i XP er derfor par programmering, hvor metoden foreskriver at 38

41 5 Metode kritik af XP 5.4 Test driven development parrene sammensættes efter behov, og gerne ændres dagligt alt efter arbejdsopgaven. Dette er efter devisen om at to hoveder er bedre end et. (Rosenberg and Scott, 2000) ser også dette som værende et udmærket princip, i teorien i hvert fald. De sætter spørgsmålstegn ved praksisen med at alle udviklerne skal være samlet i samme lokale, da dette ikke altid er muligt. (Rosenberg and Scott, 2000) ser samtidig et problem i at de ikke er muligt at holde nogen enkeltperson ansvarlig for noget, da alle er ansvarlige for alting. (Rosenberg and Scott, 2000) ser ikke noget forkert i brugen af par programmering, men er dog mere skeptiske overfor baggrunden for brugen af denne i XP. De opfatter brugen af par programmering som et forsøg på at kompensere for den manglende analyse, ved i stedet tvinge udviklerne til at gennemgå den samme kode. Egne erfaringer Selv ser vi både fordele og ulemper ved parprogrammering. Fordelene ved parprogrammering ifølge XP skulle være, at der laves mindre fejl fordi der er 2 udviklere på samme opgave. Vi mener selv der er fordele og ulemper ved dette. Det kræver bl.a. at to personer formår at arbejde godt sammen, hvilket personerne i mellem kan være problematisk i stressede perioder. Den klare fordel er at 2 personer understøtter hinanden, og hjælper hinanden igennem vanskelige dele af udviklingen. Desværre kommer personen som er medhjælper hurtigt selv til at kede sig. Vi mener selv, at ved trivielle opgaver er parprogrammering ikke en fordel, mens ved sværere opgaver kan det være en fordel, fordi 2 personer kan hjælpe hinanden ved at komme med forbedrende ideer og på den måde forbedre programmet, og understøtte hurtigere udvikling. Mens ved mindre opgaver opfatter vi parprogrammering som værende et spild af ressurser som vil kunne anvendes bedre. 5.4 Test driven development Test driven development (TDD) er en funktionel proces der tvinger udviklere til at fokusere over hvad de ønsker af selve processen. Metoden kræver værktøjer til at kunne anvende det fuldt ud, og det ville desuden være belejligt at kunne anvende metoden på brugerader og ikke kun metode output. TDD er ekstra anvendeligt ved refaktorering af kode, men kræver som minimum at udvikleren har tænkt over hver testcase. Hvis testcasene til gengæld er korrekte, er det hurtigt at undersøge om hvorvidt en refaktorering af ko- 39

42 5.4 Test driven development 5 Metode kritik af XP den virker efter hensigten. Dog hævder (Stephens, 2003) at måden hvorpå XP anvender testcases, medfører at designløsninger ikke revideres af erfarne senior programmører, der istedet fokuseres på konstant udvikling af designet. Faren ved dette er at tests kun afslører fejl på kode niveau, og ikke forkerte designløsniger, hvilket ifølge (Stephens, 2003) kræver menneskelig involvering. Egne erfaringer Det kan opleves lidt trivielt, at skulle skrive testcases til selv simple outputs. Vi mener selv der kan gå for lang tid med at skrive testcases til disse simple kodestykker, hvorved mængden af arbejde lagt i disse testcases langt overstiger brugbarheden af de resultater fra dette. Derfor mener vi at brugen af testcases bør minimeres i visse tilfælde, og kun anvendes på mere omfattende opgaver, hvor det kan være svært at overskue koden. Et godt eksempel på hvor det ikke er så anvendeligt at skrive testcases; f.eks. ved udarbejdelse af GUI'en. At skrive testcases i den rækkefølge som XP foreskriver virker også omvendt. Vi foretrækker at skrive testcasene når vi mener det enkelte stykke kode er klar til at gennemgå test. Da det ofte ender med dobbeltarbejde, da man i et sådant tilfælde skal ændre både selve den skrevne kode, samt testcasen dertil Mangel på ansvarsdeling Big design metoder har ifølge (Rosenberg and Scott, 2000) en arbejdsdeling hvor hver udvikler har en bestemt rolle i udviklingsholdet, og løser så opgaverne inden for dette område. I XP er denne arbejdsdeling en anden, nemlig at alle laver alt for at udviklingen skal være sjov og lærerig for alle udviklerne. Dette er ifølge (Rosenberg and Scott, 2000) ikke den rigtige måde at arbejde på, da der ikke er noget galt i at f.eks. have gode designere til at lave designet. Egne erfaringer Dette har vi dog ikke oplevet som værende et ret stort problem gennem vores projekt. Delvist som følge af at vi maksimalt har tre par programmører ad gangen. Dette har i vores udvikling medført et naturligt ansvar hos delgrupperne imellem, idet disse delgrupper har påtaget og specialiseret sig i udvalgte opgaver. Dette kunne øjensynligt godt virke som værende i modstrid med XP's ånd om at "alle laver alt"(beck, 2002, s. 54). Dog har vi forsøgt at holde denne specialicering i vores udvikling til at delgrupperne bag 40

43 5 Metode kritik af XP 5.4 Test driven development de specikke kodestykker stod til ansvar for at svare på tvivlsspørgsmål omkring den specikke kode. Valget om til dels at bryde med XP's ånd på dette område bunder i den begrænsede tid projektet var bundet af. Dette faktum gjorde at der ikke var uanede tid til at sætte sig ind i kode-dokumentationen, hvilket skabte et behov for at danne disse specialister internt i gruppen for at sætte kode-processen i gang. Som nye brugere af XP, er metoden en tung maskine at igangsætte, med mange caseværktøjer at sætte sig ind i. Dog føler vi at på trods af disse tidsbegrænsninger og manglende erfaring med case-værktøjer, at vi ikke helt har brudt med XP som metode, men i stedet forsøgt kompenseret for at kunne følge metoden Jo simplere, jo bedre Et mål i XP er altid at arbejde hen mod den simpleste løsning som virker. Herved undgås der også at der implementeres unødig funktionaliteter. Dog har (Rosenberg and Scott, 2000) sine forbehold overfor tankegangen at hvis du tror du ikke har brug for det, så har du ikke brug for det. Opfordringen til at stræbe efter den simpleste løsning, kan lede udviklere til at bruge lette lappe-løsninger på kode, fremfor at lægge den ekstra arbejdskraft i at bygge en mere robust og simplere struktur. Samtidig bliver kodens anvendelighed lagt over på udviklerne der enerådigt bestemmer hvilke problemer der er værd at løse. Dette stiller store krav til at udviklernes indbyrdes kvalitetskrav stemmer overens. Således mener (Stephens, 2003) at ved at have et gennemarbejdet designdokument er udviklerne fri for at tænke genbrugligheden af en given funktion, idet de blot kan slå op i designdokumentet Koden er designet Et andet punkt i XP losoen som (Rosenberg and Scott, 2000) stiller spørgsmålstegn ved, er påstanden om at gennemløbende refaktorering er detaljeret design arbejde. XP tilhængere støtter denne påstand som værende en økonomisk og tidsmæssig fordel for projektforløbet, da kode er let at ændre og det derfor ingen betydning har om designet halter efter. (Rosenberg and Scott, 2000) ser et problem i denne påstand da det fra udviklernes side ville kræve at de gentagende gange krydser grænsen mellem design delen som ligger i nedskrevne brugerhistorier og løsningsmetoderne som skal laves i koden. Dette kan i sidste ende betyde at design og kode fejl vil blive blandet. (Rosenberg and Scott, 2000) pointerer at dette vil ende i spildt arbejde da tiden brugt på at nde og rette fejl i koden. Tiden brugt på at få koden til at fungere vil nu være spildt da designet skal ændres og store sektioner af koden som udviklerne har arbejdet på derved også skal refaktoreres. (Rosenberg 41

44 5.4 Test driven development 5 Metode kritik af XP and Scott, 2000) mener, at selvom denne metode godt kan anvendes i praksis og kan levere brugbare systemer, så er den ikke optimal. Ved ikke at gøre sit bedste i samtlige stadier af projektet og gennemarbejde dem før kodningen starter, er resultatet dømt til aldrig at blive optimalt. Egne erfaringer Praksisen med at koden er designet har ofte ikke været tilstrækkelig, hvilket der er ere grunde til. Dels har alle gruppemedlemmer ikke samme erfaring med programmering, hvilket betyder det kan være ekstremt tidskrævende at læse kildekode frem for et egentligt designdokument. Samtidig har fraværet af et designdokument i ere tilfælde ledt til unødige funktioner eller forfejlede antagelser i applikationen. I disse situationer kunne det have været hensigtsmæssigt at have brugt mere tid på en grundigere analyse for derigennem at have været i stand til at opstille et solidt modellag. Det kan virke meningsløst at anvende objektorienterede sprog, hvis der ikke er grundig nok viden om hvilke klasser og objekter der skal være i samspil. XP's foreskrivning af få, men større klasser, synes herved at betyde at store dele af ideen om OOP går tabt. I vores erfaring kan XP, som (Rosenberg and Scott, 2000) også hævder, hurtigt blive til en konstant lappeløsning, selv til trods for den konstante refaktoring af koden, idet det ikke er gennemtænkt fra start Koden er selv-dokumenterende En anden antagelse i XP er, ifølge (Rosenberg and Scott, 2000); at kode er selvdokumenterende højniveausprog, hvilket vil sige at alt anden dokumentation er overødig og upålideligt. XP fokuserer stærkt på mundtlig overlevering og resten vil koden kunne fortælle selv den uerfarne udvikler hvad vedkommende har brug for at vide om systemet. (Rosenberg and Scott, 2000) er enig i at dette er et ønsket resultat, men mener dog at frygten for subjektiv og forældet dokumentation er irrationel og mere en fejl fra udviklernes side, og ikke mediet. Problemet i manglende dokumentation er at denne information vil være spredt blandt de forskellige udviklere som muligvis ikke er der til fremtidig vedligeholdelses af koden. Egne erfaringer Dette princip har vi haft nogle vanskeligheder med. Ideelt set er princippet udmærket, men undlader dog at tage højde for den menneskelige faktor. Den programmør som i første omgang har skrevet koden kan have brugt lang tid på at læse API'er før vedkommende har skrevet koden. Hvis koden står 42

45 5 Metode kritik af XP 5.5 Positive erfaringer med XP alene kan det være svært for den næste udvikler, udelukkende at skulle bruge kildekoden til at få indblik i arbejdet. Dette har i vores projekt været med til yderligere at forankre en programmør til et givent stykke kildekode Caseværktøjer XP foreskriver brugen af mange caseværktøjer for at automatisere opgaver. Denne ide synes også at være udmærket, men ofte viser det sig at mange caseværktøjer ikke er tilgængelige eller meget tidskrævende at blive fortrolige med. Egne erfaringer med caseværktøjer Gennem vores projekt har vi erfaret at der ndes mange forskellige værktøjer. Kendetegnet ved disse er, at hvert eneste værktøj kræver meget tid til konguration og indlæring, første gang de bruges i et udviklingsforløb. Den tid dette tager, er reelt set tid hvori der ikke bliver udviklet. Vi har derfor erfaret, at XP er en meget tung metode første gang den bruges. Derudover er det ikke ligegyldigt hvilket udviklingssprog som anvendes i udviklingen, idet unit-testing ikke ndes til alle sprog. XP metoden knytter sig derfor tæt op af hvilket IDE der anvendes, hvilket der bør tages højde for, inden udviklingsprocessen påbegyndes. 5.5 Positive erfaringer med XP XP bygger på en iterativ udviklingsmetode modsat det traditionelle udviklingsparadigme, såsom vandfaldsmodellen, som har eksisteret længe, og som udspringer af traditionel ingeniør-tankegang. Oprindelig udsprunget fra hardware branchen, og videreudviklet i software branchen (Biering-Sørensen et al., 2002). Vandfaldsmodellens udgangspunkt er antagelsen om at hele processen er forudsigelig samt at softwareudviklingsprocesser er ens. Problemet i metodikken er at udviklingsprojekter sjældent er ens, hvorfor det bliver meget svært at komme med forudsigelser om processen, hvilket er den antagelse XP søger at gøre op med. Forudsigelig fremstilling Det er muligt først at færdiggøre specikationer, derefter at udvikle. Man kan fra starten troværdigt estimere arbejdsbyrde og omkostninger. Ny produkt udvikling Sjældent muligt at udfærdige detaljerede og endelige specikationer på forhånd. Det er ikke muligt at estimere ved starten. I takt med empirisk data fremkommer, bliver det i stigende grad muligt at estimere og planlægge. 43

46 5.5 Positive erfaringer med XP 5 Metode kritik af XP Det er muligt at identicere, planlægge og bestille alle de detaljerede aktiviteter. I starten er det ikke muligt. Tilpassede skridt, drevet af udviklings-feedback løkker er påkrævet. Kreativ tilpasning til uforudsigelig forandring er normen, og forandrings-raten er høj. Tilpasning til uforudsigelig forandring er ikke normen, og forandrings-raten er relativt lave. Tabel 5.1: Forudsigelig kontra ny produkt udvikling (Larman, 2005, s.3) Pointen i tabel 5.1 er, at de este udviklingsprocesser aldrig er ens og det altid vil være et nyt udviklingsprojekt som påbegyndes. Dette håndterer XP ved at strukturere det ustrukturerede og uforudsigelse. Således kan selv store projekter skulle kunne færdiggøres uden de problemer som eksisterer i traditionel udvikling såsom vandfaldsmodellen. Udviklingsprocessen påbegyndes fra starten af projektet, og der tages højde for at der vil komme ændringer til det udviklede. Således har vi allerede efter første iteration f.eks. kunnet fremvise brugeraden til kunden. Kunden har således på et tidlig tidspunkt kunnet hjælpe til med at modicere denne yderligere til næste iteration. Den konstante tætte kontakt med kunden, har givet kunden mulighed for at sikre at det som implementeres, også er efter dennes behov. Dette må i sidste ende medføre at kunden får øget tilfredshed, idet kunden gennem hele forløbet har fået applikationen skræddersyet efter dennes behov. XP holder orden i kaos ved hele tiden at dele projektet ned i små timeboxed processor. Det betyder at når første iteration påbegyndes kan denne ikke ændres. Processen kan dog afkortes således at en ny kan påbegyndes. Dette er en keypractice i XP at processen er stabil for udvikleren, for at der er et holdepunkt og kaos ikke opstår. Netop denne stabilitet fungerer rigtig godt for udviklingen. Vi oplevede at korte og stabile iterationer, bevirkede at udviklingen fungerede bedst. Stabile i den forstand at vi søgte at holde mål og krav for iterationerne i ro således at nye ideer ikke blev indskudt i iterationerne efter arbjedet med disse var startet. Istedet blev nye ideer udskudt til fremtidige iterationer. XP fastholder som metode at alt der kan automatiseres skal automatiseres. Netop denne tankegang mener vi at på størrere projekter er grundlæggende. Det sikrer mod irritation fra udviklernes side ved at denne undgår at skulle udføre trivielle opgaver og kan bruge tiden på det relevante, kodningsprocessen. XP hurtige tilgang til processen mener vi er væsenlig for enhver udvikler, hvor fokus ofte vil være rettet mod det kodeprocessen i stedet for blive i det dokumentationsoverhead som ofte ender med at blive forkastet. XP synli- 44

47 5 Metode kritik af XP 5.6 Universitetsprojekter gører hurtig et produkt som vi mener er vigtig for at holde lysten oppe og til at forsætte. Det er vigtigt at der konstant kan konstateres en udvikling i processen. XP sikrer dette ved små, men hurtigere releases hvilket betyder der konstant kan ses progression i udviklingen. Dette betyder øger samtidig lysten til at bidrage med yderligere fordi processen er synlig. Dette bemærkede vi selv ved at der eksisterer en glæde ved at se et resultat blive synliggjort hurtigt i forløbet. Modsat andre udviklingsforløb hvor brugeraden kan vælges at blive implementeret som det sidste. Dette kunne foreksempel betyde en relativ stor kodebase, men intet synlig output. TDD metoden er ydermere med til at synliggøre denne process således at hvis det ikke er konkret brugerade-udvikling, kan der altid spores progression i form af testcases som koden består. Flere aspekter af parprogrammering anser vi som positivt. Dels betyder det at en svag udvikler med støtte fra en stærk udvikler kan bidrage med kode samtidig med egne evner udvides. I en størrere orginisation med ere udviklere vil det også være med til øge kontakten imellem de enkelte udviklere. Samt anskueligøre for den enkelte udviklere de andres problemstillinger når der samtidig skiftes mellem opgaver. Parprogrammeringen betød for projektet at det var nemmere at få hele gruppen til at kode på projektet, modsat tidligere projekter hvor den enkelte selv koder en opgave. Det betød at også en hjælp til de mindre erfarende, og hjalp dem i gang. 5.6 Universitetsprojekter Vi har oplevet en række problemer ved anvendelse af XP i forbindelse med et universitetsprojekt, samtidig ndes ere problemstillinger som er svære at løse i forhold til brugen af XP. Vi anser XP for at være en metode der, til trods for den er agil, indebærer en stor del forarbejde for at kunne påbegynde udviklingen af et projekt. Her tænkes der specielt på brugen af caseværktøjer. Der ndes forskellige caseværktøjer, hvor vi har været begrænset til de gratis værktøjer. Disse værktøjer kræver alle en større eller mindre mængde opsætning. Selve opsætningen af disse værktøjer besværliggøres idet værktøjerne tilsyneladende er udviklet efter XP princippet om at dokumentation er overødig, og således er mængden af dokumentation meget begrænset eller ikke eksisterende. Samtidig er opsætningen af værktøjerne desværre er ikke automatiseret og bærer præg af stadigvæk at være under udvikling. Således går tiden anvendt på opsætning af værktøjer fra det primære i XP, nemlig udvikling af software. 45

48 5.6 Universitetsprojekter 5 Metode kritik af XP XP praksisen om fælles ejerskab og ansvar, synes at passe godt på projekter i gruppesammenhæng, hvor alle netop er fælles ansvarlige for det samlede projekt. Hvis man således går ud over selve programkoden og overfører disse principper til alle aspekter af projektet, kan dette have en ligeledes gavnlig eekt. Eksempelvis kan langtrukne diskussioner, om f.eks. formulering undgås, idet det står alle frit at refaktorere alle dele af både rapport samt programkode. XP metoden, som helhed, bygger på tæt kundekontakt samt stor fokus på produktudviklingen, hvorimod universitetsprojekter ikke udelukkende evalueres på output i form af en given implementering, men i større grad på det akademiske indhold i rapporten. Dette medfører at det kan være svært at overbevise en kunde om at ligge den tilstrækkelige, og i XP ganske betragtelige, tid og indsats i projektet, idet der ikke kan stilles nogen garantier om anvendeligheden af det endelige produkt. Derved synes XP at være en udviklingsmetode til mellemstore projekter, h- vor universitetsprojekter må anses som værende mindre projekter, idet der både skal afsættes tid til undervisning, rapportskrivning samt den egentlige udvikling. Derfor bliver det svært at nå tilstrækkelige iterationer. I planlægningen af et XP projekt arbejdes der ud fra re faktorer: Omkostninger Tid Kvalitet Omfang - Hvor kunde og ledelse maksimalt må fastlægge tre af faktorerne, således udviklingsholdet kan bestemme over den sidste. Et universitets projekt har som bekendt en fast dato hvor projektet slutter, hvorved faktoren omkring tid synes at være irrelevant i universitets sammenhæng. Ligeledes er faktoren omkring omkostninger irrelevant, idet et universitets projekt ikke kan tilføres yderligere ressourcer. I akademisk sammenhænge giver det ligeledes kun ringe mening at ændre på faktorerne omkring kvalitet, i hvert fald i nedadgående retning, således må denne også betragtes som værende fastlåst. Dette betyder at der reelt set kun er faktoren omkring omfang at ændre på. Da denne faktor samtidig, ifølge XP, er den mest betydningsfulde faktor at ændre på. Idet denne faktor har stor indydelse på de tre andre, synes der at være et paradoks ved brugen af XP i universitetsprojekter, idet kunden kun 46

49 5 Metode kritik af XP 5.7 Opsummering er i stand til at ændre en af de tre faktorer som XP foreskriver. Ligeledes burde udviklingsholdet kunne ændre på den af de re faktorer kunden ikke fastsætter, dog er den eneste faktor udviklingsholdet har at ændre på, ligeledes omfanget. Således kan planlægningen af et universitetsprojekt kun blive til en forhandling mellem kunde og udviklingsgruppe omkring omfanget af projektet, hvorved hele grundidéen med XP praksisen med de re faktorer synes at være forsvundet. 5.7 Opsummering Vores egne erfaringer med XP kan kun holdes op med vores tidligere erfaringer. XP gør op med en gammel fortid om at udviklingen skal fastlægges i faste rammer og skemaer som i vandfaldsmodellen. XP forsøger i stedet, at gøre iterativ udvikling struktureret og lægge vægt på de gode elementer heri. Mange af de metoder der anvendes i XP vil uden videre kunne anvendes i en traditionel udvikling, f.eks. TDD (Test driven development) hvilket er en god måde at sikre, og højne, kvaliteten igennem et projekt. Vi mener der er mange gode elementer i XP metodikken som bør overvejes ved fremtidige projekter. Unit-testing er helt sikkert et aspekt som vil blive anvendt ved fremtidige projekter. Dog er der i gruppen mere uenighed omkring brugen af parprogrammering, om hvorvidt parprogrammering er hurtigere og mere eektivt end individuel programmering i grupperummet. Den tætte kontakt udviklere imellem og den adere struktur i udviklingen, udviklerne imellem, synes vi er et positivt grundelement, i et sådant projekt af denne type idet alle i gruppen er tvunget til at udvise ansvarlighed og dedikation. Yderligere har vi også overvejet hvorvidt en kombination af højere dokumentationskrav samt større overvejelser omkring hvilke objekter der er i spil, ville være fordelagtigt i senere projekter, hvis XP ønskes anvendt. XP gør dog op med det dokumentations overhead som typisk kan opstå i overgangen fra en fase til en anden, i det traditionelle udviklings paradigme. Det at XP anser dokumentation for at være forældet allerede ved udgivelsestidspunktet og derfor helt bør undlades, stiller store krav til de case værktøjer der benyttes hvis det skal kompensere for denne mangel. Samtidig stiller det også store krav til at koden altid er simpel og let overskuelig. Vi mener selv, at en mere ideel løsning er at nde et sted midt i mellem. Vi mener at der behøves nogen form for dokumentation, idet dokumentation i form af kode er ikke tilstrækkelig. Vi mener at en blanding af Javadoc og UML sandsynligvis vil være tilstrækkelig i de este tilfælde. 47

50 5.7 Opsummering 5 Metode kritik af XP 48

51 . KAPITEL 6 Estimering og usikkerheder Prediction is very dicult, especially if it's about the future - Niels Bohr I dette kapitel beskrives de estimeringer vi har lavet gennem projektforløbet, samt de usikkerheder og erfaringer der har været med disse. 6.1 Estimering Agile udviklingsmetoder som XP forudsætter ikke en tidsplan, men anerkender at kunder nødvendigvis behøver estemering af projektets længde. Dette kunne være i forbindelse med størrere projekter, som afhænger af projektet. Til tidsestemering foreslår (Larman, 2005, Kapitel 11) at der anvendes a- daptive planning. Der fastsættes løse datoer for de enkelte iterationer samt milestone releases. Til hver enkelt release fastsættes ekstra tid, således der vil være tid afsat i tilfælde af problemer opstår under udviklingen. De første iterationer bør derfor anvendes til præcisere og forstå den samlede opgave, og indsamle statestik for projektet. Til at indsamle information om tidsestemeringer anvendes caseværktøjet X-planner, som kan tracke den enkelte udviklers opgaver. Egne erfaringer Selvom vi hver gang estimerede tiden der skulle anvendes til en opgave, ved brug af X-planner, viste det sig ofte at være utilstrækkelige estimeringer. Som det forholder sig med de este metoder og værktøjer, hvor der skal vurderes ud fra egen erfaring, gør det beslutningerne usikre, hvis disse erfaringer ikke er på et niveau hvor der kan estimeres ud fra disse. Dette gør sig især gældende i uddannelses sammenhæng, da det i de este tilfælde er første gang en bestemt metode, eller værktøj anvendes. Ydermere skyldes denne usikkerhed samtidig også vores manglende erfaring med forskellige aspekter af Java. Specielt GUI delen har været problematisk at estimere, på trods af anvendelse af

52 6.2 Opsummering 6 Estimering og usikkerheder graske udviklingsvæktøjer. Det viser sig ofte ved specikke Java klasser der bruges til at styre grak. Disse opfører sig ikke konsistent igennem forskellige nedarvninger på trods af nedarvnings principperne i Java. Et eksempel på dette var, da vi skulle opdatere et tekstfelt hvilket kunne gøres umiddelbart, hvorimod det var fuldstændig anderledes metoder der skulle anvendes når vi anvendte tabeller. Sådanne problemer har været udfordrende at forudsige, fordi vi ikke har tilstrækkelig erfaring med de graske komponenter i Java, samt dokumentationen tager tid at sætte sig ind i. 6.2 Opsummering Det lykkedes aldrig at estimere 100%, enten overvurderede eller undervurderede vi opgavens omfang. Problemet bunder til dels i vores manglende erfaring med programmering, da vi derfor mangler en bedre grundlang for at vurdere omfanget opgaverne. Derudover kræves det også at have tilpas mængde statistik om det faktiske tidsforbrug pr. udvikler for at kunne bruge dette til at estimere efter, hvilket ikke lykkedes os at opnå inden for denne projektperiode. Vi anser dog metodens udgangspunkt som anvendelig. Det er dog vigtigt at hver enkelt udvikler trænes til at anvende tidsestimeringsværktøjerne. Ved tilstrækkelig øvelse og en tilpas mængde erfaring forudser vi det som værende muligt at kunne planlægge iterationer samt opgaver til disse. 50

53 . KAPITEL 7 Tanker vedrørende software udvikling Vi vil i dette kapitel, med baggrund i vores essays skrevet i faget Software Filoso, beskrive de tre aspekter af software udviklingsprocessen vi har behandlet i disse. Vi vil redegøre for aspekter omkring de konsekvenser det kan have for en virksomhed at tage ny software i brug. Yderligere behandles der i vore essays, forskellige aspekter af udviklingsmetoden, hvilke vi ligeledes vil redegøre for. Vore essays i fuld form kan ndes i appendix D på side Gidseltagning i Extreme Programming I dette essay behandles forskellige aspekter af den reelle brugbarhed af onsite kunden i XP regi. I essayet hævdes det at brugen af en onsite kunde måske ikke er så værdifuld, idet hele situationen har visse ligheder med en gidseltagning. Yderligere siges det, at hvis situationen kan ses som værende en form for gidseltagning, med en onsite kunde i gidselrollen, kan visse særlige omstændigheder omkring gidseltagning være gældende. Dette kunne være at kunden efter længere tid sammen med udviklerne, som deres gidsel, måske vil begynde at sympatisere med dem. Denne sympati minder om det såkaldte Stockholm syndrom hvor gidsler efter længere tid i selskab med deres kidnappere, udvikler sympati for dem og ikke længere føler at det de gør, er forkert. I sådanne tilfælde vil onsite kunden ikke længere være i stand til at træe objektive valg baseret på virksomhedens reelle behov. Således udviste der sig tvivl om hvorvidt en onsite kunde vil træe de rigtige beslutninger vel vidende, at det ville være til stor besvær for udviklerne. Ligeledes omhandler essayet hvorvidt XP's manglen på grundig analysearbejde, kan opvejes af onsite kundens rolle som en form for organisk kravspeciaktion eller om dette blot fører til ad hoc beslutninger og øjebliks løsninger. Denne påstand underbygges af (Rosenberg and Scott, 2000), idet de hævder at denne mangel på analysearbejde medfører, at hverken kunde eller udvikler forholder sig tilstrækkelig kritisk reekterende til tingene, inden udviklingen

54 7.2 Orden i kaos 7 Tanker vedrørende software udvikling påbegyndes. 7.2 Orden i kaos Orden i kaos behandler de aspekter i udvikling omkring brugerindragelsen i henholdsvis softsystems og hardsystems. XP forkaster analysedelen mod i- stedet at indrage brugerhistorier og dele problemerne op i mindre problemer indtil de er løselige. Udfra dette argumenteres der for at XP ikke bør anvendes som udviklingsmodel for mindre rmaer ud fra egne oplevelser omkring software udvikling. Samtidig repræsenterer XP metoden en faldgruppe for udviklingen idet der gives plads til kundens løbende ændring i kravene, ved gentagende refaktoreringer. Herved bevæger udviklerne sig via en ukendt rute uden noget fast mål og i værste fald kan det resultere i en uendelig løkke af iterationer. Der drages en sammenligningen mellem at udvikle software efter XP metoden og at samle et stue møbel købt i Ikea uden samleanvisning, hvilket i værste fald kan ende ud med et uanvendeligt produkt fordi der tidligt i processen er ikke er oprettet konsensus mellem udvikler og kunde. Det konkluderes at XP ikke fungerer i sammenhæng med små virksomheder og det udviklede software aldrig vil leve op til de behov der ville have været opstillet ved en grundig analyse af hele problemstillingen. 7.3 Konsekvenser af implementering af software Dette essay omhandler tanker vedrørende implementering af software i virksomheder. Essayet starter ud med at omhandle software implementeringer generelt for derefter at fokusere på virksomheden Workout & Fitness. Igennem første del af essayet beskrives motivationen for at opdatere eller implementere nyt software i en virksomhed. Der argumenteres bl.a. for økonomiske gevinster på længere sigt ved implementering af nyt software. Herefter tager essayet fat i aspekter omhandlende virksomhedens personale, der også vil blive påvirket i stor grad af nyt software. Der argumenteres for at ledelsen af virksomheden skal være meget opmærksomme på hvilken type software der implementeres, da en eventuel unødig overvågning kan have negative konsekvenser på det sociale miljø samt arbejdsrutiner i virksomheden.der tages derefter fat på den kommunikationsform, nyt software kan medføre i virksomheden. Her beskriver essayet den kommunikationsform der ndes i virksomheden Workout & Fitness, samt hvordan kommunikationen vil blive påvirket af det nye software der vil blive implementeret. Derefter beskrives 52

55 7 Tanker vedrørende software udvikling 7.3 Konsekvenser... mulige konsekvenser for virksomheds strukturen ved nyt software. Der argumenteres for a softwaren kan overtage mange opgaver der hidtil er blevet varetaget af personer, og derved overødiggøre disse. Dette kan derfor betyde afskedigelser af disse personer. Til sidst konkluderes der på tankerne vedrørende konsekvenserne af implementering af nyt software. Vi argumenterer for at den nye kommunikation i virksomheden vil eliminere mange af de tvivls spørgsmål, samt misforståelser mellem medarbejdere der hidtil har eksisteret i virksomheden. Der argumenteres også for at softwarens opgave er, at varetage trivielle opgaver hvilket derved bevirker at arbejdsrutinerne og dagligdagen i Workout & Fitness både eektiviseres og bliver mindre trivielle. 53

56 7.3 Konsekvenser... 7 Tanker vedrørende software udvikling 54

57 . KAPITEL 8 Acceptance test I henhold til Extreme Programming udføres en acceptancetest af programmet for, at fastslå hvorvidt programmet lever op til kundens krav. Kunden nedskriver derfor en række krav til programmet der skal opfyldes før programmet er færdig. Disse krav har deres udspring i de brugerhistorier der indledningsvis blev udarbejdet af kunden. I vores udviklingsprocess omhandlede disse indledende brugerhistorier både lagerstyring, men også den hjemmeside der var under udvikling. Derfor blev acceptancekravene udformet som en kombination mellem kravene til hjemmesiden og lagerstyringsprogrammet. Det har således aldrig været lagerstyrings programmets opgave, at opfylde alle acceptance test kravene, blot skulle enten de to systemer tilsammen ville opfylde acceptancetest kravene. Acceptance test kravene blev udformet af kunden da vi havde gennemført anden iteration. Grunden til at disse acceptancetest krav først blev modtaget efter anden iteration var delvist fordi kunden ikke havde tid til at udfærdige disse før, og delvist fordi der var blevet refaktureret store dele af programmet igennem hele processen hvilket bevirkede at de indledende brugerhistorier var ændret så meget at vi ikke kunne bruge disse til at udforme acceptancetest krav ud fra. Nedenfor er alle acceptancetest kravene listet og forklaret, samt hvorvidt de understøttes af enten hjemmesiden eller lagerstyrings programmet. 1. Systemet skal regulere lagerstørrelsen i antal baseret på varenummer. Dette er muligt via hjemmesiden, men også i lagerstyrings programmet. 2. Det skal være muligt at indtaste indkøb således at varelageret justeres. Dette krav har vi valgt at anse som værende det samme krav som punkt Det skal være muligt at reservere/låse en artikel til en kunde ved reservation.

58 8 Acceptance test Dette er en salgsopgave og derfor ikke noget der skal styres fra et lagerprogram. Derfor er det kun hjemmesiden der kan reservere et produkt i databasen. Produkter bliver reserveret ved at produkt beholdningen automatisk tælles ned når en vare bestilles. 4. Det skal være muligt at genbruge kundedata til følgesedler og labels. Det er muligt både via hjemmesiden og lagerstyrings programmet at genbruge alt den data der ndes om kunden i databasen. Dog er det kun muligt at printe følgeseddler ud via hjemmsiden på nuværende tidspunkt. Det vil også blive muligt at prite en følgeseddel ud via lagerstyringsprogrammet i en senere iteration. 5. Det skal være muligt at beregne værdien af varelageret baseret på indkøbspris ex. moms. Dette er en funktion der er vigtig både for lageret men også for ledelsen, derfor er det vigtigt at både hjemmesiden men også lager programmet kan vise dette. 6. Det skal være muligt at beregne totalværdien inkl. udstillingsmodeller i forretningen ved status baseret på indkøbspriser ex. moms. Samme som punkt 5. men med mulighed for at medtage værdien af udstillingen i butikken. Det er ikke muligt at se samlet værdi for mere end et sted af gangen. Der adskilles imellem lager og den tilhørende butik. Dette er dog kun en database indstilling der nemt kan laves om, hvilket vil blive refaktoreret i lagerstyrings programmet i en senere iteration. 7. Det skal være muligt at se såvel indkøbspris som salgspris på hver enkelt artikel. Det er muligt at se indkøbspris og salgspris i både lager programmet og på hjemmesiden. 8. Det skal være muligt at se hvilke ordre der er undervejs, samt at lave kommentarer ud for hver enkelt artikel. F.eks. om en artikel er udsolgt hos leverandøren eller er på vej til lageret. Det antages her at der menes ordre udført at Workout & Fitness af bestilling af vare hjem til Workout & Fitness lager. Dette er ikke muligt i lagerprogrammet eller hjemmesiden efter anden iteration. 9. Det skal være muligt at indlægge en basislager nomering, med angivelse af hvor mange stk. af hver artikel der skal være på lager i henholdsvis høj- og lavsæsonnen. 56

59 8 Acceptance test Dette er ikke understøttes i databasen på nuværende tidspunkt, og for at undgå en refaktorering af hele programkernen sent i projektforløbet bliver dette udsat til en senere iteration. 10. Det skal være muligt at lave ere lagre og opgøre værdien af disse særskilt og sammen som punkt 5. Det er muligt via hjemmesiden at oprette nye lagre. Det er også muligt både via programmet og hjemmesiden at se værdien af de separate lagre. Det er dog kun muligt at få den samlet værdi af lagret via lager programmet. 11. Det skal være muligt at muligt at afslutte et salg. Dette er muligt i lager programmet og på hjemmesiden. 12. Det skal være muligt at eksportere regnskab til c5. Dette vil blive muligt på hjemmesiden, men ikke i lager programmet. 13. Det skal være muligt at forbinde til den centrale database. Dette er muligt både på hjemmesiden og i lager programmet. 14. Det skal være muligt at sende defekte produkter tilbage til leverandøren. Dette vil kun blive muligt i lager programmet, men det kræver en central opdatering af databasen. Denne vil blive lavet i en fremtidig iteration. 15. Det skal være muligt at gennemføre et salg. Det er kun muligt at gennemføre et salg via hjemmesiden, da lager programmet ikke skal stå for salg, men eektivisering af salg. Figur 8.1 på den følgende side viser mulighederne i både lager programmet, men også den tilhørende hjemmeside. Det kan ud fra guren ses at det kun er kriterierne 8 og 9 der ikke understøttes nogle steder i programmet eller hjemmesiden efter anden iteration. 57

60 8 Acceptance test Figur 8.1: I tabellen indikere et ueben at kravet er understøttet. Et udråbstegn viser at kravet endnu ikke understøttes. Et minus viser at kravet endnu ikke understøttes og der ikke er et krav for at det skal understøttes i det endelige program. 58

61 . KAPITEL 9 Test Der er en tendens blandt udviklere til at tænke meget mekanisk på software udvikling, hvilket bevirker at der lægges mere vægt på at funktionaliteten virker hensigtsmæssigt. Det er dog også vigtigt at anskue software udvikling fra et brugbarhedmæssigt synspunkt. Således er et vigtigt succeskriterie for softwareudvikling at softwaren virker, her tænkes der ikke kun på de funktionelle krav til softwaren, men også selve brugbarheden af softwaren. Det er derfor vigtigt at teste software for brugbarhedsproblemer. 9.1 Testformål Vi valgte at afholde en brugbarhedstest i Usabilitylab for at identicere brugbarhedsproblemer som kunden måtte have ved brugen af det udviklede system. Derefter ønskede vi at klassicere samt beskrive problemerne og opstille eventuelle løsningsforslag af problemerne ved hjælp af resultaterne fra brugbarhedstesten. XP foreskriver brugen af iterationer og brugermøder, hvilket gør at programmet løbende bliver vurderet af kunden i samarbejde med udviklerne. Denne form for gennemgang gør, at udviklerne kan fange en del problemer og misforståelser, som brugeren måtte have omkring programmet, under og mellem de forskellige iterationer. Selv om vi testede gennem iterationer, ønskede vi stadig kunden afprøvede vores program når det er færdigt, så vi identicerede problemer med henblik på brugbarhed, da det har stor betydning for kunden at produktet er intuitivt og brugbart. Vi gennemførte en brugbarhedstest og opstillede derefter en prioriteret tabel over mulige brugbarhedsproblemer, se gur 9.3 på side 65. Som ved videreudvikling af programmet kunne fungere som en prioriteringstabel over problemer der kan afhjælpes i fremtidige versioner.

62 9.2 Teori 9 Test 9.2 Teori Vi fulgte Jerey Rubins vejledning for en tænkehøjt-test da vi udførte vores brugbarhedstest (Rubin, 1994, s ). I denne vejledning fremhæves punkter for hvordan sådanne tænkehøjt-test skal udføres. Af disse fremhæver vi, at vi ikke må redde testpersonerne hvis de har problemer med at gennemføre en opgave, samt at vi skal sikre os at testpersonen er færdig med en opgave før der påbegyndes en ny opgave. Ved at huske på dette under testen er det vores overbevisning at testen bliver udført på en måde der sikrer at alle opgaver bliver gennemført af testpersonen, og derved kan vi danne os et bedre billede af brugbarheden af programmet. Det er dog stadig klart at selvom disse to punkter bliver fremhævet ønsker vi stadigt at overholde alle aspekter at tænkehøjt-test i g. (Rubin, 1994, s ). Til identicering af de fundne problemer i brugbarhedstesten har vi anvendt skema 9.1. Ud fra dette skema blev de enkelte problemer kategoriseret ud fra log-materialet, som enten værende kosmetisk, alvorlig eller kritisk. Ved kosmetiske problemer oplever testpersonen mindre forsinkelser og forundring i programmet. Ved alvorlige problemer oplever testpersonen forsinkelser på op til ere minutter og programmet strider i høj grad med brugerens forventning og forståelse. Et kritisk problem opstår når testpersonen møder et problem der forhindrer testpersonen i at gennemføre opgaven eller i sådan en grad strider med testpersonens forventning at vedkommende ikke kan fortsætte. Møder mere end en testperson det samme kritiske problem bliver dette problem efterfølgende katagoriseret til at være en brugbarhedskatastrofe. Figur 9.1: Skema til katagorisering af fundne problemer Opstilling af test Til udførelsen af brugbarhedstesten blev der anvendt Usabilitylab med det dertilhørende optagelsesudstyr. Rollefordelingen under testene inkluderede 60

63 9 Test 9.3 Fremgangsmåde en testleder, en teknisk ansvarlig, to loggere og en observatør. Testen blev udført på en bærbar computer tilsluttet Usabilitylabs udstyr og kunne derigennem forbindes til internettet, så der kunne skabes kontakt til databaserne. De to loggere blev udstyret med hver sin computer til notering af observationer under testen og observatøren blev placeret i teknikrummet for bedre at kunne have overblik over de enkelte tests. Testpersonerne blev til gennemførelsen af testen stillet en række opgaver og spørgsmål som kan ndes i Appendiks C.1 på side 82. Brugbarhedstesten blev udført ved hjælp af 4 testpersoner, hvis demograske data kan ndes i C.3 på side 82. Disse testpersoner repræsenterede dog ikke de endelige brugere af systemet. 9.3 Fremgangsmåde Testen blev udført i Usabilitylab, hvor der er mulighed for audio- og videoobservation, samt mulighed for resten af gruppen at observere uden at forstyrre udførelsen af testen. For en illustration af Usabilitylab, se gur 9.2 på næste side. Disse observationsmuligheder gjorde vi selvfølgelig brug af, men idet rammen for semestret ikke er brugbarhedstest, valgte vi ikke at lave en dybere analyse af det indsamlede materiale, men anvender det materiale loggerne indsamlede og fortolkede sideløbende med testen. Indsamlet audio- og videomateriale tages dog i brug hvis der skulle opstå uklarheder omkring testen eller forskel i loggernes fortolkning af et identiceret problem. Testlederen, som også fungerede som kontaktperson mellem testpersonerne og de øvrige gruppemedlemmer, startede med at byde testpersonerne velkommen og introducerede dem til selve testen. Det var vigtigt at testlederen k testpersonerne til at slappe af og føle sig trygge ved situationen og de kommende opgaver. Testpersonerne k efterfølgende udleveret de enkelte opgaver, efter testlederen havde introduceret dem til testen. Testen blev sluttet af med at testpersonerne blev udspurgt til deres holdning og oplevelse af programmet. Testen logges af to personer der skriver noter på computer i det tilstødende lokale. Loggerne noterede også hvordan testpersonerne reagerede på de givne opgaver og hvordan vedkommende valgte at gribe dem an. Da disse notater senere ville ligge til grunde for den efterfølgende analyse fandt vi det også vigtigt at bruge to forskellige loggere, samt en observatør der under testen havde det gyldne overblik. Hvis der i den efterfølgende analyse ville komme uoverensstemmelser i loggernes og observatørens fortolkninger, ville vi kunne anvende det indsamlede audio- og videomateriale som reference. 61

64 9.4 Resultater 9 Test 9.4 Resultater Figur 9.2: Opstilling i Usabilitylab Resultatet af vores brugbarhedstest endte ud i ti identicerede brugbarhedsproblemer katagoriseret til et kritisk problem, fem alvorlige og re kosmetiske. Den samlede liste af problemer er vist i listen 9.3 på side 65 og er listet efter deres alvorlighed, samt hvilke testpersoner der fandt dem i de enkelte opgaver. Vi vil nu beskrive hvordan de enkelte problemer opstod og hvad de indebar. Problem #1: Færdiggørelse af ordre Katagoriseret til at være kritisk. Testpersonen kunne ikke gennemskue hvilken del af programmet der håndterede udførelsen og afslutning af indgående ordre. Testpersonen begyndte at søge programmet systematisk igennem i et forsøg på at nde de rigtige oplysninger og en testperson opgav til sidst. Problem #2: Redundant data Katagoriseret til at være alvorlig. Testpersonen skulle nde et produkt på et givent lager i systemet, men kunne ikke gennemskue hvor i systemet vedkommende kunne nde de rigtige data. Testpersonen var i tvivl om opgaven var fuldført, men valgte at gå videre. Problem #3: Ikonfortolkning af complete order Katagoriseret til at være alvorlig. Flere testpersoner misforstod betydningen 62

65 9 Test 9.4 Resultater af ikonet for complete order. Dette gjorde at ere af testpersonerne overså denne knap ved udførelsen af opgaven og antog at den havde en anden betydning. Først efter forgæves søgning i andre dele af programmet k testpersonerne afkodet betydningen bag dette ikon. Problem #4: Tilføje nye produkter til lageret Katagoriseret til at være alvorlig. Under tilføjelsen af et nyt produkt til lageret, blev en af testpersonerne meget forvirret, da vedkommende ikke kunne nde nogen information om hvilket lager han på daværende tidspunkt lavede ændringer i. Testpersonen forsøgte at gå tilbage til menuen over varehus status for at lave ændringen der, men var ikke sikker på om dette var den rigtige måde at løse opgaven på. Problem #5: Usikkerhed i opdatering Katagoriseret til at være alvorlig. Ved udførelsen af en opdatering i databasen kom testpersonen meget i tvivl om ændringerne var blevet foretaget. Testpersonen kunne ikke gennemskue at de nye ændringer både var synlige i Product reception og i Warehouse status. Testpersonen søgte begge menuer igennem uden at få den bekræftelse som vedkommende manglede. Problem #6: Mange data på nogle skærmbilleder Katagoriseret til at være alvorlig. Dette problem oplevede testpersonen gentagende gange i ere af opgaverne i brugbarhedstesten. Ved gennemførelsen af opgaverne oplevede testpersonen ere gange at mængden af data og information på de forskellige skærmbilleder var overvældende. En mangel på forklaring af de forskellig tabeller ledte ere gange til misforståelser. Problem #7: Cancel knap i Order new article Katagoriseret til at være kosmetisk. Under Order new article menuen forsøger brugeren at anvende cancel knappen til at vende tilbage til programmets forside. Denne knap fungerede ikke og testpersonen benytter efter ere forsøg tilbage knappen i stedet for. Problem #8: Pop-up besked ved Deliver order Katagoriseret til at være kosmetisk. Flere af testpersonerne oplevede ved afsluttelse af Deliver order at de k bekræftelses beskeden bagved det primære programvindue. Dette pop-up vindue burde i stedet altid være i forgrunden. Problem #9: Printning af Complete order Katagoriseret til at være kosmetisk. Ved udprintning af en ordre fra Com- 63

66 9.4 Resultater 9 Test plete order menuen, giver programmet ingen feedback om denne handling bliver gennemført. Problem #10: Startsiden Katagoriseret til at være kosmetisk. En testperson kommenterende under testen at vedkommende fandt opbygningen af startsiden uoverskuelig. Dette gjorde at vedkommende havde svært ved at navigere igennem programmet. Vi vil i følgende afsnit kort gå i dybden med enkelte af de fundne brugbarhedsproblemer, da vi føler at disse giver et vigtigt indblik i de ændringer der bør refaktoreres i programmet eller havde stor betydning for testpersoners oplevelse af programmet. Problem #1 viste at testpersonerne havde et problem med at gennemføre og afslutte en ordre i programmet. Dette problem er tæt relateret til problem #3 hvor testpersonerne ikke kunne fortolke betydningen af ikonerne på forsiden. Denne faktor gjorde at mange af testpersonerne ignorede "complete order"på forsiden af programmet da de blev bedt om at løse denne opgave. Ved afslutningen af testen kommenterede en testperson også at vedkommende i starten automatisk antog at denne knap var en form for accept knap på grund af ikonet, som var et grønt ueben. Dog kunne denne sammenhæng også være grundet i, at testpersonerne ikke havde et stort nok kendskab til virksomheden og deres gøremål. Vi kunne i testen se at ere af testpersonerne var forvirrede over at de skulle færdiggøre en ordre før de overhovedet havde oprettet en. Ud fra beskrivelsen af resultaterne fra spørgsmål re, kan vi se, at konsistensen omkring valg af selve lageret skal forbedres. I opgave et skulle der vælges et lager inden brugeren kunne se status for lagerartiklen på det pågældende lager. Testpersonerne oplevede derefter inkonsistens mellem denne opgave, og opgave re hvor lageret skulle opdateres, idet der i denne opgave ikke skulle vælges lager, hvilket førte til alvorlige problemer. Grundet virksomhedens beslutning om refaktoreringen af databasen på et sent tidspunkt i udviklingen bevirkede det at der kun blev udviklet til understøttelse af ét lager i lager-opdaterings delen af programmet, derved skulle der ikke vælges lager. Dog blev andre dele af programmet udviklet efter denne refaktorering og dermed understøttede disse dele af programmet den nye struktur i databasen. I ere opgaver anså testpersonerne feedback fra programmet som værende mangelfuldt eller fraværende. Der tænkes her på problem #9 fra opgave tre, 64

67 9 Test 9.5 Test overvejelser hvor testpersonen skulle printe noget ud fra systemet. Print rutinerne er noget der sker mange gange i løbet af en dag ved brugen af lagerstyringsprogrammet og vi anser derfor denne funktion som værende vigtigt. Da printerfunktionen ikke var implementeret under testen, gav den ikke feedback til testpersonen hvilket burde overvejes til den endelige version af programmet, da feedback er en naturlig del af brugervenlig interaktion. Testpersonen blev dog gjort opmærksom på denne funktion ikke virkede under testen, så irritationen ville være minimal. Figur 9.3: Fundne og klassicerede problemer fra brugbarhedstesten 9.5 Test overvejelser Et andet kritikpunkt af vores brugbarhedstest er testpersonernes manglende viden og erfaring med Workout & Fitness' arbejdsrutiner og virksomhedsstruktur. Igennem vores test var der ere indikationer på at testpersonerne manglede indblik i Workout & Fitness' arbejdsrutiner for at kunne gennemføre de pågældende opgaver. Problemet vi her tænker på er problem #1 hvor testpersonerne bliver bedt om at skulle gennemføre en ordre. Vi kunne have søgt at afhjælpe dette problem ved at orientere vore testpersonerne mere om Workout & Fitness' arbejdsopgaver og rutiner. Derigennem kunne vi have tilstræbt at gøre vore testpersoner mere lig slutbrugerne af programmet. 65

68 9.6 Konklusion 9 Test 9.6 Konklusion De fundne problemer under testen har vi placeret i gur 9.3 på foregående side. I brugbarhedstesten fandt vi ti problemer, fordelt på fem alvorlige, et kritisk og re kosmetiske. Generelt kan vi med denne test af programmet forstå hvor vigtigt det er, at have testpersoner fra den rigtige demograske gruppe, når man skal teste branchespecikke elementer i et program. Dog mener vi stadig, at generelle brugbarhedsaspekter kan blive afdækket vha. testpersoner der ikke passer ind i den demograske slutbruger gruppe. Vi har igennem hele processen forsøgt at få programmet til at ligne og opføre sig som et normalt windows program, hvorved majoriteten af folk med større eller mindre IT-kendskab for således at gøre disse bedre i stand til at genkende funktioner. Således kan vi at konkludere at programmet lever op til de krav der er blevet stillet fra Workout & Fitness. Denne konklusion er baseret på det faktum, at de fundne fejl vil blive rettet i senere versioner af programmet. 66

69 . KAPITEL 10 Diskussion Gennem dette projekt har der rejst sig forskellige spørgsmål og overvejelse med hensyn til brugen af den valgte udviklingsmetode, som ikke direkte relaterede til vores projekt. Disse har vi således ikke behandlet igennem rapporten men ønsker nu at belyse nogle af disse overvejelser Samme projekt, to fremgangsmåder Gennem udviklingsforløbet har der været ere overvejelser omkring brugen af XP i forhold til, at vores kunde har været en relativ lille virksomhed med begrænsede ressourcer. Dette har givet anledning til forskellige overvejelser omkring valget af udviklingsmodel; Hvordan ville forløbet have været såfremt vi fra starten af projektet havde inddelt os i to halvgrupper hvor den ene fulgte en traditionel objekt orienteret analyse og design(ooad) metode, og den anden XP? Vi kunne således have undersøgt hvorvidt kundens begrænsede ressourcer ville have kommet til udtryk på forskellig vis, gennem to forskellige udviklingsmetoder. Således kunne det undersøges hvorvidt man gennem en OOAD metode ville have været i stand til, gennem et omfattende analysearbejde, at have styret uden om de problemer den manglende kundekontakt i XP medførte i vores tilfælde. Det kunne ligeledes have været interessant efterfølgende at sammenholde resultatet af de to forskellige udviklingsforløb i forhold til det endelige produkt. Hvilket af disse produkter ville have været bedst i overensstemmelse med kundes krav. Det kunne ligeledes være interessant at se i hvor stor grad de to gruppers opfattelse af problemet ville stemme overens, for således at kunne sammenligne brugen af brugerhistorier kontra kravspecikation. Efterfølgende kunne en brugbarhedstest af begge de resulterende produkter, afsløre hvorvidt den løbende kundekontakt i XP er med til at reducere antallet af brugbarhedsproblemer i produktet. Man kunne ligeledes undersøge hvorvidt to forskellige udviklingsmetoder ville resultere i en mærkbar forskel i tidsforbrug. Således

70 10.2 Samme fremgangsmåde andet projekt 10 Diskussion ville man kunne afprøve hvorvidt XP praksisen om at undlade traditionel analyse og design arbejde, i virkeligheden reducerer det faktiske tidsforbrug, eller blot ytter det til senere i udviklingsforløbet Samme fremgangsmåde andet projekt Vi har overvejet hvordan et XP projekt ville have forløbet med en større virksomhed, med ere ressourcer til rådighed, som samarbejdspartner, idet vi mener det kunne være interessant at gennemføre endnu et udviklingsforløb efter XP med en sådan virksomhed. Efter et sådant forløb ville vi således være i stand til at sammenholde erfaringerne fra dette, med de erfaringer vi har gjort gennem dette projekt. Efterfølgende kunne metodekritikken fra de to forløb sammenholdes, for derved at undersøge hvor stor betydning den mængde ressourcer virksomhedens er i stand til at allokere, reelt set, har for projektet. 68

71 . KAPITEL 11 Konklusion I dette projekt ønskede vi at undersøge hvordan en applikation til at integrere delsystemer i en virksomhed udvikles efter udviklingsmetoden XP, i overensstemmelse med dette semesters tema om brugerinddragelse i udviklingen. Dette har resulteret i en delkomponent til et system der igennem to iterationer er gået fra ideer og tanker opsamlet ved brugermøder, til et program, i stand til at interagere med virksomhedens database og dermed også virksomhedens hjemmeside. Udfra erfaringer dannet i dette projekt kan vi konkludere at XP som metode til udvikling af software kun bør anvendes som udviklingsmodel forudsat virksomheden er i stand til at stille tilstrækkelige ressourcer til rådighed. Derfor har det ikke været en proces uden problemer, idet samarbejdet med kunden til tider har været begrænset, som følge af at Workout & tness er en forholdsvis lille virksomhed med begrænsede ressourcer. Således kan vi udlede at XP som udviklingsmetode ikke er det ideelle valg, når samarbejdspartneren er en mindre virksomhed med begrænsede ressourcer. Dette er tilfældet, idet XP praksisen om at have en onsite kunde til stede under udviklingsforløbet, naturligvis besværliggøres når kunden ikke har ressourcer til dette. Ydermere kan vi konkludere at XP giver et væsentligt anderledes programdesign sammenlignet med f.eks. OOAD metoder, idet en mangel ved XP må siges at være en bedre anvendelse af OOP, da brugerhistorier ikke fokuserer på objekt orienteret design. Vi har erfaret at dekomponering af problemstillinger gennem divide & conquer bør anvendes med forsigtighed, idet det samlede overblik over systemet hurtigt går tabt. Kundekontakten i XP, samt den dertilhørende udarbejdelse af brugerhistorier, er en disciplin som behøver træning for både kunde og udvikler, for at frembringe de bedste resultater. For at kunne opnå bedre brugerhistorier,

72 11 Konklusion bør der afsættes tid og ressourcer på at forstå kunden. Brugerhistorier kræver indlevelse i kundens hverdag for, i nødvendig grad, at forstå opgavens omfang. Vi må konkludere at dette ikke kan erhverves, i tilstrækkelig grad, hverken ved brug af MSN Messenger samtaler, eller et re timers besøg hos kunden, men bør opnås over ere dage. XP har fungeret hensigtsmæssigt i forbindelse med identicering af kravene til systemet ved hjælp af brugerhistorier, idet det tilsyneladende er nemt for kunden at forklare de nuværende arbejdsgange, derved kan vi som udviklere udlede krav til produktet i samarbejde med kunden. Som en del af brugerindragelsen i projektet, valgte vi at foretage en usability test, i form af en tænke-højt test. I denne test afdækkede vi ti brugbarheds problemer fordelt på: ét kritisk, fem alvorlige samt re kosmetiske brugbarhedsproblemer. Enkelte af brugbarhedsproblemerne mener vi til dels skyldes testpersonernes manglende indsigt i forretningsgangene hos kunden, idet en sådan viden kunne have givet nogle bedre forudsætninger for løsning af testopgaverne. Vi må konkludere at med den viden vi gennem dette projekt har tilegnet os omkring XP og brugerindragelse, ville vi ikke vælge metoden igen i lignende problemstillinger. Vi mener metoden har sin berettigelse hvor kundens ressourcer tillader at der kan afsættes tilstrækkelig tid, eller at udviklingen eventuelt kunne foregå hos kunden. 70

73 . KAPITEL 12 Fremtidig arbejde Efter det kendskab samarbejdet med Workout & Fitness har givet os, gør dette os i stand til at fremsætte følgende fremtidsvisioner for vores program Fremtiden for vores program Fremtidige versioner af produktet kunne indeholde mere end selve lagerstyringen. Det er ønsket fra kunden, at programmet skulle udvides til at kunne im- og eksportere data fra økonomisystemet, Microsoft C5, hvilket var planlagt at de skulle opgradere til. Det kunne endda være tænkeligt, at programmet kunne udvides så kraftigt, at det ville være unødvendigt at benytte ere applikationer til forskellige opgaver. Så selve lagerstyringsprogrammet ville have funktioner og muligheder lignende C5, der derved gjorde det nuværende økonomistyring overødig. Dermed ville programmet ikke længere blive betegnet som et lagerstyringsprogram, men en helt system, indeholdende lagerstyring, økonomistyring samt diverse administrationsfunktioner, skræddersyet specielt til virksomheden Workout & Fitness.

74 12.1 Fremtiden for vores program 12 Fremtidig arbejde 72

75 Litteratur. Kent Beck. Introduktion til Extreme Programming. IDG FORLAG, , Stephen Biering-Sørensen, Finn Overgaard Hansen, Susanne Klim, and Preben Thalund Madsen. Håndbog i Strukturet Programudvikling. Ingeeniøren bøger, , Alistair Cockburn and Laurie Williams. Programming, Steinar Kvale. InterView. Hans Reitzels Forlag, The Costs and Benets of Pair Craig Larman. Agile and Iterative Development. Pressman, , Doug Rosenberg and Kendall Scott. XP: Cutting thourgh the hype, Jerey Rubin. Handbook of Usability Testing. John Wiley & Sons, Matt Stephens. The Case Against Extreme Programming, Edward Tufte. The visual Display of Quantitative Information. Graphics Press, Don Wells. What is Extreme Programming? extremeprogramming.org/what.html, 1999.

76 12.1 Fremtiden for vores program 12 Fremtidig arbejde 74

77 . APPENDIKS A Mødeprogram Dato: Dagens program Der fortælles kort om hvad der skal ske, og varigheden bliver ca. 3 timer Brugerhistorier Teori - Thomas har fået tilsendt kapitlet om kundens rolle fra Beck's bog, så teorien skal sættes i relation hertil. Hvordan det skal foregå, herunder at der skal skrives en handling på hver seddel, samt at prioritere hvilke funktioner/handlinger som er vigtigst at få med, og hvilke kan udskydes til næste iteration hvis det bliver nødvendigt. Prototype Userinterfaces Foregår ved at tegne det på papir, skitser. Der anvendes UML/owcharts til at forklare vinduernes gang i programmet. Punktet om UML vil ikke fylde særlig meget på dette, møde da det højst sandsynligt først blive fra 2. iteration det bliver vigtigt. Customer test / acceptancetest. Hvad kræves der for at programmet er færdigt - Hvad er succes kriteriet for næste iterations funktionaliteter, og måske det samlede program hvis det er tydeligt allerede på nuværende tidspunkt.

78 76 A Mødeprogram

79 . APPENDIKS B Brugerhistorier Dato: Vi har noteret os følgende fra samarbejdet med virksomheden Workout & Fitness. Vi noterer os at der lægges meget vægt på at arbejdsprocesserne behøves eektiviseret og ønskes at være rationelle. Problemstillingen i virksomheden ligger meget i at der ndes meget redundant arbejde, hvor de samme data indtastes ere gange. Kunden lægger derfor vægt på at netop de processer optimeres. Kunden ønsker derfor, for virksomheden, et modul således at når bestillingen er foretaget af kunden, at han ikke behøves at indtaste kundens data igen. På fjernlageret i Flensborg skrives der i øjeblikket manuelt følgesedler og fakturaer ud, som vedlægges den bestilte vare. Denne proces ønskes automatiseret således at fjernlageret kun behøver at trykke på en knap hvorefter de nødvendige udprintninger sker og der automatisk sendes mail til kunden med vigtige oplysninger omkring afsendelse. Kunden oplever i øjeblikket at meget af hans tid går med at snakke med kunder, som ikke har modtaget deres varer, og ønsker status for hvornår de er ekspederet. Ved at kunden selv kan undersøge forsendelsesoplysningerne mener kunden at unødige opkald vil formindskes. Kunden forestiller sig der sendes en mail til kunden med forsendelsesoplysninger indeholdende et track & trace nummer på ordren. Der forsøgtes at udarbejde en brugerade i samarbejde med Kunden. Kunden's erfaring og fantasi begrænser ham til hvordan systemet bør se ud. Der aftales derfor at vi kommer med forslag, som diskuteres. Der er derfor blevet valgt, at vi ud fra punkterne forsøger at udarbejde de nødvendige brugerader og sender dem til evaluering hos kunden. Ved gennemgang af de enkelte punkter har vi fået en god indsigt i hvad systemet skal indeholde og kunne.

80 B Brugerhistorier Det besluttes sammen med kunden, at vi påbegynder lagerdelen og track & trace systemet. Til udarbejdelse af dette, har vi modtaget papirer på h- vordan nuværende lagersystemer fungerer i virksomheden. Det fungerer ved at Flensborg afdelingen udarbejder vareoptæling og indskriver det i et excel ark som tilsendes til Thomas en gang om ugen. Fordi den nuværende struktur med lageroptælling umiddelbart vil kunne implementeres i en SQL database besluttes det at fortsætte denne struktur, og lægge den i en SQL. 1. Genanvendelse af data Bestilling fra kunde Faktura Fragtbrev Afsenderlabels 2. Fra bestilling til track & trace Bestilling Ordrebekræftelse Betalingsadvis fra PBS Faktura Vareafsendelse Track & trace hos fragtrma 3. Automatisk varebestilling baseret på Varelagerets størrelse med foruddenerede normtal, januar, februar osv. Hver måned forudenerers med betegnes som index 100, hvor en salgstigning så måske vil resulterer i bestilling af næste måneds varelager idekseret til 123. Statistik varebetegnelse afgang Tilpasset efter omsætningsudvikling med tilhørende indeksering 4. Lagerstørrelse Web-visning af antal på lager Leverandørafgivne ordre med tilgang Lagerindgang med opdatering af økonomisystem og web 78

81 B Brugerhistorier 5. Udlejning Oversigt over udlejet udstyr info om Varetegnelse Varenummer Udlejningsmåned / år Vejl. pris Leje pris pr. måned Nedskrivningsværdi udregnet fra vejl. pris med 25% rente opgjort pr. måned Udlejningsstatestik fra sidste år med varebetegnelse opgjort pr. måned Progressiv stigning skal påvirke inkøbsstørrelse Til mødet bemærkes det tidsmæssige pres fra kunden's side, med løbende telefoner der ringede. Det kunne måske være ønskeligt med mere tid på virksomheden, men det er desværre ikke muligt at afsætte mere tid. Kontakten ugen igennem forsøges at holdes så tæt som muligt ved at anvende telefon og . Brugerhistorier på tekstform Når en kunde skriver personlige data på en bestilling, bliver disse sendt til mig i en . Disse data skriver jeg derefter ind i et pdf dokument og sender denne til lageret i tyskland. Derefter føres kundes personlige data in i vores regskabsprogram. Når en kunde afgiver en ordre, skal vi selv manuelt udsende en ordrebekræftelse. Herefter udfyldes kundes data i en faktura, der sendes med produktet når det forlader varelageret. Bestilling til varelager foregår ved hjælp af et excel dokument. Når der er mangler på lageret bliver de pågældende produkter nedført i et exceldokument, der herefter sendes til vores leverandører via . Antallet vurderer vi selv. For at få en lagerstatus ringer jeg til Lageret og beder om en manuel optælling af lageret. herefter udarbejder de en lagerstatus i et excel dokument som de sender til mig på mail. 79

82 B.1 Interview guide B Brugerhistorier Udlejning af udstyr styrer vi i øjeblikket ved hjælp af gammeldags papirarbejde. Vi har en mappe hvor vi har oversigter over hvem der har lejet hvad for noget udstyr, samt et sæt regler for hvor meget nedskrivning diverse udstyr skal have efter en given tid. B.1 Interview guide Kan du Fortælle lidt om virksomhedens struktur. Hvordan forgår kommunikationen, kan du eventuelt tegne og skrive det? Hvordan håber du denne tegning vil se ud med det nye system, og kan du tegne og skrive det? Kan du forklare hvordan en typisk arbejdsdag foregår, hvilke arbejdsopgaver du har osv. Hvilke arbejdsopgaver tager mest af din tid i dagligdagen? Hvilke arbejdsopgaver gentager du est gang i løbet af en dag? Hvilke ønsker har du til et system i virksomheden? Er der nogle specikke arbejdsgange / rutiner du gerne ser optimeret gennem systemet? 80

83 . APPENDIKS C Introduktion til test Jeg vil gerne starte med at takke dig for at du vil hjælpe os med at gennemføre denne test omkring vores system. For at gøre spørgsmålene lettere at huske vil jeg udlevere spørgsmålene til dig et for et, for at være sikker på at jeg husker det hele og får givet de samme oplysninger til samtlige testdeltagere. Det system du skal hjælpe os med at teste er et lagersystem placeret i Flensborg, som er tiltænkt en distributør af tnessudstyr med navnet workout & tness. Systemet er ikke færdigudviklet så visse funktioner vil ikke være tilgængelige når du bruger systemet. Dette skal du ikke bekymre dig om, Jeg skal nok gøre dig opmærksom på disse. Testen forløber på den måde, at du får stillet et antal opgaver som du skal forsøge at løse ved hjælp af systemet. Jeg vil bede dig om at løse opgaverne på følgende måde. 1. Først læser du opgaven højt, 2. derefter fortæller du mig hvordan du forstår opgaven, 3. og til sidst går du i gang med at løse opgaven. Mens du løser opgaven vil jeg gerne at du tænker højt. Det betyder at du skal sige, hvad du har tænkt dig at gøre og hvad der evt. overrasker dig samt hvad du tænker under selve testen. Jeg ved godt at det ikke er naturligt at sidde og snakke højt så derfor vil jeg minde dig på det hvis du skulle glemme det. Hvis du får problemer undervejs må du gerne spørge mig, men jeg vil nok ikke hjælpe dig direkte, jeg vil i stedet forsøge, at få dig til at komme videre selv. Det skal også nævnes, at det ikke er dig vi tester, men systemet. Når du er færdig med en opgave vil jeg bede dig sige til så jeg ikke er i tvivl. Inden vi går igang vil jeg gerne hvis du vil læse denne samtykkeerklæring grundig igennem og underskrive den hvis du er indforstået med den, så testen kan begynde! (Følgende billede illustrere et eksempel på en underskrevet samtykkeerklæring C.1 på side 83)

84 C.1 Testspørgsmål C Introduktion til test C.1 Testspørgsmål Testspørgsmål: En kunde kommer ind i butikken og forespørger nogle 1,25kg, 30mm vægtskiver. Er denne vare på lageret i Flensborg? Hvad er fragtprisen på et dips stativ Delta? Du ønsker og nde oplysninger om kongurationen af programmet. Hvilken server adresse benytter programmet til at forbinde til serveren? Giver systemet dig noget information om de indtastede oplysninger er korrekte? Du har lige færdigpakket en ordre, og er nu klar til at afsende denne til kunden. Fuldfør ordren, med tilhørende ordre ID: Hvad er den pålydende værdi af ordre ID: ? Print ordren og gå til forsiden for at afslutte. Der er lige kommet en ny sending varer ind fra din leverandør. Dette indebærer 5 stk. Kettler Match Pro. Tilføj dette antal til lageret. Hvor mange af disse varer burde der i alt på lager nu? Udsende Virker systemet overskueligt? Finder du det ønskede information for at gennemføre opgaven? Var der et spørgsmål der virkede ulogisk eller udfordrende? C.2 Samtykkeerklæring C.3 Demogrask data af testpersoner 82

85 C Introduktion til test C.3 Demogrask data af testpersoner Figur C.1: Samtykkeerklæring Figur C.2: Demogrask data 83

86 C.3 Demogrask data af testpersoner C Introduktion til test 84

87 . APPENDIKS D Essays fra Software loso Herefter følger vore essays, skrevet i faget software loso, i fuld længde. D.1 Gidseltagning i Extreme Programming? Et essay i Software Filoso Lavet af: Lars Christiansen & Alex Ranch I traditionel systemudvikling er analyse i forbindelse med en kravspecikation en meget vigtigt del af udviklingsprocessen. Gennem grundig analyse udarbejder man således et dokument i samarbejde med kunden, som således ligger til grund for den videre udvikling efter devisen godt begyndt, er halvt fuldendt. I XP søger man at overødiggøre denne analysefase, og springe mere hovedkulds ud i udviklingsprocessen, ved at gøre brug af en såkaldt onsite kunde. Denne onsite kunde skal indgå som et medlem af udviklingsgruppen som en slags organisk kravspecikation, med erfaring og beføjelser til at træe afgørende valg på virksomhedens vegne. Altså skal denne onsite kunde fraytte sin normale arbejdsplads og ytte ind sammen med udviklingsholdet, gennem hele udviklingsforløbet. Dette synes at være en udmærket ide, idet programmørerne hele tiden kan få besvaret spørgsmål ved løbende at rådføre sig personligt med den onsite kunde. Men; er denne dobbeltrolle hos onsite kunden i virkeligheden ikke en interesse konikt, idet vedkommende vil stå med et ben i hver lejr. Altså lidt som en lus mellem to negle, idet onsite kunden både har et ansvar over sin virksomhed som jo er hans egentlige arbejdsplads, men også over for udviklerne som vedkommende skal arbejde tæt sammen med gennem hele projektforløbet som sagtens kan strække sig over lang tid. Hvis man ser på en denition af et gidsel: En person som tilbageholdes af den ene part i en konikt, som sikkerhed for at deres krav tilfredsstilles af den modstående side.

88 D.1 Gidseltagning i Extreme Programming? D Essays fra Software loso - passer det egentligt ret godt på denne situation; Onsite kunden er nærmest udviklernes gidsel, idet vedkommende er tvunget til at være hos udviklerne gennem hele forløbet. Onsite kunden holdes altså som gidsel af udviklerne, indtil deres krav er tilfredsstillet af den modstående side, nemlig at applikationen godkendes. Onsite kunden er i den, for et gidsel, lidt unikke situation at han repræsenterer den modstående side, og kan derfor være med til at tilfredsstille de krav som udviklerne stiller. Derfor er det ikke en direkte kon- ikt mellem udviklerne og den virksomhed onsite kunden tilhører, men en indirekte konikt, hvor virksomheden måske slet ikke opdager noget. Onsite kunden vil måske i denne situation være tilbøjelig til føje udviklerne, og derved muligvis tilsidesætte virksomhedens krav for at tilfredsstille udviklerne, eller som en form for sympati for udviklerne og deres arbejde. Hvis nu det hele mest af alt virker som en gidseltagning, bliver hele situationen pludselig anderledes. Man kunne forestille sig at der ville opstå et specielt forhold mellem udvikler og onsite kunden. Dette forhold kunne minde om det såkaldte Stockholm syndrom hvor en person, i dette tilfælde onsite kunden, efter nogen tid i en gidselsituation opbygger sympati for sine gidseltagere (udviklerne). Alt dette leder os frem til følgende: Er en onsite kunde i extreme programming ikke et gidsel der handler efter andet og mere end virksomhedens interesse? Og i så fald, hvor brugbar er informationen fra en onsite kunde så i virkeligheden? Hvis et menneske lidende af Stockholm syndrom, som millionær arvingen Patty Hearst, kan tvinges til at gøre noget så ekstremet som at røve en bank, hvor urealistisk er det så at tro at en onsite kunde ikke kan tvinges til at føje udviklerne? Det er trods alt samme principper som Stockholm syndromet meget militær træning foregår efter, hvor igennem det er muligt at få mennesker vil gøre de mest ekstreme ting for hinanden. Det samme gør sig gældende for kulter og religiøse sekter, hvor medlemmer kan overtales til at begå selvmord med hjælp af denne stærke følelse af sammenhørighed. Hvis en onsite kunde er i en situation med to muligheder: 1. Den rigtige løsning for virksomheden han repræsenterer, men som samtidig medfører et kæmpe besvær for udviklerne 2. Den næsten rigtige løsning, som samtidig ikke er den helt ideelle løsning for virksomheden, vil kræve at virksomheden former sig efter applikationen og ikke omvendt, men til gengæld er den mest belejlige løsning for udviklerne. - Vil vedkommende, i et sådant dilemma, så træe en beslutning velvidende, at det vil være til stort gene for udviklerne? Svaret på dette spørgsmål er jo næsten indlysende hvis man holder de evolutionspsykologiske mekanismer 86

89 D Essays fra Software loso D.2 Orden i kaos bag Stockholm syndromet for øje. Hvis dette er tilfældet, hvor nyttefuld er brugen af en onsite kunde så? Reduceres onsite kunden så ikke blot til en syndebuk? Således udviklerne efterfølgende altid kan give onsite kunden skylden hvis virksomheden denne repræsenterer, klager! Yderligere er der vel også en fare for at udviklerne bruger onsite kunden som et ukritisk opslagsværk slåedes de derfor ender med at lave ad hoc løsninger, idet de, i så fald, ikke forholder sig særligt kritisk reekterende. Som det fremgår, ser vi en række uhensigtsmæssigheder ved brugen af en onsite kunde i XP. Man risikerer at træe ad hoc beslutninger som resulterer i dårlige øjebliksløsninger som senere skal refaktoreres som det hedder sig i XP - Altså at man skal lave sit arbejde om. Bliver dette en for omfattende disciplin i projektforløbet risikerer man at den mængde tid man har sparet ved at undlade analyse stadiet, skal betales tilbage med renters rente senere i forløbet. XP indeholder uden tvivl en masse brugbare tiltag til softwareudvikling, men når brugen af en onsite kunde, tilsyneladende er så problematisk, og fejlbehæftet, at den ligefrem deler mange af karakteristikaene ved en gidseltagning, hvad er alternativet så? Dette problem med brugen af onsite kunder kunne måske afhjælpes ved at gøre brugen af denne, mere dynamisk. I stedet for at benytte den samme onsite kunde igennem hele udviklingsfasen, kunne man udskifte onsite kunden ud efter f.eks. en måneds udvikling. Dette ville sandsynligvis minimere sandsynligheden for at noget lignende Stockholm syndromet opstår. Simpelthen fordi der kommer nyt blod til udviklingsgruppen i form af en ny onsite kunde, Således ville en onsite kunde ikke nå at binde sig for meget til udviklerne. Lars Christiansen & Alex Ranch - INF2 - i202a D.2 Orden i kaos - kundeindragelse fungerer ikke i XP-systemudvikling Af Mikkel Bundgaard & Brit Jensen 4. Semester informatik, gruppe i202a 2006 extreme Programmings modellen fokuserer på kundeindragelse under hele udviklingsforløbet og gør kraftig brug af refaktoreringsmetoder og dele udviklingen op i små bidder. Kundeindragelsen baseres på, at en repræsentativ gruppe har det samlede overblik. Dette betyder at delelementer til det færdige produkt aldrig kommer med, fordi der aldrig er blevet foretaget en analyse som kommer rundt i hele forløbet. Resultatet ender op som en lappeløsning bestående af gaatape og stråltråd for at holde delene sammen. Der er sket et skred i systemudvikling som traditionelt udvikles efter hardsystemsudviklingsloso, hvor udviklingsprocessen foregår lineært. Extreme Programming(herefter XP) gør op med gammeldags udviklingsparadigmer som vandfaldsmodellen og foretager istedet udviklingen i små iterationer. Ved det traditionelle vandfaldsparadigme er kundekontakten udelukkende i analysen og afsluttende test som er først og sidst i udviklingsforløbet, modsat XP hvor 87

90 D.2 Orden i kaos D Essays fra Software loso kundeindragelsen foregår under hele udviklingsforløbet. Kravet om tæt kundekontakt i XP betyder at virksomheden må opgive, en eller ere, medarbejdere under udviklingsforløbet. I XP kommer kravet af at udviklerne er nødsaget til at kunne sætte sig ind i kundens verden og derfor have kunden tæt på, og bedst hvis udviklingen foretages hos kunden. De medarbejdere må nødvendigvis være nøglepersoner i virksomheden fordi de skal repræsentere og have kendskab til hele virksomhedens arbejdsgange. Kun de færreste virksomheder har råd og mulighed for at undvære vigtige nøglepersoner i virksomheden igennem hele udviklingsprocessen, fordi de udgør det bærende elementer i virksomhedens arbejdsgange. Dette betyder for XP at personen vil være, enten mindre tilgængelig, eller mindre værdifuld for udviklingen. I mindre virksomheder vil det få større betydning fordi der er færrere personer til at kompensere for manglende arbejdskraft. En repræsentativ gruppe fra virksomheden anvendes som erstatning for en analyse over problemstillingen i virksomheden. For at undgå at forholde sig til et stort system, indeles og udarbejdes kun små delmængder af systemet gennem deres udsagn. Dette gøres efter divide and conqueror metoden, indtil det samlede system er opnået. Metoden antager at software udvikling er ligesom legoklodser og problemfrit sammensættes uden yderligere omtanke. Problematikken kan bedst sammenlignes med IKEA-møbler som kommer i samlesæt. Ved XP tankegang vil samlesættet komme uden brugsanvisning og indholdsfortegnelse, og personen vil skulle tage hver lille del og forsøge at sammensætte med næste del, indtil møblet er færdigsamlet. Kaos opstår og samlesættet ender i aaldsskakten når det opdages at en limning blev fortaget for tidligt og har ødelagt processen. Resultatet sammenligneligt med XP, men XP forsøger at undskylde sig med at refaktorering forbedrer koden og det samlede resultat fremstår færdigt efter passende antal iterationer. Istedet ender det som en lappeløsning i hjørnet af stuen holdt sammen af gaatape og ståltråd. I XP udarbejdes tidligt i forløbet i samarbejde med kunden, en acceptance test som danner grundlag for systemet. Når systemet gennemfører testen, er programudviklingen færdig. Denne test er problematisk at udarbejde i fællesskab med en repræsentativ gruppe fordi der sjældent skabes konsensus om hvad systemet skal kunne og hvad der er muligt at udvikle. Der vil altid være usikkerheder. Derved står XP på den ene side som et hardsystem hvor konsensus behøves og på den anden, som et softsystem hvilket er i XPs ånd, men hvor der ikke eksisterer en fælles konsensus. 88

91 D Essays fra Software loso D.2 Orden i kaos At XP står som softsystem og hardsoftsystem 1 ses både ved analysen og under selve udviklingen. Hele planlægningen giver plads til ændringer og ændringer imødekommes ved planlægningen af næste iteration. Under selve iterationen, fungerer XP som et hardsystem, hvor iterationen færdiggøres, mens ved planlægningen og analysen af krav foregår XP som et softsystem hvor kundens syn indrages løbende i processen. Hvem ender med at tage stilling til hvilken acceptance test der skal udføres, udviklere eller kunde. I den ene lejr står kunden og med sine modstridende krav, men som den betalende, og i den anden lejr står udviklere og behøver konsensus for at kunne forsætte udviklingen. Det færdige system ender med at blive en usikker aære og vinderen bliver den som råber højst under processen, og opfylder derved ikke nødvendigvis de behov som iværksatte udviklingen hos kunden. I XP udvikling tages der højde for kundens usikkerhed og konstant ændrede behov ved at eliminere analysen og kun udarbejde små elementer og konstant refaktorere dem. I udviklingsforløbet afsættes ca. 30% af tiden til refaktorering af koden hvilket forudsætter at kundens behov er enkelt at imødekomme og kunden ikke forsætter med at ændre krav. Dette betyder at udviklingen, i værste fald, kan forsætte i det uendelige uden at nærme sig et endeligt produkt, modsat hardsystems hvor kravene bliver klarlagt og fastlåst og herefter ikke ændres efter næste fase. Dette er sammenligneligt med at bevæge sig i en labyrint uden at nærme sig midten fordi ruten ikke kendes og væggene yttes. Hvis vi ser på XP som udviklingsgrundlag for et større system med ukendte udfordringer og en repræsentativ kundegruppe kan det ikke sikres, at der opnåes en fælles tilfredshed hos alle i virksomheden, fordi kun de færreste er blevet hørt. Udviklingen vil være i fare for at forsætte i det uendelige eller til pengekassen bliver lukket og kunden står med en lappeløsning som aldrig kom til sin ret. Det oer som kunden nødvendigvis må afgive i form af tæt kundekontakt får stor betydning for resultatet af udviklingen. Hos mindre virksomheder ville det oer være nærmest umuligt at drive igennem uden at få konsekvenser for daglige arbejdsprocesser. Hos størrere virksomheder vil resultatet være ens, fordi gruppen af repræsentanter blot er størrere. Risikoen for at ende i en uendelig løkke af nye iterationer er for stor i XP til at det bør anvendes i størrere udviklingsprojekter. 1 Computers in context, Bo Dahlbom et al, s

92 D.3 Konsekvenser... D Essays fra Software loso D.3 Konsekvenser af implementering af nyt software Hvis konsekvenserne af ny software implementering i en virksomhed skal forstås bliver vi nød til at se på forskellige ændringer i virksomheds strukturen en sådanne implementering medfører. Det er klart at opdateringer af virksomhedens software systemer, eller en implementering af nyt software er en udgift, og derfor er det nødvendigt for gennemførelsen af sådanne implementeringer at virksomheden tjener på denne. Det vil altså sige at virksomheden vil kræve at det nye software forøger omsætningen. Denne forøgelse kan ske ere steder; papirarbejde bliver minimeret, hvilken medfører at tiden kan blive brugt på andre, mere krævende opgaver, optimering af automatiseret opgaver, ofte set i bilindustrien, mm. Ens for alle disse optimeringer er at implementering af software har medført en øget produktion i virksomheden. Ved automatiseret opgaver, som en robot der skærer metal ønsker vi ikke at snakke om arbejdsgangen for denne specikke robot da vi ikke tilskriver sådanne en robot menneskelige kvaliteter, men det kunne være interessant at se på arbejdsgangen efter implementering af ny software på et kontor miljø da der her arbejder mennesker. Arbejdsgangen Vi ønsker kun at fokusere på arbejdsgangen i et kontor miljø i denne evaluering af konsekvenserne af implementering af software. Når vi evaluere arbejdsgangen omkring sådanne implementeringer er det vigtigt at vi evaluere hvordan det sociale sammenspil mellem medarbejderne kommer til at forgå. I sagens natur vil en edb løsning på et kontor miljø bevirke at meget data bliver tilskrevet til dette system. Derved bliver alt tilgængeligt for ledelsen. Dette vil med stor sikkerhed føre til en del stress hos medarbejderne da de nu ved at de kan blive overvåget af ledelsen. Det kan argumenteres at sådanne et system derfor vil stimulere en vis form for bureaukrati, da ledelsen vil have en tendens til at sikre eektivitet via overvågning. Grunden til denne overvågning kan ligge i ledernes tendens til ikke at ville fralægge sig ansvar og overblik over medarbejderne. Denne overvågning kan legitimeres i unikke tilfælde hvor en sådan individualisering af arbejdsopgaver ligger til grund for individets løn. Sådan et tilfælde eksisterer i virksomheder som Workout & Fitness, hvor sælgere lønnes efter provision. Derfor er det yderst vigtigt for ledelsen at kunne se statistikker over hver medarbejders arbejdsindsats. Ydermere føres der log over medarbejdernes færden i systemet, da interne supportere, ved systemfejl, kan nde fejlen mere eektivt. Alt dette fører til en komplet overvågning af virksomhedens medarbejdere. Ser vi på den nuvæ- 90

93 D Essays fra Software loso D.3 Konsekvenser... rende arbejdsgang i virksomheden forgår arbejdsgangen i virksomheden ved individuel selvkontrol. Det vil altså sige, at medarbejderne selv kontrollerer hvad de arbejder med og om de opfylder kravene fra ledelsen. Det er klart at elementer som sælger provision ikke kan forfalskes, da sælger skemaer skal sendes til ledelsen hver uge via . Selve arbejdsgangen i virksomheden ændres altså fra den gamle rutine hvor der blev sendt s fra en person til en anden, til nu at være en komplet automatiseret proces. Der kan derfor argumenteres for at kommunikationen i virksomheden også bliver ændret som resultat af implementeringen af nyt software. Kommunikation Kommunikationen i en virksomhed er yderst vigtig for at virksomheden fungerer optimalt på et socialt niveau. At medarbejderne kan snakke sammen uden pres fra enten ledelsen eller andre faktorer, og stadigt nå den arbejdsbyrde der er blevet pålagt det enkelte individ er kritisk for det sociale netværk i virksomheden. Det er efter vores overbevisning et ikke målbart men bestemt ikke ubetydeligt element at have en god intern kommunikation i virksomheden. Mange problemer og spørgsmål kan besvares af andre personer tæt på hinanden ved simpel snakken. Det er derfor vigtigt at bibeholde denne uocielle kommunikation mellem medarbejderne i virksomheden selvom der bliver implementeret en ny software løsning. Som kommunikationen i Workout & Fitness forgår nu er det en meget lagdelt kommunikation, meget lig den kommunikation der ndes i hæren. Medarbejderne taler enten med andre på samme niveau, eller går et niveau op i kommandovejen. Ved implementering af det nye software og dertilhørende hjemmeside var det altså yderst vigtigt at hjælpe denne uocielle kommunikation. Dette blev afhjulpet med et internt forum hvor hvert individ i virksomheden kunne stille spørgsmål, også spørgsmål der ikke er relateret til virksomheden for at understøtte det uocielle element. Yderligere er selve afstanden mellem medarbejderne i virksomheden et element der skal medregnes. Virksomheden har hovedkontor i Århus, lager i Tyskland, butik i Tyskland og en nyopstartet salgsafdeling i Sverige. Derfor er det svært for medarbejderne at kommunikere indbyrdes da der så ville være store telefoniske omkostninger forbundet med dette. Derfor er næste skridt i kommunikationsplanen for Workout & Fitness, at implementere en IP-telefoni løsning i virksomheden så medarbejderne er yderligere rustet til at føre kommunikation imellem hinanden. 91

94 D.3 Konsekvenser... D Essays fra Software loso Målsætning Målet med at implementere et nyt softwaresystem i virksomheden Workout & Fitness, er først og fremmest at få besparelser på budgettet på længere sigt. Et af de negative aspekter ved besparelser på arbejdsrutiner, kan medføre at medarbejdere bliver afskediget, da der ikke længere er behov for den samme mængde arbejdskraft. Dog mener ledelsen i Workout & Fitness, at lettelser på monotone arbejdsrutiner vil give medarbejderne mere tid til at sælge produkter, og derved skabe større vækst og prot i virksomheden. Vurdering Vi mener på baggrund af vores argumentering af implementeringen af det nye software i Workout & Fitness vil bidrage til en mere udfordrende arbejdsgang, med større frihed og større eektivitet. Som helhed vil arbejdsopgaverne blive delt bedre op mellem medarbejderne, og der vil ikke fremkomme de samme misforståelser i virksomheden som der kan ske i den nuværende situation. Det eneste negative aspekt af en fornyelse af softwaren i virksomheden er at der kommer mere overvågning over medarbejderne, dog kan dette administreres af ledelsen så det ikke påvirker de enkelte medarbejdere, men dette er en ledelses beslutning. 92