Scrum + XP = sant

Kristian BjörkD06, Lunds Tekniska Högskola

dt05kb1@student.lth.se

Frederik Blauenfeldt JeppssonD06, Lunds Tekniska Högskola

dt06fb8@student.lth.se

2010-03-02

1

AbstractScrum och XP är två agila metoder för programvaruutveckling. Båda metoder beskriverpraktiker för agil mjukvaruutveckling men ur olika perspektiv. Scrum fokuserar på attfö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 litetXP-projekt för att förbättra utvecklingsprocessen. Många av Scrums praktiker lämpar sigspeciellt bra i storskaliga organisationer, men vår studie visar att Scrum och XP är envinnande kombination även i små projekt.

2

Innehåll

1 Inledning ..................................................................................................... 42 Bakgrund ..................................................................................................... 4

2.1 Kursprojektet .......................................................................................... 42.2 XP ......................................................................................................... 52.3 Scrum .................................................................................................... 6

3 Metod .......................................................................................................... 84 Hypotes ....................................................................................................... 95 Resultat ....................................................................................................... 106 Slutsats ....................................................................................................... 117 Referenslista ............................................................................................... 13A1 Terminologi ................................................................................................. 14A2 Enkät .......................................................................................................... 15

3

1 Inledning

I moderna mjukvaruutvecklingsprojekt har agila utvecklingsmodeller blivit allt mer populärade senaste åren. Två av de mest populära är eXtreme Programming (XP) och Scrum. Bådamodeller beskriver process och praktiker för agil mjukvaruutveckling men ur två olikaperspektiv; XP ur utvecklarnas perspektiv och Scrum från projektledningsperspektivet. Imånga projekt används trots detta uteslutande en av modellerna utan att ge praktikernafrå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 isymbios.

Syftet med denna studie är därför att undersöka vilka praktiker från Scrum-modellen sompassar i ett litet XP-projekt. Vissa ändringar till de olika praktiker vi har valt att studera hardock gjorts för att passa projektet.

Kapitel 2 beskriver kursprojektet för studien, samt metoderna XP och Scrum. I kapitel 3redogörs för hur studien ska gå till väga. Hypotesen för studien beskrivs i kapitel 4 ochresultaten 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 iAppendix A.

2 Bakgrund

XP används ofta i moderna mjukvaruprojekt men med större och globala organisationeruppkommer nya svårigheter, svårigheter som Scrum försöker lösa. Vårt mål är att studerahur väl denna kombination fungerar för utvecklingsteam av storleken 8-10 personer. Dethar skrivits många artiklar och texter om hur Scrum och XP fungerar och hur användbarametoderna är. Flera studier har jämfört XP och Scrum och vägt deras för- och nackdelarmot varandra men också undersökt huruvida de kan lära av varandra eller kanske till ochmed kombineras. De flesta fall där detta undersökts har dock förekommit inom stora projektsom 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 iett team för att ta fram en programvaruprodukt. Fokus ligger på metoden eXtremeProgramming, en högiterativ, så kallad agil, utvecklingsprocess som syftar till hållbarutveckling av mjukvara. Kursen tar upp principer för samarbete med beställaren, planering,hållbar design/implementation, testning och leverans. [EDA260 10]

4

Kursen består av två delar: teoridelen, där den grundläggande teorin presenteras ochtestas, och projektdelen där teorin tillämpas i ett projekt bestående av 8-10 personer i ettutvecklingsteam. Arbetet i projektet är uppdelat på tretton tillfällen där det första är ettprojektstartmöte där projektet och medlemmarna i teamet presenteras. De övriga tolvtillfällena är uppdelade över sex veckor och utgörs av ett planeringsmöte á två timmar ochen laboration á åtta timmar varje vecka.

Under planeringsmötet planeras veckans arbete genom att göra en tidsestimering av olikastories, 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 idenna roll ställer krav på funktionalitet och användning. Efter kundens prioritering görs enuppskattning av hur mycket funktionalitet som kommer att kunna implementeras undernästa laboration och varje utvecklare får en spike att utföra tills nästa mötestillfälle. Enspike ä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 parinom teamet med en egen dator. Alla datorer är placerade så att muntlig kommunikationmellan paren kan ske utan ansträngning. Vid enskilda laborationstillfällen skall kundenförses med en fungerande version av systemet, detta görs genom teamet skickar densenaste versionen av systemet till kunden innan en bestämd tid. För att möjliggöra förutvecklarna att rätta till mindre fel brukar denna deadline sättas i ett par timmar innanlaborationens slut, detta gör att teamet vid dessa laborationstillfällen har mindre tid attimplementera funktionalitet.

2.2 XP

Begreppet eXtreme Programming introducerades först av Kent Beck [Beck 99]. Beckpresenterar en metod för att stödja mjukvaruutveckling i moderna agila projekt. Med ettagilt projekt menas ett projekt där krav och prioriteringar kan ändras under utvecklingensgång. Beck bryter ner utvecklingen i tre olika delar: Design, Planering och Utveckling. Inomvarje område rekommenderar sedan Beck ett antal metoder eller praktiker som ska följasfö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ågramönster som fokuserar på enkelhet och konsekvent utveckling. Bland dessa ingår SimpleDesign, som säger att utvecklare endast skall designa koden för att stödja den aktuellafunktionaliteten och inte planera för framtiden. Det anses även viktigt att se till attrefaktorisera metoder kontinuerligt och att undvika s.k. gudklasser som har allt för mycketfunktionalitet inbakad. Detta ger systemet en agil design som lätt kan ändras och byggaspå. 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 ochinte drar sig för att ändra i den.

5

Vidare förespråkar Beck att ha en representant för kunden i teamet. Representanten skallfinnas tillgänglig på heltid för att hjälpa utvecklarna att producera det kunden faktiskt vill hagenom att hjälpa till med prioritering, releasegranskning och att svara på frågor. Genom attha en kund i teamet och jobba i små iterationer får både stakeholders och utvecklarestä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 attfokusera och för att få en kontinuerlig kodgranskning som höjer kodkvaliteten. Av dennaanledning skall även Test-Driven Development användas, vilket innebär att tester skaskrivas för funktionalitet innan den implementeras. Alla utvecklare skall även befinna sig isamma rum under utvecklingen för att höja kommunikationen. Beck anser att godamöjligheter för muntlig kommunikation höjer kvaliteten på kommunikationen och sparartid. 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äkrautvecklare och övriga stakeholders om att produkten som utvecklas är överskådlig, flexibelför kravändringar och framförallt rätt [Schwaber 07]. Själva termen Scrum kommer ifrånsporten 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 specifikupphovsman ansvarig för att ha grundat metoden, tvärtom finns det många som bidragitmed 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örasoch väljer ut funktionalitet som man beräknar hinna implementera under development-fasen. Under denna fas finns inga specifika regler för utveckling utan man gör vad somkrävs för att följa planeringen. Under post-game efter varje utvecklingsiteration görstakeholders en inspektion av systemet och gör ändringar inför nästa iteration [Schwaber07].

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 äransvarig för att representera alla stakeholders intressen, genom att förse teamet medproduktkrav, 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älpateamet fokusera. Utvecklingsteamet skapar sedan utifrån product backlog en sprint backlog,som är en lista över funktionalitet som förväntas implementeras under sprinten, ochansvarar för att kraven implementeras. De är kollektivt ansvariga för hela mjukvaran ochiterationens 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

som alla skall resultera i ett körbart system. Det som skiljer de olika iterationernas mål åt ärvilken funktionalitet systemet skall innehålla vid slutet. Varje iteration börjar med ettplaneringsmöte där Product Owner och utvecklingsteamet träffas. I den första delen avmötet presenterar Product Owner den högst prioriterade funktionaliteten, tillsammans medteamet skrivs sedan ett kontrakt på vilken funktionalitet som skall finnas med i systemet islutet av iterationen. I den andra delen av mötet, där endast teamet närvarar, planerassedan iterationen i detalj genom att dela upp funktionaliteten i tasks och utföra impactanalysis. En task är en del av en story och impact analysis innebär att man analyserar hurfunktionalitet som ska läggas till kan påverka befintlig funktionalitet i programmet. Efterplaneringsmötet startar utvecklingen, där varje dag inleds med ett möte, daily scrum, därvarje medlem svarar på tre frågor: "vad har du gjort sen förra mötet?", "vad planerar du attgö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 överiterationens arbete. Ett scrum board är en fysisk överblick över vilken funktionalitet somingår i iterationen och i vilken utvecklingsfas varje task befinner sig. För varje fas definierasvad som krävs för att den ska anses klar. När en task uppfyllt dessa krav flyttas den åthö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

att poängtera processen, detta gör det enklare för noviser att försäkra sig om att alla stegfö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 iiterationens sprint backlog. Vanligtvis uppdateras detta diagram efter varje dags slut meden uppdaterad uppskattning av det kvarvarande arbetet. En burn-down chart ger en brauppfattning av hur snabbt arbetet fortskrider och gör det möjligt att uppskatta när arbetetmed iterationen är klart [Schwaber 07]. I figur 2 visas ett exempel på en typisk burn-downchart 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 somutvecklats under iterationen. Detta är ett informellt möte och fungerar mest som en sortssammanfattning av iterationen för både utvecklare och stakeholders. Mellan detta möte ochnästa iteration håller Scrum Master ett sprint retrospective meeting med teamet där mananalyserar vad som gick bra och dåligt under iterationen, samt vilka överraskningar manstötte på [Schwaber 07].

3 Metod

Många praktiker inom Scrum och XP överlappar varandra. Vi har i dessa fall valt att behållaterminologin inom XP för att undvika onödig förvirring. De praktiker från Scrum vi valt attinföra i projektet är de som saknas i XP och som vi tror kan tillämpas i ett litet projekt. Vihar tagit hänsyn till att många av praktikerna inom Scrum är inriktade på projektledning förstörre projekt med flera parallellt arbetande team. Projektet påverkas även av att kursenhar ett fast schema med begränsad tid för de olika momenten samt kursmål som skalluppfyllas.

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 impactanalysis av stories. Detta eftersom tankesättet uppmanas i XP utan att finnas uttryckligensom en praktik.

8

Under långlaborationerna tar vi coacher rollen som scrum master. I början av dagenanordnas en daily scrum med avsikt att samordna teamets arbete och mål. För att geutvecklarna en överblick över hur arbetet fortgår kommer ett scrum board och en burn-down chart användas. Vi kommer även att poängtera vikten av att föra god dokumentationför framtida vidareutveckling av systemet. En sprint retrospective kommer att hållas i slutetav varje laboration för att sammanfatta och utvärdera dagens arbete och resultat. Någotsom redan finns i kursens upplägg, men inte uttryckligen i XP, är stand-up meetings. Dettakommer vi att använda för att uppmana teamet att diskutera stora problem ochdesignändringar.

Vi kommer att utföra en anonym enkätundersökning under kursens slutskede, se AppendixB: Enkät. Syftet med denna är att vi ska försöka bilda oss en uppfattning om hur de infördaScrum-praktikerna har påverkat teamet.

4 Hypotes

Det är vår uppfattning att Scrum och XP kan kombineras för att höja produktiviteten ochkvaliteten i ett projekt, jämfört med om metoderna används var för sig. Vi tror även attScrum-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 underplaneringsmötet kunna spara tid som går åt att föra designdiskussioner underlaborationstillfället. Genom att göra en bra tidsestimering vill vi kunna garantera kunden attviss funktionalitet skall finnas tillgänglig vid varje iterations slut. Vår sprint backlog skafungera som ett kollektivt mål med iterationen och hjälpa teamet att fokusera underlaborationen.

Under laborationerna kommer vi att anta rollen som scrum master och sträva efter attkunna 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 igrupp samtidigt som teamets ansvarskänsla för produkten ökar [Schwaber 07]. Dettaeftersom alla står till svars inför varandra inom teamet och inte bara inför ledningen [Vriens03]. Vi hoppas också att medvetenheten sprids i teamet med hjälp av stand-upmeetings vid omfattande problem eller designändringar [Vriens 03].

Våra förhoppningar är att utvecklingsprocessen ska drivas främst av teamet och att vårscrum board ska underlätta detta. Vi hoppas också att vi coacher och kunden med hjälp avdenna 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 islutet av varje långlaboration. Tanken är att denna ska ge teamet och oss coacher en bild

9

av hur projektet ser ut, vad som gjorts under dagen och att vi tar med oss lärdomar fråniterationen 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 underresten av projektets gång. En överblick över teamets estimering av hur många poäng somskulle hinnas med och hur många poäng som faktiskt klarades av under iterationen visas itabell 1.

Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5 Iteration 6

Estimering 20 27 13 23 22 20

Avklarade 23 33 10 26 22 20

Tabell 1. Poängestimering och resultat per iteration

Som man ser i tabellen var teamets estimering relativt bra men skiljde sig från resultatetmed 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 anonymenkätundersökning bland utvecklarna i teamet för att jämföra deras syn på vissa områden iprojektet med våra förväntade resultat. Som komplement till svaren höll vi även en kortdiskussion kring resultaten. Enkäten presenteras i Appendix B och resultaten avenkätundersökningen visas i tabell 2.

Påstående Medelvärde

Jag har haft en bra överblick över hur storiespåverkar varandra innan jag kom tilllaborationen

3.625

Mina spikes har gynnat teamet och inte baravarit hemläxa

4.125

Det har varit teamets ansvar att drivautvecklingen framåt

4.5

Jag har haft en god översikt över hur arbetetfortskridit under laborationen

3.375

Jag har varit medveten om vad de övrigaparen arbetat med under laborationerna

3.25

10

Stand-up meetings har hjälpt mig att följadesignändringar

3.875

I slutet av laborationen har jag haft bra kollpå vad som gjorts under dagen

4.125

Tabell 2. Enkätsvar

6 Slutsats

Vi fann att som väntat så kompletterar Scrum utveckling i XP-projekt bra. Scrum hjälper tillmed att ge feedback till kunden, se till att iterationen är välplanerad men ändå agil och visaarbetets fortgång. [Rising 00] Scrum fungerar ännu bättre i större projekt med flerautvecklingsteam, men vi tycker att det hjälpt att strukturera processen även i ett XP-projektav denna storlek. Tidsestimeringen har fungerat bra även om det under vissa iterationerskiljde 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ämstasvårigheten de fann var att göra en detaljerad estimering på tasks. Vi tror att det är svårtatt 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 varjetask kurvan mycket, vilket medförde att kurvan ibland var orörlig under långa perioder föratt sedan rasa tvärt. Detta gjorde det svårt att följa utvecklingen och förutspå utkomsten aviterationen, 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 deinförda Scrum-praktikerna förbättrade arbetsprocessen. Mest nöjda var teamet med dailyscrum som de upplevde gav en bra överblick över vad som skulle göras under dagen, vilkahinder som fanns och vilken information som fanns att tillgå. Även om estimeringen avstories var ganska bra stötte teamet ofta på överraskningar under implementeringen avdem. Detta tyder på att den impact analysis som utfördes under planeringsmötena inte vartillräckligt omfattande. Den version av Scrum Board som vi använde oss av gav inteutvecklarna en tillräckligt bra överblick över vilka par som arbetade med vad. Teamet ansåg

11

att detta hade kunnat göras tydligare om tasks markerats med något som representeradeparet som arbetade med dem, exempelvis foton. Det positiva med vår Scrum Board var attman kunde se om stories var påbörjade eller klara, samt att den tydligt strukturerade upparbetsprocessen. Teamet upplevde att stand-up meetings hjälpte dem att ta beslut rörandesystemets design men det var först under sprint retrospective som de fick en överblick överhur 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 delav kursprojektet. Även i team som inte uttalat använder sig av Scrum har morgonmötet ochavslutande reflektioner använts för att sprida medvetenheten i teamet. Även sprint backlogoch scrum boards har blivit naturliga hjälpmedel för arbetsprocessen. Många organisationeri mjukvaruindustrin har funnit att deras planering, estimering och överblick har förbättratsav att införa Scrum-praktiker i XP [Jensen 03] [Kniberg 07] [Rising 00]. Tillsammans bildarmetoderna en pålitlig och högkvalitativ arbetsprocess för modern programvaruutveckling,som kräver hög flexibilitet, kvalitet och insyn i projektet.

12

7 Referenslista

[Beck 99]Beck K. (1999). Embracing change with extreme programming. IEEE computer, 1999, vol.32, p. 70-77, Citeseer.

[EDA260 10]Kursbeskrivning EDA260 - Programvauutveckling i grupp. Hämtad 21 Februari 2010 frånhttp://www.ka.lth.se/kursplaner/arets/EDA260.html

[Jensen 03]Jensen, Zilmer (2003). Cross-continent Development Using Scrum and XP. In: Proceedingsof Extreme Programming and Agile Processes in Software Engineering, 4th InternationalConferance, 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 usingthe 4D Analytical Tool (4-DAT). In: Proceedings of European and Mediterranean Conferenceon Information Systems (EMCIS), Costa Blanca, Alicante, Spain, July 6-7 2006.

[Rising 00]Rising L. & Janoff N.S. (2000). The Scrum software development process for small teams.IEEE software, 2000, vol. 17, p. 26-32.

[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: Proceedingsof Agile Development Conference, Salt Lake City, USA, June 25-28 2003.

13

A1 Terminologi

Burn-down chart är ett diagram som visar korrelationen mellan mängden arbete somkvarstå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 ochvokabulär inom projektet.

Daily Scrum är ett möte på 15 minuter där utvecklarna redovisar vad som gjorts sedanplaneringsmötet och vad de planerar att göra under laborationen.

Impact Analysis är en analys av hur implementation av ny funktionalitet kan påverkabefintlig 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 ivilken utvecklingsfas varje task befinner sig.

Scrum Master är en person som antar rollen som projektledare och ser till attarbetsprocessen 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 attimplementera 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 dennuvarande 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 enhetstesterskrivs innan själva koden som ska testas skrivs.

14

A2 Enkät

15