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

Storlek: px
Starta visningen från sidan:

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

Transkript

1 SCRUM vs. XP en jämförelse mellan två lättviktsmetodiker Phut Tran D01, Lund Tekniska Högskola 21 februari 2006

2 Innehållsförteckning ABSTRACT INLEDNING VAD ÄR EN LÄTTVIKTSMETODIK? [1] EXTREME PROGRAMMING (XP) [2, 3] XPs fem grundläggande värderingar XPs tolv praxisar SCRUM-METODIKEN [4] Hur går ett SCRUM-projekt till? [4, 3] Faktorer att ta hänsyn till vid utarbetning av releaseplanen SCRUMs olika faser SCRUM controls SCRUM-projekt SCRUM VS. XP [2, 6, 8, 9] Vad är gemensamt? Vad skiljer dem åt? Vilken är att föredra? Vad kan SCRUM tillföra XP? SAMMANFATTNING REFERENSLISTA

3 Abstract Denna artikel behandlar metodiken SCRUM och hur det står sig i jämförelse med XP. SCRUM är liksom XP en lättviktsmetodik. Efter en kort introduktion av vad en lättviktsprocess är samt en repetition av XP följer en sammanfattning av lättviktsmetodiken SCRUM. Därefter följer en jämförelse mellan SCRUM och XP. Vad är gemensamt och vad skiljer dem åt? Är den ena att föredra före den andre? Eller spelar det ingen roll då de båda metodikerna baseras på lättviktsvärderingar? Skulle man kunna förena det bästa från de båda metodikerna. Kan SCRUMs idéer göra XP ännu bättre än vad det redan är? 3

4 1 Inledning Traditionella utvecklingsmetodiker är sekventiella och förutsätter att alla krav läggs fram i början och är tydliga innan man går vidare till nästa fas. I dagsläget är projektkraven allt annat än tydliga. Många av kraven är oklara eller okända även under produktutvecklingen på grund av att kunden inte riktig vet vad han vill. Ändrade faktorer i omgivningen kan leda till att kunden får för sig att ändra kraven under produktutvecklingscykeln. Detta har lett till mycket huvudvärk bland utvecklarna som helt enkelt inte kan hantera det kaos som uppstår. Många projekt drabbas därför av förseningar och budgetöverskridningar och en del projekt misslyckas totalt. I denna miljö har lättviktsmetodikerna växt fram för att avhjälpa dessa problem. [4] Som studenter på Lund Tekniska Högskola är XP den enda vi lättviktsmetodik som vi har fått lära oss och använt oss av praktiskt. XP verkar för övrigt vara den populäraste lättviktsmetodiken då de flesta artiklarna om lättviktsprogramvaruutveckling jag har stött på utgår mer eller mindre från XP. Men det finns andra lättviktsmetodiker. Därför skulle det vara intressant att studera en annan lättviktsmetodik på djupet för att kunna ser hur det förhåller sig till XP. Jag har valt att studera lättviktsmetodiken SCRUM för att se hur den skiljer sig från XP. Är den att föredra framför XP i vissa situationer? Skulle man kunna utnyttja dess idéer till att förbättra XP? Dessa frågor har jag försökt att besvara i [1, 2, 3, 4] denna artikel. För att kunna möjliggöra jämförelsen inleds artikeln med en kort introduktion om vad en lättviktsprocess är. Därefter följer av en repetition av XP-metodiken som sedan åtföljs av ett kapitel som behandlar SCRUM-metodiken. I det avslutande kapitlet jämförs sedan de två metodikerna. 2 Vad är en lättviktsmetodik? [1] Ordet lättvikt kommer från det engelska ordet agile som betyder snabb eller rörlig. Det som kännetecknar lättviktsmetodikerna är att större vikt läggs på människor än själva processerna och verktygen samt att administrationen hålls på en minimal nivå. Osäkerheten kan vara mycket stor i ett mjukvaruprojekt och dessutom utsätts ett projekt ständigt för ändringar. Därför fokuserar man mycket på att göra lättviktsmetodikerna anpassningsbara. Istället för att har en omfattande planeringsfas i början av projektet görs det i mindre iterationer parallellt med implementationsfasen för att kunna hantera de ändringar som uppkommer under projektets gång. Lättviktmetodikerna har mycket gemensamt fastän de mer eller mindre har växt fram oberoende av varandra. Därför samlades representanter för några lättviktsmetodiker och bildade The Agile Alliance. De formulerade ett manifest, Manifesto for Agile Software Developement, där man enades om fyra punkter som skulle vara gemensamma för alla lättviktsmetodiker: Individer och samspel framför processer och verktyg. Samspelet mellan gruppmedlemmarna är viktigare än de verktyg och processer som används. Börja 4

5 därför först med att försöka sammansvetsa teamet. Valet av verktygen är förvisso viktigt men det kan komma senare. Fungerande mjukvara framför uttömmande dokumentation. Dokumentation är bra men för omfattande dokumentation är värre än för lite. De tar mycket tid att producera och uppdatera samt lång tid att läsa igenom. Mycket dokumentation kan undvikas genom att utvecklarna istället pratar med varandra. Skapa ingen dokumentation om inte behovet av den är omedelbart och viktigt. Det viktigaste är att det finns en fungerande mjukvara att leverera till kunden. Kundsamverkan framför kontraktförhandlingar. Framgångsrika projekt är beroende av återkopplingen från kunden. Därför är det viktigt med fortlöpande samarbete med kunden så att man kan leverera det som kunden verkligen vill ha. Anpassning till förändringar framför följande av plan. Ett mjukvaruprojekt utsätts oftast för ändrade krav. Många projekt har havererat på grund av att man inte kunnat ta hand om dessa ändringar. Därför är det viktigt att man utvecklar i små iterationer och bara planerar för några veckor framåt. På det sättet slipper man låsa sig till en viss plan eftersom man ändå inte vet vad som händer om några månader eller år. I samband med manifestet formulerade också The Agile Alliance tolv principer som utmärker en lättviktsprocess. Några av dem är att man ska: sträva efter att göra kunden nöjd genom att leverera fungerande program tidigt och ofta. välkomma ändringar eftersom det kan gynna kundens konkurrenskraft. bygga projektet kring motiverade individer eftersom det i ett lättviktsprojekt är människorna som är framgångsfaktorn. kommunicera muntligen (utvecklarna emellan) eftersom det är det bästa sättet att förmedla information på. bygga kod av hög kvalitet och som är enkel att ändra i. Då kan vi lättare ta hand om ändrade krav när de kommer. 3 Extreme Programming (XP) [2, 3] Extreme Programming är, i motsats till andra lättviktsmetodiker, en mycket konkret metodik vilket kanske kan förklara dess popularitet. De traditionella utvecklingsmetodikerna har långa utvecklingscykler vilket gjorde det nästan omöjligt att anpassa sig till ändrade krav. XP har löst detta genom att krympa dessa utvecklingscykler och istället göra dem oftare. Så istället för att planera, analysera och designa för flera år framåt försöker XP att utföra dessa aktiviteter lite i taget och mycket oftare. Dessa många korta iterationer och en nära kundkontakt gör det möjligt att anpassa projektet för kravändringar. XP baseras på fem drivande värderingar. 3.1 XPs fem grundläggande värderingar 5

6 Kommunikation. Direkt muntlig kommunikation är viktig för att undvika problem samt för att snabbt kunna lösa problem när de väl uppstår. Enkelhet. Implementera endast för dagens krav och gör koden enkel. Det är inte lönsamt med omfattande implementeringar för vad som skulle kunna komma i morgon eftersom kraven kan ändras. Om koden är enkel kan den lätt anpassas för att uppfylla morgondagens krav när det behövs. Feedback. Det är svårt att göra det rätt från början och det som är rätt i dag kanske inte är det i morgon. Med ständig feedback från kunden kan man istället tidigt utreda fel och missförstånd. Utvecklarna kan arbeta med större tillförsikt och kunden får produkten han vill ha. Kurage. Man måste våga säga sin mening. Kurage krävs för att de ovannämnda principerna ska fungera. Man måste till exempel ha kurage för att kunna förkasta dåliga lösningar och finna nya lösningar som förespråkar enkelhet. Respekt. Alla är lika viktiga i teamet och ingen är mer värd än den andre. Om ingen bryr sig om de andra eller vad de gör så kommer XP inte att fungera. Utifrån dessa värderingar har man utformat tolv stycken praxisar. 3.2 XPs tolv praxisar Planeringsmöte. Här tas en översiktligt plan fram. Kunden presenterar några funktionaliter, så kallade stories, för utvecklarna som sedan estimerar tiden det kommer ta att implementerar varje funktionalitet. Baserad på dessa estimeringar prioriterar kunden sedan vilka funktionaliteter som är viktiga för honom att ha med vid nästa release. Utvecklarna kommer sedan att endast implementerar dessa funktionaliteter. Små releaser. Systemet ges ut efter varje iteration trots att hela systemet ännu inte är implementerad. Nya releaser görs ofta vilket kan variera mellan varje dag till varje månad. Kunden får då möjligheten att provköra de nya funktionaliteter i sin hemmamiljö och kan på så sätt snabb ger feedback. Metafor. En systemmetafor underlättar kommunikationen mellan utvecklarna och kunden (som oftast inte är teknisk kunnig). Enkel design. Designen och koden ska hållas enkelt. Den får till exempel inte innehålla duplicerad kod eller en massa onödiga metoder och klasser som egentligen inte gör någonting. Implementera endast det som krävs idag, inte det som kan tänkas komma i framtiden eftersom kraven kan ändras. Testning. Utvecklarna skriver enhetstester för varje funktion de implementerar. Efter att utvecklarna implementerad en ny funktion ska alla dessa tester köras om igen och passeras. På det sättet kan programmerarna vara säkra på att inget i systemet har gått sönder i och med införandet av den nya funktionen. Kunden skriver acceptanstester för att kunna validera att detta verkligen är den produkt han vill ha. Acceptanstesterna görs på systemnivå (black-box testning). Refaktorisering. Förbättra och strukturerar om koden utan att förändra själva funktionaliteten. Att funktionalitet bibehålls kan enkelt kontrolleras genom att man kör om alla enhetstesterna. 6

7 Parprogrammering. All produktionskod ska skrivas av ett par utvecklare vid en datorn. Parprogrammering möjliggör fortlöpande kodgranskning samt att designbesluten alltid ska fattas av minst två individer. Kunskap om systemet och erfarenheter sprids när alla programmerar med alla. Kontinuerlig integrering. All ny kod som passerar alla enhetstesterna ska integreras med resten av systemet. Ändringar som inte passerar enhetstesterna förkastas. Kollektivt ägande av kod. Alla utvecklare får ändra i all kod vid vilken tidpunkt som helst när han anser det är nödvändigt. På-plats-kund. Kunden eller en kundrepresentant ska ständigt finnas på plats tillsammans med teamet. På det sättet kan utvecklarna snabb få feedback från kunden, ställa frågor och utreda missförstånd. Risken för att utvecklingen drivs åt fel håll minskas avsevärt med denna praxis. 40-timmarsarbetsvecka. Trötta utvecklare skriver dålig kod. Låt dem inte arbeta övertid. Öppen arbetsplats. Teamet ska arbeta i ett stort rum tillsammans där datorerna finns i mitten. Det gör det lättare för utvecklarna att kommunicera med varandra vilket leder till att problem kan klaras upp snabbare. 4 SCRUM-metodiken [4] SCRUM är främst en metodik för att hantera, förbättra och underhålla existerande system. Den kräver därför att det redan finns en befintlig design och kod. Metodiken är en vidareutveckling av den iterativa och inkrementella objekorienterade utvecklingscykeln. Traditionella metodiker säger att programvaruutveckling är en väldefinierad process som kan planeras och estimeras och slutföras framgångsrik. Erfarenheter visar på motsatsen. De visar att systemutvecklingsprocessen är en komplicerad och komplex process. För att kunna hantera den krävs det maximum flexibilitet och lämpliga processkontroller. Utvecklingsprocessen SCRUM utgår därför ifrån att systemutvecklingsprocessen är en komplicerat och oförutsägbar process. Särskilt analys-, design- och implementationsfasen, det så kallade sprint-fasen 1, är oförutsägbara. För att ta hand om det oförutsägbara och kontrollera riskerna används en kontrollmekanism bestående av bestämda SCRUM controls. Det som kännetecknar SCRUM-metodiken är bland annat: Den första och sista fasen (Planning och Closure) består av väldefinierade processer. Det är bara att läsa dokumentet om hur man går tillväga och sedan följa det punkt för punkt. 1 Jag har medvetet valt att behålla de engelska termerna när jag skriver om SCRUM. Att kalla SCRUM för Klunga och sprint för spurt skulle bara förvirra läsare som senare önskar läsa mera om SCRUM i engelsk litteratur. Termerna är kursiverade för att det ska synas att de är på engelska. 7

8 Sprint-fasen är en empirisk process. Empirisk innebär att man ska lära sig av sina tidigare erfarenheter från tidigare sprint för att kunna bli bättre vid nästa sprint. De flesta processerna här är antingen okontrollerbara eller odefinierade. Sprintfasen betraktas som en svartlåda som man kontrollerar med externa SCRUM controls. Sprints är olinjära 2 och flexibla. Om lämpliga processer finns kan man utnyttja dem annars kan man bygga upp sin kunskap om processen genom att utnyttja befintligt kunskap och trial and error. Projektet är öppet ända tills Closure-fasen. Det som ska levereras kan ändras när som helst under Planning- och Sprint-fasen. Resten av detta kapitel är uppbyggd på följande sätt: nästföljande underkapitel beskriver hur ett typiskt SCRUM-projekt går till och de efterföljande underkapitlen beskriver de olika delarna i projektet mera ingående. 4.1 Hur går ett SCRUM-projekt till? Först börjar med man en planeringsfas där en plan skapas. Man utformar en product backlog-lista på vad som ska göras. Utifrån listan bestämmer man den nya releasen. Marknadsgruppen eller kunden fastställer sedan ett releasedatum. En initial arkitektur utvecklas men utvecklingsteamet är förbered för att denna arkitektur kan komma att ändras under utvecklingen. Utvecklingsteamet och marknadsgruppen arbetar sedan tillsammans för att välja ut de funktionerna av störst betydelse inför första releasen. Om utvecklingsteamet anser att tiden inte kommer att räcka till för att implementera alla funktioner förhandlar man om ett mindre antal funktioner. Efter detta skapas det så kallade backlog-listor för de olika sprints med saker som ska utföras enligt den prioritetsordning man kommit överens om. Ett SCRUM-projekt kan bestå av flera utvecklingsteam men varje utvecklingsteam får inte består av mer än 10 personer. Efter den inledande planeringsfasen går man över till utvecklingsfasen som består av många små utvecklingsiterationer, så kallade sprints, för att kunna utveckla produkten inkrementellt. En sprint varar mellan en till fyra veckor. Varje team tilldelas ett antal arbetsuppgifter innan sprinten. Teamet identifierar de arbetsuppgifter som ska göras och för in dem i sprint backlog-listan. Före varje sprint samlas teamet för att uppdatera backlog-listan och omprioritera arbetsuppgifterna. Teammedlemmar skriver upp sig och får ansvar för att slutföra några arbetsuppgifter inom en rimlig tid (innan sprinten är till ända). Under sprinten tillåts inga ändringar utifrån. Under sprinten har teamet dagligen SCRUM-möten där alla teammedlemmar är med. En SCRUM master leder mötena och förvissa sig om att alla i gruppen gör framsteg genom [4, 3] 2 Med olinjär får jag uppfattningen att tiden för implementering av kraven kan variera under sprinten. Man kan aldrig säkert veta hur mycket tid det kommer att ta att implementera en backlog item eftersom man även måste ta hänsyn till variablerna kvalitet, kostnad och konkurrens. 8

9 tracking. Han antecknar besluten som görs och håller reda på vad som ska göras. Ett SCRUM-möte ska vara kort (mellan 15 till 30 minuter) och koncentrerad. Under mötet hinner man diskutera hindren och problemen som uppkommit men inte deras lösningar. Det görs i ett senare möte där endast de berörda parterna är med. En sprint måste resultera i en synlig och användbar produkt där de efterfrågade funktionerna är implementerade. Efter en sprint träffas alla projektets medlemmar inklusive kunden. Under detta möte kan allting ändras: arbetsuppgifter läggs till, tas bort eller omprioriteras. Kundens prioritera vilka saker som är viktiga inför nästa sprint. Här kollar man också på sina estimeringar och se hur dem stämmer med verkligheten. Efter varje sprint förbättras estimeringarna och en bättre plan kan utarbetas för varje gång. När produktstyrelsen anser att systemet är redo för en release går man över till Closurefasen där produkten förbereds för release med tillhörande dokumentation. 4.2 Faktorer att ta hänsyn till vid utarbetning av releaseplanen Enligt SCRUM ska planen för en mjukvarurelease baseras på följande faktorer: Kundens krav hur ska systemet förbättras Tidspress hur lång tid har vi på oss för att fortfarande kunna vara konkurrenskraftiga Konkurrens hur är konkurrensstatusen och vad krävs för att vara bäst av dem Kvalitet vilken kvalitet förväntas med avseende på punkterna ovan Vision vilka ändringar krävs för att uppfylla systemets vision. Resurser vad slags personal och hur mycket kapital finns tillgängligt Med dessa ovannämnda faktorer kan man utarbeta en initialplan. Dessa faktorer kan ändras under projektet och för att lyckas man måste ta hänsyn till dem även i framtiden. Då mycket är osäkert görs inget omfattande plan utan planeringsfasen gås igenom snabbt. 4.3 SCRUMs olika faser SCRUM består av följande faser: Pregame o Planning: Här utformas en omfattande product backlog-lista på vad som ska göras. Baserad på listan bestämmer man den nya releasen (eller releaser) och dess leveransdatum samt estimerar tiden och kostnaden för den. o Architecture / High Level Design: Här bestämmer man hur backlog items ska implementeras. Man identifierar de ändringar som behövs för att kunna implementera backlog items och man försöker också identifierar de eventuella problem som kan uppstå på grund av ändringarna. Man ser också över systemarkitekturen och modifierar den vid behov för att den ska kunna stödja de nya kraven. Game 9

10 o Development Sprints: Med i beräkningar har man hela tiden de variabler som påverkar utvecklingen: tiden, kraven, kvaliteten, kostnaden samt konkurrensen. Styrelsen använder dessa variabler för att bestämma när fasen slutar. Utvecklingen av systemet drivs framåt med hjälp av många små iterativa utvecklingscykler, så kallade sprints. Varje sprint har ett bestämt syfte, en så kallad sprint goal. Huvudsyftet med en sprint är att kunna leverera värdefullt funktionalitet. En sprint löper över en bestämd tidsperiod och består av följande aktiviteter (som utförs av ett eller flera team): Review: Varje dag har teamet ett möte tillsammans för att presentera det som utförts och granska framstegen. Här får man möjlighet att diskutera de hinder samt problem som uppstått. Nya items läggs till sprint backlog-listan. Riskerna granskas och man definierar vilka åtgärder som ska vidtas. Adjust: Här slår man ihop informationen man information från Review-mötenen som sedan läggs de i berörda paketen. Develop: Här öppnas paketen för implementeringen av de nya funktionaliteterna till den nya releasen. Man får endast ändra i ett paket som är öppet (den del av systemet som teamet får ändra i). Man kodar, testar och dokumenterar ändringarna. Wrap: Här stängs paketen. När ett paket stängs får inga kodändringar göras i den delen av systemet. En exekverbar version av ändringarna skapas med beskrivning på hur dessa ändringar implementerat kraven i sprint backlog-listan. Efter varje sprint följer ett mer omfattande granskningsmöte: Produktstyrelsen och hela teamet är närvarande och deltar. Även berörda försäljningspersonal, marknadspersonal, kunder och andra får vara med. Man granskar delar av det exekverbara systemet som omfattar de backlog items som tilldelats teamet och även ställen där ändringar gjorts för att möjliggöra implementeringen av dessa backlog items. Man kan introducera nya backlog items och tilldela dem till teamen. Riktningen och innehållet på det som ska levereras kan också ändras. Utifrån komplexiteten och framstegen bestäms en ny tid för nästa omfattande granskningsmöte. Vanligtvis är en sprint mellan en till fyra veckor lång. Postgame o Closure: Här förbereder man den utvecklade produkten inför release genom integrering, systemtestning samt färdigställande av användarmanual. 4.4 SCRUM controls Inom programvaruutvecklingen är mycket oförutsägbar. Därför man kan inte använda sig av väldefinierade processer som säger: Gör så här och så här för då kommer resultatet 10

11 att bli bra. Istället för väldefinierade processer har SCRUM istället infört så kallade SCRUM controls. Dessa controls består av verktyg och faktorer man ska utnyttja för att övervaka utvecklingen och styra projektet i rätt riktning. Utnyttjande av dessa controls gör att man kan hantera kravändringar och problem som uppstår under utvecklingen. Risk är den främsta control. Riskuppskattning hjälper oss att bestämma om de andra controls behöver uppdateras och om andra åtgärder behöver vidtas. SCRUM har följande controls: Backlog: Backlog är en lista bestående av backlog items. Backlog items kan vara funktionalitetskrav som är splittrade i mindre delar, buggar, kundens krav på förbättringar, konkurrenskraftig funktionalitet samt teknikuppgraderingar. Release/Enchancement: en samling av backlog items som anses genomförbara inom en viss tid om man ta hänsyn till variablerna krav, tid, kvalitet och konkurrens. Packets: Packet är en produktkomponent som behöver ändras för att förverkliga en implementering av en ny backlog item. Changes: Ändringar av en packet som måste göras för att implementera en backlog item. Problems: Vid implementering av en backlog item kan problem uppstå som måste lösas. Risks: Riskuppskattning görs fortlöpande och åtgärder planeras. Riskuppskattning är mycket viktig eftersom den avgör om projektet kommer att bli framgångsrikt eller ej. Solutions: lösningar till risks och problems. Issues: Andra saker som inte går under termerna packets, changes och problems. Dessa controls används i olika faser. Utvecklarna kan använda dem för att hantera ändringar och problem. Produktstyrelsen använder dem för att hantera product backloglistan. 4.5 SCRUM-projekt Termen SCRUM är tagen från spelet Rugby. I Rugby är scrum ett team bestående av åtta spelare (forward) som arbetar tillsammans för att flytta bollen till motståndarens målområde. Teamet är fokuserad mot ett gemensamt mål och arbetar tätt ihop där varje spelare i gruppen har en bestämd roll. Så är det också i ett SCRUM-team. Varje teammedlem vet sin roll och sina uppgifter och hela teamet arbetar mot ett bestämt mål. Inför varje ny release skapas ett projektteam bestående av följande mindre grupper: Management: En grupp som bestämmer innehållet och tiden för den nya release. Gruppen styr projektets utveckling och ta hand om product backlog-listan, riskerna och releaseinnehållet. Development teams: Utvecklingsteamet är små, inte mer än 10 medlemmar. Teamet består av utvecklare, dokumenterare och kvalitetskontroll personal. Varje 11

12 team tilldelas en bestämd mängd packets med tillhörande backlog items. Teamet identifierar ändringar som behöver göras, utför dem och ta hand om de problem som eventuellt uppstår. Teamet väljs ut så att all kunskap och expertis som krävs för implementeringen finns i teamet. Ett projektteam består också av berörda marknadspersonal, försäljningspersonal och kunder. SCRUM förespråkar att dem är med för att man ska kunna bestämma lämpligt innehåll för releasen samt en lämplig tidpunkt för lanseringen. Det som känneteckna SCRUM-projekten är följande: Flexibla levererbara: innehållet på det som levereras dikteras av omgivningen. Flexibelt schema: det levererbara kan behövas släppas tidigare eller senare än man planerad från början. Små team: inte mer än 10 personer i ett team men det får finnas flera team i ett projekt. Frekventa granskningar: teamets framsteg granskas ofta, vanligtvis med 1 till 4 veckors intervall. Samarbete: samarbetet inom teamet och utanför teamet är mycket viktigt. 5 SCRUM vs. XP [2, 6, 8, 9] 5.1 Vad är gemensamt? Båda metodikerna förespråkar små utvecklingsteam: 3-16 personer för XP och 5-10 för SCRUM eftersom man anser att små team arbetar effektivare. Kommunikation underlättas och kunskapen sprids snabbare. I både XP och SCRUMP spelar kunden en viktig roll, han är en del av teamet. Detta är inte förvånande eftersom lättviktsmetodiker kräver att kunden inta en aktiv roll. Han ska lägga fram och ta bort krav, prioritera, ge feedback för att kunna styra projektet i rätt riktning, finnas till hands när utvecklarna behöver ställa frågor, etc. Båda metodikerna tidsestimerar arbetsuppgifterna. I XP är det utvecklarna som estimerar hur mycket tid (dagar/veckor/månader) som krävs för varje story. I SCRUM är det produktägaren som tillsammans med utvecklarna estimerar backlog items i dagar. Efter varje iteration/sprint jämför man sina estimeringar med det som verkligen har utförts för att kunna förbättra sin estimering inför nästa iteration. I XP börjar man varje iteration med ett planeringsmöte där kunden får förklara och prioritera storiesarna. Storiesarna delas upp i mindre uppgifter som utvecklarna skriver sig upp på. I SCRUM inleder man också varje sprint med ett planeringsmöte. Man tittar i sprint backlog-listan och utvecklarna väljer items de tror sig kan klara av att implementera inom angiven tid. Man diskuterar också hur man ska uppnå sprint-målet. 12

13 Både XP och SCRUM förespråkar direkt kommunikation mellan utvecklarna. SCRUM stödjer det med sina dagliga möten. XP stödjer det med dagliga stand up möten och kräver dessutom att alla teammedlemmar sitter i samma rum. Utanför en iteration/sprint kan kunden lägga till, ta bort eller ändra kraven hur som helst. I SCRUM tillåts mindre ändringar från kunden under en sprint men stora ändringar tillåts inte. Det är dock tillåtet i XP där en ny story skapas och man gör en omplanering. Kvaliteten är viktig i lättviktsutveckling. XP och SCRUM förespråkar fortlöpande och automatisk integrationstestning, med en daglig build och smoke test. XP har enhetstester och parprogrammering för att kunna försäkra kodkvalitet. Både i XP och SCRUM slutförs varje iteration/sprint med en informell granskning. 5.2 Vad skiljer dem åt? SCRUM är främst en metodik för att hantera, förbättra och underhålla för existerande system. XP däremot är även anpassad för mjukvaruprojekt som startar från noll. XP är anpassad för ett utvecklingsteam per projekt. I SCRUM kan det finnas flera team som arbetar parallellt. XP innehåller mycket lite vägledning för projektstyrning. SCRUM är däremot utformat för styrning av mjukvaruutvecklingsprojekt. Förespråkarna för SCRUM, Schwaber och Beedle, rekommenderar därför att man ska komplettera SCRUM med exempelvis XP 3. XP använder sig av metaforer för att hjälpa alla att förstå hur sakerna hänger ihop samt underlättar kommunikationen mellan utvecklarna sinsemellan och kunden. SCRUM har inget sådant utan har endast små mål inför varje sprint. Men det finns såklart inget i SCRUM som hindrar utvecklarna från att använda sig av metaforer. I XP är det kunden som anger kraven genom att skapa en hög av stories. I SCRUM är det produktägaren (inte nödvändigtvis kunden) som skapar och underhåller product backloglistan (motsvarighet till stories-högen). SCRUM har inga bestämda processer under implementationsfasen (sprint-fasen) utan lämnar det öppet för utvecklarna att fritt välja sina egna mjukvaruutvecklingstekniker och praxisar. XP har bestämda och konkreta praxisar som man ska följa och det anser många vara en fördel. Värt att lägga märke till är att en av praxisarna är De är bara regler. Så även i XP kan man välja att bortse från vissa praxisar eller anpassa dem efter teamets behov. 3 Rekommendation från boken Agile Software Development With SCRUM, skrivet av K. Schwaber och M. Beedle. 13

14 5.3 Vilken är att föredra? Styrkan i XP är att den är en mycket konkret metodik. Den innehåller konkret vägledning igenom alla faser under produktutvecklingen. För små projekt där kraven är vaga och föränderliga och där man inte ställer så höga krav på projektstyrning är XP att föredra. SCRUM däremot saknar konkret vägledning under implementationsfasen men styrkan i SCRUM är projektstyrningen. På grund av detta kan SCRUM, i motsats till XP, har flera utvecklingsteam som arbetar på samma produkt parallellt. Där skulle man kunna använda SCRUM för att skala upp XP för större projekt bestående av flera mindre utvecklingsteam. Det var just det en grupp utvecklare på SAS institut i Danmark gjorde och resultat verkar vara mycket lyckat. I början körde man bara med XP men ganska snart dök det upp problem med att koordinera och prioritera arbetet mellan det danska teamet och de andra 4-5 teamen på huvudkontoret. För att avhjälpa dessa problem infördes SCRUM i kombination med XP. Utvecklingsteamen rapporterar att SCRUM har gjort deras planering, estimering och tracking mycket lättare. Snart började man även ha dagliga möten med teamen med hjälp av videokonferens och man tyckte att bara det har förbättrat projektstyrningen mellan teamen avsevärt. [7] 5.4 Vad kan SCRUM tillföra XP? XP fokuserar mycket kring tekniska detaljer om hur man ska programmera. SCRUM lägger däremot större vikt på hur man organiserar teamen, hur man delar upp arbetet mellan de olika teamen samt hur arbetet ska planeras. Mycket av det som finns i SCRUM finns redan i XP. Om man skulle kalla Sprint Planning Meeting för Planning Game, SCRUM Master för Coach, Sprint för Iteration, Story för Backlog item och Daily SCRUM Meeting för Stand-up Meeting så har man faktiskt en enkel variant av XP. Men vad händer när ett projekt behöver fler än 10 utvecklare, kanske upp till hundra utvecklare? Då blir det genast svårare att koordinera arbetet i XP på grund sådana praxisar som Collective Code Ownership, Continuous Integration och Open Workspace. SCRUM löser det genom att dela upp utvecklarna i mindre team och inför det så kallade SCRUM of SCRUM meeting för att koordinera arbetet mellan teamen. [10] På grund av storleken kan inte alla i teamen närvara vid dessa möten. Istället sänds en representant från varje team. Vanligtvis är det är SCRUM mastern eftersom det är han som har översikten över vad hans team har uträttat och känner till dem olika hindren och problemen som dykt upp. En sak som möjliggör uppdelningen av arbetet i SCRUM är att metodiken säga att man ska dela upp systemet i moduler, så kallade packets. Denna uppdelning görs under Design and System Architecture fasen. Dessa packets ska vara mer eller mindre vara oberoende av varandra. Inför varje sprint väljer varje team ut ett antal högprioriterade backlog items och tilldelas de packets som de behöver för att kunna implementera dessa items. Teamet får endast ändra i dem packets som har tilldelats dem. På det sättet slipper man stora merging-problem eftersom de olika teamen aldrig i samma kod. Det fina med SCRUM är att när man har delat upp det stora antalet utvecklarna i mindre team så blir genast alla XPs praxisar giltiga igen. Slutsatsen är att SCRUM bör ses som 14

15 ett komplett till XP och inte en konkurrent. SCRUM gör det möjligt att tillämpa XP på stora projekt med många utvecklare. 6 Sammanfattning SCRUM är lättviktsmetodik som fokuserar mycket på styrningen av mjukvaruutvecklingen och lägger inte så stor fokus konkreta praxisar. Många väljer därför att kombinera projekstyrningen från SCRUM med exempelvis praxisarna från XP. Detta är genomförbart eftersom SCRUM och XP i grunden är väldig lika som vi har sett i vår jämförelse. Det är endast små detaljer som skiljer dem åt. (Till detta djupstudie var det meningen att jag också skulle testa SCRUMs idéer på XPprojektet där jag och en annan student coachar ett team. Detta har dock inte blivit av eftersom jag tycker att SCRUM och XP vid en närmare granskning är väldigt likt varandra. Det är bara det att de använder olika termer. Fördelar med SCRUM i kombination med XP märks först när man behöver koordinera de olika utvecklingsteamen i ett större projekt. Detta är dock inte fallet i vårt lilla XP-projekt med endast 8 utvecklare. Att börja kalla iteration för sprint och story för backlog item skulle förvirra mer än det skulle hjälpa utvecklarna.) Referenslista [1] R. C. Martin. Agile Software Development. Prentice Hall, [2] Kent Beck: Embracing Change With Extreme Programming, IEEE 1999 [3] Kent Beck: Extreme Programming Explained: Embrace Change (2 nd edition), Addison-Wesley [4] Ken Schwaber: SCRUM Development Process (Advanced Development Methods) [5] Linda Rising and Norman S. Jannoff, AG Communication System: The Scrum Software Development Process for Small Teams, IEEE SOFTWARE, July/August 2000 [6] Pekka Abrahamsson & Others: New Directions on Agile Methods: A Comparative Analysis, Technical Research Centre of Findland, VTT Electronics, IEEE 2003 [7] Bent Jensen and Alex Zilmer: Cross-Continent Development Using Scrum and XP, SAS Institute A/S [8] An Agile Comparison, [9] Martin Fowler: The New Methodology, [10] The Scrum Development Process,

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

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

ALM Live: Scrum + VSTS

ALM Live: Scrum + VSTS ALM Live: Scrum + VSTS Explained and distilled for Everyone! Micael Herkommer micael.herkommer@inexor.se Introduktion Micael Herkommer Developer Coach & Solutions Architect INEXOR EPiServer Professional

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

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

Therese Hansson & Magnus Jonsson. Motivationsfaktorer - Test inom Agila utvecklingsprojekt

Therese Hansson & Magnus Jonsson. Motivationsfaktorer - Test inom Agila utvecklingsprojekt Motivationsfaktorer - Test inom Agila utvecklingsprojekt Magnus Jonsson & Therese Hansson Flerårig erfarenhet från ett globalt utvecklingsprojekt där vi införde Agile & Scrum metodik i hela organisationen

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

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

Automation Region. Affärsdriven systemutveckling genom agila metoder. Stefan Paulsson Thomas Öberg

Automation Region. Affärsdriven systemutveckling genom agila metoder. Stefan Paulsson Thomas Öberg Automation Region Affärsdriven systemutveckling genom agila metoder Stefan Paulsson Thomas Öberg Frontit Frontit är ett svenskt konsultföretag i gränslandet mellan Management & IT, som stärker sina kunders

Läs mer

Scrum Scrum. en beskrivning. a description. V 2012.12.13 2012 Scrum Alliance,Inc 1

Scrum Scrum. en beskrivning. a description. V 2012.12.13 2012 Scrum Alliance,Inc 1 " Scrum Scrum en beskrivning a description 1" 1 Scrums principer Värderingar från Agile Manifesto Scrum är mest känt av de agila arbetssätten. Agile Manifesto utgör en gemensam bas för att arbeta agilt

Läs mer

Agila Metoder. Nils Ehrenberg nils.ehrenberg@mah.se

Agila Metoder. Nils Ehrenberg nils.ehrenberg@mah.se Agila Metoder Nils Ehrenberg nils.ehrenberg@mah.se Agenda Agila Metoder: Scrum och sprints Lean och Design Workshops Kravställning Agil Utveckling Individer och interaktioner istället för processer Fungerande

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

Presentation. Fredrik Runnsjö 1996 Utvecklare 2004 Testare ~2006 Scrum/Canban

Presentation. Fredrik Runnsjö 1996 Utvecklare 2004 Testare ~2006 Scrum/Canban Presentation Fredrik Runnsjö 1996 Utvecklare 2004 Testare ~2006 Scrum/Canban Om AddQ Mission Vi skapar affärsnytta för kunden genom specialisttjänster inom test, kvalitetssäkring och effektivisering Tjänsteområden

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

Tentamen, delkurs Projektstyrning Webbutvecklare SU13, Malmö

Tentamen, delkurs Projektstyrning Webbutvecklare SU13, Malmö Sida 1/14 Tentamen Projektstyrning, Webbutvecklare, WU13, Malmö Tentamen, delkurs Projektstyrning Webbutvecklare SU13, Malmö Plats: Plushögskolan Malmö Tid: fredag 29 november 2013, kl. 9.00-12.00 Tillåtna

Läs mer

Agil mjukvaruutveckling. 1DV404, Jesper Andersson

Agil mjukvaruutveckling. 1DV404, Jesper Andersson Agil mjukvaruutveckling 1DV404, Jesper Andersson Agilt? Innehållet i alla mjukvaruutvecklingsprocesser! Roller! Aktiviteter! Artefakter Processmodeller Många smaker Unified Process Kanban SCRUM normativ

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

Metoder för Interaktionsdesign

Metoder för Interaktionsdesign Metoder för Interaktionsdesign Föreläsning 4 Projektmetodik och Scrum Kapitel 9-12 + 14, Scrumbok Det högra spåret Vi lämnar nu det vänstra spåret de mjukare delarna och går in på det högra spåret som

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

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. på fem minuter

Scrum. på fem minuter Scrum på fem minuter DET TALAS MYCKET OM SCRUM OCH LÄTTRÖRLIGA METODER JUST NU STÄLL DIG FÖLJANDE FRÅGOR A simple method for the management of complex projects... Äldre metoder fokuserar på att hålla planen,

Läs mer

Steget efter CAD Data Management. Per Ekholm

Steget efter CAD Data Management. Per Ekholm Steget efter CAD Data Management Per Ekholm Agenda Vilka processer/discipliner stöds i PDMLink Dokument management Configuration Management Change Management Project Management Hur utvärderar jag behovet?

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

Distribuerad mjukvaruutveckling med extreme Programming

Distribuerad mjukvaruutveckling med extreme Programming Distribuerad mjukvaruutveckling med extreme Programming Jörgen Nilsson, d00jni@efd.lth.se February 22, 2005 Sammanfattning Denna artikel är en djupstudie skriven under en kurs i coaching av XPteam, på

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

Testdriven utveckling. Magnus Jonsson Siemens Medical Solutions

Testdriven utveckling. Magnus Jonsson Siemens Medical Solutions Testdriven utveckling Magnus Jonsson Siemens Medical Solutions 2 Soarian Stort projekt, ca 400 personer i projektet Distribuerad utveckling i USA, Indien och Sverige Web baserat lösning med admin client

Läs mer

SCRUM. En agil projektmetod baserad på empiri - vad fungerar och vad fungerar inte?

SCRUM. En agil projektmetod baserad på empiri - vad fungerar och vad fungerar inte? SCRUM En agil projektmetod baserad på empiri - vad fungerar och vad fungerar inte? Grundprinciper Projektgruppen organiserar och planerar sitt eget arbete Fokus på verksamhetsnytta Alla krav prioriteras

Läs mer

HÖSTTERMINEN. Scrum STF INGENJÖRSUTBILDNING AB. Vi vidareutbildar ingenjörer och tekniker. Din partner för livslångt lärande

HÖSTTERMINEN. Scrum STF INGENJÖRSUTBILDNING AB. Vi vidareutbildar ingenjörer och tekniker. Din partner för livslångt lärande STF INGENJÖRSUTBILDNING Vi vidareutbildar ingenjörer och tekniker Scrum STF KOMPETENSINFO NR 63/2011 HÖSTTERMINEN STF INGENJÖRSUTBILDNING AB Din partner för livslångt lärande WWW.STF.SE Scrum i praktiken

Läs mer

Agilt arbetssätt i komplexa organisationer. Välkomna! Anna Picetti, IT-HUSET 2011-10-27. www.it-huset.se

Agilt arbetssätt i komplexa organisationer. Välkomna! Anna Picetti, IT-HUSET 2011-10-27. www.it-huset.se Agilt arbetssätt i komplexa organisationer Välkomna! Anna Picetti, IT-HUSET 2011-10-27 Ord från en företagsledare Ett bra genomförande är 90 procent av framgången och strategin 10, varav magkänslan är

Läs mer

Agil utveckling ställer nya krav på upphandling. Roland Bäcklin, Jaybis Konsult AB roland.backlin@jaybis.se

Agil utveckling ställer nya krav på upphandling. Roland Bäcklin, Jaybis Konsult AB roland.backlin@jaybis.se Agil utveckling ställer nya krav på upphandling Roland Bäcklin, Jaybis Konsult AB roland.backlin@jaybis.se Roland Bäcklin Tidigare: Utvecklare, Systemarkitekt, Projektledare, CTO, CIO, Riksinstruktör,

Läs mer

SCRUM. på fem minuter

SCRUM. på fem minuter SCRUM på fem minuter DET TALAS MYCKET OM SCRUM OCH LÄTTRÖRLIGA METODER JUST NU STÄLL DIG FÖLJANDE FRÅGOR A simple framework for managing complex projects Traditionella metoder fokuserar på att hålla planen,

Läs mer

Agila Avtal. avtalsformer som kan fungera. Carina Meurlinger carina.meurlinger@agero.se

Agila Avtal. avtalsformer som kan fungera. Carina Meurlinger carina.meurlinger@agero.se Agila Avtal Hur man säljer in agila projekt olika avtalsformer som kan fungera Carina Meurlinger carina.meurlinger@agero.se Min syn på saken och kundens Detta är vad vi alla önskar Lite om mig själv Carina

Läs mer

Agil testning i SCRUM

Agil testning i SCRUM Agil testning i SCRUM Petter Salomonsson Petter.salomonsson@addq.se Tel: 0708-398435 Kort presentation AddQ Consulting AB tydlig fokus på test och kvalitetssäkringstjänster erbjuder mycket erfarna konsulter

Läs mer

Agile - det moderna synsättet på mjukvaruutveckling Ordet Agile kommer från engelskan och kan närmast översättas med flexibel, dynamisk och smidig. Med det menar vi dynamiska projekt som konstruktivt kan

Läs mer

Testbara krav. SAST Syd 2012-02-09. Ställ gärna frågor under presentationen eller efteråt Åhörarkopior distribueras efteråt

Testbara krav. SAST Syd 2012-02-09. Ställ gärna frågor under presentationen eller efteråt Åhörarkopior distribueras efteråt Testbara krav SAST Syd 2012-02-09 Ställ gärna frågor under presentationen eller efteråt Åhörarkopior distribueras efteråt Ulf Eriksson Produktägare på ReQtest Specialist på kravhantering och test Grundare

Läs mer

Agila metoder en kartläggning av teori och praktik

Agila metoder en kartläggning av teori och praktik Agila metoder en kartläggning av teori och praktik Anna Georgsson 16 augusti 2010 Examensarbete på kandidatnivå, 15 hp Handledare: Jürgen Börstler Examinator: Jonny Pettersson UMEÅ UNIVERSITET INSTITUTIONEN

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

Teststrategier och Testcertifiering. Per Strandberg, Maj 2013

Teststrategier och Testcertifiering. Per Strandberg, Maj 2013 Teststrategier och Testcertifiering Per Strandberg, Maj 2013 1 Lite om Test i Allmänhet och ISTQB Certifiering Mål med testning? Förebygga fel Hitta fel eller risk Underlätta och ge stöd vid utveckling

Läs mer

2009-02-02. Verktyg för agil systemutveckling. Vad är ett verktyg? Olika typer av verktyg för mjukvaruutveckling. Vad kan ett bra verktyg tillföra?

2009-02-02. Verktyg för agil systemutveckling. Vad är ett verktyg? Olika typer av verktyg för mjukvaruutveckling. Vad kan ett bra verktyg tillföra? Vad är ett verktyg? Verktyg för agil systemutveckling Individuals and interactions over processes and tools - The Agile Manifesto Papper, penna, linjal CAD-program Skruvmejsel Skruvdragare Etc 1 2 Vad

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

Agila systemutvecklingsmetoders inverkan på kundrelationer

Agila systemutvecklingsmetoders inverkan på kundrelationer < Agila systemutvecklingsmetoders inverkan på kundrelationer Case Esmi Annika Paajanen Institutionen för marknadsföring Svenska handelshögskolan Helsingfors 2014 SVENSKA HANDELSHÖGSKOLAN Institution: Marknadsföring

Läs mer

Projektmetodik II. HF1005, Informationsteknik och ingenjörsmetodik för Datateknik. Projektarbete

Projektmetodik II. HF1005, Informationsteknik och ingenjörsmetodik för Datateknik. Projektarbete Projektmetodik II HF1005, Informationsteknik och ingenjörsmetodik för Datateknik Projektarbete Förväntade resultatet är t.ex. en produkt Vi behöver arbeta med Analys Faktainsamling Genomförande Rapportering

Läs mer

1 z. En agil arbetsmetod för utveckling av ett leverantörsstöd

1 z. En agil arbetsmetod för utveckling av ett leverantörsstöd 1 z En agil arbetsmetod för utveckling av ett leverantörsstöd An Agile method for development of a producer support system Albert Fors Arman Jakupovic EXAMENSARBETE 2014 Postadress: Besöksadress: Telefon:

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

SCRUM & sprint-retrospektiv

SCRUM & sprint-retrospektiv - användandet av sprint-retrospektiv, dess utformning och relevans för kontinuerlig förbättring. Kandidatuppsats, 15 högskolepoäng, SYSK01 i informatik Framlagd: Juni, 2011 Författare: Christian Andersson

Läs mer

AGIL KRAVHANTERING. Hitta behoven bakom kraven!! Thomas Nilsson! Agile Coach & Mentor! CTO, Responsive

AGIL KRAVHANTERING. Hitta behoven bakom kraven!! Thomas Nilsson! Agile Coach & Mentor! CTO, Responsive AGIL KRAVHANTERING Hitta behoven bakom kraven!!! Thomas Nilsson! Agile Coach & Mentor! CTO, Responsive KRAVSTÄLL EN PRODUKT! Skriv ner tre krav som ni ställer på produkten INNOVATIONSDRIVNA PRODUKTER...

Läs mer

Whitepaper Green Bullet Agil HR

Whitepaper Green Bullet Agil HR Whitepaper Green Bullet Agil HR Agil HR Inledning Detta whitepaper syftar till att förklara vad Agile är och hur HR bör anpassa sitt arbete för att skapa större värde i en agil organisation. I takt med

Läs mer

Kvalitetssäkring i ett Scrumteam

Kvalitetssäkring i ett Scrumteam Kvalitetssäkring i ett Scrumteam Richard Kronfält, 29 september 2011 Handuppräckning > Hur många arbetar idag som Testare? > Hur många arbetar idag som Programmerare? > Hur många arbetar idag med projektledning

Läs mer

Scrumguiden. Den definitiva guiden till Scrum: Spelets regler. Juli 2013. Utvecklad och underhållen av Ken Schwaber och Jeff Sutherland

Scrumguiden. Den definitiva guiden till Scrum: Spelets regler. Juli 2013. Utvecklad och underhållen av Ken Schwaber och Jeff Sutherland Scrumguiden Den definitiva guiden till Scrum: Spelets regler Juli 2013 Utvecklad och underhållen av Ken Schwaber och Jeff Sutherland Innehåll Syftet med Scrumguiden... 3 Definitionen av Scrum... 3 Teorin

Läs mer

Användbarhet i sitt sammanhang

Användbarhet i sitt sammanhang Användbarhet i sitt sammanhang Världsanvändbarhetsdagen 2009-11-12 Anders Hedberg, Guide Konsult Stockholm Innehåll En helikoptertur över ett projekts olika faser med belysning på användbarhet i förhållande

Läs mer

Den agila utvecklingen

Den agila utvecklingen Den agila utvecklingen En jämförelse mellan teori och praktik Agile Development A Comparison between Theory and Practice JENNIE HÄGGLUND JOHANNA FRE MARIA KARLSSON Examensarbete/Kandidatuppsats i Informatik

Läs mer

Projektplan, Cykelgarage

Projektplan, Cykelgarage Projektplan, Cykelgarage Johan Anderholm, (dt08ja5@student.lth.se) Jon Andersen (dt08ja8@student.lth.se) Marcus Carlberg (dt08mc4@student.lth.se) Simon Ekvy (dt08se2@student.lth.se) Stefan Johansson (dt08sj7@student.lth.se)

Läs mer

Professionell masterutbildning i programvaruteknik

Professionell masterutbildning i programvaruteknik Professionell masterutbildning i programvaruteknik Mälardalens högskola Blekinge Tekniska Högskola Chalmers Tekniska Högskola & Göteborgs Universitet Swedish Institute of Computer Science Swedsoft i samarbete

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

Processbeskrivning Systemutveckling

Processbeskrivning Systemutveckling ProcIT-P-015 Processbeskrivning Systemutveckling Lednings- och kvalitetssystem Fastställd av Sven Arvidson 2011-09-12 Innehållsförteckning 1 Inledning 3 1.1 Symboler i processbeskrivningarna 3 2 Systemutvecklingsprocessen

Läs mer

Lean software development och lättrörlig utveckling

Lean software development och lättrörlig utveckling Lean software development och lättrörlig utveckling TOBIAS FORS & MIKAEL LUNDGREN Agenda Vi vill visa: Ett pågående paradigmskifte i mjukvaruvärlden Nämligen: Lean: en teoribas för lättrörlig utveckling

Läs mer

Lean programvaruutveckling

Lean programvaruutveckling Lean programvaruutveckling Av Ludvig Hagmar (d01lh@efd.lth.se eller l_hagmar@hotmail.com) Den 12:e Februari 2006 Abstract: Denna djupstudie behandlar den agila metoden Lean software development eller Lean

Läs mer

Kursinformation. Metodik för programvaruutveckling. Utvecklingsprocessen för programvara. Innehåll. Processmodell. Exempel

Kursinformation. Metodik för programvaruutveckling. Utvecklingsprocessen för programvara. Innehåll. Processmodell. Exempel Kursinformation Metodik för programvaruutveckling Föreläsning 3 Latex ok för litteraturstudierapport (prata med mig bara) Nästa föreläsning är av Björn Regnell (jag är med också) Presentationer imorgon

Läs mer

SCRUM som utvecklingsmetod

SCRUM som utvecklingsmetod SCRUM som utvecklingsmetod Så fungerar det i verkligheten Kandidatuppsats inom Data- och Systemvetenskap (15hp) Författare: Handledare: Martin Levin Torsten Palm Uppsala: januari 2011 1 Sammanfattning

Läs mer

Insikt. kräver kunskap, erfarenhet och förståelse

Insikt. kräver kunskap, erfarenhet och förståelse Insikt kräver kunskap, erfarenhet och förståelse Målet är utveckling... håller inte måttet Företag med teknologibaserad utveckling står idag inför många utmaningar. Den viktigaste är utan tvekan förmågan

Läs mer

Projekt Rapport. RaidPlanner. Jeanette Karlsson UD10

Projekt Rapport. RaidPlanner. Jeanette Karlsson UD10 Projekt Rapport RaidPlanner Jeanette Karlsson UD10 Abstrakt: Denna rapport handlar om mitt projekt i kursen Individuellt Mjukvaruutvecklings projekt. Rapporten kommer att ta upp hur jag gått tillväga,

Läs mer

Framtidens Team AB. utvecklingsprogram för unga/nya chefer/ledare. utbildning i kommunikologi, grundnivå: intensiv träning i nya paradigmets ledarskap

Framtidens Team AB. utvecklingsprogram för unga/nya chefer/ledare. utbildning i kommunikologi, grundnivå: intensiv träning i nya paradigmets ledarskap Framtidens Team: utvecklingsprogram för unga/nya chefer/ledare utbildning i kommunikologi, grundnivå: intensiv träning i nya paradigmets ledarskap 2009 Framtidens Team 1 Framtidens ledarskap Vi tror att

Läs mer

Platina och kvalité. Rasmus Staberg, Teknisk direktör, 2014-04-08

Platina och kvalité. Rasmus Staberg, Teknisk direktör, 2014-04-08 Formpipe Platina och kvalité Rasmus Staberg, Teknisk direktör, 2014-04-08 04 08 1 Formpipe Presentation Bakgrund Platina släpptes som första release år 2000. Fick pris för Best in show från Bill Gates

Läs mer

IT-projektledning - introduktion 725G62

IT-projektledning - introduktion 725G62 IEI Tommy Wedlund Läsanvisningar, IT-projektledning introduktion, 725G62 IT-projektledning - introduktion 725G62 Läsanvisningar tentamen inför tentamen I tentamen ingår följande kurslitteratur: The IBM

Läs mer

Sammanställning av kursvärdering

Sammanställning av kursvärdering Dnr HS 214/42 Sammanställning av kursvärdering (blanketten används inte för lärarutbildningskurser) Fakulteten för humaniora och samhällsvetenskap Sammanställning av vårterminens kurser ska vara underskriven,

Läs mer

Projekt intranät Office 365 av Per Ekstedt

Projekt intranät Office 365 av Per Ekstedt Projekt intranät Office 365 av Per Ekstedt 1 BESKRIVNING AV UTFÖRANDE Uppdraget planeras att genomföras med ett agilt arbetssätt samt best practice från Microsoft gällande SharePoint online. Uppdraget

Läs mer

Du fulländar mig! Om synergierna mellan agila metoder och UX. Joakim Holm Adaptiv AB. Erik Hammarström Antrop AB

Du fulländar mig! Om synergierna mellan agila metoder och UX. Joakim Holm Adaptiv AB. Erik Hammarström Antrop AB Du fulländar mig! Om synergierna mellan agila metoder och UX Joakim Holm Adaptiv AB Erik Hammarström Antrop AB Vetenskapliga metoden 1. Observera verkligheten 4. Genomför experiment 2. Utforma hypotes

Läs mer

En jämförande studie av begreppet Agil utveckling i teori och praktisk användning

En jämförande studie av begreppet Agil utveckling i teori och praktisk användning Teknik och samhälle Datavetenskap Examensarbete 15 högskolepoäng, grundnivå En jämförande studie av begreppet Agil utveckling i teori och praktisk användning A comperative study of the agile concept. Agile

Läs mer

Modell för agil utveckling och förvaltning av produkter

Modell för agil utveckling och förvaltning av produkter Beslutsdatum: 2014-07-23 MDH 1.1-396/14 1 (4) Beslutande: Förvaltningschefen Ansvarig för tillämpning: Förvaltningschef Dokumentansvarig: Rektors kansli Dokumenttyp: Processbeskrivning Datum för ikraftträdande:

Läs mer

ALM Live. April 2008 Effektivare projektarbete med Visual Studio 2008

ALM Live. April 2008 Effektivare projektarbete med Visual Studio 2008 ALM Live April 2008 Effektivare projektarbete med Visual Studio 2008 Jaha, och vem är du då? Magnus Juvas Lösningsarkitekt Transcendent Group Och vad gör ni då? Inom området ALM gör Transcendent Group

Läs mer

Agila Organisationer

Agila Organisationer Att förändra f och leda Agila Organisationer m.thelin@jaybis.se *Utveckla agil def: Agila organisationer förändra och led! Förändra Möjliggör med ett Core Team Involvera Vision Utbilda Aktivitetsbacklogg

Läs mer

Den Agila utvecklingen

Den Agila utvecklingen Den Agila utvecklingen En studie baserad på den agila metodikens utformning i praktiken The Agile development A study based on the agile methodology in practice Madelein Larsson, Nathalie Lindholm Centrum

Läs mer

Hur lyckas med förändring?

Hur lyckas med förändring? 1 Hur lyckas med förändring? Mattias Hermansson, förändringsledare 2 Agenda förändringsmättnad förändringsledning ledarskap och samarbete fokus 3 Vem är Mattias Hermansson? Förändringsledare Chef Föreläsare

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

Generella riktlinjer vid distribuerad Scrum En kvalitativ studie av hur ett distribuerat projekt bedrivs med hjälp av Scrum

Generella riktlinjer vid distribuerad Scrum En kvalitativ studie av hur ett distribuerat projekt bedrivs med hjälp av Scrum Generella riktlinjer vid distribuerad Scrum En kvalitativ studie av hur ett distribuerat projekt bedrivs med hjälp av Scrum General guidelines for distributed Scrum A qualitative study of how a distributed

Läs mer

Förslag på intervjufrågor:

Förslag på intervjufrågor: Förslag på intervjufrågor: FRÅGOR OM PERSONENS BAKGRUND 1. Var är du uppväxt? 2. Om du jämför din uppväxt med andras, hur skulle du ranka din egen uppväxt? 3. Har du några syskon? 4. Vad gör de? 5. Vilka

Läs mer

Kurser och seminarier från AddQ Consulting

Kurser och seminarier från AddQ Consulting och seminarier från AddQ Consulting Vår vision är att genom fokus på kvalitet och effektivitet inom IT bidra till att underlätta människors vardag. Kompetensutveckling är nyckeln till framgång för dig

Läs mer

Lyckade projekt - finns det?

Lyckade projekt - finns det? Lyckade projekt - finns det? Maria Lindqvist Björkman Enea Business Software Enea Business Software 2002 Sida 1 Agenda Förväntningar kund & leverantör Statistik om projekt Framgångsfaktorer Exempel på

Läs mer

Projektledare vs ScrumMaster

Projektledare vs ScrumMaster Projektledare vs ScrumMaster Finns det rum för den klassiske projektledaren i en agil värld? Carina Meurlinger carina.meurlinger@agero.se Lite om mig själv Carina Meurlinger Konsult på Agero sedan 2005

Läs mer

Tillsammans är vi starka

Tillsammans är vi starka Tillsammans är vi starka Välkommen! Sättet vi lever vår vision och vår affärsidé på är vad som bland annat skiljer oss från våra konkurrenter. Det handlar om HUR vår omgivning upplever samarbetet med oss

Läs mer

Projektarbete DAVC20

Projektarbete DAVC20 Projektarbete DAVC20 DAVC20, Per Strömgren 2002-10-28 Make a plan. Then follow the plan. Watts Humphrey 2 DAVC20, Per Strömgren, 1 Vad handlar detta om?! 3 DAVC20, Per Strömgren Examination För godkänt

Läs mer

Agile i ett större sammanhang

Agile i ett större sammanhang Agile i ett större sammanhang Thomas Nilsson http://www.responsive.se http://www.responsive.se/thomas Agile Developer, Coach & Mentor Vad driver kostnaden? 1) Felaktig funktionalitet Inkluderande missuppfattningar,

Läs mer

Övningstenta, examinationsfrågor 2015-03-09

Övningstenta, examinationsfrågor 2015-03-09 Swedish Software Testing Board (SSTB) International Software Testing Qualifications Board (ISTQB) Agile Tester Certificate in Software Testing Övningstenta, examinationsfrågor 2015-03-09 Tillåten tid:

Läs mer

PROJEKT ALBYLEN. Datum: 25 mars 2011. AV: Magnus Lindgren, Mattias Jonsson, Alexander Paskota, Jimmie Yngvesson, Erik Nilsson

PROJEKT ALBYLEN. Datum: 25 mars 2011. AV: Magnus Lindgren, Mattias Jonsson, Alexander Paskota, Jimmie Yngvesson, Erik Nilsson PROJEKT ALBYLEN Datum: 25 mars 2011 AV: Magnus Lindgren, Mattias Jonsson, Alexander Paskota, Jimmie Yngvesson, Erik Nilsson 0 Sammanfattning: Föreningen Albylen som bedriver aktivitets- och friskvårdscentrum

Läs mer

Idag. Förväntningar. Farhågor 2014-02-03. Agil användbarhetsutveckling för handhållna enheter TNM082, VT2014, FÖ2. Agil utveckling Scrum

Idag. Förväntningar. Farhågor 2014-02-03. Agil användbarhetsutveckling för handhållna enheter TNM082, VT2014, FÖ2. Agil utveckling Scrum Agil användbarhetsutveckling för handhållna enheter TNM082, VT2014, FÖ2 Idag Agil utveckling Scrum Förväntningar En helt ny utmaning. Det ska inte vara som andra kurser Företag har oka erfarenhet inom

Läs mer

Delivering Business Value through IT

Delivering Business Value through IT Delivering Business Value through IT Verklig affärsnytta genom leverans av kvalitativa IT-projekt IT-projekt handlar om affärsnytta. Vi är experter på att leverera IT-projekt, vårt pragmatiska angreppsätt

Läs mer

QC i en organisation SAST 2008-09-16

QC i en organisation SAST 2008-09-16 QC i en organisation SAST 2008-09-16 1 Agenda Hur är vi organiserade inom test på SEB? Hur är QC uppsatt på SEB? Hur arbetar vi med QC i en stor organisation? Uppfyllde QC våra förväntningar och hur har

Läs mer

Agil projektmetodik Oscar Landström & Oskar Odervall

Agil projektmetodik Oscar Landström & Oskar Odervall Kandidatarbete i Medieteknik 30 hp VT 2012 Agil projektmetodik En studie av den agila metodiken och Scrums inverkan på IT-projekt Oscar Landström & Oskar Odervall Examinator: Peter Ekdahl Handledare: Pirjo

Läs mer

Identifiera kundbehov En sammanfattning och analys av kapitel 4 i boken Product Design and Development

Identifiera kundbehov En sammanfattning och analys av kapitel 4 i boken Product Design and Development Identifiera kundbehov En sammanfattning och analys av kapitel 4 i boken Product Design and Development Grupp 6 Ali Abid Kjell Nilsson Patrick Larsson Mälardalens högskola KN3060, Produktutveckling med

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

men borde vi inte också testa kraven?

men borde vi inte också testa kraven? men borde vi inte också testa kraven? Robert Bornelind Presentation på SAST, 24 februari 2011 SQS Software Quality Systems Sweden AB Innehåll Introduktion Kvalitet, tid och kostnad Process Testning av

Läs mer

Agila metoder och motivation

Agila metoder och motivation Agila metoder och motivation Varför blir man produktiv av att flytta lappar på en whiteboard? Tomas Jansson tomas.jansson@kau.se Agila metoden Scrum Sprint planning Every 24 hours Daily scrum Sprint backlog

Läs mer

Pragmatisk programmering. Cyberrymden 2001-10-03. Marcus Rejås Pragmatisk programmering,16 december 2002 1(29)

Pragmatisk programmering. Cyberrymden 2001-10-03. Marcus Rejås <marcus@rejas.se> Pragmatisk programmering,16 december 2002 1(29) Pragmatisk programmering,16 december 2002 1(29) Pragmatisk programmering Cyberrymden 2001-10-03 Marcus Rejås $Id: slides.tex,v 1.14 2002/12/16 14:52:59 rejas Exp $ Metainformation Denna

Läs mer

Javautvecklare. Utbildningsfakta. 400 YH-poäng, 2 år

Javautvecklare. Utbildningsfakta. 400 YH-poäng, 2 år Javautvecklare 400 YH-poäng, 2 år Utbildningsfakta Kurser (12 stycken) Grundläggande programmering och javaverktyg 50 yhp Grafiskt gränssnitt och interaktion 20 yhp Internet, webb och webbramverk 40 yhp

Läs mer

Agile Enterprise Architecture

Agile Enterprise Architecture Agile Enterprise Architecture Manifesto for Agile Software Development 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

Fakulteten för ekonomi, kommunikation och IT. Jenny Ericsson. Kanban. Går metoden att använda för att styra utvecklingsprojekt? Informatik.

Fakulteten för ekonomi, kommunikation och IT. Jenny Ericsson. Kanban. Går metoden att använda för att styra utvecklingsprojekt? Informatik. Fakulteten för ekonomi, kommunikation och IT Jenny Ericsson Kanban Går metoden att använda för att styra utvecklingsprojekt? Informatik C-uppsats Datum: VT 2011 Handledare: Examinator: Lars-Erik Axelsson

Läs mer

Introduktion till lättrörlig produktutveckling med Lean och Scrum

Introduktion till lättrörlig produktutveckling med Lean och Scrum Introduktion till lättrörlig produktutveckling med Lean och Scrum Mikael Lundgren Introduktion Lean och Agile är populära begrepp idag, då många verksamheter inspireras av Toyotas framgångar och effektiva

Läs mer

Metoder och verktyg för funktionssäkerhet

Metoder och verktyg för funktionssäkerhet Metoder och verktyg för funktionssäkerhet Projektstart 1. Hantera kraven En bra process är grunden för att hantera kraven i ett säkerhetsprojekt. Det krävs att du har en tydlig spårbarhet mellan krav och

Läs mer