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

Transkript

1 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

2 Abstract Scrum och XP är två agila metoder för programvaruutveckling. Båda metoder beskriver praktiker för agil mjukvaruutveckling men ur olika perspektiv. Scrum fokuserar på att förbättra utvecklingsprocessen medan XP lägger mer tyngd på att höja kvaliteten på mjukvaran som utvecklas. Denna rapport undersöker om Scrum kan införas i ett litet XP-projekt för att förbättra utvecklingsprocessen. Många av Scrums praktiker lämpar sig speciellt bra i storskaliga organisationer, men vår studie visar att Scrum och XP är en vinnande kombination även i små projekt. 2

3 Innehåll 1 Inledning Bakgrund Kursprojektet XP Scrum Metod Hypotes Resultat Slutsats Referenslista A1 Terminologi A2 Enkät

4 1 Inledning I moderna mjukvaruutvecklingsprojekt har agila utvecklingsmodeller blivit allt mer populära de senaste åren. Två av de mest populära är extreme Programming (XP) och Scrum. Båda modeller beskriver process och praktiker för agil mjukvaruutveckling men ur två olika perspektiv; XP ur utvecklarnas perspektiv och Scrum från projektledningsperspektivet. I många projekt används trots detta uteslutande en av modellerna utan att ge praktikerna från den andra en tanke. Från erfarenheter av att jobba i projekt som, om än inte uttalat, använder sig av praktiker från båda har vi fått en annan bild - den att de två kan fungera i symbios. Syftet med denna studie är därför att undersöka vilka praktiker från Scrum-modellen som passar i ett litet XP-projekt. Vissa ändringar till de olika praktiker vi har valt att studera har dock gjorts för att passa projektet. Kapitel 2 beskriver kursprojektet för studien, samt metoderna XP och Scrum. I kapitel 3 redogörs för hur studien ska gå till väga. Hypotesen för studien beskrivs i kapitel 4 och resultaten tas upp i kapitel 5. Resultaten diskuteras i vår slutsats i kapitel 6. Områdesspecifika termer är markerade i kursiv stil och förklaras närmare i texten eller i Appendix A. 2 Bakgrund XP används ofta i moderna mjukvaruprojekt men med större och globala organisationer uppkommer nya svårigheter, svårigheter som Scrum försöker lösa. Vårt mål är att studera hur väl denna kombination fungerar för utvecklingsteam av storleken 8-10 personer. Det har skrivits många artiklar och texter om hur Scrum och XP fungerar och hur användbara metoderna är. Flera studier har jämfört XP och Scrum och vägt deras för- och nackdelar mot varandra men också undersökt huruvida de kan lära av varandra eller kanske till och med kombineras. De flesta fall där detta undersökts har dock förekommit inom stora projekt som har ett behov av att organisera agil utveckling. 2.1 Kursprojektet Arbetet i projektet utförs som en del av kursen EDA260 - Programvaruutveckling i grupp. Syftet med kursen är att ge kunskaper om, och praktisk erfarenhet av, hur man samverkar i ett team för att ta fram en programvaruprodukt. Fokus ligger på metoden extreme Programming, en högiterativ, så kallad agil, utvecklingsprocess som syftar till hållbar utveckling av mjukvara. Kursen tar upp principer för samarbete med beställaren, planering, hållbar design/implementation, testning och leverans. [EDA260 10] 4

5 Kursen består av två delar: teoridelen, där den grundläggande teorin presenteras och testas, och projektdelen där teorin tillämpas i ett projekt bestående av 8-10 personer i ett utvecklingsteam. Arbetet i projektet är uppdelat på tretton tillfällen där det första är ett projektstartmöte där projektet och medlemmarna i teamet presenteras. De övriga tolv tillfällena är uppdelade över sex veckor och utgörs av ett planeringsmöte á två timmar och en laboration á åtta timmar varje vecka. Under planeringsmötet planeras veckans arbete genom att göra en tidsestimering av olika stories, krav på funktionalitet som ska ingå i programmet, som sedan prioriteras av kunden. I denna kurs är kunden en lärare vid LTH som agerar beställare av systemet och som i denna roll ställer krav på funktionalitet och användning. Efter kundens prioritering görs en uppskattning av hur mycket funktionalitet som kommer att kunna implementeras under nästa laboration och varje utvecklare får en spike att utföra tills nästa mötestillfälle. En spike är en hemuppgift med avsikten att utforska en möjlig lösning på ett problem. Laborationerna sker i en sal utrustad med tillräckligt många datorer för att förse varje par inom teamet med en egen dator. Alla datorer är placerade så att muntlig kommunikation mellan paren kan ske utan ansträngning. Vid enskilda laborationstillfällen skall kunden förses med en fungerande version av systemet, detta görs genom teamet skickar den senaste versionen av systemet till kunden innan en bestämd tid. För att möjliggöra för utvecklarna att rätta till mindre fel brukar denna deadline sättas i ett par timmar innan laborationens slut, detta gör att teamet vid dessa laborationstillfällen har mindre tid att implementera funktionalitet. 2.2 XP Begreppet extreme Programming introducerades först av Kent Beck [Beck 99]. Beck presenterar en metod för att stödja mjukvaruutveckling i moderna agila projekt. Med ett agilt projekt menas ett projekt där krav och prioriteringar kan ändras under utvecklingens gång. Beck bryter ner utvecklingen i tre olika delar: Design, Planering och Utveckling. Inom varje område rekommenderar sedan Beck ett antal metoder eller praktiker som ska följas för att försäkra att slutresultatet håller hög kvalité. För underlätta för utvecklare att jobba parallellt i ett agilt projekt förespråkar Beck några mönster som fokuserar på enkelhet och konsekvent utveckling. Bland dessa ingår Simple Design, som säger att utvecklare endast skall designa koden för att stödja den aktuella funktionaliteten och inte planera för framtiden. Det anses även viktigt att se till att refaktorisera metoder kontinuerligt och att undvika s.k. gudklasser som har allt för mycket funktionalitet inbakad. Detta ger systemet en agil design som lätt kan ändras och byggas på. Andra mönster som Common Vocabulary och Collective Codings Standard fokuserar på att få utvecklarna att använda samma "språk" så att alla kan förstå koden som skrivs och inte drar sig för att ändra i den. 5

6 Vidare förespråkar Beck att ha en representant för kunden i teamet. Representanten skall finnas tillgänglig på heltid för att hjälpa utvecklarna att producera det kunden faktiskt vill ha genom att hjälpa till med prioritering, releasegranskning och att svara på frågor. Genom att ha en kund i teamet och jobba i små iterationer får både stakeholders och utvecklare ständig feedback på arbetet. Med stakeholder menas någon som investerat i projektet. Själva utvecklingen i XP-projekt är tänkt att ske i par. Detta för att hjälpa utvecklarna att fokusera och för att få en kontinuerlig kodgranskning som höjer kodkvaliteten. Av denna anledning skall även Test-Driven Development användas, vilket innebär att tester ska skrivas för funktionalitet innan den implementeras. Alla utvecklare skall även befinna sig i samma rum under utvecklingen för att höja kommunikationen. Beck anser att goda möjligheter för muntlig kommunikation höjer kvaliteten på kommunikationen och sparar tid. XP prioriterar därför god kommunikation framför god dokumentation. 2.3 Scrum Scrum är en annan modell för mjukvaruutveckling som koncentrerar sig på att försäkra utvecklare och övriga stakeholders om att produkten som utvecklas är överskådlig, flexibel för kravändringar och framförallt rätt [Schwaber 07]. Själva termen Scrum kommer ifrån sporten rugby där det är den samling som görs vid varje återstart av spelet. Det har skrivits många artiklar om arbetssättet i Scrum och det finns inte en specifik upphovsman ansvarig för att ha grundat metoden, tvärtom finns det många som bidragit med olika delar av metoden. Men metoden kan brytas ner till tre faser: pre-game, development och post-game [Qumer 06]. I pre-game ser man över vad som behöver göras och väljer ut funktionalitet som man beräknar hinna implementera under developmentfasen. Under denna fas finns inga specifika regler för utveckling utan man gör vad som krävs för att följa planeringen. Under post-game efter varje utvecklingsiteration gör stakeholders en inspektion av systemet och gör ändringar inför nästa iteration [Schwaber 07]. I projektet finns det tre uttalade roller: Product Owner, utvecklingsteam och Scrum Master. Projektets Product Owner kan liknas vid XP's kund och är en person i teamet som är ansvarig för att representera alla stakeholders intressen, genom att förse teamet med produktkrav, deadlines och dag-till-daghjälp. Kraven sätts i en lista, kallad product backlog. Det är sedan Product Owners ansvar att kontinuerligt prioritera denna lista för att hjälpa teamet fokusera. Utvecklingsteamet skapar sedan utifrån product backlog en sprint backlog, som är en lista över funktionalitet som förväntas implementeras under sprinten, och ansvarar för att kraven implementeras. De är kollektivt ansvariga för hela mjukvaran och iterationens framgång. Scrum Master kan liknas vid en projektledare och ansvarar för att få processen att fungera [Schwaber 07]. Arbetet i ett Scrum-projekt är uppdelat i ett antal mindre iterationer (i Scrum kallat sprints) 6

7 som alla skall resultera i ett körbart system. Det som skiljer de olika iterationernas mål åt är vilken funktionalitet systemet skall innehålla vid slutet. Varje iteration börjar med ett planeringsmöte där Product Owner och utvecklingsteamet träffas. I den första delen av mötet presenterar Product Owner den högst prioriterade funktionaliteten, tillsammans med teamet skrivs sedan ett kontrakt på vilken funktionalitet som skall finnas med i systemet i slutet av iterationen. I den andra delen av mötet, där endast teamet närvarar, planeras sedan iterationen i detalj genom att dela upp funktionaliteten i tasks och utföra impact analysis. En task är en del av en story och impact analysis innebär att man analyserar hur funktionalitet som ska läggas till kan påverka befintlig funktionalitet i programmet. Efter planeringsmötet startar utvecklingen, där varje dag inleds med ett möte, daily scrum, där varje medlem svarar på tre frågor: "vad har du gjort sen förra mötet?", "vad planerar du att göra idag?" och "vilka hinder finns det för ditt arbete?" [Schwaber 07]. Iterationens sprint backlog görs tillgänglig på ett scrum board för att öka översikten över iterationens arbete. Ett scrum board är en fysisk överblick över vilken funktionalitet som ingår i iterationen och i vilken utvecklingsfas varje task befinner sig. För varje fas definieras vad som krävs för att den ska anses klar. När en task uppfyllt dessa krav flyttas den åt höger till nästa fas. En bild över vårt scrum board visas i figur 1 nedan. Figur 1. Utvecklingsfaserna för tasks på vår scrum board. Det som skiljer det vårt scrum board från ett mer typiskt är att vårt innehåller fler faser för 7

8 att poängtera processen, detta gör det enklare för noviser att försäkra sig om att alla steg för att hålla en hög kodkvalité tas. Ett typiskt scrum board brukar endast bestå av tre faser: inte påbörjad, påbörjad och klar [Kniberg 07]. Under iterationen används även en burn-down chart för att visa det kvarvarande arbetet i iterationens sprint backlog. Vanligtvis uppdateras detta diagram efter varje dags slut med en uppdaterad uppskattning av det kvarvarande arbetet. En burn-down chart ger en bra uppfattning av hur snabbt arbetet fortskrider och gör det möjligt att uppskatta när arbetet med iterationen är klart [Schwaber 07]. I figur 2 visas ett exempel på en typisk burn-down chart som visar arbetets framsteg under en iteration. Figur 2. Exempel på en Burn-down chart för en iteration som pågår under 31 dagar och innefattar 26 tasks. Varje iteration avslutas med ett sprint review meeting där teamet redovisar vad som utvecklats under iterationen. Detta är ett informellt möte och fungerar mest som en sorts sammanfattning av iterationen för både utvecklare och stakeholders. Mellan detta möte och nästa iteration håller Scrum Master ett sprint retrospective meeting med teamet där man analyserar vad som gick bra och dåligt under iterationen, samt vilka överraskningar man stötte på [Schwaber 07]. 3 Metod Många praktiker inom Scrum och XP överlappar varandra. Vi har i dessa fall valt att behålla terminologin inom XP för att undvika onödig förvirring. De praktiker från Scrum vi valt att införa i projektet är de som saknas i XP och som vi tror kan tillämpas i ett litet projekt. Vi har tagit hänsyn till att många av praktikerna inom Scrum är inriktade på projektledning för större projekt med flera parallellt arbetande team. Projektet påverkas även av att kursen har ett fast schema med begränsad tid för de olika momenten samt kursmål som skall uppfyllas. Under planeringsmötena, som representerar planning game eller sprint planning meeting, kommer vi att skapa en sprint backlog för iterationen. Vi kommer att avsätta tid för impact analysis av stories. Detta eftersom tankesättet uppmanas i XP utan att finnas uttryckligen som en praktik. 8

9 Under långlaborationerna tar vi coacher rollen som scrum master. I början av dagen anordnas en daily scrum med avsikt att samordna teamets arbete och mål. För att ge utvecklarna en överblick över hur arbetet fortgår kommer ett scrum board och en burndown chart användas. Vi kommer även att poängtera vikten av att föra god dokumentation för framtida vidareutveckling av systemet. En sprint retrospective kommer att hållas i slutet av varje laboration för att sammanfatta och utvärdera dagens arbete och resultat. Något som redan finns i kursens upplägg, men inte uttryckligen i XP, är stand-up meetings. Detta kommer vi att använda för att uppmana teamet att diskutera stora problem och designändringar. Vi kommer att utföra en anonym enkätundersökning under kursens slutskede, se Appendix B: Enkät. Syftet med denna är att vi ska försöka bilda oss en uppfattning om hur de införda Scrum-praktikerna har påverkat teamet. 4 Hypotes Det är vår uppfattning att Scrum och XP kan kombineras för att höja produktiviteten och kvaliteten i ett projekt, jämfört med om metoderna används var för sig. Vi tror även att Scrum-praktikerna kommer att höja medvetenheten i projektet för alla involverade parterna - kunden, ledningen och utvecklarna. Vår förhoppning är att genom att införa impact analysis vid tidsestimeringen under planeringsmötet kunna spara tid som går åt att föra designdiskussioner under laborationstillfället. Genom att göra en bra tidsestimering vill vi kunna garantera kunden att viss funktionalitet skall finnas tillgänglig vid varje iterations slut. Vår sprint backlog ska fungera som ett kollektivt mål med iterationen och hjälpa teamet att fokusera under laborationen. Under laborationerna kommer vi att anta rollen som scrum master och sträva efter att kunna ta ett steg tillbaka och låta utvecklingsprocessen drivas av teamet, enligt [Mar 02]. Vårt mål är att se till att processen följs och att hjälpa till om hinder för processen uppstår. Genom att organisera en daily scrum i början av dagen hoppas vi att medvetenhet sprids i grupp samtidigt som teamets ansvarskänsla för produkten ökar [Schwaber 07]. Detta eftersom alla står till svars inför varandra inom teamet och inte bara inför ledningen [Vriens 03]. Vi hoppas också att medvetenheten sprids i teamet med hjälp av stand-up meetings vid omfattande problem eller designändringar [Vriens 03]. Våra förhoppningar är att utvecklingsprocessen ska drivas främst av teamet och att vår scrum board ska underlätta detta. Vi hoppas också att vi coacher och kunden med hjälp av denna tillsammans med vår burn-down chart ska kunna få en bra översikt över arbetet. Ytterligare överblick över projektet hoppas vi att få genom att hålla en sprint retrospective i slutet av varje långlaboration. Tanken är att denna ska ge teamet och oss coacher en bild 9

10 av hur projektet ser ut, vad som gjorts under dagen och att vi tar med oss lärdomar från iterationen till den kommande. [Kniberg 07]. 5 Resultat Arbetet i projektet har fungerat bra med Scrum-praktikerna som införts. De har inte på något sätt hämmat XP-metoden utan snarare strukturerat arbetssättet på ett bättre sätt. Tidsestimeringen under första veckan satte nivån för vad kunden förväntade sig under resten av projektets gång. En överblick över teamets estimering av hur många poäng som skulle hinnas med och hur många poäng som faktiskt klarades av under iterationen visas i tabell 1. Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5 Iteration 6 Estimering Avklarade Tabell 1. Poängestimering och resultat per iteration Som man ser i tabellen var teamets estimering relativt bra men skiljde sig från resultatet med mellan 15-25%. Det var svårt att mäta resultaten av införandet av våra valda Scrum-praktiker i projektet. Vi utförde därför en De övriga Scrum-praktikerna var svåra att mäta rent konkret. Därför utförde vi en anonym enkätundersökning bland utvecklarna i teamet för att jämföra deras syn på vissa områden i projektet med våra förväntade resultat. Som komplement till svaren höll vi även en kort diskussion kring resultaten. Enkäten presenteras i Appendix B och resultaten av enkätundersökningen visas i tabell 2. Påstående Jag har haft en bra överblick över hur stories påverkar varandra innan jag kom till laborationen Mina spikes har gynnat teamet och inte bara varit hemläxa Det har varit teamets ansvar att driva utvecklingen framåt Jag har haft en god översikt över hur arbetet fortskridit under laborationen Jag har varit medveten om vad de övriga paren arbetat med under laborationerna Medelvärde

11 Stand-up meetings har hjälpt mig att följa designändringar I slutet av laborationen har jag haft bra koll på vad som gjorts under dagen Slutsats Tabell 2. Enkätsvar Vi fann att som väntat så kompletterar Scrum utveckling i XP-projekt bra. Scrum hjälper till med att ge feedback till kunden, se till att iterationen är välplanerad men ändå agil och visa arbetets fortgång. [Rising 00] Scrum fungerar ännu bättre i större projekt med flera utvecklingsteam, men vi tycker att det hjälpt att strukturera processen även i ett XP-projekt av denna storlek. Tidsestimeringen har fungerat bra även om det under vissa iterationer skiljde upp till 25 % jämfört med resultatet. Detta beror på att iterationerna är så pass små att även om det bara fattas en task vid slutet av dagen ger det stora utslag på jämförelsen. Teamet visade en god förståelse för hur stories påverkade designen och den främsta svårigheten de fann var att göra en detaljerad estimering på tasks. Vi tror att det är svårt att göra estimeringen bättre under en så pass kort iterationsperiod. Projektets burn-down chart var främst till för att ge projektledarna och kunden en överblick över hur arbetet framskred på en högre nivå än scrum boarden. Även här påverkade varje task kurvan mycket, vilket medförde att kurvan ibland var orörlig under långa perioder för att sedan rasa tvärt. Detta gjorde det svårt att följa utvecklingen och förutspå utkomsten av iterationen, ett exempel på detta finns i figur 3. Figur 3. Burn-down chart från iteration 2. Resultatet av enkätundersökningen i utvecklingsteamet visade att teamet upplevde att de införda Scrum-praktikerna förbättrade arbetsprocessen. Mest nöjda var teamet med daily scrum som de upplevde gav en bra överblick över vad som skulle göras under dagen, vilka hinder som fanns och vilken information som fanns att tillgå. Även om estimeringen av stories var ganska bra stötte teamet ofta på överraskningar under implementeringen av dem. Detta tyder på att den impact analysis som utfördes under planeringsmötena inte var tillräckligt omfattande. Den version av Scrum Board som vi använde oss av gav inte utvecklarna en tillräckligt bra överblick över vilka par som arbetade med vad. Teamet ansåg 11

12 att detta hade kunnat göras tydligare om tasks markerats med något som representerade paret som arbetade med dem, exempelvis foton. Det positiva med vår Scrum Board var att man kunde se om stories var påbörjade eller klara, samt att den tydligt strukturerade upp arbetsprocessen. Teamet upplevde att stand-up meetings hjälpte dem att ta beslut rörande systemets design men det var först under sprint retrospective som de fick en överblick över hur designen ändrats under dagen. XP och Scrum är lika på många sätt och stödjer båda agil programvaruutveckling. Metoderna kompletterar varandra så pass bra att vissa Scrum-praktiker blivit en naturlig del av kursprojektet. Även i team som inte uttalat använder sig av Scrum har morgonmötet och avslutande reflektioner använts för att sprida medvetenheten i teamet. Även sprint backlog och scrum boards har blivit naturliga hjälpmedel för arbetsprocessen. Många organisationer i mjukvaruindustrin har funnit att deras planering, estimering och överblick har förbättrats av att införa Scrum-praktiker i XP [Jensen 03] [Kniberg 07] [Rising 00]. Tillsammans bildar metoderna en pålitlig och högkvalitativ arbetsprocess för modern programvaruutveckling, som kräver hög flexibilitet, kvalitet och insyn i projektet. 12

13 7 Referenslista [Beck 99] Beck K. (1999). Embracing change with extreme programming. IEEE computer, 1999, vol. 32, p , Citeseer. [EDA260 10] Kursbeskrivning EDA260 - Programvauutveckling i grupp. Hämtad 21 Februari 2010 från [Jensen 03] Jensen, Zilmer (2003). Cross-continent Development Using Scrum and XP. In: Proceedings of Extreme Programming and Agile Processes in Software Engineering, 4th International Conferance, Genova, Italy, May 25-29, 2003 (p. 1014). Springer Berlin / Heidelberg. [Kniberg 07] Kniberg H (2007). Scrum and XP from the Trenches: Enterprise Software Development. Lulu.com [Mar 02] Mar K. & Schwaber K. (2002). Scrum with XP. Salisbury University, Informit.com [Qumer 06] Qumer A. & Henderson-Sellers B. (2006). Comparative evaluation of XP and Scrum using the 4D Analytical Tool (4-DAT). In: Proceedings of European and Mediterranean Conference on Information Systems (EMCIS), Costa Blanca, Alicante, Spain, July [Rising 00] Rising L. & Janoff N.S. (2000). The Scrum software development process for small teams. IEEE software, 2000, vol. 17, p [Schwaber 07] Schwaber K. (2007). What is Scrum? dev.volaroint.com [Vriens 03] Vriens C. (2003). Certifying for CMM Level 2 and ISO9001 with XP@Scrum. In: Proceedings of Agile Development Conference, Salt Lake City, USA, June

14 A1 Terminologi Burn-down chart är ett diagram som visar korrelationen mellan mängden arbete som kvarstår och framstegen av teamets arbete med tiden. Collective Codings Standard innebär att utvecklingsteamet följer samma kodkonvention. Common Vocabulary innebär att man använder sig av en gemensam terminologi och vokabulär inom projektet. Daily Scrum är ett möte på 15 minuter där utvecklarna redovisar vad som gjorts sedan planeringsmötet och vad de planerar att göra under laborationen. Impact Analysis är en analys av hur implementation av ny funktionalitet kan påverka befintlig funktionalitet i ett program. Product Backlog är kundens prioriterade lista över stories. Scrum board är en fysisk överblick över vilken funktionalitet som ingår i iterationen och i vilken utvecklingsfas varje task befinner sig. Scrum Master är en person som antar rollen som projektledare och ser till att arbetsprocessen följs och att eventuella hinder elimineras. Simple Design innebär att man väljer det enklaste sättet man kan komma på för att implementera funktionalitet i ett program. Spike är en hemuppgift med avsikten att utforska en möjlig lösning på ett problem. Sprint är en utvecklingsiteration, vanligtvis av storleken 1 månad. Sprint Backlog är en lista över funktionalitet som förväntas implementeras under den nuvarande sprinten. Stakeholder är någon som investerat något i projektet. Story är ett krav på funktionalitet som programmet ska innehålla. Task är en del av en story som brutits ner i mindre delar. Test-Driven Development är en metod för utveckling av kod som innebär att enhetstester skrivs innan själva koden som ska testas skrivs. 14

15 A2 Enkät 15