Studie av estimeringstekniker för Extreme Programming. F. Stål D08, Lunds Tekniska Högskola

Studie av estimeringstekniker för Extreme Programming F. Stål D08, Lunds Tekniska Högskola dt08fs5@student.lth.se 27 februari 2012

Sammanfattning Den här studien syftar på att analysera ett fåtal estimeringsteknikers förmåga att vara lämpliga för mjukvaruprojekt i mindre grupper samt med projektmodellen Extreme Programming. Störst fokus har lagts på tekniken Planning Poker och för att få praktisk data till studien har den prövats under ett studentprojekt med en grupp på åtta personer. Alla deltagare är andra årets studenter i programmet Datateknik på Lunds Tekniska Högskola (LTH). Den resterande data är hämtad från tidigare studier och med hjälp av dem framhävs en jämförelse på olika teknikers för- och nackdelar samt deras flexibilitet att passa in i ett projekt med Extreme Programming.

Innehåll 1 Inledning 1 2 Bakgrund 1 2.1 Estimering...................................... 1 2.2 Tidigare studier................................... 1 2.3 Coaching av programvaruteam.......................... 2 2.4 Enduro....................................... 2 3 Estimeringtekniker 2 3.1 Mindre struktur................................... 2 3.1.1 Planning Poker............................... 2 3.1.2 Unstructured Groups............................ 3 3.1.3 Statistical Groups............................. 3 3.2 Större struktur................................... 3 3.2.1 Delphi.................................... 3 3.2.2 Decision Markets.............................. 3 4 Påverkande faktorer 4 4.1 Domänkunskap................................... 4 4.2 Erfarenhet...................................... 4 4.3 Exakthet...................................... 4 5 Implementering i XP-projekt 5 5.1 Faktorernas roll................................... 5 5.2 Tillämpning i XP.................................. 5 5.3 Jämförelse...................................... 6 6 Planning Poker i studentprojekt 6 6.1 Utgångspunkt.................................... 6 6.2 Kortleken...................................... 6 6.3 Resultat....................................... 7 6.3.1 Iteration 1.................................. 7 6.3.2 Iteration 2.................................. 8 6.3.3 Iteration 3.................................. 8 6.3.4 Iteration 4.................................. 9 6.3.5 Iteration 5.................................. 9 6.3.6 Iteration 6.................................. 9 7 Slutsatser 10 Referenser 11

1 Inledning Ett problem med att tidsestimera mjukvara är just att det är en estimering, en uppskattning. Vanligtvis i extreme Programming (XP) och andra agila metoder, jämför man i efterhand hur pass bra eller dåligt resultatet blev enligt planeringen och efter ett antal iterationer när teamet känner sig bekväma med systemet brukar estimeringarna också bli mer korrekta. Det som krävs är en fördefinierad estimeringsteknik redan från första planeringsmötet, men även också att samtliga medlemmar aktivt deltar vid estimering av varje funktionalitet. Varje estimering behöver spegla teamets förmåga och inte enbart en eller två personer, man bör alltså utnyttja kunskaper och tidigare erfarenheter av samtliga medlemmar. Risken för underestimering kan öka, ifall det enbart speglar ett fåtal medlemmar. För att kunna genomföra studien var det först nödvändigt att leta reda på tidigare studier samt artiklar angående tidsestimering av mjukvara. Med hjälp av referenserna till den här studien var det möjligt att få en klarare bild av planeringsprocessen och även förståelse för diverse vikter i t.ex. XP-projekt. Nästa steg utfördes efter det att projektgruppen bildats och gick ut på att utföra en bedömning av de olika medlemmarnas erfarenhet av programmering, arbete i grupp och XP. Detta steg utfördes även under projektets gång med det största syftet att bedöma gruppens medvetande kring det utvecklade systemet. Under de första möten utfördes estimeringarna i två grupper om fyra personer. När det väl ansågs att projektgruppen besatt tillräcklig kunskap om deras eget system, tog tre iterationer, introducerades Planning Poker[Gre02] vid det fjärde planeringsmötet som en ersättande teknik att tidsestimera. Avsnitt 2 tar upp bakgrunden för estimering av mjukvara samt målet med kursen studien utfördes i. Avsnitt 3 beskriver de olika estimeringsteknikerna som behandlades i den här studien. Avsnitt 4 innehåller de områden jag valt att studera och deras koppling till estimeringsprocessen. I avsnitt 5 utförs en jämförelse mellan estimeringstekniknerna från avsnitt 3 och deras sammanhang till faktorerna i avsnitt 4. Avsnitt 6 behandlar appliceringen av Planning Poker till ett XP-projekt och dess reslutat. Avslutningsvis behandlar avsnitt 7 en sammanfattning över hela studien. 2 Bakgrund 2.1 Estimering En av de stora praktikerna i XP är Planning game [Bec99]. Den menar på att både utvecklare samt kunden ska tillsammans bestämma vad som ska ingå i nästkommande iteration. Kunden står för prioriteringen för varje funktionalitet, han bestämmer vad som bör vara implementerat efter nästa iteration samt vad som kan skjutas fram. Utvecklare står för kostnaden för vardera funktionalitet, de estimerar tiden det tar att implementera [BF00]. Den här studien är baserad på estimering, en process eller handling inom planeringsprocessen. Planering är alltså inte estimering och vice versa [McC09]. Utan att direkt citera, menar Steve McConnel i [McC09] att målet med estimering är exakthet, ett noggrant estimat. Målet med planering är istället att nå ett specifikt resultat. För att en estimeringsmetod ska behöva passa in till XP behöver den då också ha stöd för att metoden ska kunna utföras i en grupp. Det har bara genomförts ett fåtal tidigare studier inom området gruppestimering, något som även nämns i [MØHB08]. 2.2 Tidigare studier En mycket liknande studie har genomförts tidigare i [Hau06] där tekniken Planning Poker introducerades i mitten av ett XP-projekt för att se ifall det genererade förbättrade estimeringar. 1

M. Jørgensen utförde en granskning mellan olika tekniker [Jør04] som är en utav de viktigaste källorna jag använt för min egen studie. 2.3 Coaching av programvaruteam Studien utfördes i samband med och inom kursen Coaching av programvaruteam på LTH. Kursen är uppdelad i två delar, en teoretisk och en praktisk vilka utförs under varsin läsperiod. Målet är lära ut diverse tekniker och grundläggande teori hur man agerar som coach till ett mjukvaruprojekt. Det behövs sedan under den praktiska delen då kursmedlemmarna ska agera, parvis, som coacher för andra årets studenter på datateknik i kursen Programvaruutveckling i grupp. 2.4 Enduro Projektet som utförs går under benämningen Enduro. Målet är att utveckla ett system för tidtagning till en tävling som går ut på att köra motorcykel på en stig i skogen. Det ska finnas ett program för registrering av tider och ett ytterligare program för hantering och sortering för tiderna registrerade under tävlingen. Det ska finnas möjlighet till olika tävlingstyper, något som kunden kräver efterhand. Studenterna i en utvecklingsgrupp har som mål att lära sig parallell utveckling i en större grupp med hjälp av XP. Samtidigt ska de även pröva på nya metoder att utföra en utvecklingsprocess, metoder som ingår i XP. 3 Estimeringtekniker 3.1 Mindre struktur Det existerar ej fördefinierade estimeringstekniker som saknar struktur helt och hållet [McC09, Hau06, Jør04]. Det finns även det en klar skillnad i hur pass mycket fokus är placerad på strukturen mellan teknikerna. Med struktur menas, i det här sammanhanget, hur djupgående tekniken är samt behovet av inlärningsmål för ett utförande [MØHB08]. För mer förståelse av ämnet i fråga krävs en tydlig beskrivning av de olika teknikerna behandlade i den här studien. Vi börjar med de med lite mindre struktur. 3.1.1 Planning Poker En relativt omtalad samt studerad teknik är Planning Poker [MØHB08, Hau06, Coh06]. Den blev först introducerad av James Grenning [Gre02] med syftet att kombinera erfarenheter och kunskaper från samtliga medlemmar i ett team. Medverkande i estimeringar får utdelat varsin kortlek med fördefinierade siffervärden. Dessa värden kan antingen representera implementationstid eller, så kallade, story points [Coh06]. För varje enhet som skall estimeras väljer medverkande ett kort från sin lek och placerar det framför sig med valörsidan nedåt. Korten visas inte förrän samtliga valt ett från sin lek. De medverkande som valt kort vilka skiljer sig från majoriteten behöver dela med sig av anledningen till valet. Det kan inträffa att en som valt ett lågt kort känner till ett speciellt sätt problemet kan lösas på eller att en medverkande med högt kort har erfarenhet av problemets svårighetsgrad [Coh06, Hau06]. Omgångar fortsätter tills valörerna konvergerar mot ett visst värde. 2

3.1.2 Unstructured Groups En mindre strukturerad metod än Planning Poker är Unstructured Groups och har den simpla definitionen, precis som namnet gör anspråk, att estimeringar utförs gruppvis med diskussioner tills ett gemensamt beslut nås [MØHB08]. Den här tekniken är inte mycket studerad, däremot används den ofta ifall utvecklingsgruppen inte valt en annorlunda och mer strukturerad teknik [McC09, Jør04]. En studie av Moløkken-Østvold och Jørgensen [MØJ04] visade att estimeringar utförda i diskussionsgrupper var mer precisa än individuella estimat kombinerade med strukturerade tekniker. 3.1.3 Statistical Groups Exempel på en teknik där det tas hänsyn till individuella estimat är den ovannämnda Planning Poker. En ytterligare teknik med liknande princip är Statistical Groups. Vad som skiljer sig från denna metod och Planning Poker är främst anonymiteten [MØHB08]. Planning poker syftar på att estimeringar inte skall vara anonyma för det bidrar till brist av diskussion och argumentering av problemet inom teamet [Gre02, Coh06]. Med Statistical Groups utförs även estimeringar individuellt men istället används statistiska metoder för att få fram ett värde som speglar hela teamet. Det finns inga direktiv på mest lämplig statistisk metod för den här tekniken [Jør04, MØHB08]. Det kan t.ex. röra sig om väldigt simpla metoder som uträkning av medel- eller medianvärde. 3.2 Större struktur Till skillnad från det tre teknikerna i avsnitt 3.1 finns det även en del andra metoder med mer konkret struktur. Jag har valt, i den här studien, att studera två tekniker med större struktur. En utav metoderna går under benämningen Delphi och framtogs av ett företag vid namn Research ANd Development (RAND) tidigt under 50-talet [MØHB08]. Den andra tekniken, Decision Markets, använder diverse metaforer för att beskriva estimeringsprocessen. Det existerar inte någon stor skillnad mellan dessa två tekniker mer än deras sätt att utföras på [MØHB08]. 3.2.1 Delphi Delphi behandlar individuella estimeringar via enskilda diskussioner mellan en medverkande i estimeringsprocessen samt en moderator. Det utgörs, med andra ord, inga överenskommelser eller argumentation mellan de olika medverkande [MØHB08]. Dessa diskussioner pågår i iterationer med samtliga i teamet och bör bestå av konstruktiv återkoppling samt statistiska mått, likt i den ovannämnda tekniken Statistical Groups, för att delphi ska utnyttjas på rätt vis. Iterationer pågår tills det att ett majoritetsbeslut har nåtts vilket bestämts av moderatorn. En annan viktig punkt att poängtera är att medverkande i estimeringen bör vara experter inom området [Jør04, MØHB08]. 3.2.2 Decision Markets Den sista tekniken jag valt att studera har namnet Decision Markets. Den här metoden använder sig av en aktiemarknad (eng. stock market) som metafor där varje val (eng. decision) representerar ett aktiekapital (eng. stock) [MØHB08]. Medverkande till estimeringen bjuds in för att investera pengar i de val som de anser kommer att bli det slutgiltiga resultatet. Inom den här tekniken behöver inte, och bör inte, de medverkande enbart bestå av utvecklare utan också intressenter till projektet [MØHB08]. 3

En medverkande som investerat i ett val som blir det faktiska slutresultatet blir tilldelad ett fiktivt pris, exempelvis en summa pengar. Tekniken bygger således på att framhäva, anonymt bör markeras, aktörernas personliga åsikter och skapa en fördelning över de mest sannolika valen. Decision Markets behandlar engagemanget för de olika medverkande, något som en del studier eller forskare anser bör läggas stor vikt på [McC09, MØHB08]. 4 Påverkande faktorer För att kunna göra en någorlunda jämförelse i avsnitt 5 mellan teknikerna från avsnitt 3 har jag valt att gå närmare in på två olika faktorer jag anser har en påverkan på ett estimat. Detta avsnitt behandlar även en tredje faktor, exakthet (eng. accurcacy), vilket är grunden till att använda en fördefinierad estimeringsteknik. 4.1 Domänkunskap Inom området kravhantering placeras det en relativt stor vikt på analytikers, utvecklares samt kundens kunskaper kring domänen. För att lyckas genomföra ett mjukvaruprojekt krävs det information inom den domän slutprodukten berör. Ifall exempelvis kunden inte innehar tillräcklig domänkunskap görs processen med att ta reda på krav och eventuella behov betydligt svårare [McC09]. Det samma gäller utvecklare för implementering- och planeringssprocesser. Ett huvudsyfte med XP är att stödja förändringar på kundens krav genom utvecklingen, något som majoriteten av dess praktiker är tänkta behandla. Inom projektet Enduro introduceras utökningar samt förändringar av systemet redan vid andra iterationen. Vanligtvis orsakar detta ett problem bland de olika teamen. Däremot genereras inte ett lika stort problem vid efterföljande förändringar, vilket kan ses som en ökad domänkunskap. 4.2 Erfarenhet Ett estimat på en user story är vanligtvis baserat på tidigare erfarenheter så väl som programmeringskunskaper från den som estimerat [MØJ04, McC09]. I vissa fall kan det även handla om personlig intuition. Ifall benämningen expert är definierad, i utvecklingssammanhang, som en person med stor erfarenhet av utveckling vore det fördelaktigt att låta samma person ansvara för estimeringar vilka berör områden erfarenheten täcker. Ett problem kan däremot uppstå inom agil utveckling att lyckas ta reda på alla erfarenheter för samtliga medlemmar i ett team för att sedan dra nytta av dem [Coh06]. 4.3 Exakthet Att lyckas, vid varje försök, få exakta estimeringar har visat sig vara en omöjlighet [MØHB08, McC09, Jør04]. Anledningen är den stora mängden av faktorer som behöver tas till hänsyn samt att det finns ofta en gräns för hur mycket arbete man kan lägga ner på estimering innan exaktheten börjar bli sämre [Coh06]. Istället är det upp till projektteam att finna en balans mellan nerlagd tid och exaktheten [Gre02]. Denna balans blir dock aldrig ett statiskt mått. Den kommer istället ändras t.ex. då teamet får en större domänkunskap, rubrik 4.1, vilket betyder att mindre tid behöver användas för att få hög exakthet. 4

5 Implementering i XP-projekt Innan vi börjar med en direkt jämförelse mellan teknikerna från avsnitt 3 och utvärderar deras möjlighet till att implementeras i ett XP-projekt behövs det först en kort repetition av, vad jag anser, relevanta delar inom XP. Dessa områden är inte någon grund för jämförelsen mellan teknikerna utan det lämnas åt läsaren att själv bestämma deras betydelse för estimeringsprocessen. Kommunikation Grunden till mjukvaruutveckling som ett team är kommunikation mellan medlemmarna, eftersom det hjälper till att reda ut största mängden problem som uppstår under processen. Dålig eller brist av kommunikation kan leda till att kunskap och erfarenheter inte får flöda inom teamet. Återkoppling Genom kontinuerliga utgåvor (eng. release) får teamet möjlighet till återkoppling under utveckling och inte enbart i slutändan. Denna återkoppling är nyttig eftersom den kan indikera vad ett team i ett XP-projekt behöver stäva efter samt var ribban bör placeras. Reflektioner Vid varje planeringsmöte, borträknat det första, har teamet möjlighet till att själva reflektera över nerlagt arbete. Det ger oftast resultatet att medlemmar lyckas finna eventuella brister som de sedan kan arbeta för att förbättra. Även då inga brister hittas finns det aldrig ett perfekt XP-team, d.v.s. de bör alltid sträva efter förbättring. 5.1 Faktorernas roll Vad kan då sägas om de tre faktorerna i avsnitt 4? Förhoppningsvis leder det ofta till att kunskap om domänen ökar efterhand som projektet får fortgå. I mitt eget team var det relativt tydligt vid de första två planeringsmötena att någon god kunskap om domänen inte existerade. Däremot förbättrades kunskapen efterhand och i slutändan kunde varje medlem ge en förklaring på de olika delarna av systemet, vad de representerade och vad huvudmålet med projektet var. Erfarenhet har en viss liknelse med domänkunskap med hänsyn till att även det förbättras under projektet. Däremot tar dess betydelse inom estimering en annorlunda form. Resultaten av estimeringar från de olika teknikerna kommer till att ge skilda reslutat beroende på hur spridda erfarenheterna är inom teamet. De med stor erfarenhet har lätt för att överrösta de med mindre, vilket kan betyda att man går miste om en medlems lösning till ett problem enbart för den innehar mindre erfarenhet. Eftersom XP består av korta iterationer[bec99] bidrar det både till mindre enheter och funktionalitet att estimera samt fler tillfällen för ett team att planera. Ett team brukar vanligtvis försöka att tänka några steg framåt, men för det mesta estimeras ny funktionalitet utefter den nuvarande versionen av ett system. Detta gör det då även lättare för teamet att kunna ge mer exakta estimat eftersom de inte behöver placera allt för mycket vikt på senare tillägg eller förändringar, det är något som istället tas om hand i systemets design. 5.2 Tillämpning i XP Implementering av tekniker såsom Statistical Groups, Delphi och Decision Markets är fortfarande möjligt, trots att de inte föreskriver om diskussioner av medlemmarna och medverkande i estimeringsprocessen sinsemellan. Däremot bidrar de då även inte till kommu- 5

nikation i teamet samt det finns ingen möjlighet till att teamet lär ut teamet, d.v.s. att medlemmarna drar nytta och lärdomar av varandra. För att använda sig av Decision Markets i ett XP-projekt kan en del utav reglerna behöva modifieras. Istället för att placera ut pengar kan story points användas. Det största problemet är dock att modifiera aktiekapitalen, valen, utan att gå ifrån metaforen aktiemarknad. När det istället kommer till de tre mindre strukturerade teknikerna existerar inte samma problem för modifiering, helt enkelt eftersom det inte är nödvändigt. Eftersom spelreglerna till Planning Poker säger inget om vilka kort som bör ingå i en lek är det upp till moderatorn själv att bestämma. Detsamma gäller valet av statistisk metod för Statistical Groups. 5.3 Jämförelse Vad som visats finns det tydliga skillnader och likheter i de olika estimeringsteknikerna. Det som är mindre tydligt och kan kräva mer djupgående information är deras påverkan och krav på faktorer som domänkunskap och tidigare erfarenheter. Tabell 1 är en uppställning av samtliga studerade estimeringstekniker samt hur mycket de beror på i två av faktorerna från avsnitt 4. Dessa värden kommer ifrån djupgående läsning av vardera teknik samt utifrån korsreferens med tidigare studier angående estimering i grupp eller enskilt. Värt att nämna är att värdena är även min egen uppfattning av den tillgängliga informationen från tidigare forskning [MØHB08, Jør04, McC09]. Teknik Struktur Domänkunksap Erfarenhet Planning Poker Låg Liten Normal Unstructured Groups Låg Normal Normal Statistical Groups Låg Stor Stor Delphi Hög Normal Liten Decision Markets Hög Stor Stor Tabell 1: Jämförelse mellan de olika estimeringsteknikerna 6 Planning Poker i studentprojekt 6.1 Utgångspunkt Teamet den här studien utfördes på var samtliga studenter inom datateknik på LTH. Alla förutom en medlem befann sig på sitt andra läsår. Redan vid projektets start var det tydligt att det existerade en gemensam faktor angående XP. Ingen medlem hade dessförinnan samarbetat inom ett mjukvaruprojekt som använt sig av XP. De hade dessutom ingen erfarenhet av programmering utanför tidigare kurser vid LTH. 6.2 Kortleken Till studiens praktiska prövning användes åtta kortlekar om åtta olika kort, se figur 1. Ess, 2, 3, 5, 8, Knekt och Kung var de sju valörerna i kortleken och det åttonde kortet var en figur av en kaffekopp vars syfte var att indikera önskan av paus. Ifall någon utav deltagarna valt det sistnämnda kortet bröts estimeringsprocessen tillfälligt och gruppen tog en 15 minuters rast. 6

Figur 1: Kortleken för studien. 6.3 Resultat Nedan befinner sig resultaten av estimeringarna i form av tabeller för samtliga iterationer. Tabellerna är konstruerade med kolumner för estimerad tid (Tid?), faktisk tid (Tid!) samt differensen mellan de två för samtliga stories eller tasks. Negativa värden i sista kolumnen medför förluster i arbetskraft och har den direkta förklaringen att det inträffat en underestimering. 6.3.1 Iteration 1 Vid planeringsmötet inför den första iterationen utnyttjade teamet en metod likt Unstructured Groups från avsnitt 3. De delade upp sig i två mindre grupper om fyra personer, jag och min parcoach agerade som moderator för varsin grupp och varje story eller task estimerades efter de genomgått en kort diskussionsprocess. Anledningen till varför detta kan kallas ostrukturerat är eftersom vi gav teamet inga direktiv på hur de valde att genomföra processen. Det enda kravet som ställdes var att dela upp varje story i mindre delar, innan de estimerade, för att upprätthålla principen bakom baby steps [Bec99]. 7

Story/Task Tid? Tid! t 3.1 1h 15min 45min 3.2 2h 1h 30min 30min 3.3 2h 1h 23min 37min 3.4 2h 3h -1h 3.5 1h 1h 30min -30min 4 3h 23min 2h 37min 5 2h 1h 52min 8min 6 5h 3h 40min 1h 20min 7 3h 1h 32min 1h 28min 8 2h 15min 1h 45min C 3h 1h 32min 1h 28min Totalt 26h 16h 52min 9h 8min Tabell 2: Iteration 1 6.3.2 Iteration 2 Det andra planeringsmötets estimeringar utfördes i linje med det föregående. Inget ändrades i metodiken. Nämnvärt angående tabell 3 är att Story B påbörjades under första iterationen. Story/Task Tid? Tid! t B 2h 3h 12min -1h 12min 9 5h 4h 15min 45min 10 3h 2h 20min 40min 11 2h 1h 1h 13 3h 4h -1h 14 2h 50min 1h 10min Totalt 17h 15h 17min 1h 43min Tabell 3: Iteration 2 6.3.3 Iteration 3 Precis som för de två tidigare iterationerna utfördes estimeringarna för iteration 3 på samma vis. Arbete på Story E pågick under hela föregående iteration och återupptogs vid starten för den här iterationen. 8

Story/Task Tid? Tid! t E 2h 8h 42min -5h 18min F 4h 45min 3h 15min 12 5h 1h 45min 3h 15min 15 2h 2h 0 16 2h 1h 1h 17 2h 35min 1h 25min 18 2h 2h 55min -55min 19 8h 1h 24min 6h 36min 20 1h 2h 49min -1h 49min Totalt 28h 21h 55min 6h 5min Tabell 4: Iteration 3 6.3.4 Iteration 4 Planning Poker introducerades under det fjärde planeringsmötet. Varje teammedlem fick en kortlek utdelad och det hölls en kort genomgång av spelreglerna. Teamet hade fler stories än i något tidigare möte att estimera men processen tog kortare tid. Ett flertal gånger ändrades majoritetens estimat efter korta diskussioner angående svårighetsgraden av en story. Story 20, 24 samt 25 påbörjades under iteration 3. Story/Task Tid? Tid! t G 3h 2h 40min 20min 26, 31 2 + 5h 6h 1h 25 3h 8h 20min -4h 20min 12 1h 2h 15min -1h 15min 24 2h 1h 50min 10min 20 2h 3h 39min -1h 39min 27 5h 2h 32min 2h 38min 23 2h 45min 1h 15min Totalt 25h 28h -3h Tabell 5: Iteration 4 6.3.5 Iteration 5 Även under det femte planeringsmötet användes planning poker som estimeringsteknik. Vid det här stadiet gick det att betrakta en ökad vana av systemet bland de olika medlemmarna. Detta gav resultatet att de kunde föra mer noggranna diskussioner kring varje story. Varje story för sig behöll fortfarande delvisa avvikelser mellan estimerad tid och faktisk tid. Däremot blev en mycket mindre skillnad mellan den totala estimerade tiden och den totala faktiska tiden, något som kan ses nedanstående tabell. 9

Story/Task Tid? Tid! t 31B 5h 2h 25min 2h 35min 32 1h 3h 30min -2h 30min 21 2h 4h 20min -2h 20min 22 1h 30min 30min 33B 8h 6h 2h Totalt 17h 16h 45min 15min Tabell 6: Iteration 5 6.3.6 Iteration 6 Förutom av vara den sista iterationen för projektet var även iteration sex det tredje och sista tillfället då teamet utnyttjade planning poker under planeringsmötet. En del utav de resterande stories omfattade kodgranskning och kvalitetsförsäkran, vilket gjorde det svårt för teamet att successivt diskutera lösningsförslag. Resultatet blev en minskning av exakthet i estimaten jämfört med föregående iteration. Story/Task Tid? Tid! t 30 8h 4h 4h 33A 5h 6h 50min -1h 50min 35 1h 24min 36min H 3h 2h 10min 50min J 3h 1h 4h Totalt 19h 14h 24min 4h 36min Tabell 7: Iteration 6 7 Slutsatser XP talar mycket om vikten av parallellt arbete inom ett mjukvaruprojekt. För att det ska uppnås behöver bl.a. kommunikationen inom teamet hållas hög. Även om det finns möjligheter till att modifiera en estimeringsteknik är det fortfarande fördelaktigt med stöd för gruppdiskussioner. Decision market är nog den teknik vilken minst passar till ett XP-projekt. Den förlitar sig mycket på att medverkande i estimeringar har god kunskap och erfarenheter av tidiga projekt och liknande system. Ifall den implementerades i ett XP-projekt skulle det även medföra att kunden medverkade i estimeringsprocessen, något som är i direkt motsättning till the planning game inom XP[BF00]. Den enda fördelen är att det kan bidra till kundens engagemang. Vad som kunde observeras under den praktiska tillämpningen av planning poker var skillnaden av engagemang och diskussioner under estimeringarna. Vid tillfällen då samtliga medlemmar i teamet behöver bidra med sina individuella åsikter och förslag krävs det då också att de genomför en noggrannare fundering innan deras val, istället för att bara välja ett värde så att man sen kan lägga den (en story) åt sidan. Vad som kan ses i tabellen nedan är att det gav en del positiva resultat att införa en fördefinierad estimeringsteknik. Det bör dock tas i beaktning är att ju fler iterationer som pågår desto mer bekväma känner sig ett team till deras projekt. Tabellen består av samma totala differens för vardera iteration från tabellerna under avsnitt 6.3. Den innehåller även 10

en kolumn för estimeringarnas exakthet vilket, i detta fall, är kvoten mellan totalt faktisk tid och totalt estimerad tid. Iteration t Exakthet 1 9h 8min 64.9 % 2 1h 43min 89.9 % 3 6h 5min 78.2 % 4 3h 89.2 % 5 15min 98.5 % 6 4h 36min 75.8 % Tabell 8: Sammanställning av samtliga iterationer. Ifall mer tid kunde utnyttjas till studien hade det utförts en större undersökning av skillnaden mellan metodiken som användes i de tre första iterationerna med gruppestimeringar utan struktur samt Planning Poker. Det hade även varit intressent för studien att prova en ytterligare teknik för att se ifall resultatet av både engagemang och exakthet förbättrats eller försämrats. Tack Ett stort tack till alla de som granskat den här studien samt gett återkoppling. Det har hjälpt till att förbättra både strukturen så väl som innehållet. Jag vill även tacka teamet (Team09, 2010-2011) för deras deltagande och vilja att pröva planning poker som estimeringsteknik. Referenser [Bec99] Kent Beck. Embracing change with extreme programming. IEEE Computer, 32(10):70 77, 1999. [BF00] K. Beck and M. Fowler. Planning Extreme Programming. Addison-Wesley, Boston, MA, 2000. [Coh06] Mike Cohn. Agile Estimating and Planning. Pearson Education, Inc, 2006. [Gre02] James Grenning. Planning poker or how to avoid analysis paralysis while release planning. 2002. [Hau06] Nils Christian Haugen. An empirical study of using planning poker for user story estimation. In AGILE, pages 23 34, 2006. [Jør04] [McC09] Magne Jørgensen. A review of studies on expert estimation of software development effort. Journal of Systems and Software, 70(1-2):37 60, 2004. Steve McConnell. Software Estimation: Demystifying the Black Art. Steve Mc- Connell (All), 2009. [MØHB08] Kjetil Moløkken-Østvold, Nils Christian Haugen, and Hans Christian Benestad. Using planning poker for combining expert estimates in software projects. Journal of Systems and Software, 81(12):2106 2117, 2008. [MØJ04] Kjetil Moløkken-Østvold and Magne Jørgensen. Group processes in software effort estimation. Empirical Software Engineering, 9(4):315 334, 2004. 11