Pavel Denisov D01, Lunds Tekniska Högskola 21:e februari 2006

Transkript

1 Hur ett XP-projekt påverkas av ett webbaserad projekthanteringsverktyg Pavel Denisov D01, Lunds Tekniska Högskola 21:e februari 2006 Abstrakt XP är bra att organisera små exibla grupper med utvecklare med små medel. En av XPs kärnprinciper är dock att kunden är hela tiden på plats och består med hjälp, förklaringar, väljer riktning för projektet och även ser hur arbetet fortskrider. Ute i den verkliga världen sitter kunden oftast i en annan stad och har begränsade kommunikationsmöjligheter. Med Internets intåg är det nu mycket enklare att brygga dessa avstånd. Vi undersöker hur ett webbaserat verktyg kan användas i ett XPprojekt från olika personers synviklar. Vi kommer fram till att ett sådant verktyg innebär väldigt många fördelar och inga nackdelar. Införandet av ett sådant verktyg innebär inte heller några risker, eftersom det är väldigt enkelt att falla tillbaka på traditionella metoder. 1 Introduktion Det här dokumentet riktar sig främst till lärare och studenter i kursen Programvaruutveckling i grupp som ges på Datavetenskapinstitutionen, Lunds Tekniska Högskola. Det förutsätts att läsaren har grundläggande kunskaper i mjukvaruutvecklingsprocessen och speciellt då Extreme Programmering [1]. XP och agila metoder har börjat bli mer och mer populära i industrin och det nns nu många företag som använder sig av dessa i alla sina projekt. Dock vet vi både från egen erfarenhet och publicerad material [2] att större projekt har alldeles för avancerade krav för att enkelt kunna hanteras via stories på papper. Det är också väldigt sällan som man har kunden på plats så att man kan fråga eller veriera eller visa hur det går. Därför är det viktigt att ha ett verktyg av något slag som strömlinjeformar utvecklingsprocessen och gör den genomskinlig. Ett sådant verktyg mycket väl skulle kunna vara en tavla med pennor, men det skulle också kunna vara en server som alla jobbar mot. Med Internets genombrott, har man nu möjlighet att med enkla teknologier sätta upp ett webbaserat verktyg som skulle kunna få med kunden i utvecklingsprocessen trots avstånd. Ett sådant verktyg skulle även kunna förenkla trackingen för utvecklarna, förbättra möjligheterna för coacher att planera och följa utvecklingen och eventuellt möjliggöra distansarbete för utvecklarna, ifall sådant skulle krävas (detta bryter återigen mot en av XPs principer, men kan vara en ganska realistisk situation på ett företag med t.ex. inhyrd konsult eller när tex en av utvecklarna är bortrest, sjuk, har ingen möjlighet att komma till kontoret, etc). Dokumentet består av följande avsnitt: Bakgrund Här beskrivs anledningen till att denna studie skrevs, Frågeställning Avsnittet behandlar frågan som studien försöker besvara, Förundersökning och analys Beskrivning av material som användes i studien och en analys av frågan, Fastställandet av tillvägagångssättet Genomgång av hur studien genomfördes rent praktiskt, Resultat Här presenteras resultat från frågeformuläret och coachens noteringar, Diskussion Vi tolkar resultatet, försöker dra några slutsatser och diskuterar 1

2 studien och dess genomförande. 2 Bakgrund Datavetenskapinstitutionen på Lunds Tekniska Högskola har under era år haft en kurs i mjukvaruutveckling där man tillämpar XP-metoden. Kursen är obligatorisk för 2:a års studenter som får lära sig att utveckla i grupp och får samtidigt prova på en modern utvecklingsprocess som börjar bli mer och mer populär. Samtidigt nns det en valfri kurs för 3:e års studenter som innebär att man får prova vara en coach för ett XP-team. Dessa kurser kombineras mycket väl tillsammans på ett sätt som gör att alla deltagande får ut så mycket som möjligt utav det. I coaching-kursen ingår en djupstudie som ett obligatoriskt moment. Detta arbete är just en sådan djupstudie. 3 Frågeställning Att utvärdera ett enskilt verktyg som skulle kunna ersätta det traditionella sättet att tracka är relativt trivialt och inte så intressant, därför formulerades frågan på ett mera generellt sätt. Frågan som ställdes var: Hur påverkar ett webbaserat verktyg trackingen i ett XP-projekt? Vi analyserar frågan en bit. Varför webbaserat? Man skulle kunna utöka frågan till att omfatta alla verktyg som använder sig av internet-uppkopplingen för kommunikation. Steget är faktiskt inte lika långt numera med utvecklingen av AJAX som möjliggör webbaserade användargränssnitt som beter sig som en klientapplikation [3]. Det nns dock skillnader mellan en applikation med ett graskt användargränssnitt och en websida. Alla användare i målgruppen är redan bekanta med hur ett webgränssnitt fungerar (länkar, formulär, etc) medan en applikation kan ha ett speciellt utseende på sina komponenter. Det tillkommer dessutom installation och distribution av programmet, vilket är ytterligare steg som ska tas i beaktning. Ett webbaserat verktyg gör det enkelt för alla att komma åt informationen från vilken klient som helst (numera klarar de esta mobiltelefoner att visa vanliga hemsidor) därför känns det rätt naturligt att undersöka just sådana verktyg. Vi begränsar oss också till trackingen. XP består av era så kallade core practices, men det är bara några som involverar kunden: planning game och add a customer to the team; dessutom är kunden involverad i trackingprocessen genom att det är viktigt för kunden att veta vilken hastighet teamet har för närvarande och vilka stories som beräknas bli klara under interationen. Det kan hända så att om en story tar alldeles för lång tid jämfört med hur den var prioriterad så kan den nedprioriteras under arbetets gång. För att kunna göra det, måste kunden hela tiden veta hur projektet ligger till och därför är trackingen väldigt viktig. Planning game är i sig ett ganska komplicerad process där det händer väldigt mycket på ganska kort tid. Att designa ett datoriserat verktyg som stödjer planning game är därför ganska svårt. Ett verktyg som stödjer trackingen kan dessutom hjälpa till med integrationen av kunden i teamet, vilket är som sagt ett större problem i industrin. 4 Förundersökning och Analys I förundersökningen ingick dels att leta upp och utvärdera att antal olika verktyg och dels att läsa några artiklar som skulle ge er infallsvinklar på ämnet och kanske berätta om erfarenheter och slutsatser från liknande fall och studier. Det gjordes också en enkel analys av användarna. För att förenkla förarbetet, var valet endast mellan verktyg som gick att köra på en Linuxserver (eftersom det var den enda platformen som var tillgänglig) och vara gratis (demoversioner som kräver registrering och annat jobbigt togs inte med). Följande verktyg ingick därmed från början i undersökningen: ExtremePlanner [4] TrackIt [5] XPlanner [6] XPWeb [7] XPMT [8] Artiklarna valdes efter någotsånär relevans och intresse. Det fanns en hel del artiklar om försök av införande av datoriserade verktyg i XPprojekt, men väldigt få artiklar som behandlade dynamiken mellan inblandade personer och deras roller på ett djupare plan än bara en allmän beskrivning av XP praktikerna. Följande artiklar ingick till slut i förstudien: 2

3 [2] I den här studien användes ett datorbaserat verktyg för hantering av krav från kunden. Förutom att kunden var på plats hela tiden och var dedikerad för projektet, liknar upplägget vårt eget projekt väldigt mycket. Det var därför intressant att se vilka problem som uppstod och om de kunde knytas an till vårat projekt också. [9] Den här artikeln går genom vad det innebär för en utvecklare att bli avbruten mitt i en uppgift. Anledningen till att den valdes var för att i rollen tracker, som är en del av XPs praktiker, ingår att samla information om hur gruppen ligger till. Beroende på hur denna uppgift utförs, kan det innebära avbrott för utvecklarna. Därför var det intressant vilka typer av abrott påverkade utvecklingen på vilket sätt. [10] Här presenteras en studie om hur man kan designa ett verktyg som stödjer XP och ISO 9001:2000 standarten, vilket är intressant ur industrisynvinkel. Det ligger en bra bit utanför ramen för våra skolprojekt, men är ändå rätt intressant om man ska ha en anknytning till den riktiga världen. [11] Ett annat webbaserat verktyg, som dock inte ingick i studien på grund av sin udda tekniska implementering. Artikeln går dock genom grundligt processerna som ingår i XP och hur man designar ett verktyg som stödjer dessa. [12] Utveckling av ett XPverktyg som är inbyggd i Eclipse. Hade verktyget istället varit webbaserat hade det kunnat ingå i studien, men nu nöjer vi oss med att försöka dra några paralleller och slutsatser från deras erfarenheter. Användare av verktyget skulle vara följande: utvecklarna, coacher och kunden. Utvecklarna skulle använda verktyget för att välja vilken story de skulle börja arbeta på, baserat på kundens prioriteringar och vilka storys som var redan tagna. De skulle även kunna lägga till upptäckta storys och tasks och ändra estimeringen ifall de upptäckte att den var fel. Coacherna skulle använda verktyget för att följa utvecklingsprocessen och se vilka storys som tog för lång tid och om man skulle omfördela arbetet i det fallet så att de högst prioriterade storys blev klara först. Kunden skulle ha möjlighet att följa projektet även när han/hon inte var på plats och även upptäcka snabbt ifall nån story tog för lång tid och kanske behövde omprioriteras i så fall. I ett litet projekt som vårat, nns det inte så många beroenden mellan kraven, så vi kan inte hoppas att få samma fördel på den punkten som teamet i [2] gör. Det blir dock enklare att hantera förändringar i kraven, eftersom dels är man inte begränsad av en fast yta vilken en tavla utgör och en ändring innebär inte att man behöver sudda och rita om allting. En tracker i traditionell XP är en person som går runt och tar reda på hur teamet ligger till och uppdaterar informationen på tavlan. Det nns olika sätt att hantera denna roll coacherna kan agera som tracker, man kan utse en av utvecklarna som en fast tracker eller så går denna roll runt i gruppen med tex varje iteration eller varje dag (samma sak i vårt fall). I alla dessa fall, innebär det att trackern avbryter utvecklingen om så för en kort stund för att fråga ut utvecklarna hur dem ligger till. Även sådana små avbrott kan störa koncentrationen [9] och bör helst undvikas. De två senare fallen, dvs då en av utvecklarna är tracker, innebär också att en av paren tvingas avbryta sitt jobb för att en av utvecklarna ska sköta sina uppgifter som tracker. För att minimera dessa avbrott kan man med hjälp av ett webbaserat verktyg distribuera trackinguppgiften på alla utvecklare. Det innebär att inget enskilt par blir lidande och den tid varje par lägger ner på att uppdatera tracking informationen minskar, eftersom de inte behöver förklara sin situation för en utomstående utan kan helt enkelt föra in sin status på webben, vilket tar i normala fall några sekunder. Ett datoriserat verktyg kan också använda sig av den införda informationen för att bygga mer eller mindre avancerade grafer och sammanställa statistik över projektet [11]. Både na grafer och statistik används ofta i många presentationer för att imponera lyssnaren och maskera avsaknaden av väsentlig innehåll. Den högre ledningen i ett företag vill dock väldigt gärna ha en enkel översikt över alla projekt som är aktiva och hur de ligger till jämfört med deadlines. Sådana grafer och dokumentation över projektets framskridning kan också krävas för att företaget ska bli certierad [10]. Det kan därför vara bra om det går att generera sådan information automatiskt, eftersom manuell sammanställning är väldigt tidskrävande och kräver merarbete (om man använder tavla 3

4 för tracking måste all information skrivas ner också för att möjliggöra sammanställning). 5 Fastställandet av tillvägagångssättet Först och främst så måste arbetssättet och processen fastställas. Metoden är redan denierad och vi måste använda oss av alla XPpraktiker, dvs verktyget måste stödja XPmetaforen på något sätt, och helst rakt av för att minimera förvirringen. Det nns ytterligare begränsningar arbetet pågår under en dag i veckan och en iteration är endast en dag lång. Det innebär att arbetet mäts i timmar (vissa verktyg hade dagar som tidsatom). Det nns dessutom väldigt begränsade möjligheter att genomföra en utbildning vad gäller användadet av verktyget. Baserat på dessa förutsättningar valdes XPlanner [6] och installerades för testning. Hur verktyget skulle användas berodde bland annat vem skulle vara trackern i projektet och hur denna arbetsuppgift skulle genomföras. Eftersom hela tanken med att använda ett webbaserat verktyg var att ersätta dem traditionella verktygen, övervägdes inte tavlan som ett mellansteg överhuvudtaget (man skulle kunna annars uppdatera informationen på en tavla och efter arbetsdagens slut uppdatera informationen i webverktyget. Skulle kunna vara ett alternativ i större projekt där man vill ha kvar tavlan pga exibilitet eller någon annan anledning men ändå vill att informationen ska digitaliseras och göras tillgänglig online. Fördelen här är att man kan alltid ta en bild på tavlan och bifoga den för att utvecklarna ska minnas bättre vad det handlar om). Följande alternativ fanns: En dedikerad tracker som kontinuerligt uppdaterar verktyget med jämna mellanrum Rollen tracker vandrar rund med bestämda intervall, men det är fortfarande en person som uppdaterar verktyget åt gången Alla är sin egen tracker och uppdaterar verktyget kontinuerligt Ett webbaserat verktyg ger alla åtkomst åt datan samtidigt (lite som Collective Code Ownership, fast nu är det Collective Planning Ownership). Det vore onekligen intressant att uttnyttja denna möjlighet och jämföra med grupper som använder andra sätt att tracka. Man kunde jämföra vad en tracker tillför gruppen som person och vad innebär det att ta bort denna person överhuvudtaget. Därför valdes det sista alternativet, att alla är sin egen tracker. Om man ska ersätta alla traditionella verktygen, så måste också storykorten ersättas på planeringsmötet. I vårt fall är kunden dock alltid med på planeringsmöten och ska svara på frågor och prioritera stories på ganska kort tid. Det är alltså viktigt att underlätta planeringen och få den att gå så smidigt som möjligt. Fördelen med ett webbaserat verktyg är samtidigt störst först när någon inte har möjlighet att närvara och är alltså inte så stor i detta fallet. Med detta i åtanke valdes följande arbetssätt vid planeringsmötena: Estimeringen sker helt och hållet med hjälp av traditionella hjälpmedel storykort, tavla, papper och penna, etc Här har utvecklarna stora möjligheter att skicka korten mellan varandra, klottra på kanter, gå fram till tavlan och rita. Flexibiliteten är väldigt stor och främjar dialog och kreativitet. Planeringen sker genom att kunden med hjälp av estimeringen placerar storykorten i ordningen av prioritet. Det nns möjlighet att ytta korten och kasta om ordningen hur som helst och när som helst. Utvecklarna plockar storykorten som de vill vara ansvariga för. Detta sker återigen snabbt och enkelt tack vare exibiliteten. Estimeringen, prioriteringen och vem som är ansvarig antecknas noga och det ges som spike åt en av utvecklarna att lägga in stories och tasks i webverktyget. Det innebär att på morgonen när iterationen ska börja, kan utvecklarna gå in direkt och börja plocka stories och tasks i webverktyget. 6 Resultat 6.1 Resultat från formuläret 6 coaches och 8 utvecklare svarade på webenkäten, 14 svar sammanlagt. Av dessa hade 5 erfarenhet från något slags projekthanteringsverktyg. I följande tabell har grupperna numrerats om: 4

5 grp # svar verktyg tracker betyg 1 3 web alla 4,4,4 2 2 tavla coach 2,4 3 2 web alla 4,4 4 3 tavla coach 3,4,3 5 2 web coach 4,3 6 2 cvs alla 4,4 Det var inte så många som lämnade bra kommentarer, men här följer en kort sammanställning. Kommentarerna har följande format: 1. Kommentera verktyget som ni använde i gruppen 2. Hur mycket tid la ni ner på trackingen? 3. Hur skulle du vilja förbättra trackingen? 1. ingen tracking hände när coacherna var borta. Bra översikt över vår dåliga estimering 2. några minuter 3. coach grupp 6: 1. lätt och enkelt, kanske lite fult (bara en textl) 2. inte mycket alls 3. eclipse-integration utvecklare grupp 6: 1. enkelt, fungerar bra. 2. några minuter Coachens antekningar coach grupp 1: 1. fungerade bra, trevligt att utvecklarna kan göra det själva 2. några minuter 3. utvecklare grupp 1: 1. utvecklare glömde registrera påbörjade/avslutade storys. Tillgänglig varsomhelst, närsomhelst. Enkelt 2. några minuter 3. integration med eclipse coach grupp 2: 1. utvecklarna glömde skriva upp sig på storys, kom inte ihåg hur länge de jobbat. 2. ca 15 min 3. webbaserat, integrerat med eclipse utvecklare grupp 4: 1. Det fungerade, klart och enkelt att överblicka, svårt att samla info 2. ca 20 min 3. Bättre läsbarhet coach grupp 5: Som coach har man följt arbetet och anteknat vad som har fungerat väl och vad som har fungerat dåligt. Nedan följer ett något slags sammanfattning av dessa antekningar. Inför första iterationen förbereddes verktyget av coacherna själva eftersom teamet har inte haft en möjlighet att sätta sig in i arbetssättet och bekanta sig med verktyget. Under iterationen har vi sagt att de ska uppdatera informationen på webben minst en gång i halvtimmen och påminnt dem nitiskt om detta. På grund av strul med installationen har de inte haft möjlighet att titta på verktyget innan heller, men efter en kort genomgång innan iterationen startade fortlöp arbetet smidigt och trackningen verkade fungera bra. Efter iterationens slut visade sig dock underliga resultat. Totalt hade teamet arbetat 32.6 timmar vilket är som det borde vara, men när man tittar på enskilda personer så varierade arbetstiden mellan 2.8 och 6.3 timmar, vilket är mycket underligt eftersom alla har suttit och jobbat exakt samma antal timmar. Inför iteration 2, ck en av utvecklarna som spike att lägga in stories i verktyget och det fungerade väldigt bra. Däremot så gick vår server ner, eftersom just denna dag byttes internet på hushållet där servern står. Det innebar att teamet föll tillbaka på tavlan som trackning och vi coacher tog an uppgiften att tracka. Efteråt skrevs arbetstiden ner och en av utvecklarna ck som spike att lägga in den i efterhand. Sammantaget fungerade det inte så bra, då 5

6 teamet som helhet hade tydligen jobbat 48.0 timmar och enskilda arbetsinsatser varierade mellan 2.2 och 11.5 timmar. För att råda bot på detta, hade vi under följande planeringsmöte en diskussion om varför trackningen är viktig och vad den tillför egentligen. Dessutom gavs det som spike åt alla att leka runt i verktyget och upptäcka bättre hur det fungerar. Spikningen utfördes med varierande entusiasm. Under iterationen fungerade trackningen bättre dock 30.3 jobbade timmar totalt och enskilt varierade mellan 1.9 och 4.7 (de esta låg på 4 timmar). Även denna gång har utvecklarna utfört trackningen själva utan påminnelser från oss. En sak som inte har fungerat alls än så länge, är omestimeringen av tasks. Även om utvecklarna inte glömmer att uppdatera hur mycket de har jobbat på en tast, glömmer de att uppdatera hur mycket de tror att det är kvar. Under interation 4 fungerade trackingen mycket bättre och genomsnittet för arbetstimmar var 6.5 timmar per utvecklare. Stories uppdaterades mycket bättre och vi hade bra koll på vilka stories som var färdiga och vilka som tog längre tid än väntat. Iteration 5 fungerade lika minst lika bra, även om det blev mindre timmar jobbat. Gruppen har äntligen fått in arbetssättet. Det tog lite tid men är väl ganska bra, med tanke på hur mycket annat de måste tänka på samtidigt. 7 Diskussion Det är ganska klart att denna studie har alldeles för liten underlag för att säkert kunna svara på ställd fråga. Det nns dock möjligheter för en intressant diskussion och kanske även några slutsatser. Nedan försöker vi tolka resultatet från formuläret och knyta ihop den med egna observationer och tidigare studier. Vi kommer även att duskutera vad som inte gjorts rätt och hur man skulle kunna förbättra det. Dessutom kommer vi att nämna hur man skulle kunna gå vidare med denna studie för att få fram mer och bättre resultat så att man kan svara bättre på frågan som ställdes högre upp. Projektet som studien baserade sig på är kanske inte det bästa, eftersom det är ganska litet i sin omfattning, har ganska få och enkla relationer mellan storys, väldigt korta iterationer och väldigt få storys också. Allt detta bidrar till att ett verktyg som används i ett sådant projekt måste antingen vara specialanpassat eller väldigt exibelt. Trackingen var dessutom inte lika viktigt i detta projektet, eftersom gruppen hade väldigt få problem att hålla reda på sitt status helt enkelt genom att prata med varandra. Det fanns inte heller några chefer som krävde kontinuerliga rapporter. Kunden var också rätt passiv och var tydligen nöjd med att få en kort statusuppdatering på plats, vilket skedde endast ett par gånger per iteration. Det beror nog på, som sagt, att våra iterationer var så korta att det räkte med detta. Om iterationen var istället några veckor, så hade det varit av högre vikt för kunden att veta hur gruppen ligger till under hela iterationen. Med tanke på hur litet det här projektet är, skulle man kunna anpassa trackingen en bit och inte mäta på sådan detaljerad nivå som enskilda tasks eller till och med storys. Ett alternativ skulle i så fall vara att mäta det sammanlagda antalet timmar som man la ner och hur många man hade estimerat från början. Problemet med detta sättet är att man förlorar en mycket viktig uppgift med trackingen att veta vem som håller på med vad och hur länge de har hållit på. Coacherna skulle inte ha så mycket aning om hur gruppen låg till förrän i slutet av iterationen och likaså kunden. Man kan dock argumentera att enskilda tasks är för mycket att hålla reda på eftersom det är endå ett och samma par som håller på med en story. Motargumentet är att paret behöver ändå hålla reda på sina tasks för att enklare kunna estimera storyn och för att kunna planera sin arbetstid och då kan dem lika gärna använda samma verktyg för det, helt enkelt för att få ett enhetligt arbetssätt. Det vore nog bra om man kunde bestämma detta från fall till fall och att verktyget skulle stödja båda sätten. I vårt fall så stödde inte XPlanner en story utan tasks och alltså tvingades utvecklare skapa åtminstone ett task per story ändå. Webformuläret visar att de som använde något slags webbaserat verktyg var generellt sett mer nöjda med trackingen än de som använde något annat. Tyvärr var det väldigt få svar så resultatet kan vara snedfördelat, men det känns ändå som att det nns en trend i alla fall. Ett problem som tagits upp är att utvecklarna är dåliga på att uppdatera när de startar och avslutar en story/task. Samma sak gällde nyupptäckta tasks, även om i just vår grupp la utvecklarna in en del nya tasks när dem upptäckte dem, men det var långt ifrån alla. Detta problem var dock samma för webbaserade verktyg som för de traditionella. Om 6

7 det är en person som är tracker, så kommer inte informationen fram förrän tracker har frågat paret i frågan vad de jobbar på just nu. Detta kan dock åtgärdas genom bättre integration med utvecklingsverktyget, i vårt fall eclipse. En sådan integration skulle kunna innebära att utvecklare inte kan börja skriva kod förrän de har markerat vilken story de jobbar på. Varje gång de gör en commit skulle de kunna ange, förutom kommentaren, hur mycket tid det är kvar på storyn eller om den är rentav färdig. Samtidigt kan man assosiera ändringar i cvs med en viss story, vilket är bara positivt. Detta arbetssätt skulle väsentligt förenkla för utvecklarna och stödja trackingen. Verktyget som beskrivs i [12] låter därmed väldigt intressant, eftersom det verkar stödja ett liknande om inte exakt samma arbetssätt. Webenkäten hade behövt vara mycket mer omfattande för att kunna användas som underlag för några slutsatser. Det hade till exempel inte skadat med några svar från kunden. Det innebär att den behöver förberedas mycket mer noggrant för att kunna integrera svar från alla inblandade. Det skulle nog hjälpa också ifall man kunde göra det obligatoriskt att svara. De kommentarer som gavs tillsammans med egen erfarenhet pekar på att både coacherna och utvecklarna ck ut väldigt mycket av att använda ett webbaserat verktyg istället för tavlan. Som coach ck man en bra översikt över hur man låg till och det var enkelt att upptäcka när ett par körde fast och vidta åtgärder. Utvecklarna hade lättare att följa upp också, även om det inte går att dra några slutsatser om hur det påverkade trackingen för dem, eftersom i grupper som inte använde ett webbaserat verktyg är det coacherna som stod för trackingen. Resultatet visar att det nns endast fördelar med ett införandet av ett webbaserat verktyg: Det minimerar avbrott i utvecklingen De inblandade användare upplever det som mer positivt och mer användbart Det är inga problem att falla tillbaka på traditionella verktyg ifall så skulle krävas Går att använda på distans och ökar därmed integrationen av kunden i teamet i dem fall då kunden inte är på plats hela tiden Minimerar trackingarbetet genom att förenkla editeringen av information Har möjlighet att ge bättre överblick genom grafer och statistik Utvecklarna kan sköta uppdateringen själva Möjlighet att integrera med utvecklingsverktyget vilket innebär ännu er fördelar Det verkar vara rätt många som har uppfattat dessa fördelar, eftersom så många grupper valde att använda ett webbaserat verktyg. Detta är helt klart en trend som kommer att hålla i sig och eventuellt innebära att alla grupper har ett sådant verktyg. Det börjar då bli intressant att införa ett gemensamt sådant och börja stödja detta även från institutionens håll. Det är trots allt så att alla som ska syssla med mjukvaruutveckling i industrin kommer att använda ett liknande verktyg förr eller senare. Valet av verktyget har kanske inte varit det bästa. Det nns tydligen ingen dokumentation för användningen överhuvudtaget, så det enda man kan göra är att testa och se vad resultatet blir. Användargränsnittet var inte det mest självklara, så vissa svårigheter uppstod. Förmodligen det största problemet var att förstå hur estimeringen sparades och användes och det problemet är fortfarande inte löst, även om vi har några teorier. Verktyget har inte heller någon enkel resultatsida där det presenteras siror som är gemensamma för de esta XPprojekt, tex farten. Åt andra sidan ska det inte spela någon roll vilket verktyg som används för frågeställningen är mer generell än så. Sammanfattningsviss kan man konstatera att inget av de verktyg som var med i uttagningen i början var perfekt. Alla hade mer eller mindre användarovänliga gränssnitt och dålig exibilitet. Det kan dock bero på att endast gratisverktyg var med. Med stor sannolikhet nns det verktyg som är väldigt bra men som kanske kostar en slant. Det första vi kan se är att utvecklarna har varit dåliga på att rapportera exakt vem som har jobbat med vad. Detta beror på era olika säker: Dåligt bekanta med verktyget. Det fanns som sagt ingen dokumentation och inte allting är självklart. De skriver alltså in fel saker trots att de menar rätt. Litet projekt. Eftersom vi har så få stories och tasks och de är så små, är det stor risk att ett par hoppar lite mellan tasks utan att anteckna det. Vi hade fallet att paren bytte tasksen med 7

8 varandra och att ett par upptäckte att de jobbat på fel story, fast det var rätt sak de gjorde. Att skriva över tiden på detta sättet visade sig vara inte helt lätt. Lathet / glömskhet. Att komma ihåg att hela tiden anteckna hur mycket de har jobbat och hur mycket de har kvar är inte lätt när man jobbar på detta sätt för första gången och har samtidigt mycket annat nytt att tänka på (praktiker, programmet, kunden, etc). För att förbättra detta, skulle man behöva skriva ett eget verktyg som är helt och hållet anpassat för detta projekt och som har ännu bättre användargränssnitt: istället för att anteckna hur mycket man har jobbat på en task, så uppger man när man börjat jobba på en task och när man slutat, så att tiden och vem som jobbar med tasken uppdateras automatiskt Man kan även införa automatiska påminnelser där man skriver in hur mycket man tror att det är kvar. Detta kräver dock mer avancerad funktionalitet än vad som är möjligt med vanliga hemsidor. Går dock alldeles utmärkt med AJAX. Strömlinjeforma arbetet. Kräver dock att man har en väldigt standariserad process, vilket vi ju har. Däremot så tycker vi att i vårt fall var det bra att behålla storykorten vid planeringsmöterna. Designa ett datoriserat verktyg som skulle erbjuda lika mycket exibilitet samtidigt som det var lika enkelt och snabbt att använda ligger på gränsen till det omöjliga. Något som skulle vara intressant att testa i framtiden är verktyget som beskrivs i [12]. Det är väl intregrerat med eclipse och har något slags support för planning game. Det verkar dock inte ha något webinterface men det kanske man kan klara sig utan genom att utbilda kunden i att använda eclipse tillsammans med detta verktyg. Det kan också vara så att det är väldigt enkelt att lägga till ett webinterface till verktyget och då kanske det blir en riktig silver bullet för hanteringen av XPprojekt. Referenser [1] [2] D. M. Woit, Requirements interaction management in an extreme programming environment: a case study, in ICSE '05: Proceedings of the 27th international conference on Software engineering, pp , [3] [4] [5] [6] [7] [8] [9] M. Czerwinski, E. Horvitz, and S. Wilhite, A diary study of task switching and interruptions, in CHI '04: Proceedings of the SIGCHI conference on Human factors in computing systems, pp , New York, NY, USA, 2004, ACM Press. [10] M. Melis, W. Ambu, S. Pinna, and K. Mannaro, Requirements of an iso compliant xp tool, in Lecture Notes in Computer Science Vol. 3092, pp , [11] S. Pinna, S. Mauri, P. Lorrai, M. Marchesi, and N. Serra, Xpswiki: An agile tool supporting the planning game, in Lecture Notes in Computer Science Vol. 2675, pp , [12] M. Holcombe and B. Kalra, Agile development environment for programming and testing (adept) - eclipse makes project management extreme, in Lecture Notes in Computer Science Vol. 3556, pp ,