Scrums användning i Extreme Programming projekt. Lunds Tekniska Högskola D07 Lars-Olof Rydgren EDA

Transkript

1 Scrums användning i Extreme Programming projekt Lunds Tekniska Högskola D07 Lars-Olof Rydgren EDA

2 Sammanfattning I denna djupstudie givet av kursen Coaching i Programvaruutveckling på Lunds Tekniska Högskola (LTH) kommer Scrum att hanteras vid sidan om ett Extreme Programming-projekt (XP). XP används i kursen Programvaruutveckling i Grupp (PVG) som läses av studenter från olika åldersgrupper och program på LTH. Perspektivet av denna djupstudie kommer ligga från coachens sida som läser Coaching i Programvaruutveckling och utvecklarna kommer vara studenter från PVG-kursen i ett team på cirka tio personer. Scrum kommer i denna djupstudie analysera era av dess metoder för att sedan förhoppningvis kunna implementera ett ertal i PVG-projektet utan att överlappa för mycket av idén bakom XP; vissa metoder är identiska till XP om några generaliseringar görs, vissa går utanför kursens restriktioner och vissa kan komplementeras tillsammans med XP. Djupstudien kommer därför gå igenom mycket av terminologin för Scrum och jämföra dess skillnad till XP. Till slutet kommer de Scrum-inspirerade delar som applicerar på PVG-projektet att presenteras; framförallt görs en Product Management Sprint Backlog analysis som utvärderar hur projektet har gått från Scrums perspektiv. 2

3 Innehåll 1 Inledning 4 2 Scrum Roller inblandade i Scrum Hur ser processen ut? Pre-game - planering Game - utvecklingen av produkten Post-game Övriga moment och termer i processen Adoptera Scrum Var börjar man? Vilka underlag och vilken miljö förväntas? Vilka är Scrums svaga punkter? Användning av Scrum i PVG-projektet 10 5 Slutsats 12 6 Referenser 14 3

4 1 Inledning Scrum och XP har mycket gemensamt vilket gör att de fungerar bra som komplement för ett företag som driver en agil mjukvaruutveckling. Båda har sin egen terminologi för dess utförande och vilka riktilinjer som ska följas för att uppnå deras metodologi. I PVG-kursen kan inte Scrum bli tillämpat optimalt pågrund av att det är ett ramverk som beskriver mycket av hur man ska organisera och planera ett företags mjukvaruutveckling - till jämförelse med XP som förklarar mer om hur man ska programmera [1]. Därför kommer denna djupstudie spegla mycket av dess innehåll mot Scrums användning i företag för att hitta alla likheter respektive olikheter mellan Scrum och XP. Många av Scrums likheter används automatiskt i PVG-projektet, medans olikheterna saknar antingen omfånget från företagsnivå eller är för omfattande för att kunna tillämpas i detta projekt. För att hitta alla likheter och olikheter måste mycket av teorin gås igenom stegvis och jämföras med XP. Djupstudien kommer däremot inte beskriva XP alltför mycket, endast nämna de delar som kolliderar eller överlappas av Scrum. Synvinkeln som XP kommer ha på det hela är hur den tillämpas i PVG-kursen och inte nödvändigtvis i näringslivet. När vi vet vad Scrum handlar om måste vi ta reda på hur man adopterar Scrums metodologi. Om vi identierar en Scrum praxis som platsar in i PVGprojektet - hur ska vi då angripa användningen av den och vilka underlag krävs av Scrum för att kunna använda den? Antas det samma miljö som XP? Måste några generaliseringar göras för att kunna korskoppla de båda? Detta utforskas vidare i avsnitt 3. I avsnitt 4 kommer de moment som Scrum har att erbjuda att sammanställas. Många av dem kan anses analoga till de metoder som PVG-projektet redan använder, och att hitta någon konkret skillnad mellan Scrum och XP är onekbart väldigt svårt. En Scrum metod för att sammanställa data från hela projektets iterationer är det mest konkreta som kommer utnyttjas i denna djupstudie. Denna sammanställda data kan gömma mycket informativa mönster eller spår från dåligt planerade iterationer. 2 Scrum Scrum är ett ramverk för mjukvaruutveckling, den beskriver en typisk iterativ process som ska följas ända fram till att produkten är färdig-utvecklad. Processen är agil i den mån om att det är ett själv-organiserat litet team av utvecklare som är optimerat på exibilitet, produktivitet och en varierande marknad med nära kontakt till kunden. 2.1 Roller inblandade i Scrum Det nns tre huvudroller i Scrum som man måste veta om [2]: Product Owner: Denna person är kunden från ett företag som kommer ställa krav på teamet så att han/hon får den produkt som önskas. Product 4

5 Owner ansvarar för att utvecklingen blir konsistent och sysselsatt med tillräckligt många krav för att skapa en aktiv miljö fram tills releasen. En Product Backlog (PB) (som vi pratar mer om i 2.2) kommer kunden att fylla med prioriterade items - där varje item är en funktionalitet som ska implementeras i produkten. ScrumMaster: Detta är coachen för ett team. ScrumMaster ska upprätthålla att Scrums riktlinjer och regler följs av utvecklarna. Teamet behöver även organisera sig, förstå målet och lösa upp eventuella konikter inom teamet. Detta hjälper ScrumMaster till med, samt att struktuera så det blir mer yt i produktiviteten. The Team: Teamet är de 5-9 utvecklarna som levererar, designar, testar, refaktoriserar, dokumenterar och konverserar med Product Owner för att få en klar bild på vad produkten ska innehålla. Deras expertis ska innefatta alla roller som har med funktionaliteten att göra - testning, kodkvalitet, mönster etc. Detta är viktigt för att kunna få ett självständigt drivande team. 2.2 Hur ser processen ut? Det yttersta skalet av Scrum kan man dela upp i tre faser [3][4] som visas tydligare i Figur 1: Pre-game - planering Detta är främst Product Owner's fas där visionen av produkten ska brytas ner i delar och presenteras tydligt för mjukvaruutvecklarna. Denna fas består i sin tur av två sub-faser: Planning: Här planerar Product Owner den Product Backlog som successivt byggs upp av items med beskrivningar om funktionaliteten som så småningom ska implementeras. En ny produkt börjar alltid med en vision [5] som ytligt beskriver den initiala idén. En vision bryts ner era theme som beskriver det tekniska omfånget och möjliga marknads relaterade problem. Ett theme bryts ner till concepts som beskriver en grupp av stories relaterade till varandra. Varje concept har i sin tur requirement denitions som skulle kunna jämföras med stories från XP, till och med ännu mer specierade än så är tasks. Specikationerna kan vara allt från nya system, bugg xar, ändringar på något gammalt och refaktoriseringar. Samtidigt som denna Product Backlog skapas så ska Product Owner prioritera vilka items som ska utvecklas först. System Architecture: Här får teamet en chans att gå igenom Product Backlog djupare, kolla vilka modikationer som behöver göras, eventuella design ändringar i programmet, analysera vilka problem som kan uppstå osv. Är det en ny produkt så bör det undersökas tydligare om vilken vision Product Owner hade i tanken när idén kom, så att de får en bra solid projektstart. Komplikationer ska diskuteras och frågor måste besvaras innan nästa fas påbörjas. 5

6 Figur 1: Scrums iterativa process visar hur en Product Backlog skapas och förs vidare igenom utvecklingen Game - utvecklingen av produkten Här börjar en iterativ mjukvaruutveckling av produkten där varje iteration kallas för en Sprint som vanligtvis löper över två till fyra veckor. Sprintens längd är anpassad till tidsestimeringen av en Product Management Sprint Backlog (PSB) som innehåller items valda från Product Backlog. [5] Varje sprint börjar med ett planerings möte, resultatet av den är en tidsestimerad och item-prioriterad PSB. PSBn kommer göras mer implementeringsvänlig och bilda en Development Sprint Backlog (DSB). Teamet programmerar, testar, designar och dokumenterar under denna sprint där de följer innehållet från PSB. Det är inte alltid alla steg behövs för att bryta ner en vision. I PVG-projektet skulle en vision motsvara hela Enduro programmet. I slutet av varje sprint återkopplas vad som åstadkommits med teamet i ett möte, kallad en Sprint Review. Allt som är färdig implementerat presenteras för Product Owner så att en uppdaterad version av Product Backlog skapas till nästa sprint över vad som missades eller eventuella tillägg som bugg x osv Post-game Produkten är färdigutvecklad och man gör i ordning produkten för marknaden - integration, testning och dokumentation m.m. 2.3 Övriga moment och termer i processen Sprint Planning Meeting: Som nämns under kommer varje sprint börja med ett möte, detta mötet kallas Spring Planning Meeting. Det är ett möte mellan ScrumMaster, Product Owner och teamet där en PSB ska skapas utifrån en PB. PSB kommer innehålla estimerade och prioriterade items. Product Owner kommer välja de items med högst prioritet och teamet ska diskutera dessa resonabelt beroende på hur mycket tidsenheter de tror de kan implementera under 6

7 sprinten. Daily Scrum Meeting: Innan dagen startar har man ett stand-up möte som det diskuteras med alla utvecklare om vad som hände förra dagen, vad man har för planer idag och eventuella problem som måste åtgärdas [5]. Burn-Down Chart: Efter varje sprint kommer en så kallad burn-down chart att uppdateras. Idén handlar om att prediktera vilket datum produkten är färdig - detta görs med hjälp av att estimera antalet tidsenheter hela projektet kommer att ta och efter varje sprint dra bort den summa tidsenheter som har implementerats. Eftersom tidsestimeringen av stories sker iterativt i PVG-projektet kan detta inte tillämpas där. Sprint Retrospective: Detta handlar om att reektera föregående iteration med hela gruppen och få feedback från Product Owner på vad som gick bra och dåligt. Något av de som gick dåligt ska sättas i fokus för nästa iteration och följas upp, så att det sker en förbättring i utvecklingen av produkten. Dock ska de saker som var bra inte glömmas. PSB analysis: Är en sammanställd tabell med tasks från alla iterationer där eventuella mönster i produktiviteten kan hittas. Den beskriver mycket av task strukturen för varje iteration i projektet och hur interna förändringar påverkar resultatet antingen positivt eller negativt. Den visar även hur stort arbete som förväntas på varje person i teamet. 3 Adoptera Scrum När ett företag ska adoptera Scrum i deras team så beror det mycket på vad den tidigare mjutvaruutvecklingsmetoden var. Studenterna i PVG-projektet har med stor sannolikhet ingen praktisk erfarenhet av agila metoder sedan innan, men har en teoretisk bakgrund av XP som delar många agila karaktäristiker med Scrum. 3.1 Var börjar man? Det handlar mer om att teamet ska acceptera Scrum som ett bra sätt att jobba på. Det är inte alltid man vill byta arbetssätt om motivet saknar innebörd, och det är inte alltid företaget tillåter att man gör det [6]. Det nns på så sätt alltid två huvudspärrar för varje företag innan de kan implementera Scrum: Brist på information angående Scrum Företaget tillåter inte skiftet till en annan modell Det räcker med att upplysa personalen om Scrum - förklara vokabulären, metaphorerna, hur det fungerar och framhäva dess agila sida som en styrka. Så fort denna information har landat i folkets öron kommer tankarna att sprida sig på alternativa tillvägagångssätt att programmera och hantera mjukvaruutvecklingen. In a reasonably healthy company, once the impediments to adoption are removed, Agile adoption will occur. [6] 7

8 Med andra ord - Scrum händer, om det ska hända. Faktumet är att varje individ kommer vilja arbeta på ett sätt som passar dem bäst. Hittar de styrkan hos Scrum så kommer de dra sig dit själva, och därmed företaget, tillåtelse av företaget är på så sätt högst subjektivt till var gränsen går. Denna attidyd för att adoptera Scrum fungerar dock inte i PVG-projektet för det kräver att studenterna kan teorin bakom Scrum, samt att kursen accepterar dess användande till fullo istället för XP. I vårat fall får vi hitta liknelser mellan Scrum och XP eller specialfall där Scrum kan hoppa in som en utfyllnad av något XP missade. För att göra detta måste karaktäristikerna hittas för respektive, vilket gås igenom djupare i avsnitt 4.2 och 4.3. Samma tänk som Scrum händer, om det ska hända kan dock tidigt märkas även i XP - om utvecklarna i PVG-projektet inte nner t.ex. Test-Driven- Development lämpligt, saknar kunskap eller inte ser dess styrka så kommer den att sorteras bort från arbetsdagen. ScrumMaster eller coachen måste på så sätt aktivt ansvara för att tydliggöra och följa upp reglerna för Scrum eller XP. Focus Practice var en del av coachernas uppgift att uppmana teamet om varje vecka vad som gällde. En Focus Practice på Daily Scrum möte är fullt möjligt. 3.2 Vilka underlag och vilken miljö förväntas? I en studie på IT-industrin i Pakistan undersöktes spärrarna för en implementering av Scrum, de kom fram till fem större anledningar som stärkte acceptabiliteten för Scrum [3]: Genemsamt direktiv Kollektiva beslut istället för autokratiska Stärkande av teamet Bra prioritering av produktens funktionalitet Bra arbetsmiljö Mycket av vad som får Scrum att frodas i ett företag är att engagera stakeholders, managers, direktörer och team leaders i konceptet [6]. Är de tillräckligt intresserade så har de chansen att inuera deras teammedlemmar i Scrums riktilinjer. Det behövs engagemang från de överordnande rollerna samt det individuella intresset. Scrum kräver även beslut som alla känner sig involverade i. Mycket av samarbetet ligger i att diskutera fram beslut, lösa eventuella konikter och hitta en gemensam nämnare. Om beslutet sedan blir alltför autokratiskt kommer detta skapa mindre engagemang. Problemet kallas lack of commitment som närmare beskrivs av P. Lencioni's Five Dysfunctions [7], och har mycket med gruppens psykologi att göra vilket gör att detta också gäller för XP. Ett Scrum team måste stärkas och peppas till liknelse av vad ett fotbolls team behöver (ordet Scrum härstammar till och med från rugbyn), fast i en annan form. För fullständig dedikation av varje utvecklare behövs en yttre kraft som motiverar dem till arbetet och hjälper dem lösa problemen tillsammans, här 8

9 måste ScrumMaster särskillt hjälpa till i projektstarten. Även här är coachens ansvar i XP projektet analogt för det har att göra med situationsanpassat ledarskap som beskrivs närmare av FIRO-modellen [8], vilket är generellt för alla coacher, speciellt i agilt sammanhang. I pre-game fasen där mycket av strukturen faller på plats så måste prioriteringen av de items som ska implementeras inte ske i en vattenfalls liknande anda, beslut kan komma och gå. Product Owner kommer ändra prioriteringarna efter varje sprint och då är det viktigt att inte planera för långt fram. I Scrum varar dock en sprint i 2-4 veckor till skillnad från PVG-projektets motsvarande till sprint - en iteration, vilket är på en vecka. Detta innebär att planeringsmötena i Scrum har större vikt på att få fram något konstruktivt om det ska visa betydelse för fyra veckor framöver, tillskillnad från en plan för bara en vecka. Vilket också är anledningen till att mer tid har reserverats åt Sprint Planning Meeting än till PVG-kursens planeringsmöte (tre timmar respektive två timmar). Miljön där man arbetar måste vara anpassad till Scrums riktlinjer. Product Owner ska alltid vara nära till hands, det är då viktigt att man håller honom/henne uppdaterad på var projektet ligger och frågor angående funktionaliteten ska diskuteras så snabbt som möjligt. Utvecklingen kommer aldrig följa den initiala planen, så varje utvecklare måste vara öppen för ändringar. Även i XP så ska kunden jobba inom teamet och vara nära till hands [9]. Denna studie från Pakistan applicerar väl över vad som kan anses analogt mellan XP och Scrum. Vi har fått reda på att ScrumMaster delar samma ansvar som en coach i ett XP projekt - skapa engagemang, stärka teamet, ingripa vid problematik, vara medveten om Lencioni's dysfunktioner och FIRO-modellen. Product Owner/kunden skall vara nära till hands [10], prioritera stories efter varje iteration/sprint, svara på frågor och som vi lärde oss från avsnitt planera items/stories till utvecklarna. Vi har även fått reda på att i Scrum Planning Meeting diskuteras följande iteration/sprint mer genomgående än planeringsmöten i XP eftersom en sprint är längre än en XP iteration. Vilket innebär att prioriteringar och estimeringar har en större betydelse för Scrum att göras korrekt i detta mötet. 3.3 Vilka är Scrums svaga punkter? Som nämnts tidigare så händer Scrum om det ska hända, det krävs rätt miljö för att det ska fungera, t.ex. är kommunikationen en stor faktor för Scrums eektivitet [11]. Brister detta fundament blir det en stor risk för projektet. Detta gäller även för kommunikationen mellan era teams i större projekt som kanske inte har lokal tillgång till varandra. Följande sju risker för större projekt har identierats på Global Software Development (GSD) när Scrum använts, alla applicerar inte på små projekt som PVG-kursen men har ändå en relevans i att avslöja Scrums svaga punkter: Asynkron kommunikation, svårt att hitta tidsutrymme för möten med alla involverade Brist på teamets översiktliga vy av projektet 9

10 Kommunikationen saknar omfång För lite vertyg som hjälper samarbetet och kommunikationen För många utvecklare i ett team Inte tillräckligt med dedikerade mötesrum Teamen är inte alltid lokalt nära varandra för att kunna mötas Slutsatsen som kan dras av detta är att Scrum är högst benäget av att ha en socialt stimulerad miljö mer än något annat. Nästan alla nämnda risker har med bristfällig kommunikation att göra. Att det är för många utvecklare på samma team handlar också om att kommunikation blir klumpig och mindre agil. Produktiviteten styrs av denna faktor med andra ord. Detta måste man ha i åtanke när ens företag ska adoptera Scrum. Att använda strategier för att minimera kommunikationsfel är högst relevant, t.ex. splitta större teams i två delar men ändå ha dem lokalt nära varandra, använd Wiki eller gemensamma kanaler där informationen kan delas, rotera arbetsområden för utvecklarna så de blir mer uppmärksamma på andra delar av koden eller planera mötena väl innan om vad som måste gås igenom [11]. Kommunikationsstrategier är inte någon direkt praxis inom Scrum utan är uppenbarligen en ståndpunkt där många av riskerna pekar åt. Alla de nämnda strategierna förutom att splitta teams användes mer eller mindre automatiskt i PVG-projektet vilket gör Scrum analogt till XP även här. 4 Användning av Scrum i PVG-projektet Efter att ha gått igenom Scrums process kortfattat och vad det innebär att adoptera Scrum in i ett XP projekt - så har vi samlat på oss en hel del fakta som antingen överlappar vårat PVG-projekt eller som kan utnyttjas: Sprint Planning Meeting: Planning Meeting som var en obligatorisk del har i Scrum en väldigt central punkt. Generaliseringen som först måste göras här är att en iteration i PVG-projektet är det samma som en sprint. Planning meetings händer i början av en ny/uppdaterad Product Backlog eller för XP vid en ny lista med stories. Vid varje möte estimeras en tidsenhet och prioritet för varje item/story som kommer läggas till i PSBn/storylistan för iterationen/sprinten. Detta mötet är essentielt för Scrum och även för XP då man får chans att träffa Product Owner/kunden, samtidigt som vartenda item ska diskuteras för att brytas ner i implementerbara tasks. Sprint Retrospective: Att reektera över veckan var också obligatoriskt, men har också en väldigt central del i Scrum under game-fasen. Efter varje iteration diskuterades vad som gått bra och dåligt, samt vad som kan göras bättre för att eektivisera processen till nästa gång. Främst Focus Practices kom upp, men även problem som behövde lösas, eventuella refaktoriseringar och bad smells. I Sprint Retrospective ska Product Owner också vara delaktig. Lars Bendix (som var våran kund/product Owner) gav förutom feedback också 10

11 ut belöning i form av godis för bra beteende, vilket direkt påverka sättet att tänka för studenterna. Vad jag som coach främst påverka i retrospekten var att ställa frågor som vad gick dåligt i förra releasen som vi ska göra bättre i nästa?, vilket jag sedan kontrollerade att de faktiskt följde upp det som svarats på frågan. I denna aspekten tänkte jag noga på att inte visa problemen för dem utan låta dem se problemen själva och agera därhän. Daily Scrum meeting: Detta stand-up mötet tillämpades i PVG-projektet och används visserligen av XP också. Ofta är starten på morgonen svårt att få igång något produktivt arbete på. Detta korta möte fungerade som en initialiserings rutin där vi inte bara hälsade varandra välkomna utan löste problem som förmodligen hade skapat konikter senare under förmiddagen. Denna kvart återkopplades också spikes som gjordes under helgen för att ge oss en ny inblick i koden. Om det var testfall som inte fungerade eller röd kod i repository så kom det upp på detta mötet och en snabb plan för att åtgärda problemet vidtogs. Dagens första arbetetsuppgifter delegerades också ut parvis här. En snabb Sprint Retrospective gavs även här om det var något speciellt att tänka på från föregående iteration. PSB analysis: För att generera en PSB analysis måste ytterligare en generalisering göras; och det är att en PSB är densamma som den prioriterade och estimerade iterativa storylistan som fördes fram under planeringsmötena. Denna generaliseringen tycker jag är accepterbar med tanke på att teamet lade mycket energi på att diskutera fram hela strukturen på många storys, ibland till och med satt på övertid av mötet och estimera dem hänsynsfullt, vilket också görs när en PSB ska skapas enligt requirement renery processen [5]. En PSB och denna storylistan är på så sätt väldigt lika varandra. PSB analysen har hämtat data från trackern, kontraktet och fakturan för varje iteration i projektet. Sammanställningen kan ses i Table 1. Totala antalet timmar speglar de tasks som blev prioriterade och estimerade överhuvudtaget för iterationen, inte bara de som planerades bli klara. Detta ger oss en annan synvinkel på det hela; det innebär alltså att eektiviteten inte är menad till att öka efter varje iteration (eftersom vi skulle bli bättre på att estimera stories). Eektiviteten har med belastningen för iterationen att göra; hur mycket arbete som lades med i PSBn jämfört med hur mycket som slutfördes. Faktorer som refaktorisering, bug x, release, testning och liknande påverkar eektiviteten för de innebär att man lägger arbete på något annat än de tasks som planerats för iterationen. Antalet timmar/task förklarar hur pass ranerade tasks är. Kanske är de för stora? Kanske skulle de kunna brytas ner i mindre tasks? En stor task motsvarar större ändringar i projektet när de commitas och gör det även svårare att distribuera ut arbete till alla när det gäller små projekt som i PVG-kursen. Avg. Tasks/Par och Avg. Timmar/par är också intressanta i den mån om att de visar hur mycket arbete som förväntas av varje par för iterationen. I iteration 2 och 3 så fokuserades mycket på att göra en release, xa buggar, testa programmet, uppdatera dokumentation och provköra osv.. Vilket innebar att eektiviteten sjönk lite till skillnad från första iterationen. Efter iteration 3 så gavs feedback från releasen av kunden vilket hade en del 11

12 Iteration Tasks Totala antal timmar Timmar kvar Avg. Timmar/Task 3,2 3,6 2,4 3,6 3,3 2,6 Avg. Tasks/Par 2 1,8 2 1,8 2,2 1,8 Avg. Timmar/Par 6,4 6,4 4,8 6,4 7,2 4,6 Eektivitet 100% 84% 83% 60% 64% 79% Tabell 1: Resultatet av en PSB analys över alla iterationerna i PVG-projektet. Iteration säger vilken iteration datan är ifrån. Tasks säger hur många tasks som fanns med i PSBn. Totala antal timmar är tidsestimeringen av dessa tasks. Timmar kvar är tidsenheten för de resterande tasks som fanns kvar efter iterationen. Avg. Timmar/Task är hur mycket en task är värd i genomsnitt. Avg. Tasks/Par är hur många tasks som antas implementeras av varje Par i genomsnitt. Avg. Timmar/Par är antalet timmar varje par antas jobba i genomsnitt. Eektivitet är andelen arbete som utfördes under iterationen, totala antal timmar jämfört med timmar kvar. ändringar som skulle åtgärdas i iteration 4. Detta gav upphov till den dåliga effektiviteten för iteration 4. Bland annat eftersom dessa ändringar inte estimerats och lagts med som tasks (vilket de egentligen borde göras). Samt att etapplopp var en story i iteration 4 som hade många beroende från andra stories, vilket gjorde att det var svårt att sysselsätta alla teams innan den var klar. Även mängden nya stories som föll in varje iteration påfrestade belastningen i projektet. Essentiellt är det detta en PSB analys handlar om, dvs hur task strukturen ser ut, belastningen av arbetet. I iteration 5 så skulle en release göras och detta påverkade. Men vi hade även spikat en refaktorisering som underlättade trycket något vilket trots allt release och en iteration full med nya stories - gav oss 64% i eektivitet vilket till skillnad från 60% är en ökning. Till iteration 6 hade belastningen sjunkit pågrund av den nya strukturen i koden. Detta förenklade implementation av resterande stories. Det låg även mindre prioritet på nya stories eftersom den sista releasen skulle släppas. Eektiviteten höjdes på så sätt efter att releasen blivit klar när det bara fanns två utfyllnad-stories kvar. 5 Slutsats Scrums användning i PVG-projektet gjorde ingen markant skillnad eftersom nästan allt som Scrum står för var redan standarden för projektet. Få praktiska modikationer kunde göras av XP för att göra det mer likt Scrum. Sprint Retrospective verkade vara det som var mest öppen för användning. Men även där kändes individuella reektioner, team reektioner och planeringsmötena som 12

13 låg i PVG-projektets obligatoriska moment att överlappa hela meningen med en retrospekt. En full retrospekt hade blivit en repetition av vad som redan nämnts era gånger, vilket hade tolkats mer som tjatigt än något som eektivisera processen. PSB analysen var mer givande och kändes lite som ett digram som visar låg- och högkonjunkturen av ett lands ekonomi. När belastningen blev mycket på teamet kunde de interna delarna av projektet märkas på hur eektiviteten uktuera. Tyvärr hade det ingen praktisk inverkan utan ger främst en statistik på task strukturen för iterationerna. Som nämndes har ett Scrum team 5-9 utvecklare, vårat PVG-team hade tio utvecklare. En sak jag hade velat testa här hade varit att splitta teamet i två delar och försöka styra dem parallellt under åtminstonde en iteration; frågorna som kan ställas här då är: hade den ökade agiliteten blivit mer eektiv? Hade projektet blivit mer osynkroniserat? Hade alla stories kunnat delas upp i två separata delar på detta sättet? Hur hade den genomsnittliga eektiviteten sett ut i en sammanställd PSB analys mellan de två teamen? Detta experiment hade blivit mycket intressant men dock för omständigt att genomgå när vi endast hade sex iterationer på oss att slutföra projektet. Och eftersom PVG-projektet är relativt litet projekt hade det nog inte funnits tillräckligt många delsystem som skulle kunna arbetas på separat utan att faktiskt kollidera med de två team. Om jag haft mer tid hade jag nog även gått igenom all teori för XP och PVG-projektets process för att minska på eventuella missförstånd. När termer och koncept hämtas från PVG-kursen in i djupstudien här kan det bli rätt svårt att förklara det mitt i allt för läsaren. Hade varit bättre att göra ett helt avsnitt dedikerat för att beskriva den processen, samt en till bild. 13

14 6 Referenser [1] Salo O., Abrahamsson P., "Agile methods in European embedded software development organisations: a survey on the actual use and usefulness of Extreme Programming and Scrum", Proc. Software, IET, VTT Tech. Res. Centre of Finland, Oulu, February 2008, pp. 58 [2] Wikipedia: Scrum - tyckte Wiki gav en översikt av Scrums roller som övriga referenser inte kunde lika väl men ändå nämnde ofta, godkänd referens. 1 Mars 2011 URL: [3] Akhtar, M.J.; Ahsan, A.; Sadiq, W.Z.;, "Scrum adoption, acceptance and implementation (a case study of barriers in Pakistan's IT industry and mandatory improvements", Proc. Industrial Engineering and Engineering Management (IE&EM), 2010 IEEE 17Th International Conference on, Oct. 2010, pp [4] Scrum Methodology: denna sida kompletterade [3] tillräckligt för att göra källan godkänd tycker jag. 1 Mars 2011 URL: [5] Vlaanderen, K.; Brinkkemper, S.; Jansen, S.; Jaspers, E.;, "The Agile Requirements Renery: Applying SCRUM Principles to Software Product Management", Proc. Software Product Management (IWSPM), 2009 Third International Workshop on, Sept. 2009, pp. 2-4, 9 [6] Atlas, A.;, "Accidental Adoption: The Story of Scrum at Amazon.com,", Proc. Agile Conference, AGILE '09., Aug. 2009, pp [7] P. Lencioni. 'The Five Dysfunctions of a Team', Jossey-Bass; 1 edition (April 11, 2002). pp. 6 [8] Hersey & Blanchard's situational leadership, 1 Mars 2011 URL: [9] Chromatic.; O'Reilly Media.;, Extreme Programming Pocket Guide Team-Based Software Development, Pocket Guide. 1st edition, July pp. 61 [10] Chromatic.; O'Reilly Media.;, Extreme Programming Pocket Guide Team-Based Software Development, Pocket Guide. 1st edition, July pp. 36 [11] Hossain, E.; Babar, M.A.; Hye-young Paik; Verner, J.;, "Risk Identi- cation and Mitigation Processes for Using Scrum in Global Software Development: A Conceptual Framework,", Proc. Software Engineering Conference, APSEC '09. Asia-Pacic, pp