Studie av estimeringstekniker för Extreme Programming. F. Stål D08, Lunds Tekniska Högskola
|
|
- Ulla-Britt Martinsson
- för 7 år sedan
- Visningar:
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 Contents 1 Introduktion 1 2 Bakgrund 2 2.1 Tracker programmet.........................
Läs merPlanning 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 merTDP023 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 merScrum + 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 merScrum + 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 merSCRUM 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 merAgil 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 merSCRUM. 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 merSCRUM 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 merF9 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 merBESKRIVNING 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 merNyttomaximering 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 merF7 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 merProj-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 merDeluppgift 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 mer12 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 merextreme 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 merEn 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 merReflektion 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 merKanban 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 merTDDD26 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 merF7 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 merKritik 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 mer2010-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 merSCRUM 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 merI 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 merPROJEKTLEDNING 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 merUppsats 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 merInlä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 merProj-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 merGruppdynamik 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 merAtt 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 merCREATING 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 merInspel 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 merAnvä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 merRä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 merPROJEKTRAPPORT 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 merKursö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 merPlaneringsspelets 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 merConcept 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 merAnvä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 merCoaching 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 merLinkö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 merRiktlinjer 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 merScrums 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 merAgile-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 merUtvecklingsm 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 merUPPGIFT 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 merSpå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 merAtt 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 ]
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 merSLUTRAPPORT: 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 merVerktyget 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 merHå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 merBedö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 merKursprogram, 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 merTDP023 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 merBilagor 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 mer1. (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 merInformation 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 merXP-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 merDjupstudie - 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 merCult 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 merProj-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 merKortspel. 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 merRemoteBud. 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 merAGILA 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 merIdentifiera 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 merCDC 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 merPlantPuppy 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 merIngenjö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 merD 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 merMä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 merDjupstudie 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 merPlanering. 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 merJoakim 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 merSverige 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 merStö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 merInlä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 merObservationsschema. 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 merSCRUM 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 merKurs-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 merPMM (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 merBedö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 merEffekter 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 merMESI 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 merF2 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 merBG306A 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 merAnalys 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 merVä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 mer1) 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 merMentorsundersö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 merFÖ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 merProjektarbete. 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 merTitel 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 merPavel 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 merAnvä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 merDjupstudie 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 merLi#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