En jämförande studie av begreppet Agil utveckling i teori och … · 2020. 2. 20. · En jämförande studie av begreppet Agil utveckling i teori och praktisk användning A comperative

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 development in theory and in practical use.

Germans Timofejevs

Examen: Kandidatexamen 180hp Handledare: Steve Dahlskoog Huvudområde: Data och informationsvetenskap Andrabedömare: Ivan Kruzela Program: Informationsarkitektsprogrammet

Resumé

I detta arbete undersöker vi likheter och skillnader av hur litteraturen respektive utvecklare beskriver begreppet agile.

För att komma fram till ett svar på frågeställningen gör vi en litteraturstudie där vi genom att jämföra dem olika agila utvecklingsprocesserna tar fram kriterier för hur begreppet agile beskrivs. Därefter gör vi intervjuer med representanter för 12 olika företag. Resultatet från dessa intervjuer ger oss ett svar på hur utvecklare beskriver agile.

Abstraction

In this essay we examine differences and simularities in how litterature and developers describe agile.

To find an answer to the questions asked, we study the litterature. Thru a comparison of the different agile-methods for devoloping in litterature, we construct and write down criteries for the agile method. After that we make interviews at 12 different companies. The result of these interviews gives us an answer to how the developers discribes the agile method.

Innehåll

1 Inledning.................................................................................................................................1 1.1 Tidigare studier.................................................................................................................1 1.2 Sammanfattning av tidigare studier.................................................................................4 2 Syfte och frågeställning..........................................................................................................5

3 Agila metoder – Teori.............................................................................................................6 3.1 Historik.............................................................................................................................6 3.2 Process modeller för mjukvaruutvecklingen....................................................................7 3.2.1. Vattenfallsmodellen................................................................................................8 3.2.2 Spiralmodellen.........................................................................................................9 3.2.3 Inkrementell utveckling..........................................................................................10 3.2.4 Användarcentrerad design.....................................................................................10 3.2.5 Rup.........................................................................................................................11 3.2.6 XP...........................................................................................................................12 3.2.7 Scrum.....................................................................................................................13

4 Metod...................................................................................................................................14 4.1 Litteraturstudie...............................................................................................................14 4.1.1 Datainsamling..........................................................................................................14 4.1.2 Urval av relevanta data...........................................................................................14 4.1.3 Analys......................................................................................................................15 4.2 Intervju...........................................................................................................................16 4.2.1 Urval.......................................................................................................................16 4.2.2 Frågor.....................................................................................................................16 4.2.3 Datainsamling.........................................................................................................17 4.2.4 Analys.....................................................................................................................18 5 Resultat.................................................................................................................................20 5.1 Litteraturinsamling.......................................................................................................20 5.1.2 Kriterier som kännetecknar dom olika processer.................................................20 5.1.3 Jämförelse mellan processer................................................................................25 5.1.4 Jämförelse av arbetsflöde....................................................................................26 5.2 Intervjuer......................................................................................................................27 5.2.1 Analys...................................................................................................................29 5.2.2 Små företag.........................................................................................................29 5.2.3 Medelstora företag..............................................................................................30 5.2.4 Stora företag.........................................................................................................31 5.2.5 Intervjupersoners beskrivning av agil utveckling.................................................33 5.2.6 Kriterier som karakteriserar agil utveckling..........................................................35 5.3 Jämförelse mellan litteraturs syn på agile utveckling och intervjupersonens syn.......35

6 Slutsatser..............................................................................................................................347 Diskussion.........................................................................................................................................368 Vidareforskning..............................................................................................................379 Referenser.............................................................................................................................38

1 Inledning

Ett mjukvaruprojekt kan styras på två sätt. Det första sättet att styra mjukvaruutvecklingsprojekt på, är sekventiell projektstyrning. Ett exempel på sekventiell projektstyrningsmetod är Vattenfallsmodell [14]. Det andra sättet är att använda sig av s.k. agila mjukvaruutvecklings-metoder.

Begreppet agile mjukvaruutveckling uppkom år 2001 och beskrivs i agile manifiesta. Det fanns dock metoder som kan kvalificeras som Agile redan på 70-talet. Under agile manifiesta fick dessa metoder namnet Agile. Agile är alltså ett paraplybegrepp för likartade mjukvaruutvecklingsprocesser. Ett av huvudkriterierna för att en utvecklingsprocess ska falla under begreppet agile är att utvecklingen sker iterativt. [1] Det finns en del likheter och skillnader mellan processer som faller under begreppet agile. Det finns gott om litteratur som beskriver agile utveckling där olika författare väljer olika utgångspunkter för sin beskrivning av begreppet. I boken ”Agile konsten att slutföra projekt” görs exempelvis en generell beskrivning[30]. I boken ”The Art of Agile Developement” beskrivs agile genom att utvecklings-metoden XP används som en utgångspunkt[31]. Eftersom det finns olika sätt för litteraturen att beskriva agile är det intressant att se hur agile beskrivs i litteraturen. Litteraturens beskrivning av begreppet bidrar till den teoretiska förståelsen.

Förutom den teoretiska beskrivningen finns den praktiska verkligheten i vilken utvecklare rör sig. För att lära sig vad agile är kan en utvecklare göra på två sätt. Antingen kan utvecklaren läsa sig till begreppets innebörd eller lära sig vad begreppet är genom att jobba i projekt där agila styrningsmetoder används.

Om en utvecklare har lärt sig innebörden av begreppet agile genom att arbeta med projekt som styrs agilt, kan hans förklaring av begreppet agile skilja sig från litteraturens beskrivning.Därför är det intressant att undersöka hur litteraturens beskrivning skiljer sig från utvecklarnas beskrivning av begreppet. Denna uppsats kommer att handla om dessa skillnader.

1

1.1 Tidigare studier

Som beskrivs ovan finns det redan en del skrivet om agile-utveckling. Frågan är om det finns någonting skrivet som berör vår problematik. I detta syfte använder vi oss av databasen ACM.Vi valde att använda ACM eftersom ACM är en av de största databaser som innehåller vetenskapliga artiklar inom datavetenskap (http://www.acm.org/)I vårt arbete är vi dels intresserade av agile-definitionen, dels av hur begreppet agile tillämpas. För att hitta relevanta artiklar sökte vi på artiklar som berör begreppet agile. Vi valde att söka bland artiklar publicerade från 2001 till nu, detta hänger ihop med att begreppet agile myntades år 2001[1].

När vi sökte efter artiklar tittade vi först på rubriken. Om rubriken verkade beröra vår problematik läste vi sammanfattningen för att se om något av följande kriterier behandlas

1.Agila metoder dvs. beskrivning av vad agile är2.Historia av agile-utveckling3.Tillämpning av agile-utveckling.4.Beskrivning av någon agile-metod.

Om studien behandlade någon av kriterierna läste vi studien i dess helhet och bedömde huruvida studien är relevant. För att studien skulle anses vara relevant var den tvungen att behandla definitionen av begreppet agile eller beskriva hur begreppet agile används i praktiken. Utifrån alla studier som vi har gått igenom hittade vi sex studier som var mest relevanta, dessa behandlas nedan.

Första studien: “A literature review of agile practices and their effects in scientific software development”.

Syftet med denna studie var att undersöka hur agila projektstyrningsmetoder används vid utveckling av vetenskaplig programvara och vilka effekter de agila projektstyrnings-metoder har. Huvudtesen som används i studien är att agile utveckling är bättre för arbete med kravinsamling och tester än vad sekventiell utveckling är.[25]

Slutsatser som kunde dras var att agile projektstyrningsmetoder har bättre hantering av testrelaterade aktiviteter. Studien visade en svag indikation på att agila projektstyrningsmetoder har bättre hantering av kravinsamling än vad sekventiell utveckling har. Det som är intressant för vårt arbete är att studien undersöker fördelarna med agile styrningsmetoder. Dock säger studien ingenting om hur utvecklare beskriver agile [25]

Andra studien ”Agility in context”

Syftet med detta arbete var att undersöka hur de olika agila utvecklingsprocesser används i projekt i praktiken.[23]

I studien undersöktes 16 organisationer. Studien visade att organisationer anpassar den valda agila metodiken efter projektets förutsättningar. Exempelvis väljer företaget att använda sig av scrum.

2

Efter hand inser företaget att det är svårt att nå beställaren, vilket gör att företaget måste ta beslut utan att involvera beställaren. Det som är intressant för oss är att studien betraktar hur agile programvaruutveckling används i praktiken.

Studien visar på att det finns skillnader på hur agile beskrivs och på hur agile används vid projekt. I studien framgår det att den agila metoden måste anpassas efter förutsättningar som framkommer under arbetets gång.[23]

Tredje studie: “New Directions on Agile Methods: A comperative analysis”.

Syftet med detta arbete är att analysera de agila metoder med utgångspunkt i fem kriterier. Dessa kriterier är följande: [21]

Software developement live cycle Project managment, Abstract principles vs concret guidance, Universaly predifaind vs. Situation apropariet, Emprirical evidence.

Syftet med denna analys är att jämföra agila utvecklingsprocesser med varandra och välja en metod som passar bäst för ett givet projekt.Det som är intressant för oss är att denna artikel beskriver de olika agila metoder och jämför dessa metoder med varandra.Problemet med artikeln är att artikeln inte definierar begreppet agile, utan endast berör de agila metoderna. Dessutom berörs inte hur begreppet agile används i praktiken[21]

Fjärde studien: ”A view of 20th and 21st Century Software Engineering”.

Denna artikel beskriver mjukvaruutvecklings historia för att förstå hur mjukvaruutveckling har utvecklats. I artikeln görs en prognos på hur mjukvaruutveckling kommer att bske framöver.Det som är intressant för oss är att denna artikel beskriver begreppet agile ur ett historiskt perspektiv. Genom att läsa mjukvaruutvecklingens historia kan vi få indikationer på hur agile-utveckling förhåller sig till andra mjukvaruutvecklingsprocesser. Problemet är att artikeln varken definierar begreppet agile eller undersöker hur begreppet agile används i praktiken. [4]

Femte studien: “Agile software development in the large”

Denna artikel beskriver i stora drag agil utveckling. Artikeln beskriver inte de agila utvecklingsmetoderna i detalj utan syftar till att ge en övergripande förståelse för hur agile utveckling kan bedrivas. I artikeln används begreppet agile som en beskrivning av alla agila metoder. De olika metoderna berörs inte. Dessutom berör artikeln inte hur begreppet agile används i praktiken. [18]

Sjätte studien: Using Scrum to guide the execution of software process improvement in small organisations

Denna artikel beskriver Scrum (som är en agil metod) samt hur denna metod används i små organisationer.

3

Artikeln berör inte hur begreppet agile används i praktiken, men visar hur en agil metod tillämpas i organisationer. [22]

1.2 Sammanfattning av tidigare studier

I nedanstående tabell presenteras teman som beskrivs i artiklarna ovan. (Med agila i tabellen menas att det finns beskrivning av flera agila metoder, historik innebär att agil metodik sätts i ett historisk sammanhang, praktisk tillämpning innebär att artikeln berör användning av agilutveckling i praktiken.)

New Directions on Agile Methods

A view of 20th

and 21st

Century Software Engineering.

Agile software in the large

Using Scrum

Agility in context

A literature review of agile practices and their effects in scientific software development

Agila metoder X X X

Historik X

Övergripande förklaring av begreppet agile

X

X

Praktisk tillämpning

X X X

Från beskrivningarna av artiklarna och i tabellen ovan kan vi se att ingen av de relevanta artiklarna beskriver hur människor som arbetar med mjukvaruutvecklingen beskriver begreppet agile. Tre studier beskriver hur agila metoder används i praktiken men dessa studier går inte in på hur utvecklare definierar agile.Ingen artikel beskriver hur begreppet agile beskrivs i litteraturen utifrån en litteraturgranskning. En studie gör en litteraturundersökning, men den undersöker hur agile utvecklingsprocesser används när vetenskaplig programvara byggs.En artikel beskriver olika agila utvecklingsmetoder. Artikeln gör ingen analys av dessa begrepp med avseende på litteraturens beskrivning av begreppet agile. Två artiklar beskriver övergripande begreppet agile, dock är beskrivningarna som återfinns i artiklarna väldigt kortfattade.

Ur en genomgång av tidigare forskning kan vi dra slutsatsen att det inte finns någon forskning som ger en definition av begreppet agile utifrån litteraturgenomgång och sedan undersöker hur utvecklare beskriver begreppet agile för att slutligen jämföra dessa beskrivningar.

4

2 Syfte och frågeställning

Syftet med detta arbete är att genom litteraturstudie och intervjuer beskriva huruvida litteraturens beskrivning av agile skiljer sig från utvecklarnas beskrivning av samma begrepp.

Vår frågeställning är följande:

Finns det skillnader mellan litteraturens beskrivning av begreppet agile och utvecklarnas beskrivning av begreppet?

5

3 Agila metoder - teori

IID står för iterative and incremental development[7]. Nedan beskrivs IIDs historia. Med vår historiegenomgång vill vi visa att tankesättet som fanns inom industrin har överförts till mjukvaruutveckling. Vi börjar med att gå tillbaka i tiden och beskriva hur projektstyrningsmetoder från industrin influerat projektstyrningsmetoder. Sedan visar vi hur metoder från industrin resulterat i Agila utvecklingsmetoder som används vid mjukvaruutveckling.Efter en historisk genomgång går vi igenom några mjukvaruutvecklingsmetoder.

3.1 Historik

30 och 40 -talet

Tankesätt inom projektstyrning som liknar IID kan spåras tillbaka till 1930-talet. Walter Shewhart som var en kvalitetsexpert på Bell Labbs föreslog att programmerare borde använda sig av sk. PDSA(plan-do-stady-act).[5]PDSA var ett schema för systematisk förbättringsarbete och kunde användas för att förbättra kvalité av arbetsprocessen i all tillverkningsindustri.PDSA består av 4 delar.

Plan: I detta stadie ska problem som uppstår vid tillverkningen identifieras och analyseras. Sedan ska olika lösningar föreslås.

Do: I detta stadie genomförs de föreslagna lösningarna som beskrivs ovan. Check: Här utvärderats det som gjordes på Do. Är resultatet tillfredsställande

påbörjas nästa steg. Är resultatet inte tillfredsställande återvänder man tillbaka til PLAN och jobbar igenom planeringsdelen och Do-delen på nytt. Så pågår arbetet tills resultatet är tillfredsställande och programmeringen kan gå vidare till nästa steg.

ACT: När lösningen är tillfredsställande standardiseras lösningen. Sedan återvänder programmeringsprocessen tillbaka till Plan-stadiet för att påbörja hela processen på nytt och uppnå en ännu bättre lösning.[5]

På 1940-talet började kvalitets-gurun Edward Deming marknadsföra PDSA. På 1950 talet blev PDSA-cirkeln populär. PDSA användes i tillverkningsindustri och hade ingenting med mjukvaruutvecklingen att göra. Långt senare beskrev Tom Gilb och Richard Zultner hur PDSA kunde tillämpas vid mjukvaruutvecklingen.[5]

50-talet

Förutom att PDSA-cirkeln blev populär på 50-talet har ett projekt dragits igång av NASA. Projektet är intressant för oss eftersom IID användes som styrmetod för projektet. Projektet fick benämning X-15 och gick ut på att bygga ett forsknings-flygplan. Projektet blev framgångsrikt bla. för att IID valdes som projektstyrningsmetod. X-15 projektet blev en milstolpe inom IID.[5]

X-15 projektet var ingen mjukvaruprojekt i sig, det ledde dock till att NASA använde sig av IID fö mjukvaruutveckling i sina senare projekt. [7]

6

60-talet

På 1960 talet använde NASA sig av IID i ett projekt som kallades för Mercury. IID användes när mjukvaran för projektet utvecklades. Det intressanta med Mercury var att i projektet användes korta halvdags-iterationer. [5]Både PDSA,X-15 och Mercury visar att det som idag kallas för iterativ utveckling härstammar från 1940-talets syn på hur tillverkning ska bedrivas. Det har alltså funnits metoder som liknar IID och som tillämpades inom mjukvaruutveckling redan på 50-talet. Dock blev inte IID populär förrän långt senare.

70-talet

En populär mjukvaruutvecklingsmetod under 1970 talet var Vattenfallsmodellen. Utvecklingsmetoden är sekventiell. Syftet med metoden var att mjukvaruutvecklingen skulle bli ingenjörsmässig. Mjukvaruutvecklingen jämfördes exempelvis med hur man bygger hus. Ungefär som vid ett husbygge skulle mjukvaruutveckling ske i olika steg. Projektet skulle börja med att samla in krav för att sedan designa systemet utifrån dessa krav. Utifrån designen skulle mjukvara programmeras (kan jämföras med ett husbygge där huset byggs utifrån en ritning) [14]

Efter hand insåg utvecklarna att det fanns andra sätt att tillgå för att bygga mjukvara. Mjukvaruutveckling behövde inte ske i steg utan kunde ske i iterationer där möjligheten att återvända till tidigare iteration fanns.Exempelvis har Winston Royce i sin artikel ”Developement of large software systems” nämnt att det var bättre att bryta upp ett 30 månader långt utvecklingsprojekt i kortare 10 månaders pilotprojekt. [5]

Harlan Mills har i sin artikel “Top-Down Programming in Large Systems,”föreslagit iterativ utveckling. Mills menade att det är möjligt att bryta upp systemutvecklingen i flera etapper. Varje etapp ska utvärderas och sedan ska ev. fel rättas till innan nästa etapp påbörjas[5][7]

90-talet och framåt

På 1990 talets andra hälften har IID utvecklingen satt igång på allvar. Processer som XP, FDD och DSDM skapades. [7]1990-talet kan betraktas som en viktig milstolpe för IID. Det är just detta år som IID blev populär och på allvar började användas[5]I februari år 2001 samlades en grupp av 17 experter på IID för att ha ett möte.

Under mötets gång skapades Agile Alliance. Begreppet agil utveckling myntades under detta möte. Begreppet agil utveckling blev ett samlingsnamn för olika iterativa utvecklingsmetoder [1]3.2 Processmodeller för mjukvaruutvecklingen

Detta avsnitt kommer att diskutera olika mjukvaruutvecklingsmetoder. Vi börjar med att beskriva vattenfallsmodellen därefter spiralmodellen och sist inkrementell och användarcentrerad utveckling. Som vi redan nämnt finns det två huvudsakliga grupper av mjukvaruutvecklingsmetoder. Sekventiell och iterativ. 7

Vattenfallsmodellen är en sekventiell utvecklingsmodell. Spiralmodellen och inkrementell utveckling är hybrider av sekventiella och agila utvecklingsprocesser. Efter att ha beskrivit vattenfallsmodellen (som är en ren motsats till agil utveckling), Spiralmodellen samt inkrementell utveckling kommer vi att gå över till att beskriva RUP, XP och Scrum.

Dessa tre sistnämnda modeller är agila utvecklingsmodeller.Till sist kommer vi att betrakta två produktionsmodeller som kan appliceras på mjukvaruutvecklingen. Dessa modeller är lean och kanban .

3.2.1 Vattenfallsmodellen

Från början ritades arbetsflödet som ett bild på vattenfall därav namnet Vattenfallsmodellen[6]. Principen i vattenfallsmodellen går ut på att arbetsflödet delas in i olika delar. När en del i arbetsflödet avslutas påbörjas en ny del och när delen är avslutad går det inte att komma tillbaka till denna del. Arbetet sker sekventiellt från det att kraven samlas in till det att test och leverans av systemet sker. Varje fas avslutas med leverans av dokumentation som beskriver vad som har gjorts. Exempelvis vid kravhanteringsfasen är det kravdokumentet som levereras. För att fasen ska kunna betraktas som avslutad ska dokumentation verifieras och godkännas.

Arbete enligt vattenfallsmodellen inleds med en kravinsamling. Under kravinsamlingen skrivs ett dokument som innehåller krav på systemet dvs. de egenskaper systemet ska ha och vad systemet ska kunna göra. Nästa steg i processen är design av systemet. Under designfasen skrivs ett dokument som visar hur systemet ska se ut. Om systemutvecklingen jämförs med ett husbygge korresponderar designfasen mot fasen där en ritning av huset skapas. Designen görs utifrån kravdokumentet. När designen av systemet är klar, påbörjar utvecklingen dvs. programmeringen. Fasen där programmering sker kallas för Kodning.När programmeringen är klar testats systemet. Testerna sker i två faser. Det första testet kallas för enhetstest. Under enhetstesten sätts alla delar av mjukvaran ihop och testas, för att se så att dessa delar fungerar ihop med varandra.Nästa testfas kallas för integrationstest. Under integrationstestet testas om det nya systemet fungerar tillsammans med redan befintliga system. När systemet är testat, levereras den till beställaren. Överlämmningsfasen kallas för leverans och acceptans.Efter att systemet har levererats sätts den i drift. Efter att systemet har satts i drift behöver den underhållas, eventuella felaktigheter fixas och uppdateringar behöver göras.

Den sista fasen i vattenfallsmodellen kallas för drift och underhåll. Det är i denna fas som de två sista stegen som beskrivs ovan sker.[14]

I teorin ska nästa fas ej påbörjas innan föregående fas avslutas, dock fungerar det annorlunda i praktiken. Faserna överlappar varandra. Exempelvis upptäcks brister i designen under programmeringsfasen, och då måste man gå tillbaka till designsfasen för att lösa problemet[14]. Arbetet under varje fas kan bestå av ett antal mindre iterationer. När man anser sig vara klar med arbetet fryses arbetet och programmeringen går vidare till nästa fas. En del problem som inte har blivit lösta tas med och löses i andra faser.

8

En del problem löses inte, utan dessa problem tas med till den sista fasen dvs. när systemet sätts i drift och testas.

Fördelen med vattenfallsmodellen är att en noggrann dokumentation levereras vid varje fas. Nackdelen är att modellen är oflexibel. Det är inte tänkt att det ska gå att ställa nya krav på systemet efter att man exempelvis lämnat kravinsamlingsfasen. Beställaren har begränsad möjlighet att komma med nya krav efter att kravfasen genomförts.[14]

3.2.2 Spiralmodellen

Spiralmodellen utvecklades på 1980-talet av Barry Boehm. Spiralmodellen är en kombination av iterativ utveckling och Vattenfallsmodellen. [3]

Spiralmodellen innehåller ungefär samma faser som vattenfallsmodellen. Skillnaden gentemot vattenfallsmodellen är att utvecklingen inom spiralmodellen sker iterativt.[3]

Ett utvecklingsprojekt som använder spiralmodellen kan se ut på följande sätt:Vi börjar med att beskriva hur hela utvecklingsförloppet kan se ut. Detta gör vi genom att vi först beskriver systemuppbyggnaden från första början och som sedan resulterar i alfaversionen. Projektet inleds med kravinsamlingen och kravdokument.När kraven är insamlade valideras och verifieras kraven. Kravdokumentet kompletteras med nya krav om så krävs. Det medför att en ny version av kravdokumentet görs. Det nya kravdokumentet valideras och verifieras och eventuella förändringar sker. När kravdokumentet är helt klart, görs en utvecklingsplan.Utifrån utvecklingsplanen byggs den första prototypen. När den första prototypen är klar valideras och verifieras den. Vid utvärderingen av prototypen uppstår nya krav. Insamlingen av de nya kraven sker på samma sätt som innan. När kravdokumentet är klart görs en ny utvecklingsplan. Utifrån utvecklingsplanen byggs nästa prototyp som bearbetas på samma sätt som den tidigare prototypen. Utifrån den andra prototypens resultat och nyinsamlade krav byggs den slutliga prototypen. När den slutliga prototypen har gått igenom samtliga steg som beskrivits ovan inleds nästa fas.Under nästa fas görs detaljerad design av systemet som ska byggas. Koden skrivs därefter utifrån designen. När koden är skriven testas koden. Det som testas är huruvida det som har byggts kan integreras med övriga delar av systemet. Efter testerna, sker implementering och efter implementering sker release av den version av systemet som har byggts. I vårt fall en alfaversion. Efter att alfaversionen har släppts görs planeringen av systemets nästa version. Arbetet med nästa version består av samma steg som utvecklingen av alfaversionen. Stegen upprepas tills programmet är färdigt för att släppas ut i en slutversionen.En iteration i spiralmodellen brukar ta mellan 6 månader och 2 år.[3]

I spiralmodellen går det att identifiera sekventiella faser. Dessa faser är följande:Kravinsamling, prototypbygge, design, kodning, tester. Samtliga faser finns i vattenfallsmodellen. Den stora skillnaden är att varje delfas pågår iterativt. Dessutom innehåller spiralmodellen flera delversioner som byggs innan systemet är klar.I vattenfallsmodellen görs hela utvecklingsprocessen en gång och sedan betraktas systemet som färdigt.

9

3.2.3 Inkrementell utveckling

Nästa utvecklingsmodell som vi ska beskriva är inkrementell utveckling. Denna utveckling härstammar från vatenfallsmodellen och är en vidareutveckling av vattenfallsmodellen.[13]

Utvecklingen börjar med identifieringen av sk. Inkrement. Ett inkrement är en enhet i projektet. Vid slutet av varje enhet levereras en fungerande funktion. Inkrementen bygger på varandra. Således är den andra enheten en påbyggnad på den första enheten osv.Utvecklingsprocessen i ett inkrement börjar med en analys av det som ska göras. Vid analysfasen samlas kraven in. Utifrån kraven görs designen. Utifrån designen sker kodning. När kodningen är färdig testas funktionen.Efter att ett inkrement är avslutat sker det en leverans av funktionen som byggts. Leveransen i inkrementell utveckling behöver inte innebära att en leverans till beställaren sker, utan en leverans är en milstolpe där det som har gjorts utvärderas av projektteamet. Som redan nämnts involveras inte beställaren i utvärderingen.Efter att ha utvärderad funktionen påbörjar ett nytt inkrement. Det nya inkrementet innehåller samma faser som föregående. När detta inkrementet är klart och utvärderat påbörjas ett nytt inkrement. Händelseförloppet pågår tills systemet betraktas klart. Systemet betraktas vara klart när alla krav är implementerade.[6]

Faserna i varje inkrement liknar vattenfallmodellens faser. Skillnaden mellan vattenfallsmodellen och inkrementell utveckling är att det som ska byggas bryts ner i flera funktioner som bygger på varandra. Varje funktions utvecklingsprocess påminner om vattenfallsmodellen, men i vattenfallsmodellen avslutas hela projektet när samtliga delar har arbetats igenom. I inkrementell modell arbetas varje fas igenom flera gånger om.[6][13]

3.2.4 Användarcentrerad design

Användarcentrerad design är en utvecklingsmodell där användaren engageras i utvecklingsprocessen. Användaren finns med och kan påverka utvecklingen. Syftet med detta arbetssätt är att ge användaren möjlighet att under utvecklingen påverka den slutliga produkten, till skillnad från vattenfallsmodellen där användaren framför sina krav i början av projektet.[10]

Det finns en internationell standard för användarcentrerad design. Standarden heter ISO 13407.Så här kan en arbetscykel inom användarcentrerad metod se ut[32]:

1. Hitta användningens kontenta. I denna fas identifierats vilka som kommer att använda systemet samt i vilka sammanhang systemet används.

2. Utarbeta kravspecifikationen. Här identifieras kraven. Kraven som ställs kommer från användaren, dennes verksamhet och det denna kräver för att fungera.

3. Hitta lösningarna. I denna fas identifierats olika sätt som kan användas för att bygga systemet.

4. Utvärdering. I det här steget utvärderats lösningen. Användaren ger feedback på lösningen.

Arbetsflödet liknar till en viss del vattenfallsmodellen. Arbetsprocessen består av faser som pågår sekventiellt. Dock innehåller hela processen flera steg som består av 4 faser. 10

På slutet av varje steg ger användaren feedback. Sedan görs nästa steg.

Exempel på inkrementell utveckling kan se ut som följande. Det byggs flera versioner med början i version 0.1. Bygget av versionen 0.1 består av fyra steg. När version 0.1 är klar ger användaren feedback på versionen.

Utifrån feedbacken byggs version 0.2. Bygget innehåller samma faser som i föregående steg. Stegen upprepas tills det att slutversioner är klar.Det finns stora skillnader när det gäller involvering av användaren i användarcentrerad design och i vattenfallsmodellen. I vattenfallsmodellen är användaren bara med i början av utvecklingen. I användarcentrerad utveckling görs användartesterna i varje steg. Detta för att få feedback från användaren. Ingångsvärden för nästa steg är feedbacken från användaren.[26] Arbeten med stegen i användarcentrerad design liknar arbetssättet i inkrementell utveckling. I inkrementell utveckling bestäms nästa steg från utvärderingen av föregående steg precis som i användarcentrerad design. Skillnaden mellan dessa två metoder är att i användarcentrerad design kommer feedbacken från användaren. I inkrementell utveckling behöver inte användaren involveras alls. [26]

3.2.5 Rup

RUP är en iterativ utvecklings-process som är skapad av IBM. Enligt IBM är RUP baserad på s.k. Best practeses[15]

När RUP skapades byggdes det ett ramverk som varje organisation skulle anpassa sina behov efter. RUP ska inte följas till punkt och pricka vid utvecklingen, utan anpassas efter det som ska byggas samt efter organisationen som ska bygga systemet. [15]

Utvecklingsprocessen delas in i fyra faser. Vid varje fas skapas dokumentation där det som har gjorts under fasen beskrivs. RUP har följande faser, och dokumentationen från dessa faser liger till grund för nästa fas.

1. Förberedelse: Förberedelsen kan liknas vid en förstudie där det fastställs vad som ska byggas. I slutet av fasen skapas ett dokument som beskriver kraven på det som ska byggas.

2. Etablering: Under denna fas görs följande steg; design av användarfallen, konstruktion av prototyper, arbete med risker och framställande av prototyper. Målet för denna fas är prototypframställning. Till grund för prototypen ligger designen som har byggts utifrån dokumentationen från kravinsamlingen som skapas under förberedelsen och anvädarfall. Användarfall är en beskrivning av vad en användare kan göra i systemet.

3. Konstruktion: Under denna fas byggs sytemet. Systmet byggs utifrån prototyper som levererades vid föregående fas.

4. Överlämnande: Under denna fas överlämnas systemet.

Här följer ett exempel på hur systemutveckling av en webbsida skulle kunna se ut där RUP tillämpas.

11

1. Förberedelsen : Här identifieras det som ska byggas och man kommer fram till att det ska byggas en blogg där användare ska kunna registrera sig, skriva inlägg och hantera inlägg.(Vi väljer att först bygga inlogningsystmet). Kravdokumentet skrivs.

2. Etablering: Här byggs prototypen av inloggningsystemet för bloggen. Denna prototyp baseras på beskrivningen av hur användaren ska kunna logga in. Användarfallen dokumenteras.

3. Konstruktion: Här programmeras inloggningsystemet. Sedan skrivs dokumentation om hur inloggningssystemet fungerar.

4. Överlämning: Här överlämnas inloggningssystemet till beställaren.5. Nu har vi inloggningssystem till vår blogg, bloggen är dock ännu inte klar. Vi behöver

kunna skriva och publicera inlägg. Nästa steg är att bygga publiceringsfunktion. Publiceringsfunktion byggs med samma steg som beskrivs i föregående steg.

RUP innehåller alltså fyra faser. Vid bygget av olika delar i systemet arbetar man igenom samtliga faser för den delen som för tillfället bygg. Sedan byggs nästa funktion. När nästa funktion byggs gås RUPs fyra faser igenom en gång till. Detta sker ända fram till att systemet är klart. 3.2.6 XP

XP eller extreme programing utvecklades på 1990-talet som kontrast till RUP. XP gav konkreta tips på hur programmering ska ske. Förutom det gav XP även verktyg för hur arbetet i team ska skötas.I XP används parprogrammering. Det anses att kodgranskning är positivt och genom att programmera två och två granskas koden av en kollega. I XP används sk. Test Driven Developement som innebär att det första som designas är tester. Utifrån dessa tester sker utvecklingen. Fokus ligger på att funktionerna man utvecklar ska klara testerna.Det används även Collective Code Ownership vilket innebär att alla i utvecklingsteamet förstår koden som har skrivits.[26]

XP baseras på fem principer.

1. Kommunikation: Genom att ha kunden på plats utvecklas programm som överensstämmer med vad kunden verkligen vill ha. Kunden är alltså involverad i utvecklingen.

2. Enkelhet. Dokumentationen minimeras och koden skrivs så att den är lättförståelig och lättläst

3. Feedback. För att skapa en bra produkt krävs det kontinuerlig feedback från kunden. Därför är det viktigt att ha god och kontinuerlig kommunikation med kunden.

4. Mod. Det är viktigt att kunna stå på sig d.v.s, om det känns som att något inte är populärt, men rätt ska det ändå framhävas.

5. Respekt. För att kunna arbeta effektivt och för att gruppdynamiken ska fungera krävs det att varje programmerare har respekt gentemot sina medarbetare och kunder.[28]

12

3.2.7 Scrum

Scrum används sedan 1990-talet. Scrum ska inte betraktas som en utvecklingsmetod utan snarare som en ram för hur utvecklingsprojekt bör gå till [7].Scrum har tre huvudkriterier som ska följas. Dessa kriterier är följande:

1. Transperency: Vad som pågår i utvecklingsprocessen ska vara synligt.2. Inspection: För att kunna upptäcka brister ska arbetet kontinuerligt inspekteras.3. Adaption: Arbetsprocessen ska vara anpassningsbar. Det ska gå att sätta in nya krav

under utvecklingens gång[24]

Roller i scrum

Scurms metodologi delar in alla aktörer som berörs av utvecklingen. Aktörerna delas in i följande grupper.

ScrumMaster: Scrummaster kan jämföras med en projektledare. Det finns dock skillnader mellan projektledare och Scrummaster. Scrummaster är ungefär som en coach och biträde till arbetsteamet. Scrummasters uppgift är att se till att teamet kan arbeta ostört och få alla resurser teamet behöver.

Produktägare: Produktägare är beställaren. Under utvecklingens gång ger produktägaren feedback på det som har levererats. Utifrån leveransen ställs sedan krav på nästa leverans. Produktägaren har möjlighet att påverka kraven via feedback i slutet på varje leverans.

Teamet: Scrum-team är ett utvecklings-team. Det är viktigt att förstå att inom Scrum arbetar alla i ett team dvs. utvecklingsgruppen arbetar i nära kontakt med projektägaren och scrummaster. [24]

Arbetsprocessen

Arbetsprocessen börjar med en insamling av övergripande krav för systemet man bygger. Sedan börjar utvecklingen. Utvecklingen delas in i iterationer. Iterationerna kallas för sprint. Varje sprint är ca en vecka lång. Vid slutet av varje sprint ska en fungerande funktion levereras. Sedan ger projektägaren feedback. Utifrån feedbacken och eventuellt nya krav påbörjas nästa sprint.Varje sprint börjar med nya krav som ska utföras under sprinten, detta resulterar i en produkt. Om teamet inte hinner med någon av kraven, flyttas kravet till nästa sprint. Om projektägaren vill införa nya krav går det bra, men dessa krav kommer att utvecklas i nästa sprint. Det viktiga med varje sprint är att leverera någonting som fungerar.

För att alla i teamet ska ha koll på vad som pågår i utvecklingen, anordnas korta stendup-meatings varje morgon. Syftet med dessa möten är att var och en ska redovisa hur personen ligger till i förhållande till projektet. Förutom möten finns det en tavla där man antecknar vilken funktion som man jobbar på, samt vilken fas av utvecklingen funktionen befinner sig i. [24]

13

4.Metod

För att besvara vår frågeställning använder vi oss av litteraturundersökning och intervjuer. Litteraturundersökningen används för att skapa en uppfattning om vad litteraturen säger om agile. Intervjuer används för att förklara hur utvecklare beskriver begreppet agile.Vi använder kvalitativa metoder vid undersökningen. Med kvalitativa metoder menas att undersökningen resulterar i verbala formuleringar.[16]

4.1 Litteraturstudie

I denna del används litteratur om programvaruutveckling för att undersöka hur agila utvecklingsmetoder beskrivs. För detta syfte används böcker och artiklar som källor. Syftet med litteraturstudien är att undersöka hur litteraturen beskriver begreppet agile. För att genomföra vår litteraturstudie behöver vi samla in material. Utifrån det insamlade materialet måste vi välja ut relevant data. Den relevanta datan måste sedan analyseras för att besvara vår frågeställning.

4.1.1 Datainsamling

Litteratursökningen genomfördes på två olika ställen. Malmö stadsbibliotek och databasen ACM. I Malmö stadsbibliotek söktes böcker som behandlar programvaruutveckling. Vi valde ut litteratur som behandlar följande teman: mjukvaruutveckling, softwareengenering, agil mjukvaruutveckling, inkremintell mjukvaruutveckling, spirallmodellen, vattenfallsmodellen, rup,xp, scrum, lean, camban. För att komplettera bibliotekssökningen använder vi databasen ACM I dessa två databaser söker vi på följande sökord: softwaredevelopement, software engeneering, spiralmodell, agile, scrum, xp, lean, camban, rup, waterfallmodel

4.1.2 Urval av relevanta data

Efter att ha samlat in all litteratur måste relevanta avsnitt väljas. För att välja relevanta avsnitt använder vi oss av kvalitativ innehållsanalys.

Kvalitativ innehållsanalys innebär att man söker efter bakomliggande teman i materialet som analyseras [2] Enligt A Bryman finns det ingen beskrivning om hur dem bakomliggande teman identifieras. Denna identifieringen får uppsatsskribenten själv göra. För oss är de avsnitt som behandlar agile utveckling relevnata. Förutom agile är vi särskild intresserade av vattenfallsmodellen. För att få relevant data av all insamlad material gjorde vi på följande sätt. Efter att ha valt böcker och artiklar som behandlar relevanta teman fördjupade vi oss i den enskilda boken och artikeln. I boken/ artikeln söker vi efter alla avsnitt som behandlar teman som intresserar oss (teman är beskrivna i avsnittet ovan). De relevanta kapitlet för vald artikel/bok antecknas i en tabell. Exempel på en tabell finns nedan:

Kapitel nr Kapitlens titel

4 Software processes

14

När vi har en tabell för varje artikel/bok gör vi en ny tabell där vi listar alla böcker/artiklar samt samtliga kapitels titlar som är relevanta i den givna boken. Grunden för tabellen utgör föregående tabell. Exempel på en tabell återfinns

Bokens titel Relevanta kapitel

Den sista tabellen utgör en lista över litteraturen samt var i texten den data som vi är intresserade av finns. Litteraturen i vår lista är den data som kommer att analyseras i uppsatsen.Alla artiklar/böcker som vi har samlat in kommer inte innehålla relevant information. Exempelvis alla böcker som behandlar Softwareengenering och softwaredevelopement kommer inte att innehålla information om agil utveckling. Dessa böcker/artiklar sorteras bort.

4.1.3 Analys

Vid analysen kommer vi att göra en litteraturgranskning. Litteraturgranskningen innebär att den relevanta litteraturen som berör området granskas. Syftet med litteraturgranskningen är att sammanställa litteraturen som finns om den berörda problematiken[16]. Litteraturgranskningen passar utmärkt för vår problematik eftersom det handlar om litteraturens bild av begreppet agile. Urval av den relevanta litteraturen beskrivs ovan.

För litteraturgranskningen väljer vi semantisk analys som metod.Vid semantisk analys görs en granskning av de valda begreppen genom att jämföra hur begreppet beskrivs av olika böcker/artiklar [9]För att använda oss av semantisk analys börjar vi med att göra en lista på kriterier som vi ska jämföra. Syftet med dessa kriterier är att ge oss en heltäckande bild av processen i fråga, samtidigt som vi kan jämföra processerna med varandra på ett överskådlig sätt. Utifrån denna jämförelse kan vi få en lista med kriterier som kännetecknar agile.Hela analysprocessen går till på följande sätt:

1. Vi läser de relevanta kapitl i de böcker som beskriver någon av de agila utvecklingsprocesserna.

2. För varje process gör vi en lista av kriterier som kännetecknar processen. För att avgöra vad som ska hamna på listan tittar vi efter följande saker:

Vilka steg finns det i processen? Hur involveras beställaren i processen? Finns det en klar projektledare som leder projektet? Hur ser kommunikationen i projektgruppen ut? Är processen iterativ? Är beställaren

involverad?

3. Sedan jämförs kriterierna som vi fick från de olika processerna med varandra. Vi jämför dem olika listorna med varandra och söker efter gemensamma nämnare och analyserar eventuella skillnader. Utifrån denna jämförelse görs en ny lista över samtliga kriterier som beskriver agile

4. Utifrån listan som sammanställer alla kriteriet gör vi en beskrivning av agile ur litteraturens perspektiv.

15

4.2 Intervju

För att angripa vår frågeställning. Hur utvecklarna beskriver agile? Använder vi oss av intervjuer.

4.2.1 Urval

För vår intervju har vi valt 12 IT-företag. Kravet är att företaget ska bedriva mjukvaruutveckling åt sina kunder. Samtliga företag återfinns i Öresundsregionen. Vi delade in företagen i tre kategorier. Dessa kategorier är stora företag, mellanstora företag och små företag. Vi betraktar företagen som har mellan 1och 10 anställda som små företag. Företagen med mellan 12 och 30 anställda betraktas som medelstora företag och företagen som har över 30 anställda betraktas som stora företag. Intervjupersoner som vi valde hade en position som motsvarar projektledare.

4.2.2 Frågor

Följande frågor har använts för intervjuerna.

1. Hur stort är företaget när det gäller omsättning och antal anställda. 2. Hur många deltar i utvecklingen av produkter/tjänster?3. Vad har du för utbildning?4. Hur bedriver ni utveckling/projekt på ert företaget? Beskriv processen steg för steg

från kravinsamlingen till leverans5. Vet du vad agila processer är ?6. Vad är agil utveckling för dig?

Intervjufrågor ska ge svar på vår frågeställning.När vi valde dessa frågor utgick vi från att frågorna skulle ge svar på frågeställningen hur en given intervjuperson beskriver agile. Det räckte dock inte med att enbart ställa frågan: Hur definierar du agile? Vi behövde även kunna validera och förklara givna svar. Det kan ju vara så att utvecklarna inte vet vad agile är och då blir ju svaret irrelevant. Det kan ju även vara så att utvecklarna får förståelse för begreppet agile från olika källor såsom fårm den praktiska tillämpning eller från böcker. Det kan finnas skillnader på hur utvecklare definierar agile utifrån var de hämtar kunskapen om begreppet.

Frågorna 1,2,3 är frågor med korta svar som ger förståelse för företaget, samt bakgrunden på intervjupersonerna.

Det är viktigt att veta respondenters bakgrund för att kunna förklara varför personen svarar som han/hon gör. Om personen har gått en utbildning kan det ju vara så att utbildning har berört de agila metoderna. Detta gör att personen har en förståelse av vad agile är som är hämtat från kursliterraturen. Om personen inte har läst om agile under sin utbildning eller saknar en formell utbildning kan det vara så att personen inte vet vad agile är. Givetvis kan respondenten skaffa sig kunskaper om agile från andra källor än utbildning.

Att veta företagets storlek är viktigt för att kunna förklara företagets arbetssätt. Det kan finnas skillnader mellan hur stora och små företag bedriver projekt. Är företaget väldigt stort och jobbar i stora projekt, använder företaget kanske inte agile när de bedriver sina projekt. 16

Om det sedan visar sig att utvecklare inte vet vad agile är samtidigt som företaget inte arbetar med agile kommer utvecklaren inte veta vad agile är. Är det däremot så att utvecklaren inte vet vad agile är, men företaget arbetar med agile kommer utvecklaren automatisk lära sig vad agile är. Alltså används de första tre frågonar för att få kännedom om företaget och utvecklarna för att kunna förklara svaren på de övriga två frågorna.

Fråga 4 och 6 är de mest centrala frågorna i undersökningen. Dessa frågor är diskussionsfrågor. Syftet med dessa frågor är att få en förståelse för hur intervjupersonen beskriver agile.

Under diskussionen ska anteckningar tas och sedan ska data från anteckningar presenteras i resultatdelen.

4.2.3 Datainsamling

För att besvara frågeställningen som beskrivs ovan kommer vi att använda oss av halvstrukturerad intervju. En halvstrukturerad intervju innebär att frågor skrivs av intervjuaren. Frågornas ordningsföljd efterföljs. Frågorna är formulerade antingen med öppna eller fixerade svar. Syftet med halvstrukturerad intervju är att få igång en diskussion med intervjupersonen [2]Vi valde halvstrukturerad intervju eftersom vi behövde svar på en del frågor med korta svar. Dessa frågor är fråga ett till tre. Frågorna ger oss intervjupersonens bakgrund och företagets bakgrund. Vi behöver denna information för att förstå varför utvecklaren svarar som han/hon gör på de övriga frågorna.Öppna frågor använde vi för att dra igång en diskussion. Syftet med diskussionen är att förstå utvecklarens bild av agile. Eftersom vi har frågor med korta svar samt diskussionsfrågor passar halvstrukturerad intervju oss bäst. En helstrukturerad intervju passar oss inte eftersom helstrukturerad intervju innehåller korta mestadels ja/nej frågor .[34] Svar på ja/nej frågor är inte optimala för att få en förståelse för hur en given intervjuperson beskriver agile. Ostrukturerad intervju passar oss inte heller eftersom denna intervjutyp kräver mycket erfarenhet av intervjuaren och sådan erfarenhet har inte vi.

Sättet för intervjun är antingen telefonintervju eller besöksintervju. Vilken typ av intervju som används beror på respondenten. Om det visar sig att respondenten inte har tid för besöksintervju genomförs telefonintervju. Telefonintervjun innebär att intervjun genomförs via telefon. Telefonintervju ger oss möjlighet att använda öppna svarsalternativ och ha diskussion med intervjupersonen[8]. Besöksintervju innebär att intervjuaren besöker intervjupersonen.[8] Metoden för intervjuförfarandet väljs utifrån intervjupersonens förutsättningar. Nedan beskrivs intervjuförfarandet för besöksintervjuerna och telefonintervjuerna.

Besöksintervju

Besöksintervju sker på följande sätt.Vi ringer upp respondenten och bestämmer en tid när vi kan komma för en intervju.Intervjun genomförs på företaget där respondenten jobbar. Lokalen för intervjun varierar från företag till företag. Antingen sker intervjun i intervjupersonens rum eller i ett bokat konferensrum. Under intervjun diskuteras samtliga frågor och anteckningar görs. Intervjun tar ca 30min.

17

Telefonintervju

Vi ringer upp respondenten första gången. Det är respondenten som väljer om intervjun genomförs direkt eller om vi bokar en tid för telefonintervju. När vi ringer upp respondenten ser vi till att respondenten befinner sig på kontoret. Detta gör vi genom att ringa till intervjupersonens fasta nummer. Under intervjun går vi igenom och diskuterar samtliga frågor. Anteckningar tas. Intervjun tar ca 30 min

4.2.4 Analys

Efter att ha samlat in data måste datan analyseras. Vi använder oss av semantiska analys. Den semantiska analysen beskrivs i avsnittet om metod för litteratursökning. Analysen sker på följande sätt:Vi börjar med att sortera alla intervjuer efter företagets storlek.Det kan finnas skillnader mellan hur stora och små företaget bedriver ett projekt. Sättet att driva projekt i ett givet företag kan påverka intervjupersonens syn på metoden som denne använder i sitt arbete. Det finns en del skillnader på hur en metod beskrivs och hur den används[23] Efter att ha sorterat intervjuanteckningar i storleksordning har vi tre grupper av intervjudata dessa grupper är följande:

1. Stora företa2. Mellanstora företag3. Små företag

Nu kan vi börja med att gå igenom samtliga grupper med avseende på hur företagen bedriver sina mjukvaruutvecklingsprojekt. Vi går igenom hur företagen i samtliga grupper bedriver projekt. Svaret på denna frågan får vi från svaret på fråga 4 i vår intervju. När vi analyserar denna data tittar vi efter vilka steg som finns i mjukvaruutvecklingens förlopp. Sedan jämför vi mjukvaruförloppen i gruppen med varandra. Utifrån resultatet som vi får från jämförelsen sorterar vi utvecklingsförloppen i två grupper agile och sekventiellt utveckling. När samtliga företagsgrupper är sammanställda jämför vi utvecklingsförloppen mellan grupperna. Denna jämförelse visar oss om det finns skillnader på hur projekt bedrivs i olika företag med avseende på storlek.

Nästa steg är att analysera utvecklarnas bakgrund. För att göra detta sorterar vi samtliga intervjuanteckningar efter den akademiska bakgrunden som intervjupersonen har. Olika program kan ha olika innehåll. Vissa utbildningar kan inrikta sig på projektledning andra utbildningar kanske inte berör projektledning och projektstyrning alls. Därför kan det finnas skillnader mellan vad människor från olika discipliner menar med begreppet agile.Vi får fyra grupper. Dessa grupper är följande:

1. Datateknik2. Systemvetenskap3. Datavetenskap4. Personer med annan utbildning än it.

Efter att ha sorterat samtliga intervjuer i grupper analyserar vi fråga fem och sex för att få reda på hur en given person beskriver begreppet agile. När vi analyserar data söker vi efter karakteristiska drag för agile i beskrivningen. 18

Sedan sorterar vi svaren efter personens utbildningsbakgrund. När detta är gjort, jämför vi beskrivningar av agile mellan personer i den givna gruppen. När detta är gjort jämför vi de olika gruppernas beskrivningar.

För att ta reda på hur utvecklarna beskriver begreppet agile går vi igenom samtliga 12 intervjuer. I intervjuerna analyserar vi fråga fem och sex. När vi analyserar data söker vi efter karakteristiska drag i intervjupersonens beskrivning av begreppet agile. När vi har gått igenom samtliga intervjuer, jämför vi kriterier från samtliga utvecklare. Därefter gör vi en lista där vi skriver upp kriterierna som finns med i samtliga beskrivningar. Sedan gör vi en annan lista där vi anger de kriterier som inte nämns i alla beskrivningar.Nu när vi har två listor slår vi ihop dessa listor. Kriterier skrivs i fallande ordning beroende på hur många beskrivningar kriterier nämns i.

Utifrån den nya listan gör vi en beskrivning av hur intervjupersonerna beskriver begreppet agile.

19

5 Resultat

5.1 Litteraturinsamling

Vi börjar med att presentera resultatet för analysen av dem olika agila mjukvaruutvecklingsmodellerna. Sedan presenterar vi kriterierna för agile utveckling. Kriterierna får vi genom att sammanställa de olika kriterier för alla berörda utvecklingsprocesser. Utifrån kriterierna för agile utveckling presenterar vi en beskrivning.

5.1.2 Kriterier som kännetecknar de olika processerna

Spiralmodell

Vi börjar med att beskriva stegen som finns i spiralmodellen. Sedan går vi vidare och ser huruvida processen är iterativ. Efter det tittar vi på hur kommunikationen sker inom projektgruppen och om metoden kännetecknas av en avsaknaden av klar projektledare.

Steg i processen

Utveckling av spiralmodelen ser ut på följande sättProjektet påbörjas med kravinsamlingen och kravdokument. När kraven är insamlade valideras och verifieras kraven. Om det behövs, kompletteras kravdokumentet med nya krav. Det medför att en ny version av kravdokumentet görs. Den nya kravdokumentet valideras och verifieras och ev. förändringar sker. När kravdokumentet är helt klart görs en utvecklingsplan. Utifrån utvecklingsplanen byggs den första prototypen. När den första prototypen är klar valideras och verifieras den. Vid utvärderingen av prototypen uppstår nya krav1

Från beskrivningen ovan kan vi urskilja följande steg.1. Kravinsamling2. Planering3. Prototypbygge4. Validering och verifiering

Är processen iterativ?

Utvecklingen börjar med identifiering av sk. Inkrement. Ett inkrement är en enhet i projektet.Utvecklingsprocessen i ett enskilt inkrement inleds genom en analys av det som ska göras. Vid analysfasen samlas kraven in. Utifrån kraven görs planeringen. Utifrån planeringen sker kodning som resulterar i en prototyp. När prototypen är färdig testats prototypen.Inkrementet avslutas efter att testerna genomförts. Efter att ett inkrementet avslutats börjar nästa inkrement. Nästa inkrement bygger på föregående inkrement.

Processen är iterativ eftersom arbetet sker i flera cyklar som bygger på varandra. En cykels ingångsvärde är utgångsvärde från prototypen som har levererats i föregående cykel.”När den första prototypen är klar valideras och verifieras den. Vid utvärderingen av prototypen uppstår nya krav”1

_____________1se Spiralmodellen 20

Kommunikation i processen

Det finns ingen klar beskrivning på hur kommunikation mellan medlemmarna i projektet sker.

Involvering av beställaren

Beställaren involveras inte i utvecklingsprocessen. Om detta vitnar följande citat:” Leverans i inkrementell utveckling behöver inte ske till beställaren. Leverans är en milstolpe där det som har gjorts utvärderas av projektteamet. Som redan är skrivet ovan involveras inte beställaren i utvärderingen.”1

Projektledare

Metoden kännetecknas inte av en avsaknad av projektledare.

Övrigt

Förutom de kriterier som beskrivs ovan finns det ett annat viktigt kriterie som kännetecknar inkrementell utveckling. Det är prototypbygget. Utvecklingen baseras nämligen på att utveckla en prototyp och sedan vidareutveckla prototypen tills den kan betraktas som en färdig produkt: ”När den första prototypen är klar valideras och verifieras den. Vid utvärderingen av prototypen uppstår nya krav”1

Användarcentrerad design

Nedan presenteras kriterierna för användarcentrerad design.

Steg i processenFöljande citat förklarar arbetsflödet i användarcentrerad design: ” Så här kan en arbetscykel inom användarcentrerad metod se ut:1.Hitta användningens kontenta. I denna fasen identifierats vilka som kommer använda systemet samt i vilka sammanhang.2.Utarbeta kravspecifikationen. Här identifieras kraven. Kraven som ställs av användaren och kraven dennes verksamhet kräver för att fungera ska finnas med.3.Hitta lösningarna. I denna fas identifierats olika sätt som kan användas för att bygga systemet.

4. Utvärdering. I det här steget utvärderats lösningen . Användaren ger feedback på lösningen.”2

Följande steg kan utläsas från informationen ovan:1. Hitta användningens kontenta, 2. Utarbeta en kravspecifikation, 3. Hitta lösningar,4. Utvärdering

_____________1se Spiralmodellen2se Användarcentrerad design 21


Varje steg i processen innehåller förutbestämda faser. Nästa steg är en utbyggnad av föregående steg. Det som ska göras i nästa steg bestäms av den feedback som man får från beställaren.”Arbetsprocessen består av faser som pågår sekventiellt. Dock innehåller hela processen flera steg som består av 4 faser. På slutet av varje steg ger användaren feedback. Sedan görs nästa steg. ”2

Som nämns ovan innehåller processen flera steg som i sin tur innehåller förutbestämda faser.

Varje steg bygger på föregående steg. Processen i sin helhet sker genom cyklar och inte skeventiellt, detta eftersom procesen innehåller flera steg som bygger på föregående steg. Nästa steg är inte känt till att börja med, utan planeras och genomförs utifrån resultatet från föregående steg.Processen är alltså itterativ, där varje iteration eller steg bygger på resultatet från föregående steg.




Beställaren är involverad i utvecklingen genom sin möjlighet att ge feedback. Utifrån beställarens feedback sker nästa steg i utvecklingen. ” På slutet av varje steg ger användaren feedback. Sedan görs nästa steg” 2

Projektledare

Metoden kännetecknas inte av en avsaknaden av projektledare.

RUP

Nedan presenteras kriterier för RUP

Steg i processen

Stegen i RUP beskrivs i följande citat” 1. Förberedelse: Förberedelsen kan liknas vid en förstudie där det fastställs vad som ska byggas. I slutet av fasen skapas dokument som beskriver kraven på det som ska byggas.2.Etablering: Under denna fas görs följande steg; design av användarfallen, konstruktion av prototyper, arbete med risker och framställande av prototyper. Målet för denna fas är prototypframställning.

______________________2se Användarcentrerad design 22

Till grunden för prototypen ligger design som byggs på kravinsamlings dokumentation som förberdelse fas resulterar i och användarfall. Användarfall är en beskrivning om vad en användare kan göra i systemet.3.Konstruktion: Under denna fas byggs sytemet. Systemet byggs utifrån prototypen som levererades vid föregående fas. Här skapas dokumentation som beskriver hur systemet fungerar.4.Överlämnad: Under denna fas överlämnas systemet. ”3

Ur citatet ovan kan vi utläsa följande steg1. Förberedelse, 2. Etablering, 3. Konstruktion, 4. Överlämning


Systemet enligt RUP byggs i flera delar som bygger på varandra. Varje del innehåller de steg som beskrivs ovan: ”Vid bygget av olika delar i systemet arbetar man igenom samtliga faser för just den delen som byggs för tillfället till exempel inloggningssystem. Sedan byggs nästa funktion. När nästa funktion byggs gås RUPs fyra faser igenom en gång till. Detta sker tills systemet är klar”Citatet ovan tyder på att processen är iterativ.




Beställaren behöver inte vara involverad i utvecklingsprocessen.

Projektledare

Metoden kännetecknas inte av en avsaknaden av projektledare

Övrigt

RUP är en modell som ska anpassas efter den organisation som väljer att använda modellen.Prototypbygget är en viktig komponent i RUP. Den färdiga produkten byggs utifrån prototyper som i sin tur bygger på varandra.

XPSteg i processen

1. Kravinsamling2. Tester3. Leverans

_____3se RUP

23


Utvecklingen är iterativ. Arbetet utförs i cyklar. Systemet är klart när testresultaten är tillfredsställande. Det som ska göras i varje fas bestäms av feedback från beställaren. Det vill säga att nästa steg görs utifrån beställarens feedback på det föregående steget.


Utvecklarna utvecklar i par. Kommunikation mellan dessa utvecklare sker direkt. Utvecklarna sitter bokstavligen två och två vid varje dator.I XP används s.k. Collective Code Ownership vilket innebär att alla i utvecklingsteamet har koll och förstår koden som har skrivits. CCO förutsätter att det sker kommunikation mellan medlemmarna i gruppen.


Beställaren är involverad i utvecklingen. Genom att ha beställaren på plats är det lättare att utveckla det beställaren verkligen vill ha. ”Genom att ha kunden på plats utvecklas vad kunden verkligen vill ha. Kunden är alltså involverad i utvecklingen”4

Projektledare

Metoden kännetecknas inte av en avsaknaden av projektledare.

Övrigt

XP är en beskrivning av hur arbete i projektteamet ska skötas.XP ger konkreta tips på hur det ska programmeras.Först designas tester, sedan byggs systemet. Tester används sedan som en validator.

Scrum

Steg i processen

Så ser arbetsflödet ut i scrum” Arbetsprocessen börjar med insamling av övergripande krav för systemet man bygger. Sedan börjar utvecklingen. Utvecklingen delas in i iterationer. Iterationerna kallas för sprint. Varje sprint är ca en vecka lång. Vid slutet av varje sprint ska en fungerande funktion levereras. Sedan ger projektägaren feedback. Utifrån feedbacken och eventuellt nya krav påbörjas nästa sprint.Varje sprint börjar med nya krav som ska utföras under sprinten och resultera i en produkt.”5

Ur arbetsflödet ovan kan vi identifiera tre steg i processen. Stegen presenteras nedan:1. Kravinsamling2. Utveckling 3. Feedback från projektägare4. Nästa sprint

____4se XP 24


Utvecklingen är iterativ. Utvecklingen delas in i iterationer. En iteration kallas för sprint. Varje sprint är ca en vecka lång. Vid slutet av varje sprint ska en fungerande funktion levereras. Sedan ger projektägaren feedback. Utifrån denna feedback och eventuellt nya krav påbörjas nästa sprint.


För att alla i teamet ska ha koll på vad som pågår i utvecklingen, anordnas det korta standup-meatings varje morgon. Syftet med dessa möten är att var och en ska redovisa hur personen ligger till. Förutom möten finns det en tavla där man antecknar vilken funktion som man jobbar på, samt i vilken fas utvecklingen av funktionen befinner sig i.

Involvering av beställaren.

Beställaren är involverad genom at ge feedback i slutet på varje iteration.” Sedan ger projektägaren feedback. Utifrån feedbacken och eventuellt nya krav påbörjas nästa sprint.”

Projektledare

Metoden kännetecknas av en avsaknade av projektledare. Istället finns det en roll i projektet som kallas för Scrummaster. Scrummaster fungerar mer som en coach än som en chef: ”Scrum Master kan jämföras med projektledare. Det finns dock skillnader mellan projektledare och Scrummaster. Scrummaster är ungefär som en coach och biträde tillarbetsteamet. Scrummasters uppgift är att se till att teamet kan arbeta ostört och få alla resurser teamet behöver.” 5

5.1.3 Jämförelse mellan processer

Det finns en del likheter och skillnader mellan de utvecklingsprocesser som beskrivs ovan. Nedan går vi igenom likheterna och skillnaderna mellan dessa processer. Dock jämför vi inte arbetsflödet i utvecklingspproceen i denna genomgång. med att åskådliggöra likheter och skillnader i en tabell

Iterativ process


Kommunikation* Projektledare**

Scrum X X X X

XP X X X

RUP X

Inkrementel utveckling

X

Användarcentrerad design

X X

* Det finns en beskrivning på hur kommunikation i gruppen ska gå till**Avsaknad av en tydlig projektledare______________

5se Scrum 25

I diagrammet framgår det att utvecklingen i samtliga processer sker iterativt.Beställaren involveras bara i tre av fem utvecklingsproceser nämligen i SCRUM, XP och användarcentrerad design. I de övriga två utvecklingsprocesserna är involvering av beställaren inte nödvändigKommunikationen i projektgruppen åskådliggörs bara i två processer. Dessa processer är Scrum och XP.Avsaknaden av projektledare nämns bara i Scrum.

5.1.4 Jämförelse av arbetsflödet.

Vi kan identifiera följande steg i arbetsflödet hos dem olika agila utvecklingsprocesserna:Kravinsamling, Implementering, Leverans. I diagrammet nedan kan vi se hur de olika stegen förhåller sig till de olika utvecklingsprocesserna.

Kravinsamling Design Implementering LeveransScrum X X XXP X X XRUP X X X XInkrementel utveckling

X X X X

Användarcentrerd design

X X X X

Vissa av processerna har en fas som kallas för design/planering. Exempelvis RUP. I andra processer sker designen i samband med utveckling.

De olika faser kan kallas olika i de olika processerna. Det som är viktigt att förstå är att trots de olika benämningar som finns, sker samma aktiviteter under den givna fasen.Exempelvis i RUP samlas kraven in under fasen som kallas för Etablering. I XP kallas fasen för kravinsamling.

Varje iteration avslutas med någon sorts leverans. Leverans kan ske på olika sätt. Antingen sker leveransen till beställaren och då ger beställaren feedback eller ses levernasen som en milstoldpe. Exempelivs i Scrum och användarcentrerad design ger beställaren feedback i slutet av en iteration. Leveransen kan även vara som en milstolpe där någonting ska vara klart. I Inkrementell utveckling avslutas varje inkrement på ett sådan sätt.Oavsett om leveransen sker till beställaren eller inte, fungerar analysen av det som levereras (om leveransen sker till beställaren blir feedback jämställt med analys) som ingångsvärde för krav i nästa iteration. Huruvida leverans sker till beställaren eller inte kan utläsas i tabellen i föregående avsnitt.

26

5.2 Intervjuer

5.2.1 Inledning

Nedan ska data från intervjuundersökningen presenteras.

Företagets storlek

För att skapa oss en uppfattning om storlek på företaget där intervjupersonerna jobbar behöver vi ta reda på hur många som jobbar på företaget. Vi behöver denna information eftersom det kan vara så att projekten bedrivs på olika sätt i små resp. stora företaget. Hur projekten bedrivs i organisationen kan påverka intervjupersonens uppfattning om agil utveckling.

För att kunna analysera data måste vi dela in företagen i storleksordning. Vi väljer att dela in alla företag i tre grupper. Dessa grupper är stora företag, medelstora företag och små företagVi betraktar företag som har mellan 1och 10 anställda som små företag. Företag med mellan 12 och 30 anställda betraktas som medelstora företag.Och de företag som har över 30 anställda som stora företag.

Ur intervju-analysen framgår det att: 3 av intervjupersonerna arbetar i små företag.3 intervjupersoner arbetar i medelstora företag. 6 intervjupersoner arbetar i stora företag

Respondenters akademiska bakgrund

Nästa steg i vår analys går ut på att ta reda på respondenternas akademiska bakgrund. Detta eftersom begrepeet agile kan innebära olika saker för personer med olika bakgrund. Intervjuanalysen gav följande resultat om intervjupersonernas akademiska bakgrund:4 personer har en utbildning i datateknik3 personer har en utbildning i datavetenskap2 personer har en utbildning i systemvetenskap3 personer har en utbildning i andra discipliner än datarelaterad utbildning. (En av dessa personer är i grunden maskiningenjör som sedan började arbeta med IT. Två personer har ekonomiutbildning som sedan gått över till IT.)

Hur bedrivs projekten i företagen

Vi går vidare i vår analys och tittar på hur utvecklings-projekt bedrivs i företagen, med avseende på företagets storlek.

5.2.2 Små företag

Vi börjar med att analysera de små företagen.

27

Företag1

Det första företaget har 4 anställda. Respondenten besvarar frågan om hur utvecklingsprojektet bedrivs i företaget på följande sätt(Nedan följer utdrag från intervjun):”S: Utveckling genomförs i flera cyklar. Varje cykel innehåller tre steg. F: Vilka steg finns i varje cykel?S:-Kravinsamling-Kodning-Avstämning med beställarenDen första cykeln är speciell eftersom i inledningen av första cykeln utför vi även en förstudie.F: Du säger att ni har avstämning med beställaren i slutet av varje cykel. Innebär detta att utgångsvärdet till nästa cykel är feedback som ni får från beställaren?S: Ja, det som vi kommer fram till tillsammans med beställaren vid avstämningen fungerar som ett ingångsvärde för kraven inför nästa cykel”

Ur intervjuutdraget framgår det att utvecklingen sker iterativt. Varje iteration består av 3 steg. Dessa steg är Kravinsamling, kodning och avstämning med beställaren.

Företag2

Det andra företaget har fem anställda. Varje projekt består av flera leveranser innan slutversionen levereras. Innan en leverans genomförs följande steg (Utdrag ur intervju)S: Varje steg innehåller 3 delsteg. Vi börjar med att samla in kraven, sedan implementeras kraven och slutligen levererar vi det som vi har gjortVarje projekt innehåller flera steg som innehåller redan nämnda delsteg.

Företag 3

Det tredje företaget har 7 anställda. Respondenten beskriver att utvecklingsprocessen i företaget går till på följande sätt (Utdrag ur intervju)”F: Hur bedriver ni utveckling/projekt på ert företag? Beskriv steg för steg. Från kravinsamlingen till leverans. S: Hela projektet sker i iterationer. Varje iteration bygger på föregående iteration. Varje iteration består av fyra steg. - Kravinsamling- Programmering- Leverans- Nästa itteration”Ur intervjuutdraget kan vi utläsa att utveckling sker iterativt. Varje iteration består av kravinsamling, programmering och leverans.

5.2.3 Medelstora företag

Nästa steg är att analysera medelstora företag med avseende på hur projekten bedrivs.

28

Företag1

Det första företaget har 15 anställda. På frågan om hur utvecklingen bedrivs i företaget svarar intervjupersonen på följande sätt(Utdrag ur intervju)S: Vi börjar med en förstudie. Förstudien sker bara en gång, och detta i början av projektet. Sedan samlar vi in kraven. Vi börjar alltid en iteration med kravinsamling. Efter det sker utveckling och avslutning av itterationen. Därefter påbörjar vi med en ny iteration. F: Vad gör ni vid iterationsavslutningsfasen?S: Vi utvärderar i teamet det som har byggts. Utifrån denna utvärderingen påbörjar vi kravinsamling för nästa iterationen. Företag2

Det andra företaget har 18 anställda. Projektet i detta företag bedrivs på följande sätt (Utdrag ur intervju):S:Vi får kravspec. från kund. Vi utför arbetet och har om det kräver täta möten med kunden, så att vi har samma bild av kraven och att dessa efterföljs. Efter kundmötet korrigerar vi kraven utifrån det som vi kom överens om på mötet.

Från intervjuutdraget ser vi att utvecklingen sker iterativt. Varje iteration innehåller flera steg

Företag 3

Nästa företag har 15 anställda. Projektet bedrivs på följande sätt (Utdrag ur intervju):S:Vi börjar med en förstudie, sedan samlar vi in kraven, slutligen sker utvecklingav produkten.Avslutning av iterationen. Ny iteration

Från utdraget ser vi att utvecklingen sker iterativ där varje iteration innehåller flera steg.

5.2.4 Stora företag

Företag 1

Det första företaget är ett globalt företag med 1400 anställda i bara Danmark. Projekt bedrivs på följande sätt: (Utdrag ur intervju)S:Requirements presented by business clients (internal)Requirement clarification, between developers and clientsSolution specification + documentationCodingUnit and system testing, final documentationUser acceptance testImplementation (delivery of final product)Follow upF: Are you familiar with the agile software development method?S: Yes, frequent user

Av intervjuutdraget ser vi att utveckling görs i flera steg. Enligt intervjupersonen arbetar företaget agilt.

29

Företag 2

Det andra företaget har 200 anställda. Projektet i företaget bedrivs på följande sätt (Utdrag ur intervju)S: Vi jobbar på följande sätt: Vi börjar med –Kravinsamling, sedan sker Kodning och sedan avstämning samt feedback av beställaren.Processen är cyklisk dvs. utvecklingen består av flera iterationer, alla innehåller de steg som beskrivs ovan.

Av intervjuutdragen ser vi att utveckling sker genom cyklar. Varje cykel innehåller flera olika steg. Företag 3

Det tredje företaget har 300 anställda. Utvecklingsförloppet sker på följande steg(Utdrag ur intervju)S:Projektet bedrivs cykliskt dvs. utveckling består av att vi alltid börjar med Kravinsamling. När kraven är insamlade börjar vi på nästa stegSom kallas för Förverkligande av kraven. I detta steg utvecklar vi. När detta steg är klart får vi feedback från användaren. Arbetsförloppet sker iterativt där varje iteration innehåller de steg som beskrivs ovan. Utgångspunkt för kraven till nästa iteration är feedback från användaren

Ur intervjuutdraget framgår det att utvecklingen sker iterativt. Varje iteration innehåller flera steg.

Företag 4

Det fjärde företaget har 50 anställda. Projekt bedrivs på följande sätt (Utdrag ur intervju)S: Vi börjar med insamling av kraven. Sedan Implementeras det som finns med i krav specen sedan sker LeveransVarje iteration består av stegen som beskrivs ovan. Varje projekt innehåller många iterationer.F: Sker leveransen till en beställare eller är leverans en avslutning av en iteration?S: Leverans är en avslutning av iterationen. Leverans av programvara till beställaren sker i slutet dvs. då allting är klart.

Företag 5

Nästa företag har 55 anställda. Projekten bedrivs på följande sättS:FörstudieKravinsamlingProgrammeringTestningLeveransDessa steg finns i utvecklingsprocessen(Personen hävdar att detta arbetssätt är agilt. Jag tycker att arbetssättet är sekventiellt eftersom personen beskriver att arbetet startar med förstudie och slutar i en leverans alltså förekommer inga iterationer)

30

Företag 6

Det sjätte företaget har 200 anställda. Projekten bedrivs på följande sätt: (Utdrag ur intervju)S: När vi bedriver projekt påbörjar vi med –Förstudie -Spec av anpassningar-Installation-Utbildning-Test-DriftstartF: Är spec. av anpassningar samma sak som kravinsamlingS: JaF: Varför heter inte detta steg kravinsamling?S: Därför att vi tycker att kravinsamling är någonting man gör i början av en utvecklingsprocess. Det associeras med sekventiell utveckling. Man kan säga att Spec av anpassningar innebär samma sak som kravinsamling, men i en iterativ utvecklingsprocess.F: Innebär det att kraven vid detta steg bygger på resultat av föregående iteration om sådan iteration finns? S: JaF: Ni bedriver utveckling av mjukvara i iterationer som består av stegen som beskrivs ovan. Exempelvis driftsättning. I ert fall innebär det att om ni är mitt i ett projekt, så är det en övergång mellan iterationen och om ni är i slutet av er sista iteration så innebär det driftsättning av mjukvara. Stämmer det?S: Alldeles korrekt

5.2.5 Respondeternas beskrivning av agil utveckling

Nedan presenterar vi data om vad respondenter anser vara agil utveckling. Vi sorterar svaren med avseende på respondenters akademiska bakgrund

Systemvetare

Såhär beskriver systemvetarna agile utveckling

Första respondenten beskriver agil utveckling som Iterativ utveckling med korta leveranser. Intervjupersonen svarar på följande sätt på frågan: Vad är agile utveckling för dig?:” För mig är agile iterativ utveckling med korta leveranser”

Den andra respondenten beskriver agil utveckling som iterativ utveckling med korta leveranser. Intervjupersonen svarar på följande sätt på frågan: Vad är agile utveckling för dig?:”S: För mig är agile, iterativ utveckling med korta sprintar. F: Vad menar du med korta sprintar?S: En kort iteration.”

Från intervjuer med systemvetare kan vi dra slutsatsen att personer med akademiska bakgrund inom systemvetenskap definierar agile på ett likartat sätt. Dessa personer definierar agile som Iterativ utveckling med korta leveranser.

Datavetare

Såhär beskriver datavetare agil utveckling: 31

Den första och den andra respondenten beskriver agile som iterativ utveckling med korta leveranser

Den tredje respondenten beskriver agile som iterativ utveckling där beställaren medverkar och där det inte finns en chef. (Urdrag ur intervju)”Iterativ utveckling. Medverkan av beställaren. Gruppen är självgående dvs. det finns ingen chef.F: Menar du att det är ingen som styr upp arbetet?S: Nej det finns en projektledare, men gruppens medlmemar har väldigt mycket att säga till om. Det finns ingen chef som bestämmer allt. Projektledaren är mest där för att kunna sköta kontakten med ledningen. Projektledaren bestämmer inte om vad som ska göras, utan uppgifterna fördelas gemensamt på gruppen. 33F: Kan man säga att projektledaren får en coachande roll?S: Aa, projektledaren är mer som en coach.”

Datavetarna definierar agile på ett likartat sätt. Samtliga respondenter beskriver agile som iterativ utveckling med korta leveranser. En utav intervjupersonerna går ännu längre och beskriver hans syn på hur agile utveckling styrs. Enligt denna person finns det ingen chef i projektet. Projektet innehåller istället en ledare som fungerar som en coach. Arbetsuppgifterna fördelas mellan samtliga gruppmedlemmar inom gruppen och fördelas således inte av chefen.

Datatekniker

Första respondenten beskriver agile som iterativ utveckling med korta leveranser

Andra respondenten beskriver agile som utvecklingsprocess som är indelad i korta arbetsperioder. Projektet innehåller flera sådana perioder. Personen svarar på följande sätt på frågan: Vad agile är för dig?:”Iterativ utveckling. Utveckling som är indelad i korta arbetsperioder. Projekten innehåller flera sådana perioder”

Tredje respondenten beskriver agile som ad-hoc utveckling och iterativ kommunikation med täta avstämningar. Personen svarar på följande sätt på frågan: Vad agile är för dig?:”Jag kan beskriva agile som Ad Hoc utveckling. Agile är snabb utveckling med täta avstämningarF: Vad menar du med ad-hoc utvecklingS: Ad Hoc innebär att utveckling inte sker enligt en förutbestämd plan. Man bygger först en liten del. Sedan analyserar man det som har byggts. Är man nöjd bygger man nästa del. Är man missnöjd åtgärdar man det som man är missnöjd med och går sedan över till att bygga nästa del.”

Fjärde respondenten beskriver agil som motsats till vattenfallsmodellen där det inte finns ett steg för steg-tänkandet. Det finns ingen tydlig projektledare. Personen svarar på följande sätt på frågan: Vad agile är för dig?:

32

” Opposite of waterfall model. There are no step-by-step instructions that one has to follow, instead it is up to the developer to decide how he/she wants to implement the solution in a way that suits him/her in a best possible way, while adhering to business requirements. In agile no supervision from project (or any other) manager is required.”Respondenter som har studerat datateknik definierar agile som iterativ utveckling med korta leveranser. Dessa kriterier har samtliga intervjupersoner angivit. Förutom dessa kriterier angav en av respondenter att agile är ad-hoc utveckling dvs. det finns ingen förutbestämd steg för steg plan på hur utveckling ska gå till. Dessutom har en av respondenter angett att det inte finns en tydlig chef i projektgruppen.

Personer som har övergått till it från andra branscher

Den första personen är Civilekonom som övergick till IT. Denna respondent beskriver agile utveckling som Scrum och iterativ utveckling med korta sprintar. Det som är intressant med denna person är att företaget arbetar sekventiellt, samtidigt som respondenten hävdar att företaget arbetar agilt. Personen beskriver företagets arbetssätt på följande sätt: ”Förstudie, Kravinsamling, Programmering, Testning, Leverans. Projektet börjar med en förstudie och avslutas vid leverans.”

Den andra respondenten är ekonom som övergick till IT. För personen är agile utveckling iterativ utveckling där beställaren medverkar. Det finns ingen chef.

Den tredje respondenten är maskiningenjör som började arbeta med IT. Personen vet inte vad agile är för någonting. Det som är intressant med företaget som denne personen representerar är att företaget bedriver iterativ utveckling. Personen beskriver hur projekt bedrivs i deras företag, på följande sätt: ” Vi får kravspec från kund. Vi utför arbetet och har om det krävs täta möten med kunden, så att vi har samma bild av kraven och så att dessa efterföljs. Efter kundmötet korrigerar vi kraven utifrån det som vi kom överens om på mötet.”

Respondenter som inte har en akademisk bakgrund inom IT beskriver agile på ett likartat sätt. En personer beskriver agile som scrum, samtidigt som personen hävdar att företaget bedriver agile utveckling, men utvecklingsprocessen är sekventiell. En intervjuperson vet inte vad agile är samtidigt som mjukvaruutveckling bedrivs på ett iterativt sätt.

33

6 Slutsatser

Följande kriterier enligt intervjuerna karakteriserar begreppet agile 1.Iterativ utveckling med korta leveranser2.Motsats till vattenfallsmodellen3.Ingen tydlig projektledare4. Beställaren medverkar i utvecklingen5. Iterativ kommunikation dvs. alla i projektgruppen känner till vad som händer i utvecklingen Nedan jämför vi kriterier

1. Att arbetsprocessen synliggörs för hela gruppen beskrivs av både litteraturen och av utvecklarna

2. Iterativ utveckling beskrivs av både litteraturen och av utvecklarna.3. Kommunikation i projektgruppen beskrivs både av litteraturen och av utvecklarna.4. Att beställaren involveras i utveckling finns beskrivet i både litteraturen och beskrivs

av utvecklarna.5. Avsaknad av en tydlig projektledare beskrivs av utvecklarna och av litteraturen6. Att prototyper byggs beskrivs av litteraturen, men inte av utvecklarna.

Projektledarna som arbetar med mjukvaruutveckling beskriver agile på följande sätt:Agil utvecklingsprocess är när processen sker iterativt och är motsats till vattenfallsmodellen. Ibland är beställaren involverad i utvecklingsprocessen. Projektorganisationen kännetecknas av en avsaknad av tydlig chef.

Genom att ha analyserat flera utvecklingsprocesser som beskrivs i litteraturen kan vi dra slutsatsen att litteraturen beskriver agile på följande sätt: Agil utveckling sker inte sekventiellt utan består av flera återkommande steg. Varje steg byggs på resultatet av föregående steg. Detta eftersom resultatet från föregående steg ger upphov till kravbilden för nästa steg. Därför är kravinsamlingen även ett levande dokument där kraven ändras efter behov. Varje steg benämns iteration. Varje iteration innehåller flera faser. Nya krav till nästa iteration kan komma från olika källor beroende på vilken utvecklingsprocess man arbetar med. Antingen ställs kraven från projektteamet, och då utifrån resultaten från föregående iteration eller så ställs kraven från beställaren. Nya krav från beställaren baseras på feedback som projektteamet får från denne vid leveransen av resultatet man har uppnått vid tidigare iterationer.Iterationens längd kan vara olika lång beroende på vilken metod man använder. Ju äldre utvecklingsprocessen är desto mindre kommunikation sker det mellan utvecklaren och beställaren.

Slutsatsen som vi kunde dra från vår studie är att det inte finns några signifikanta skillnader mellan hur litteraturen beskriver agile och hur intervjupersonerna beskriver agile.De enda skillnader som vi fann är att det byggs prototyper i vissa utvecklingsprocesser som beskrivs i litteraturen. Utvecklarna nämner inte prototyper alls. Vi anser att prototypbygget inte är avgörande för om en utvecklingsprocess ska räknas till agile eller inte.Det finns en del skillnader mellan de olika processerna som beskrivs.

34

Men i det stora hela finns det mycket likheter. Hela utvecklingsförloppet är exempelvis likt i alla processer. Stegen kan dock kallas på olika sätt. En skillnad mellan processerna är huruvida beställaren medverkar i processen eller inte. I exempelvis inkrementell utveckling behöver inte beställaren medverka. I scrum spelar beställaren en viktig roll. Vi tycker att huruvida beställaren är involverad i processen eller inte, inte påverkar betydelsen av agile. Därför är denna skillnad inte relevant. När vi analyserade litteraturen analyserade vi olika mjukvaruutvecklingsmetoder som föll under ett paraplybegrepp och visste att metoderna skiljer sig från varandra. Hade dessa metoder inte skilt sig, hade det inte funnits flera agila mjukvaruutvecklings metoder. Det finns lite skillnader mellan hur olika intervjupersoner beskriver agile. Dock är dessa skillnader inte signifikanta. Ett exempel på dessa skillnaden är benämningen av de olika faserna i utvecklingsprocessen. Det är bara benämningen som skiljer sig och inte fasens kontenta.

35

7 Diskussion

Slutsatsen som vi kunde dra från vår studie är att det inte finns några signifikanta skillnader mellan hur litteraturen beskriver agile och hur intervjupersonerna beskriver agile.

Metoden som vi har valt för att samla in data är relevant för frågeställningen. Detta eftersom man behöver fråga andra för att få reda på vad deras åsikter är. Det har vi gjort genom intervjuer.

För att få en inblick i den teoretiska begreppsbildningen av agile vänder vi oss till litteraturen. Literaturgranskning är en relevant metod för detta ändamål. Det räcker givetvis inte med att bara samla in data utan data måste även analyseras för att man ska kunna dra några slutsatser. För att komma fram till vårt resultat valde vi den semantiska analysen. Den semantiska analysen passar oss eftersom semantisk analys går ut på att jämföra olika texter.

I vår studie jämför vi olika mjukvaruutvecklingsprocesser med varandra.

Det finns dock en del saker som behöver tas upp när det gäller intervjuanalysen. Den mänskliga faktorn kan inverka på resultatet. Beroende på vem man intervjuar får man olika svar på vad ett begrepp innebär. Detta kan bero på att personens uppfattning av begreppet påverkas av miljön som han/hon arbetar i. Personens akademiska bakgrund kan också inverka på personens förståelse av ett visst begrepp, detta beroende på hur begreppet framställs på lärosätet. Vi hittade inte någon skillnad på hur människor beskriver begreppet agile i förhållande till storleken på företaget. Personer i olika stora företag beskrev begreppet på ett likartat sätt. Vi hittade inga skillnader mellan svaren från personer som har studerat datarelaterade utbildningar och dem som inte gjort det. Det fanns lite begreppsförvirring hos personer som inte har en it-bakgrund. En person visste inte vad agile var samtidigt som företaget där personen arbetade bedrev agile utveckling. En annan person hävdade att han visste vad agile var samtidigt som personen beskrev ett sekventiellt arbetsflöde och hävdade att det var agile. Eftersom vi visste om dessa ev. skillnader i förväg filtrerade vi bort dessa skillnaden när vi sammanställde en förklaring om hur utvecklare beskriver agile. Företagets storlek spelar ingen roll för hur intervjupersonen beskriver agile. Slutsatsen som vi kunde dra från undersökningen av storleken på företgen i vilken utvecklaren arbetar i är att i små, medelstora och stora företag bedriver utveckling på liknande sätt. Det medför att intervjupersoners syn på agile inte påverkades av företagets storlek.

Vi kan inte relatera våra resultat till någon tidigare studie. Vi har inte hittat någon studie som sammanställer litteraturens syn på agil utveckling. Vi har inte hittat någon studie som handlar om hur utvecklare beskriver agile. Vi har i heller inte hittat någon studie som jämför den teoretiska beskrivningen med beskrivningen i verkligheten.

36

8 Vidare forskning

Studien som vi har genomfört ger en indikation på att begreppet agile beskrivs likadant av utvecklare och av litteraturen. Studiens resultat leder till flera frågor rörande agile. En frågeställning till fortsatta studier är: Hur vanlig är agileutveckling bland företag? En annan frågeställning kan vara: Vilken projektstyrnings metod är mer effektiv sekventiellmetod eller agile?

37

9 Referenser

1. Agilemanifiesto(N.d) Agile manifiesta hemsida. Hämtad juli 2012 http://agilemanifesto.org/

2. A Bryman 2003. Samhällsvetenskapliga metoder. Studentliteratur

3. Barry William Boehm 1986. A spiral modell of software developement and enhacement. Software Engineering Notes

4. Barry William Boehm2006. A view of 20th and 21st Century Software Engineering. ACM

5. Carig, Basili.2003 Evolution of the PDCA Cycle

6. Claes Wohlin 2005. Introduktion till Programvaruutveckling. Studentliteratur(2)

7. Craig Larman, Victor R. Basili 2003. Iterative and Incremental Development: A Brief History.Computer Vol36

8. Dahlström 2011

9. Eriksson K. Broar 1991. Introduktion i vårdvetenskaplig metod Studentliteraturen

10. Erling S Andersen 1994.Systemutveckling principer, metoder och tekniker. Studentliteratur

11. Francisco J. Pino, Oscar Pedreira, Félix García, Miguel Rodríguez Luaces, Mario

12. Henrik Kniberg, Mattias Skarin 2010. Kanban and Scrum - making the most of both. InfoQ

13. Håkan Lindgren 2003. Programvaraprojekt Stabilitet, användbarhet och inkrementell utveckling. Studentliteratur

14. Ian. Summerwile 2010 Software Engineering

15. IBM Rational Unified Process (RUP)(n.d)IBM hemsida.Hämtad juli 2012 http://www-01.ibm.com/software/awdtools/rup/(14)

16. Jarl .Backman2008 Rapporter och uppsatser Studentliteraturen

17. Jefry Liker(N.d) Jefry Likers hemsida Hämtd juli 2012 http://www-personal.umich.edu/~liker/

18. Jutta Eckstein 2004 .Agile software development in the large. Dorset House Publishing Co.(

19. Kanban(N.d) Crisps hemsida . Hämtad juli 2012http://www.crisp.se/kanban/

20. Ken Schwaber 2009 .SCRUMGUIDE. Scrum Alliance 2009

21. Pekka Abrahamsson, Juhani Warsta, Mikko T. Siponen, Jussi Ronkainen 2003. New Directions on Agile Methods: A comperative analyse. ACM

22. Piattini 2010. Using Scrum to guide the execution of software process improvement in small organizations. Journal of Systems and Software

23. R Hoda, P Kruchten, J Noble, S Marshal 2010. Agility in context. Sigplan Notices Volume 10

24. Shook John 2010. Lean management - med hjälp av A3-analyser. Liber

25. T Stelholt, J Hannay, D Pfahl, C Benstad, P Langtangen. 2011. A literature review of agile practices and their effects in scientific software development. Oslo University

38

26. Tomas Björkholm, Hans Brattberg 2010. Din snabbguide till Lean, Agile, Scrum och XP. Vulkan

27. Toyota Produktion System(N.d) Wikepedia Hämtad juli 2012 http://sv.wikipedia.org/wiki/Toyota_Production_System

28. Extremae Programing:A gentle introduction(n.d) Hämtad juli 2012 http://www.extremeprogramming.org/

29. Royce 1970 .Developement of large softvare

30. Tomas Gustavsson 2011. Agile konsten att slutföra projekt .Tuk Företag31. James Shore 2007. The Art of Agile Developement. O'Relly32. Human centred design processes for interactive systems(N.d)Usability Net.Hämtades

juni2012 http://www.usabilitynet.org/tools/13407stds.htm.

39

http://www.usabilitynet.org/tools/13407stds.htm

Documents

En jämförande studie av begreppet Agil utveckling i teori och … · 2020. 2. 20. · En jämförande studie av begreppet Agil utveckling i teori och praktisk användning A comperative