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

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

Innehållsförteckning ABSTRACT... 3 1 INLEDNING... 4 2 VAD ÄR EN LÄTTVIKTSMETODIK? [1]... 4 3 EXTREME PROGRAMMING (XP) [2, 3]... 5 3.1 XPs fem grundläggande värderingar... 5 3.2 XPs tolv praxisar... 6 4 SCRUM-METODIKEN [4]... 7 4.1 Hur går ett SCRUM-projekt till? [4, 3]... 8 4.2 Faktorer att ta hänsyn till vid utarbetning av releaseplanen... 9 4.3 SCRUMs olika faser... 9 4.4 SCRUM controls... 10 4.5 SCRUM-projekt... 11 5 SCRUM VS. XP [2, 6, 8, 9]... 12 5.1 Vad är gemensamt?... 12 5.2 Vad skiljer dem åt?... 13 5.3 Vilken är att föredra?... 14 5.4 Vad kan SCRUM tillföra XP?... 14 6 SAMMANFATTNING... 15 REFERENSLISTA... 15 2

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

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

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

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

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

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

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

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

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

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

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

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

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, 2003. [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, www.balagan.org.uk/work/agile_comparison.htm, 2005-12-30 [9] Martin Fowler: The New Methodology, www.martinfowler.com/articles/newmethodology.html, 2005-12-30 [10] The Scrum Development Process, www.mountaingotsoftware.com/scrum/index.php, 2006-02-17 15