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

Storlek: px
Starta visningen från sidan:

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

Transkript

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

2 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.

3 Innehåll 1 Inledning 1 2 Bakgrund Estimering Tidigare studier Coaching av programvaruteam Enduro Estimeringtekniker Mindre struktur Planning Poker Unstructured Groups Statistical Groups Större struktur Delphi Decision Markets Påverkande faktorer Domänkunskap Erfarenhet Exakthet Implementering i XP-projekt Faktorernas roll Tillämpning i XP Jämförelse Planning Poker i studentprojekt Utgångspunkt Kortleken Resultat Iteration Iteration Iteration Iteration Iteration Iteration Slutsatser 10 Referenser 11

4 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

5 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 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

6 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 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] 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] 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

7 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

8 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

9 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

10 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 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

11 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 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 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

12 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 h 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 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, h 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 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

13 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 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

14 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, ) 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, [BF00] K. Beck and M. Fowler. Planning Extreme Programming. Addison-Wesley, Boston, MA, [Coh06] Mike Cohn. Agile Estimating and Planning. Pearson Education, Inc, [Gre02] James Grenning. Planning poker or how to avoid analysis paralysis while release planning [Hau06] Nils Christian Haugen. An empirical study of using planning poker for user story estimation. In AGILE, pages 23 34, [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, Steve McConnell. Software Estimation: Demystifying the Black Art. Steve Mc- Connell (All), [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): , [MØJ04] Kjetil Moløkken-Østvold and Magne Jørgensen. Group processes in software effort estimation. Empirical Software Engineering, 9(4): ,

En praktisk studie i estimeringstekniker inom extreme Programming EDA270. Fredrik Åkerberg Tommy Kvant March 5, 2013

En praktisk studie i estimeringstekniker inom extreme Programming EDA270. Fredrik Åkerberg Tommy Kvant March 5, 2013 En praktisk studie i estimeringstekniker inom extreme Programming EDA270 Fredrik Åkerberg Tommy Kvant March 5, 2013 Contents 1 Introduktion 1 2 Bakgrund 2 2.1 Tracker programmet.........................

Läs mer

Planning Poker som estimeringsteknik

Planning Poker som estimeringsteknik Planning Poker som estimeringsteknik Joakim Andersson, Christian Lindgren Lunds Tekniska Högskola, Lund, Sweden {ic06ja9, dt05cl5}@student.lth.se 2 mars 2010 Sammanfattning I den här rapporten så undersöks

Läs mer

TDP023 Projekt: Agil systemutveckling

TDP023 Projekt: Agil systemutveckling TDP023 Projekt: Agil systemutveckling Johan Åberg johan.aberg@liu.se Tre moment Projekt 8hp Marknadsföring av produkt 2hp Kopplat till projektarbetet Individuell rapport 2hp Kopplat till projektarbetet

Läs mer

Scrum + XP samt konsekvensanalys

Scrum + XP samt konsekvensanalys Scrum + XP samt konsekvensanalys Daniel Nimren dt05dn8 Douglas Frisk dt05df1 Dept. of Computer Science, Lunds Tekniska Högskola, Sweden {dt05dn8 dt05df1}@student.lth.se 1 mars 2010 Sammanfattning Denna

Läs mer

Scrum + XP = sant. Kristian Björk D06, Lunds Tekniska Högskola dt05kb1@student.lth.se. Frederik Blauenfeldt Jeppsson. dt06fb8@student.lth.

Scrum + XP = sant. Kristian Björk D06, Lunds Tekniska Högskola dt05kb1@student.lth.se. Frederik Blauenfeldt Jeppsson. dt06fb8@student.lth. Scrum + XP = sant Kristian Björk D06, Lunds Tekniska Högskola dt05kb1@student.lth.se Frederik Blauenfeldt Jeppsson D06, Lunds Tekniska Högskola dt06fb8@student.lth.se 2010-03-02 1 Abstract Scrum och XP

Läs mer

SCRUM och agil utveckling

SCRUM och agil utveckling SCRUM och agil utveckling Johan Åberg johan.aberg@liu.se Agile Manifesto We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Läs mer

Agil programutveckling

Agil programutveckling Agil programutveckling Pontus Evertsson D00, Lunds Tekniska Högskola d00pe@efd.lth.se Anna Jennerheim D00, Lunds Tekniska Högskola d00aj@efd.lth.se 2003-05-15 1 1. Inledning 3 2. Extreme Programming (XP)

Läs mer

SCRUM. Marcus Bendtsen Institutionen för datavetenskap

SCRUM. Marcus Bendtsen Institutionen för datavetenskap SCRUM Marcus Bendtsen Institutionen för datavetenskap 2 Metodik Systematiskt tillvägagångssätt för att garantera utfallet Metodiken behöver passa kontexten och tillgängliga resurser Verifiering av metodiken

Läs mer

SCRUM vs. XP en jämförelse mellan två lättviktsmetodiker

SCRUM vs. XP en jämförelse mellan två lättviktsmetodiker SCRUM vs. XP en jämförelse mellan två lättviktsmetodiker Phut Tran D01, Lund Tekniska Högskola d01pt@efd.lth.se 21 februari 2006 Innehållsförteckning ABSTRACT... 3 1 INLEDNING... 4 2 VAD ÄR EN LÄTTVIKTSMETODIK?

Läs mer

F9 del B Organisatoriskt. EDAF45 Programvaruutveckling i grupp Projekt Boris Magnusson Datavetenskap, LTH

F9 del B Organisatoriskt. EDAF45 Programvaruutveckling i grupp Projekt Boris Magnusson Datavetenskap, LTH F9 del B Organisatoriskt EDAF45 Programvaruutveckling i grupp Projekt Boris Magnusson Datavetenskap, LTH 1 Projektet - moment Projektstartsmöte 6 Iterationer (en per vecka) - 10-12 team - 12-14 personer

Läs mer

BESKRIVNING AV PROCESSMETODEN SCRUM

BESKRIVNING AV PROCESSMETODEN SCRUM NORDSCRUM BESKRIVNING AV PROCESSMETODEN SCRUM NORDSCRUM BESKRIVNING AV PROCESSMETODEN SCRUM INNEHÅLLSFÖRTECKNING inledning... 3 SCRUM... 3 Bakgrund... 3 Faser... 3 Ramverket... 3 Nordscrum... 4 StudentProjekt...

Läs mer

Nyttomaximering av spikes

Nyttomaximering av spikes Nyttomaximering av spikes Johan Hedin Sånemyr D11, LTH dat11jh1@student.lu.se Victor Shu-Ming Lam D11, LTH dat11vla@student.lu.se 2016-03-07 Sammanfattning Som projektledare av ett team programmerare så

Läs mer

F7 Agila metoder. EDAF45 Programvaruutveckling i grupp Projekt Boris Magnusson, Ulf Asklund Datavetenskap, LTH

F7 Agila metoder. EDAF45 Programvaruutveckling i grupp Projekt Boris Magnusson, Ulf Asklund Datavetenskap, LTH F7 Agila metoder EDAF45 Programvaruutveckling i grupp Projekt Boris Magnusson, Ulf Asklund Datavetenskap, LTH 1 XP - Scrum - Kanban Agila metoder Vad innehåller SCRUM Hur skiljer sig XP och SCRUM KANBAN

Läs mer

Proj-Iteration1. Arkitektur alt. 1

Proj-Iteration1. Arkitektur alt. 1 Proj-Iteration1 PVG/Coaching Boris Magnusson Datavetenskap LTH Proj-Iter1-1 Registrering Registrering Arkitektur alt. 1 Personuppgifter Starttid Sorterare Måltid Efterbehandling Resultat Tre program som

Läs mer

Deluppgift 2 Kravhantering a) (2p) När man diskuterar krav brukar man ange två olika typer av krav. Beskriv dessa och ge exempel.

Deluppgift 2 Kravhantering a) (2p) När man diskuterar krav brukar man ange två olika typer av krav. Beskriv dessa och ge exempel. Page 1 (5) Hemuppgift 1DV404 150115-150118 Deluppgift 1 Processmodeller a) (4p) Alla mjukvaruutvecklare följer någon form av utvecklingsprocess i sitt arbete. Diskutera vad organisationer brukar ange som

Läs mer

12 principer of agile practice (rörlig)

12 principer of agile practice (rörlig) X-treme programming 12 principer of agile practice (rörlig) Ge nöjd kund genom tidig och kontinuerliga leveranser Den viktigaste punkten som betyder att min vill ha kontinuerlig feedback Välkomna sena

Läs mer

extreme Programming refactored - recension och analys av Kent Becks senaste definition av XP

extreme Programming refactored - recension och analys av Kent Becks senaste definition av XP extreme Programming refactored - recension och analys av Kent Becks senaste definition av XP Måns Gunnarsson d01mg@efd.lth.se Sammanfattning Denna djupstudie består av en recension av andra upplagan av

Läs mer

En studie om parprogrammering i praktiken

En studie om parprogrammering i praktiken En studie om parprogrammering i praktiken Mia Nyström Karin Wanhainen Johan Rix 29 maj 2002 Sammanfattning Parprogrammering är en av de mest omdiskuterade grundstenarna i Extreme Programming (XP). All

Läs mer

Reflektion i Agila Projekt Djupstudie

Reflektion i Agila Projekt Djupstudie Reflektion i Agila Projekt Djupstudie Cornelia Jeppsson dat11cje@student.lu.se Alexander Wallin alexander@wallindevelopment.se Abstract Denna djupstudie undersöker hur reflektion ger stöd till utvecklarteam

Läs mer

Kanban i Extreme Programming

Kanban i Extreme Programming Kanban i Extreme Programming N. Fors och N. Hansson D06, Lunds Tekniska Högskola [niklas.fors niklas.hansson.06]@gmail.com 2mars2010 Abstract Kanban is a scheduling approach from the work philosophy just-intime

Läs mer

TDDD26 Individuell projektrapport

TDDD26 Individuell projektrapport TDDD26 Individuell projektrapport Kort beskrivning av projektet Vi hade som projekt att utveckla en digital media servicer som skulle hjälpa filmentusiasten att organisera sitt filmbibliotek. Programmet

Läs mer

F7 Agila metoder. EDAF45 Programvaruutveckling i grupp Projekt Boris Magnusson, Ulf Asklund Datavetenskap, LTH

F7 Agila metoder. EDAF45 Programvaruutveckling i grupp Projekt Boris Magnusson, Ulf Asklund Datavetenskap, LTH F7 Agila metoder EDAF45 Programvaruutveckling i grupp Projekt Boris Magnusson, Ulf Asklund Datavetenskap, LTH 1 XP - Scrum - Kanban - FDD Agila metoder: Vad innehåller SCRUM Hur skiljer sig XP och SCRUM?

Läs mer

Kritik av Extrem Programmering

Kritik av Extrem Programmering Kritik av Extrem Programmering Markus Borggren d01mbo@efd.lth.se Martin Persson d01mp@efd.lth.se D01, Lunds Tekniska Högskola 15 februari, 2004 Abstract I denna djupstudie kommer vi att försöka, på ett

Läs mer

2010-12-27 SCRUM. Vattenfallsmodellen. Analys. Design. Kod. Test. Rational Unified Process Agile. Kallas också linjär sekventiell modell.

2010-12-27 SCRUM. Vattenfallsmodellen. Analys. Design. Kod. Test. Rational Unified Process Agile. Kallas också linjär sekventiell modell. Vattenfallsmodellen SCRUM Analys Kallas också linjär sekventiell modell Introduktion Design Kod Test Rational Unified Process Agile DSDM Adaptive Software Development Crystal Feature-Driven Development

Läs mer

SCRUM och mycket mer

SCRUM och mycket mer Typ av dokument Anvisning Skapad Senaste uppdatering 2008-01-27 2008-11-13 1 (5) Sida 1 Det minsta möjliga? SCRUM och mycket mer Om man nu vill vara agile och inte har allt tid i världen, vad skall man

Läs mer

I detta avsnitt beskrivs vart parprogrammering appliceras, hur det ska fungera och även i vilket projekt det introduceras i.

I detta avsnitt beskrivs vart parprogrammering appliceras, hur det ska fungera och även i vilket projekt det introduceras i. PARPROGRAMMERING Mikael Möller, dt07mm5@student.lth.se 2011-02-28 Abstrakt Parprogrammering är ett arbetssätt där två programmerare arbetar tillsammans vid en dator med en uppgift. Studien behandlar frågor

Läs mer

PROJEKTLEDNING inom produktutveckling. Individuell inlämningsuppgift KPP039 Produktutvekling 3 Boris Mrden 2010-01-10

PROJEKTLEDNING inom produktutveckling. Individuell inlämningsuppgift KPP039 Produktutvekling 3 Boris Mrden 2010-01-10 PROJEKTLEDNING inom produktutveckling Individuell inlämningsuppgift KPP039 Produktutvekling 3 Boris Mrden 2010-01-10 Innehållsförteckning Inledning... 3 Projektarbete... 4 Projektledning & Ledarskap...

Läs mer

Uppsats i MDI En reflektion över designarbetet i tidigare inlämningsuppgift

Uppsats i MDI En reflektion över designarbetet i tidigare inlämningsuppgift Uppsats i MDI En reflektion över designarbetet i tidigare inlämningsuppgift Personlig uppsats i kursen Människa-datorinteraktion Magisterprogrammet MDI/ID 2003 11 03 Mattias Ludvigsson it3luma@ituniv.se

Läs mer

Inlämning 1 - Tentafrågor. Projektgrupp A

Inlämning 1 - Tentafrågor. Projektgrupp A Inlämning 1 - Tentafrågor Projektgrupp A 2010-11-17 Fråga \ Innlärningsmål Svar: 1 2 3 4 5 6 7 8 9 12 13 15 Fråga 1: LAU1 E x x Fråga 2: LAU1 E x Fråga 3: LAU8 B x x Fråga 4: LAU8 D x x x Fråga 5: LAU2

Läs mer

Proj-Iteration 5B. Plan för återstående iterationer

Proj-Iteration 5B. Plan för återstående iterationer Proj-Iteration 5B PVG/Coaching Boris Magnusson Datavetenskap LTH PVG/Coach 2009. Proj-Iter5B : 1 Plan för återstående iterationer Förutom att arbeta vidare på stories skall release göras både under iteration

Läs mer

Gruppdynamik och gruppsykologi i Extremet Programming

Gruppdynamik och gruppsykologi i Extremet Programming Gruppdynamik och gruppsykologi i Extremet Programming Jerry Malm, d02jm@efd.lth.se Gustav Olsson, d02og@efd.lth.se Lunds Tekniska Högskola Lund, den 22 februari 2005 Sammanfattning Denna djupstudie kan

Läs mer

Att effektivt strukturera, utföra och utvärdera spikes

Att effektivt strukturera, utföra och utvärdera spikes Att effektivt strukturera, utföra och utvärdera spikes Oscar Rydh - psy13ory@student.lu.se, Axel Rosén - mas11ar1@student.lu.se, and Joel Klint - dat13jkl@student.lu.se Lunds Tekniska Högskola Table of

Läs mer

CREATING VALUE BY SHARING KNOWLEDGE

CREATING VALUE BY SHARING KNOWLEDGE CREATING VALUE BY SHARING KNOWLEDGE PROJEKTLEDNING 101 Nidzara Dellien, Lund September 2017 PROJEKT En formell definition på projekt är följande (enligt Wikipedia): En temporär satsning för att framställa

Läs mer

Inspel till dagens diskussioner

Inspel till dagens diskussioner Intro till Agil Projektledning CMB 11 juni 2018 Mats Nyman Wenell Management AB Inspel till dagens diskussioner Historik och bakgrund Agila manifestet och de agila principerna SCRUM Kort om SAFe Wenell

Läs mer

Användarcentrerad systemdesign

Användarcentrerad systemdesign Användarcentrerad systemdesign Föreläsning 11: Agile-processer och ACSD Stefan Blomkvist Avdelningen för MDI/IT, Uppsala Universitet, Stefan.Blomkvist@hci.uu.se www.it.uu.se/edu/course /homepage/acsd/

Läs mer

Rätt ifylld bokstav ger 0.5 poäng och fel ifylld bokstav ger 0.5 poäng i avdrag. Rätt svar: Alternativ A, C, D, A, C uppifrån.

Rätt ifylld bokstav ger 0.5 poäng och fel ifylld bokstav ger 0.5 poäng i avdrag. Rätt svar: Alternativ A, C, D, A, C uppifrån. Uppgift 1 (2,5 p) Påstående/anledning-frågor. Denna fråga bygger på de olika strategier för t.ex. effektivare kund-leverantör samarbete som Damian och Chisan presenterar i sin artikel. För varje par av

Läs mer

PROJEKTRAPPORT EDA095 NÄTVERKSPROGRAMMERI

PROJEKTRAPPORT EDA095 NÄTVERKSPROGRAMMERI PROJEKTRAPPORT EDA095 NÄTVERKSPROGRAMMERI NG STRESS LUNDS TEKNISKA HÖGSKOLA - 2013-05-22 Projektmedlemmar: Emil Apelgren adi10eap@student.lu.se Fredrik Helander gda10fhe@student.lu.se Jonathan Klingberg

Läs mer

Kursöversikt Certifierad Mjukvarutestare

Kursöversikt Certifierad Mjukvarutestare Kursöversikt Certifierad Mjukvarutestare Kurs Poäng (5 yh poäng/vecka) Examensarbete 20 Grunderna inom test 20 Kommunikation i arbetslivet 15 Lärande i arbete 1 60 Lärande i arbete 2 60 Projektarbete 15

Läs mer

Planeringsspelets mysterier, del 1

Planeringsspelets mysterier, del 1 Peter Lindberg Computer Programmer, Oops AB mailto:peter@oops.se http://oops.se/ 28 februari 2002 Planeringsspelets mysterier, del 1 Om jag ska spela ett sällskapsspel för första gången så vill jag att

Läs mer

Concept Selection Chaper 7

Concept Selection Chaper 7 Akademin för Innovation, Design och Teknik Concept Selection Chaper 7 KPP306 Produkt och processutveckling Grupp 2 Johannes Carlem Daniel Nordin Tommie Olsson 2012 02 28 Handledare: Rolf Lövgren Inledning

Läs mer

Användarcentrerad systemdesign

Användarcentrerad systemdesign Användarcentrerad systemdesign Föreläsning 9: Agile-metoder, XP och ACSD Stefan Blomkvist MDI / IT, Uppsala Universitet, stefan.blomkvist@it.uu.se XP www.it.uu.se/edu/course /homepage/acsd/s04 Dagens föreläsning

Läs mer

Coaching av programvaruteam EDA270, djupstudie: Praktisk SCM användning i XP-projekt

Coaching av programvaruteam EDA270, djupstudie: Praktisk SCM användning i XP-projekt Coaching av programvaruteam EDA270, djupstudie: Praktisk SCM användning i XP-projekt Martin Malek Anders Hellström Lunds Tekniska Högskola 22 februari 2005 Version 1.0 Sammanfattning Som utgångspunkt för

Läs mer

Linköpings universitet 1 TDP029. Systemutveckling. Systemutveckling. Vanliga faser. Fler faser. Systemutvecklingsmetod

Linköpings universitet 1 TDP029. Systemutveckling. Systemutveckling. Vanliga faser. Fler faser. Systemutvecklingsmetod Systemutveckling TDP029 Systemutveckling Annika Silvervarg COIN/HCCS/IDA Systemutveckling kallas processen att ta emot en beställning på ett datorsystem, skriva en strukturerad kravspecifikation på systemet,

Läs mer

Riktlinjer för bedömning av examensarbeten

Riktlinjer för bedömning av examensarbeten Fastställda av Styrelsen för utbildning 2010-09-10 Dnr: 4603/10-300 Senast reviderade 2012-08-17 Riktlinjer för bedömning av Sedan 1 juli 2007 ska enligt högskoleförordningen samtliga yrkesutbildningar

Läs mer

Scrums användning i Extreme Programming projekt. Lunds Tekniska Högskola D07 Lars-Olof Rydgren EDA270 2011-03-01

Scrums användning i Extreme Programming projekt. Lunds Tekniska Högskola D07 Lars-Olof Rydgren EDA270 2011-03-01 Scrums användning i Extreme Programming projekt Lunds Tekniska Högskola D07 Lars-Olof Rydgren EDA270 2011-03-01 1 Sammanfattning I denna djupstudie givet av kursen Coaching i Programvaruutveckling på Lunds

Läs mer

Agile-metoder, XP och ACSD

Agile-metoder, XP och ACSD Användarcentrerad systemdesign. Föreläsning 12 Agile-metoder, XP och ACSD Stefan Blomkvist MDI / IT, stefan.blomkvist@it.uu.se & Profdoc AB www.profdoc.se www.it.uu.se/edu/course /homepage/acsd/s04 XP

Läs mer

Utvecklingsm odell och utvecklingsm etod för att skapa god kom m unikation

Utvecklingsm odell och utvecklingsm etod för att skapa god kom m unikation Kurs: Designm etodik, 3 p Delm om ent: Datum : 2 0 0 3-1 2-1 8 Utvecklingsm odell och utvecklingsm etod för att skapa god kom m unikation Nils Järgenstedt [ it3 jani@ituniv.se] Innehållsförteckning INLEDNING...

Läs mer

UPPGIFT 1 V75 FIGUR 1.

UPPGIFT 1 V75 FIGUR 1. UPPGIFT 1 V75 FIGUR 1. Varje lördag året om spelar tusentals svenskar på travspelet V75. Spelet går ut på att finna sju vinnande hästar i lika många lopp. Lopp 1: 5 7 Lopp 2: 1 3 5 7 8 11 Lopp 3: 2 9 Lopp

Läs mer

Spårning av krav i agila projekt

Spårning av krav i agila projekt Spårning av krav i agila projekt Jonas Andersson D04, Lunds Tekniska Högskola d04jad@student.lth.se Jonas Andersson D04, Lunds Tekniska Högskola d04jan@student.lth.se 2007-02-20 Abstract Denna rapport

Läs mer

Att införa XP. Daniel Nilsson och Mattias Nordahl Lunds Tekniska Högskola. 27 februari Abstrakt

Att införa XP. Daniel Nilsson och Mattias Nordahl Lunds Tekniska Högskola. 27 februari Abstrakt Att införa XP Daniel Nilsson och Mattias Nordahl Lunds Tekniska Högskola 27 februari 2012 Abstrakt Genom analys och sammanfattning av tidigare publikationer samt diskussion och reflektion av en högskolekurs

Läs mer

[Introduktion till programmering ]

[Introduktion till programmering ] KUNGLIGA TEKNISKA HÖGSKOLAN [Introduktion till programmering ] [Laboration med NXC] Tobias Johansson 05/09/13 tobiaj@kth.se Introduktionskurs i datateknik, II1310 Sammanfattning Vad som gör en ingenjör

Läs mer

SLUTRAPPORT: TEXAS HOLDEM 4 FRIENDS

SLUTRAPPORT: TEXAS HOLDEM 4 FRIENDS SLUTRAPPORT: TEXAS HOLDEM 4 FRIENDS Individuellt Mjukvaruutvecklingsprojekt (Utvecklare av digitala tjänster) Den 1 juni 2011 ABSTRAKT Rapporten tar upp positiva och negativa erfarenheter som jag erhållit

Läs mer

Verktyget FindBugs. Djupstudie i kursen EDA 270 Coachning av programvaruteam. Christofer Bach dt05cb6 Daniel Nilsson dt05dn4. Lunds Tekniska Högskola

Verktyget FindBugs. Djupstudie i kursen EDA 270 Coachning av programvaruteam. Christofer Bach dt05cb6 Daniel Nilsson dt05dn4. Lunds Tekniska Högskola Verktyget FindBugs Djupstudie i kursen EDA 270 Coachning av programvaruteam Christofer Bach dt05cb6 Daniel Nilsson dt05dn4 Lunds Tekniska Högskola 15 feb 08 1. Sammanfattning Denna djupstudie kommer att

Läs mer

Håller XP vad det lovar?

Håller XP vad det lovar? Håller XP vad det lovar? Johan Holmberg D01, Lunds Tekniska Högskola d01jh@efd.lth.se 24th February 2004 Sammanfattning Extreme programming har under sin korta livstid fått utstå hård kritik mot sitt sätt

Läs mer

Bedömning av Examensarbete (30 hp) vid Logopedprogrammet Fylls i av examinerande lärare och lämnas i signerad slutversion till examinator

Bedömning av Examensarbete (30 hp) vid Logopedprogrammet Fylls i av examinerande lärare och lämnas i signerad slutversion till examinator version 2014-09-10 Bedömning av Examensarbete (30 hp) vid Logopedprogrammet Fylls i av examinerande lärare och lämnas i signerad slutversion till examinator Studentens namn Handledares namn Examinerande

Läs mer

Kursprogram, ETSF20 Programvaruutveckling för stora projekt (PUSP), 7,5 hp

Kursprogram, ETSF20 Programvaruutveckling för stora projekt (PUSP), 7,5 hp Kursprogram, ETSF20 Programvaruutveckling för stora projekt (PUSP), 7,5 hp Version 1.0 Christin Lindholm Läsåret 2018/2019 Våren 2019 1. Inledning Syftet med kursen är att ge grundläggande kunskaper i

Läs mer

TDP023 Projekt: Agil systemutveckling

TDP023 Projekt: Agil systemutveckling TDP023 Projekt: Agil systemutveckling Johan Åberg johan.aberg@liu.se Tre moment Projekt 8hp Marknadsföring av produkt 2hp Kopplat till projektarbetet Individuell rapport 2hp Kopplad till projektarbetet

Läs mer

Bilagor Projektrapport VoteIT år 1

Bilagor Projektrapport VoteIT år 1 1(6) Bilagor Projektrapport VoteIT år 1 Innehåll Bilaga 1. Kravspecifikation... 2 Bilaga 2: Checklista för årsmötesprocessen... 3 Bilaga 3: Om typen av möten som ska stödjas... 5 Bilaga 4. Kvalitetsplan...

Läs mer

1. (3p) Inom MDI-området framhåller man att människor lär sig via metaforer. Hur menar man att detta går till?

1. (3p) Inom MDI-området framhåller man att människor lär sig via metaforer. Hur menar man att detta går till? 1. (3p) Inom MDI-området framhåller man att människor lär sig via metaforer. Hur menar man att detta går till? Att lära sig via metaforer innebär att man drar nytta av kunskap som användaren redan har,

Läs mer

Information via diagram inom ett XP-team

Information via diagram inom ett XP-team Information via diagram inom ett XP-team Staffan Åberg, Ludvig Åhlin D01, Lunds Tekniska Högskola d01sab@efd.lth.se d01lah@efd.lth.se Februari 2004 Abstrakt Detta arbete är inriktat på att förklara på

Läs mer

XP-projekt: En fördjupning

XP-projekt: En fördjupning XP-projekt: En fördjupning Extreme Programming Martin Karlsson marka@itn.liu.se K7522 011 36 34 63 Fem värden Kommunikation Var öppna Var ärliga Ta konflikter Diskutera Tag beslut Tag ansvar Kräver feedback,

Läs mer

Djupstudie - Datorbaserade system för tracking

Djupstudie - Datorbaserade system för tracking Djupstudie - Datorbaserade system för tracking Torbjörn Lundberg, dt05tl3 Joakim Svensson, dt05js8 18 februari 2008 Sammanfattning Tracking är ett hjälpmedel inom projekt för att hålla reda på information

Läs mer

Cult of Code Quality

Cult of Code Quality Jakob Schyberg (d00jsc) 2005-02-13 Coaching av Programvaruteam Josef Granqvist (d00jgr) LTH Institutionen för Datavetenskap Cult of Code Quality Vad kan en coach göra? Denna djupstudie handlar om kodkvalitet.

Läs mer

Proj-Iteration 3. Grov plan för releaser

Proj-Iteration 3. Grov plan för releaser Proj-Iteration 3 PVG/Coaching Boris Magnusson Datavetenskap LTH Proj-Iter3-1 Grov plan för releaser Kunden är mycket nöjd med första releasen som visar att stora framsteg gjorts med implementationsarbetet.

Läs mer

Kortspel. Ett spel - tusen upplevelser

Kortspel. Ett spel - tusen upplevelser Kortspel Ett spel - tusen upplevelser 1 Översikt över korten i kortleken 7 8 9 10 Knekt Överste Kung Ess 2 Prova olika spel Farmor / Mormor 3-5 7, 8, 9, 10, Knekt, Överste, Kung, Ess Reglerna för detta

Läs mer

RemoteBud. Inlämnas: Patrik Johnsson, e01pjo Viktor Karlsson, e01vk

RemoteBud. Inlämnas: Patrik Johnsson, e01pjo Viktor Karlsson, e01vk RemoteBud Inlämnas: 2005-02-01 Patrik Johnsson, e01pjo Viktor Karlsson, e01vk Abstract Skulle du också vilja styra dina lampor och rulla ner dina persienner med hjälp av din TV-fjärrkontroll? Remotebud

Läs mer

AGILA METODER. (för oss som inte kodar) Nina Berlin

AGILA METODER. (för oss som inte kodar) Nina Berlin AGILA METODER (för oss som inte kodar) Nina Berlin Agila värderingar 1. Individer och interaktioner framför processer och verktyg 2. Fungerande programvara framför omfattande dokumentation 3. Kundsamarbete

Läs mer

Identifiera kundbehov KPP306, Produkt och processutveckling, 15hp

Identifiera kundbehov KPP306, Produkt och processutveckling, 15hp 2008 02 21 Identifiera kundbehov KPP306, Produkt och processutveckling, 15hp PM, Seminarie SEM1, 3hp Kapitel 4 Seminariegrupp 7 Författare: Robin Hellsing Robin Jarl Handledare: Rolf Lövgren Sammanfattning

Läs mer

CDC en jämförelse mellan superskalära processorer. EDT621 Campus Helsingborg av: Marcus Karlsson IDA

CDC en jämförelse mellan superskalära processorer. EDT621 Campus Helsingborg av: Marcus Karlsson IDA CDC6600 - en jämförelse mellan superskalära processorer av: Marcus Karlsson Sammanfattning I denna rapport visas konkret information om hur den första superskalära processorn såg ut och hur den använde

Läs mer

PlantPuppy Räddaren för den som inte kan hålla växterna vid liv

PlantPuppy Räddaren för den som inte kan hålla växterna vid liv Lunds Tekniska Högskola Elektro- och informationsteknik Digitala Projekt PlantPuppy Räddaren för den som inte kan hålla växterna vid liv Gerda Sidwall Thygesen Sofia Sundbom Zoë Wyon ine14gth@student.lu.se

Läs mer

Ingenjörsinriktad yrkesträning - Softhouse Crossmedia Avenue. Ronny Roos, 85-02-27 4098 d04rr

Ingenjörsinriktad yrkesträning - Softhouse Crossmedia Avenue. Ronny Roos, 85-02-27 4098 d04rr Ingenjörsinriktad yrkesträning - Softhouse Crossmedia Avenue Ronny Roos, 85-02-27 4098 d04rr Inlämnad: 16 januari 2008 1 Softhouse - Crossmedia Avenue Crossmedia Avenue, är ett svenskt företag som ingår

Läs mer

D J U P S T U D I E I E D A S I M P L E C O D E A N D D E S I G N

D J U P S T U D I E I E D A S I M P L E C O D E A N D D E S I G N D J U P S T U D I E I E D A 2 7 0 S I M P L E C O D E A N D D E S I G N S. Marcus Jacobsson D03, Lunds Tekniska Högskola d03mj@efd.lth.se S. Magnus Weinberg D03, Lunds Tekniska Högskola d03mw@efd.lth.se

Läs mer

Mälardalens högskola

Mälardalens högskola Teknisk rapportskrivning - en kortfattad handledning (Version 1.2) Mälardalens högskola Institutionen för datateknik (IDt) Thomas Larsson 10 september 1998 Västerås Sammanfattning En mycket viktig del

Läs mer

Djupstudie Code smells / Refaktorisering. Martin Larsson dt08ml5 Stefan Johansson, dt08sj7

Djupstudie Code smells / Refaktorisering. Martin Larsson dt08ml5 Stefan Johansson, dt08sj7 Djupstudie Code smells / Refaktorisering Martin Larsson dt08ml5 Stefan Johansson, dt08sj7 27 februari 2012 Innehåll 1 Inledning 1 2 Bakgrund 1 2.1 extreme programming....................... 1 2.2 Programvaruutveckling

Läs mer

Planering. Planning. Hur planerar vi? Hur planerar vi? XP Bill of Rights. XP Bill of Rights

Planering. Planning. Hur planerar vi? Hur planerar vi? XP Bill of Rights. XP Bill of Rights Planning Extreme programming Planering In preparing for battle I have always found that plans are useless, but planning is indispensable - Eisenhower Vi planerar för att försäkra oss om att vi alltid gör

Läs mer

Joakim Jonsson jj222kc. Minesweeper. Individuellt Mjukvaruprojekt Joakim Jonsson

Joakim Jonsson jj222kc. Minesweeper. Individuellt Mjukvaruprojekt Joakim Jonsson Minesweeper Individuellt Mjukvaruprojekt Joakim Jonsson 08 06 2013 Abstrakt Nedan följer en slutrapport för projektet inom kursen Individuellt Mjukvaru utvecklingsprojekt. Jag har under dessa 10 veckor

Läs mer

Sverige under Gustav Vasa

Sverige under Gustav Vasa Sverige under Gustav Vasa Detta lektionsupplägg är planerat och genomfört av Daniel Feltborg. Upplägget är ett resultat av en praktiskt tillämpad uppgift i kursen Historiedidaktik då, nu och sedan, Malmö

Läs mer

Stödjande observationer

Stödjande observationer Bilaga 11. Stödjande Observationer Stödjande observationer Varför stödjande observationer? En framgångsfaktor för att utveckla undervisningen och öka förutsättningarna för att kunna bemöta elevernas behov

Läs mer

Inlämningsuppgift : Finn. 2D1418 Språkteknologi. Christoffer Sabel E-post: csabel@kth.se 1

Inlämningsuppgift : Finn. 2D1418 Språkteknologi. Christoffer Sabel E-post: csabel@kth.se 1 Inlämningsuppgift : Finn 2D1418 Språkteknologi Christoffer Sabel E-post: csabel@kth.se 1 1. Inledning...3 2. Teori...3 2.1 Termdokumentmatrisen...3 2.2 Finn...4 3. Implementation...4 3.1 Databasen...4

Läs mer

Observationsschema. Bakgrundsuppgifter. Skola: Observation nr: Årskurs/-er: Datum: Total lektionstid enligt schema (min):

Observationsschema. Bakgrundsuppgifter. Skola: Observation nr: Årskurs/-er: Datum: Total lektionstid enligt schema (min): 1 (7) akgrundsuppgifter Skola: Årskurs/-er: Observation nr: Datum: Total lektionstid enligt schema (min): Lärarens utbildning: ehörig lärare: J/N Lärarerfarenhet (antal år): ntal elever i klassen/gruppen:

Läs mer

SCRUM på Riksarkivet. Magnus Welander / 2011-05-26

SCRUM på Riksarkivet. Magnus Welander / 2011-05-26 SCRUM på Riksarkivet Magnus Welander / 2011-05-26 Agenda Metoden SCRUM Erfarenheter från Riksarkivet Sverige Metoden SCRUM Varför agile? Källa: Standish Group Önskedrömmar Kunden vet vad de vill ha Utvecklarna

Läs mer

Kurs-PM fo r HI1028, Projektkurs inom programvaruutveckling, VT16

Kurs-PM fo r HI1028, Projektkurs inom programvaruutveckling, VT16 Kurs-PM fo r HI1028, Projektkurs inom programvaruutveckling, VT16 Mål Kursen skall ge studenten träning i att utveckla en större programvara. Arbetet utförs i projektform. Projektet skall ge grundläggande

Läs mer

PMM (Process Maturity Metrics) Allmänt. Mätetal för framgångsfaktorer. 1. CM konfigurationsstyrning

PMM (Process Maturity Metrics) Allmänt. Mätetal för framgångsfaktorer. 1. CM konfigurationsstyrning PMM (Process Maturity Metrics) PMM är en metod för att mäta processmognad i utvecklingsprojekt. I korthet går metoden ut på att man utvärderar sin utvecklingsprocess med avseende på ett antal framgångsfaktorer

Läs mer

Bedömning av Examensarbete (30 hp) vid Logopedprogrammet Fylls i av examinerande lärare och lämnas till examinator

Bedömning av Examensarbete (30 hp) vid Logopedprogrammet Fylls i av examinerande lärare och lämnas till examinator version 2017-08-21 Bedömning av Examensarbete (30 hp) vid Logopedprogrammet Fylls i av examinerande lärare och lämnas till examinator Studentens namn Handledares namn Examinerande lärare Uppsatsens titel

Läs mer

Effekter av införande av agila metoder. Daniel Sundmark Mälardalens högskola

Effekter av införande av agila metoder. Daniel Sundmark Mälardalens högskola Effekter av införande av agila metoder Daniel Sundmark Mälardalens högskola Agila metoder Agila metoder Values T. ex., working software over comprehensive documentation (Agile manifesto) Agila metoder

Läs mer

MESI protokollet och dess derivater

MESI protokollet och dess derivater LTH LUNDS TEKNISKA HÖGSKOLA MESI protokollet och dess derivater Peter Persson 2015-12-08 Sammanfattning Dagens multicore processorer använder sig av ett flertal cacheminnen. Därför behövs det metoder för

Läs mer

F2 Konceptutveckling. Konceptutvecklingsprocessen och några stödjande metoder

F2 Konceptutveckling. Konceptutvecklingsprocessen och några stödjande metoder F2 Konceptutveckling Konceptutvecklingsprocessen och några stödjande metoder Disposition Introduktion Konceptgenerering Kreativa verktyg Presentation av koncept Konceptval Allmänt om koncept Ett koncept

Läs mer

BG306A Strukturmekanik, bärverksanalys MT129A Finita elementmetoden

BG306A Strukturmekanik, bärverksanalys MT129A Finita elementmetoden BG306A Strukturmekanik, bärverksanalys MT129A Finita elementmetoden Antal svar: 16 (14+28) 1. Flervalsfråga Andel Allmänt Hur tycker du kursen har varit? 1. Dålig 0% 2. Ganska bra 12,5% 3. Bra 50% 4. Mycket

Läs mer

Analys av BI-system och utveckling av BIapplikationer

Analys av BI-system och utveckling av BIapplikationer Computer Science Fredrik Nilsson, Jonas Wånggren Daniel Strömberg Analys av BI-system och utveckling av BIapplikationer Opposition Report, C/D-level 2005:xx 1 Sammanfattat omdöme av examensarbetet Vi tycker

Läs mer

Väl godkänt (VG) Godkänt (G) Icke Godkänt (IG) Betyg

Väl godkänt (VG) Godkänt (G) Icke Godkänt (IG) Betyg Betygskriterier Examensuppsats 30 hp. Betygskriterier Tregradig betygsskala används med betygen icke godkänd (IG), godkänd (G) och väl godkänd (VG). VG - Lärandemål har uppfyllts i mycket hög utsträckning

Läs mer

1) Kravhantering varför? (1.5p)

1) Kravhantering varför? (1.5p) 1) Kravhantering varför? (1.5p) Inlärningsmål : 10, 19 Kurslitteratur : [Dam], enligt kursmaterialet Enligt Damian/Chisan, vilka är de tre viktigaste vinsterna som ges av kravhantering inom mjukvaruutveckling?

Läs mer

Mentorsundersökningen 2018

Mentorsundersökningen 2018 Mentorsundersökningen 2018 Innehållsförteckning Sammanfattning...3 Inledning...4 Syfte...4 Metod...4 Enkäten...5 Resultat...6 Studielängd och tid med mentor...6 Information och kännedom om mentorsstöd...8

Läs mer

FÖRELÄSNING 8 DSV2PVT

FÖRELÄSNING 8 DSV2PVT Föreläsning 8 DSV2:PVT Kvalitet i mjukvara 1 FÖRELÄSNING 8 DSV2PVT Kvalitet i mjukvara, utvecklingsmodeller Beatrice Åkerblom beatrice@dsv.su.se Institutionen för Data- och Systemvetenskap (DSV) IT-Universitetet

Läs mer

Projektarbete. Anvisningar, tips och mallar. Sammanställt lå 05/06 av lärgruppen - Projektarbete

Projektarbete. Anvisningar, tips och mallar. Sammanställt lå 05/06 av lärgruppen - Projektarbete Projektarbete Anvisningar, tips och mallar Sammanställt lå 05/06 av lärgruppen - Projektarbete Henrik Andersson, Martina Johansson, Göran Johannesson, Björn Bergfeldt, Per-Erik Eriksson, Franz Kreutzkopf,

Läs mer

Titel Mall för Examensarbeten (Arial 28/30 point size, bold)

Titel Mall för Examensarbeten (Arial 28/30 point size, bold) Titel Mall för Examensarbeten (Arial 28/30 point size, bold) SUBTITLE - Arial 16 / 19 pt FÖRFATTARE FÖRNAMN OCH EFTERNAMN - Arial 16 / 19 pt KTH ROYAL INSTITUTE OF TECHNOLOGY ELEKTROTEKNIK OCH DATAVETENSKAP

Läs mer

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

Pavel Denisov D01, Lunds Tekniska Högskola 21:e februari 2006 Hur ett XP-projekt påverkas av ett webbaserad projekthanteringsverktyg Pavel Denisov D01, Lunds Tekniska Högskola d01pd@efd.lth.se 21:e februari 2006 Abstrakt XP är bra att organisera små exibla grupper

Läs mer

Användningscentrering i agila utvecklingsprojekt. johanna.sarna@valtech.com Valtech

Användningscentrering i agila utvecklingsprojekt. johanna.sarna@valtech.com Valtech Användningscentrering i agila utvecklingsprojekt johanna.sarna@valtech.com Valtech Vem är jag? Johanna Särnå Jobbar på Valtech sedan 3 år tillbaka Jobbar där med användbarhet och projektledning Certifierad

Läs mer

Djupstudie i parprogrammering

Djupstudie i parprogrammering Djupstudie i parprogrammering Abstrakt P. Abrahamsson D05, Lunds Tekniska Högskola dt05pa1@student.lth.se P. Norlander D07, Lunds Tekniska Högskola dt07pn3@student.lth.se 2011-02-25 Denna studie handlar

Läs mer

Li#eratur och empiriska studier kap 12, Rienecker & Jørgensson kap 8-9, 11-12, Robson STEFAN HRASTINSKI STEFANHR@KTH.SE

Li#eratur och empiriska studier kap 12, Rienecker & Jørgensson kap 8-9, 11-12, Robson STEFAN HRASTINSKI STEFANHR@KTH.SE Li#eratur och empiriska studier kap 12, Rienecker & Jørgensson kap 8-9, 11-12, Robson STEFAN HRASTINSKI STEFANHR@KTH.SE Innehåll Vad är en bra uppsats? Söka, använda och refera till litteratur Insamling

Läs mer