Kravförändringars påverkan En undersökning om kravförändringar i agila systemutvecklingsprojekt

Transkript

1 Institutionen för informatik Examensarbete i Informatik Kandidatuppsats med inriktning mot systemvetenskap Kravförändringars påverkan En undersökning om kravförändringar i agila systemutvecklingsprojekt Författare: Marcus Persson Handledare: Linda Askenäs Termin: VT-2016 Kurskod: 2IK10E

2 Sammanfattning Det är idag vanligt att arbetet inom IT-sektorn utförs i projektform och mot en marknad som hela tiden är i rörelse och som förändras. Det traditionella sättet att genomföra systemutvecklingsprojekt började runt 1990-talet att ifrågasättas, pga. att de är stela och inte accepterar kravförändringar som t.ex. ett förändrat behov från kunden. Som en reaktion på det traditionella sättet att utveckla system kom de agila metoderna, som ska acceptera kravförändring. Studier visar dock att metoderna som ska vara flexibla ofta medför problem vid kravförändringar. Syftet med uppsatsen är att undersöka hur krav hanteras under ett agilt systemutvecklingsprojekt samt hur kravförändringar kan påverka projektens resultat. Det genomfördes en kvalitativ undersökning i form av fyra intervjuer med personal från ett globalt IT-konsultföretag. Resultatet av denna studie visar att kravförändringar är något som hanteras på olika sätt beroende på hur kommunikationen mellan kund och projektgrupp genomförs, men också hur kommunikationen genomförs internt i projektgruppen. Resultatet visar också att kravförändringar, oavsett om det är stora eller små kravförändringar, påverkar resultatet för projektet negativt eller positivt beroende på ett antal faktorer som t.ex. kund, kommunikation samt projektgrupp.

3 Summary Today it is very common that the work inside the IT-sector is performed in projectform and against a market that is constantly moving and changing. The traditional way to implement systems development projects around the 1990s begun to be questioned due. that these are rigid and do not accept requirement changes during implementation, such as a changed need of the customer. The agile methods came as a reaction to the traditional way of developing systems that was supposed to accept requirement changes during a project implementation. However, studies shows that these agile methods, which should be flexible, often causes problems when requirement changes is made. The purpose of this paper is to investigate how requirements are handled in an agile system development and how requirement changes can affect project performance. A qualitative study was conducted in the form of four interviews with staff from a global IT services company. The result of this study shows that requirements change is something that is handled in different ways depending on how the communication between the customer and the project is implemented, but also how the communication is carried out internally in the project. The result also shows that requirements changes, whether it is a large or small requirements change, affect the outcome of the project negatively or positively depending on a number of factors such as customer, communication and project-team.

4 Förord Ett stort tack ska riktas till de personer som deltagit i undersökningen och som bidragit till resultatet. Det har hela tiden funnits en handledare från företaget som hjälpt till och bidragit till att guida mig framåt i arbetet och förtjänar ett stort tack. Ett stort tack till min handledare från universitetet Linda Askenäs som har varit till stor hjälp. Till sist skulle jag också vilja tacka det berörda företaget i sig för visad förståelse kring arbetet av detta examensarbete. Marcus Persson

5 1 Introduktion Inledning Tidigare forskning Problemformulering Syfte och frågeställning Avgränsning/Begränsning Målgrupp 4 2 Bakgrund och teori Traditionell och agil systemutveckling Kravhantering Linjär/Traditionell kravhantering Kravhanteringsmodeller Agil kravhantering Metodval och planering i agila projekt Svårigheter med agila arbetsmetoder Roller i agila projekt Produktägare Projektledare Projektgrupp 11 3 Metod Litteraturstudie Vetenskaplig ansats Datainsamling Urval Genomförande Analys Tillförlitlighet Validitet Reliabilitet Etiska överväganden Metodreflektion 19 4 Resultat Empiri Bakgrund Agila arbetsmetoder i projekt 20

6 4.1.3 Konkreta projektfrågor och erfarenheter Egna tankar och idealbilden Analys Kund Kommunikation Projektgrupp 30 5 Diskussion Kund Kommunikation Projektgrupp Avslutande diskussion Jämförelse med tidigare forskning 37 6 Avslutning Syfte och genomförande Slutsats Förslag till fortsatt forskning 39 Referenser Bilaga A Figur 1 Vattenfallsmodellen, s. 5. Figur 2 Överskådlig figur över identifierade teman, s. 33. Figur 3 Överskådlig figur efter resultatdiskussion, s. 37.

7 1 Introduktion I introduktionsavsnittet berörs områden som t.ex. inledning, tidigare forskning samt syfte och problemställning. Detta för att läsaren ska kunna förstå sammanhanget kring undersökningen och få en inblick i ämnet. För att läsaren ska förstå nyttan med studien redan nu, så återges syftet nedan: Syftet med uppsatsen är att undersöka hur krav hanteras under ett agilt systemutvecklingsprojekt samt hur kravförändringar kan påverka projektens resultat. 1.1 Inledning Att arbeta i projektform är idag mycket vanligt när någon form av produkt, - eller systemutveckling ska genomföras, t.ex. nyutveckling eller vidareutveckling av ett system. För att ett projekt ska uppnå sina uppsatta mål och förväntningar måste aktiviteter inom projektet utföras. Dessa aktiviteter som ska leda projektet mot ett önskat resultat genomförs ofta på olika sätt i varje projekt beroende på vad som ska utvecklas, men också beroende på vad för utvecklingsprocess/metod som valts inom projektet. Metoden som väljs inom projektet fungerar som ett ramverk eller tillvägagångssätt för personerna som arbetar i projektet och ska ge dem en bild av vad för arbete som ska utföras samt hur det ska utföras (Wohlin, 2005). Den marknad en IT-organisation inriktar sig mot är idag ofta rörlig och det är en nödvändighet att snabbt kunna anpassa sig efter förändrade behov och önskemål. Metoder som väljs inom ett projekt bestämmer hur arbetet ska utföras och därför också hur väl projektet kan anpassas mot förändringar. Traditionella systemutvecklingsmetoder använder ofta någon form av vattenfallsmodell och kännetecknas genom att arbetet utförs ett steg i taget och inget annat arbete påbörjas innan det påbörjade steget är klart, samt att kraven från beställaren på det som ska utvecklas ofta är genomarbetade och låsta, d.v.s. inte förändringsbara (Stoica et al. 2013). Som en reaktion på den traditionella utvecklingsmetodiken kom det agila arbetssättet som började användas mer under talet (Sletholt et al. 2012). Det agila arbetssättet kännetecknas av att systemet utvecklas en liten del i taget, med en liten del av den totala kravmassan från kunden som också levereras till kunden för bedömning. Detta upprepas sedan tills varje genomförd leverans bildar en helhet. Att arbeta agilt innebär att arbeta iterativt och att arbeta med lite i taget (Stoica et al. 2013). De agila arbetsmetodologierna sågs som lösningen på problemen som ofta uppstår när de traditionella metoderna används, som t.ex. att kraven ofta stängs i ett tidigt skede, d.v.s. att kravbilden inte kan ändras under projektets gång, även om kravställaren känner att kraven behöver förändras för att kunna uppnå projektets uppsatta mål (Sletholt et al. 2012). Agila metoder är något som används mer och mer och idag är det vanligt att organisationer har ett agilt arbetssätt i systemutvecklingsprojekt (Campanelli & Parreiras, 2015). De agila metodologierna ger ett mer flexibelt sätt att arbeta än de traditionella systemutvecklingsmetoderna och ger vissa fördelar (Campanelli & Parreiras, 2015). Inayat el al. (2015) framhäver att fördelar med de agila metoderna jämfört med de traditionella är 1

8 att de eliminerar kommunikationsbrist genom ett nära samarbete med kund, ingen onödigt lång projektplanering görs, förminskar arbetet med kravdokumentation men det viktigaste anses vara att det ska vara möjligt att enklare anpassa projektet mot kravförändringar. Campanelli och Parreiras (2015) menar att användning av agila arbetsmetoder kan medföra problem. En agil metod behöver ofta anpassas gentemot den berörda organisationen som ska arbeta enligt metoden. Då kan det uppstå problem om det finns en viss organisationskultur eller om organisationen gör motstånd till förändring. Inayat et al. (2015) uttrycker att de största utmaningarna med agila arbetsmetoder är att det produceras minimal dokumentation av kravförändringar, att kunden måste vara tillgänglig, budget och förutspådd längd för projektet samt kravförändringar och utvärdering av dessa. Att arbeta agilt är aktuellt idag och det finns ofta en önskan från företag att arbeta agilt av olika anledningar. Det ses ofta i jobbannonser att arbetet som genomförs på företaget är enligt en viss agil metod. Jag har kommit i kontakt med ett IT-konsultbolag som har intresse av att undersöka det agila arbetssättet grundligt. Företaget är ett globalt IT-konsultbolag och har genomfört, men genomför också, många agila projekt. Företaget har därför en fundering kring det agila arbetssättet med kravförändringar samt vad kravförändringar kan ha för följder i agila systemutvecklingsprojekt. 1.2 Tidigare forskning I en undersökning av Gillani et al. (2014) där syftet var att undersöka om systemutvecklingsprojekt lyckas bättre med kravhantering och kravförändringar genom att använda en agil metod istället för traditionella metodologier, blev resultatet att två av fyra kunder ansåg att kravhanteringen var någorlunda svårhanterlig med resultatet att kunderna endast ansågs vara någorlunda nöjda. Den tredje fjärdedelen av de deltagande företagen ansåg att hantering av föränderliga krav var svårt vilket resulterade i att tidsplanen bröts och kundnöjdheten var låg. Sammanfattat så tyckte alltså tre av fyra företag att hanteringen av kravförändringar inte blev bättre vid ett agilt arbetssätt. Denna undersökning inriktade sig på mindre och mellanstora företag. I en litteraturstudie av Inayat et al. (2015) beskrivs det att det finns stora utmaningar med agila arbetssätt när kravförändringar ska behandlas. Problemet som uppstår är att agila metoder ofta väljs av organisationer för att spara pengar på att t.ex. minimera dokumention av kravförändringar. Minimal dokumentation av krav kan leda till att problem uppstår i kommunikationen av krav som i agila metoder sker direkt mot kund. Dessa problem visades uppstå främst för att det fanns geografiska skillnader mellan kund och systemutvecklare eller om kunden är otillgänglig när dessa förändrade krav ska kommuniceras. Budget och planering är också svårhanterligt när det förekommer kravförändringar eller önskemål om kravförändringar på produkten eller systemet mitt under ett projekts genomförande. I en internationell undersökning gjord av Wagner et al. (2016), som hade som syfte att undersöka svårigheter i agila projekt, identifierades kravförändring som något som anses 2

9 vara svårhanterligt i agila systemutvecklingsprojekt. I denna undersökning deltog även Sverige. 1.3 Problemformulering It-företaget som har intresse av studien har upptäckt att det ofta finns oklarheter kring hur kravförändringar ska hanteras och hur de påverkar ett projekts resultat när det används en agil arbetsmetod som tillvägagångssätt i arbetet som utförs. Företaget ser därför ett behov av att undersöka agila arbetsmetoder närmre och hur kravförändringar hanteras och hur de påverkar ett projekts resultat. Inayat et al. (2015) har genom sin studie kommit fram till att det finns ett behov av att undersöka hur kravförändringar hanteras i projekt från verkligheten samtidigt som det generellt behövs empiriska undersökningar kring det agila arbetssättet. Petersen och Wohlin (2009) anser att det finns ett stort behov av empiriska undersökningar för att undersöka agila arbetsmetoder och att dessa undersökningar ska vara kvalitativa för att få en större förståelse och inblick i problematiken med agila arbetsmetodologier. Även Dybå och Dingsøyr (2008) beskriver att det finns ett stort behov av att undersöka olika agila arbetsmetodologier med kvalitativa metoder. En av de tidigare forskningarna som angetts visade att även företag i Sverige anser att arbetet kring kravförändringar är svårt. Därför finns det också ett behov att genomföra denna studie i Sverige. 1.4 Syfte och frågeställning Syftet med uppsatsen är att undersöka hur krav hanteras under ett agilt systemutvecklingsprojekt samt hur kravförändringar kan påverka projektens resultat. Frågeställningarna har därför formats på följande sätt: Hur hanteras kravförändringar i systemutvecklingsprojekt som använder sig av agila arbetsmetoder? Hur påverkar kravförändringar ett systemutvecklingsprojekts resultat där agila arbetsmetoder används? 3

10 1.5 Avgränsning/Begränsning Ämnesområdet agil utveckling är ett brett kunskapsområde och därav viktigt att avgränsa undersökningen. Även kravhantering är ett stort område, fokus i denna studie är enbart hur krav hanteras under den tekniska utvecklingen i ett systemutvecklingsprojekt. Undersökningen kommer alltså inte beröra hur krav tas fram eller kravhantering rent generellt. Denna undersökning inriktar sig endast på att undersöka arbetssättet kring kravförändringar vid ett agilt arbetssätt. Det kommer alltså inte göras någon problematisering av någon specifik agil arbetsmetod eller liknande. Undersökningen kommer att begränsas till ett specifikt företag, d.v.s. inga andra företag kommer vara inblandade i studien. Respondenterna som deltar i studien arbetar för tillfället på det berörda företaget som har intresse av studien. Därför ses det som en avgränsning att det inte finns någon personal från andra organisationer som deltar i studien. 1.6 Målgrupp Företaget som har intresse av, och som gör den här undersökningen genomförbar, är en direkt målgrupp för studien och kommer ta del av resultatet som sätts samman. Andra företag och organisationer som vill arbeta, eller arbetar, agilt är också en möjlig målgrupp för undersökningens resultat. Inayat et al. (2015) har genom sin litteraturstudie påvisat att det agila arbetssättet har både fördelar och nackdelar. Fördelar som de agila arbetsmetodologierna ger verkar också medföra någon form av nackdel. T.ex. att det inte behöver läggas någon större vikt vid att dokumentera kravförändringar då det istället sker en kommunikation kring detta. Enligt Inayat et al. (2015) genomförs det bristfällig dokumentation som leder till att kravförändringar försenar och medför merkostnad för projektet. Studien ska skapa en beskrivande kunskap kring kravförändring och en målgrupp kan därför också vara dem som är intresserade att bygga vidare på denna kunskap i en mer förklarande studie. 4

11 2 Bakgrund och teori De områden som presenteras i detta avsnitt är traditionell och agil systemutveckling, kravhantering, betydelsen av agila metodval och planering i agila projekt, svårigheter med agila arbetsmetoder och roller i agila projekt. En motivering till hur teorin har tagits fram, finns i metodkapitlet (avsnitt 3.1). 2.1 Traditionell och agil systemutveckling Enligt Estler et al. (2014) består traditionella och agila systemutvecklingsprocesser av aktiviteter. Dessa aktiviteter är handlingar som utförs på olika sätt i olika projekt beroende på hur arbetet utförs. Exempel på aktiviteter i systemutvecklingsprojekt är t.ex. kravhantering, design av systemet, implementation och underhåll av systemet. Detta är alltså aktiviteter som utförs på olika sätt beroende på om projektet utförs på ett traditionellt eller agilt arbetssätt. Traditionella systemutvecklingsprocesser kallas ibland linjära processer eller metoder. De traditionella utvecklingsmetoderna är strukturerade och hur arbetet ska utföras definieras ofta innan projektet startar. Det produceras ofta stora mängder dokumentation under de traditionella systemutvecklingsprojekten. Något som ofta anses viktigt är att dokumentera kravförändringar. Det är också vanligt att en detaljerad tidsplanering och budget skapas innan projektet startar vid ett traditionellt systemutvecklingssätt (Estler et al. 2014). Avison och Fitzgerald (2006) framhäver att de traditionella, eller linjära, arbetsmetoderna innehåller faser. Dessa faser innehåller aktiviteter som ska utföras för att fasen ska bli helt klar, därefter börjar arbetet med nästa fas. Innan den aktuella fasens aktiviteter är genomförda påbörjas inga andra aktiviteter eller faser. Arbetet sker därför sekventiellt. Estler et al. (2014) nämner att den vanligaste metoden som används vid traditionell systemutveckling är vattenfallsmodellen. Nedan visas ett exempel på en vattenfallsmodell där varje fas måste genomföras innan nästa börjar. Kravhantering Design Kodning Enhetstest Integrationstest Systemtest Drift & underhåll Figur 1. Vattenfallsmodellen (Wohlin, 2005). 5

12 Agila utvecklingsmetoder nämns ofta som iterativa eller inkrementell utveckling (Avison & Fitzgerald, 2006). Avison och Fitzgerald (2006) menar att de agila utvecklingsmetoderna började användas för att lösa problemen som fanns med de traditionella. De traditionella anses vara oflexibla, bidra till lägre kundnöjdhet samt bidra till kommunikationsbrist mellan de som arbetar i projektet och kund (Avison & Fitzgerald, 2006). När de agila utvecklingsmetoderna används utvecklas små delar av hela systemet och levereras till kund. Arbetet som sker i projektet, d.v.s. olika faser, genomförs parallellt och i mindre leveranser. Leveranserna behöver dock inte användas, utan kan fungera som prototyper för att kunden ska förstå och kunna vara delaktig i utveckling och föreslå förändringar (Wohlin, 2005). Det agila arbetssättet beskrivs utifrån följande fyra punkter i det agila manifestet (Beck et al. 2001): Individer och Interaktioner framför processer och verktyg. Fungerande mjukvara framför heltäckande dokumentation. Kundsamarbete framför kontraktsförhandlingar. Reagera på förändringar snarare än att följa en plan. Idag finns det många agila arbetsmetodologier som har ett agilt synsätt på hur arbetet ska utföras i ett systemutvecklingsprojekt. De mest välkända metoderna är Scrum och Extreme Programming (XP) och dessa anses genomsyras av ett agilt sätt att arbeta (Avison & Fitzgerald, 2006). 2.2 Kravhantering För att läsaren ska få en förståelse för hur kravhantering görs både linjärt och agilt ges en beskrivning av båda områdena nedan Linjär/Traditionell kravhantering Stoica et al. (2013) nämner att det traditionella sättet att hantera krav i systemutvecklingsprojekt innebär skillnader. Framtagningen av de krav som anses nödvändiga för att systemet ska uppfylla kundens önskemål är något som lägger grunden för projektet. Stoica et al. (2013) framhäver att kraven genomarbetas på en grundlig nivå för att det ska vara så exakta krav som möjligt som framgår i kravdokumentationen. Genom en specifik och detaljrik kravdokumentation kan en planering för projektet genomföras som heller inte ska brytas eller förändras. Det finns också modeller som stödjer det linjära sättet att ta fram och hantera krav. Ett exempel på dessa är vattenfallsmodellen som återges tidigare i teorikapitlet (avsnitt 2.1). Avison och Fitzgerald (2006) menar att de traditionella modellerna är beroende av de tidiga faserna som t.ex. kravinsamling, kravanalys samt kravdefinition. Detta beror på att de kravspecifikationer och dokumentation ska följas genom projektets gång. Planeringen för projektet görs ofta utifrån dessa dokument och när dessa faser är genomförda, genomförs inga ändringar av kraven. 6

13 2.2.2 Kravhanteringsmodeller UML (Unified Modeling Language) är ett sätt att specificera system och systemdesign som ofta används i många sorters systemutvecklingsprojekt. Genom att modellera med olika symboler underlättas framtagandet och förståelsen för systemet (Avison & Fitzgerald, 2006). Avison och Fitzgerald (2006) framhäver att det idag ses som en standard att använda UML vid framtagning och specificering/dokumentation av krav. En annan modell är UP (Unified Process). Denna modell är en inkrementell modell, d.v.s. de olika faserna som t.ex. design av krav och utveckling utförs en liten del i taget, flera gånger. UP är en generell process som kan användas på flertalet olika typer av projekt (Arlow & Neustadt, 2005). UP använder sig av UML som modelleringsspråk (Avison & Fitzgerald, 2006). Avison och Fitzgerald (2006) beskriver också modellen RUP (Rational Unified Process) som en modell som använder UML som modelleringsspråk. RUP är en påbyggnad av UP och ses som en komplett systemutvecklingsmodell som stödjer ett projekt i alla faser. Denna modell är därmed också inkrementell. Detta för att de som utvecklat modellen anser att det inte är möjligt att se alla krav och systembehov innan det börjar byggas Agil kravhantering I agila metoder finns ofta bara en liten del av kravmassan och planering kartlagd när projektet startar. Kravmassan byggs på succesivt och ökar kunskapen om produkten som byggs under genomförandet av projektet och på detta sätt får projektgruppen också en klarare bild av vad nästa iteration ska innehålla för arbete (Rubin, 2012). RUP, UML. Det kan vara av negativ effekt att arbeta fram och låsa alla krav innan ett projekt startar, som det görs i vattenfallsmetoderna (Rubin, 2012). Genom att låsa kraven i ett tidigt skede ökar risken för att inte möta verksamhetens behov. När kraven sen förändras, måste vi också ändra alla de andra kraven som tillhör det förändrade kravet samt de mest fundamentala för att förändringarna ska passa resten av lösningen (Rubin, 2012). Avison och Fitzgerald (2006) understryker att agil utveckling av mjukvara accepterar att krav kan vara svårdefinierade samt att det är svårt att definiera väl detaljerade krav i ett tidigt stadium av ett projekt. Kunden som beställer projektet, vet ofta inte vad de egentligen vill ha och det kan sluta med att det har utvecklats en produkt som inte fyller någon funktion för kunden. I traditionella utvecklingsmetoder upptäcks det ofta att det har utvecklats fel produkt eller system när arbetet är slutfört, vilket ofta kräver stora mängder pengar och tid för att åtgärda, i vissa fall måste nya projekt genomföras (Avison & Fitzgerald, 2006) Inayat et al. (2015) framhäver att kommunikationen, kundinvolveringen, de iterativa kraven, kravprioriteringen, den löpande planeringen samt att enklare kunna hantera kravförändringar är det som kännetecknar agil kravhantering. Inayat et al. (2015) nämner att kommunikationen i agila systemutvecklingsprojekt sker ofta ansikte mot ansikte mellan de som deltar i projektet, både kund och projektgrupp. Denna kommunikation görs ofta för 7

14 att inte behöva dokumentera händelser och milstolpar i projektet. Dock genomförs det ofta kravdokumentation i agila systemutvecklingsprojekt. Dokumentationen görs dock med något som kallas user stories som innehåller en beskrivning av kravet på systemet, men också sammanhanget som de ska utvecklas i. Genom att hela tiden genomföra kontinuerlig kommunikation, ansikte mot ansikte, får kunden hjälp att styra projektet i rätt riktning. Genom en ständig kommunikation inom projektet och samtliga intressenter, så utvecklas också kraven. Kommunikationen är beroende av medlemmarna i projektet och kundens närvaro samt intresse av att kommunicera (Inayat et al. 2015). Enligt Inayat et al. (2015) påverkar kundinvolveringen ett systemutvecklingsprojekt i stor utsträckning och om den missköts, ökar risken för ett misslyckat projekt. Om ingen identifiering görs av vem från kunden som är produktägare i projektet, och vem som ska kommunicera med projektgruppen, kan det uppstå problem som t.ex. oförstådda kravförändringar. Därför är medlemmarna i agila arbetsmetoder beroende av att hela tiden ha en dialog med en tillgänglig kund för att detta ska fungera (Inayat et al. 2015). Kundinvolveringen och den ständiga kommunikationen framkallar hanteringen av kraven, d.v.s. de iterativa kraven. Iterativa krav betyder att projektgruppen arbetar med en liten del av kraven och hela tiden utvecklar och förändrar de framtagna kraven. Genom att hela tiden interagera med intressenter om kraven stärks också relationen med kunden samtidigt som det krävs mindre tid för att utveckla kraven (Inayat et al. 2015). Enligt Inayat et al (2015) följer oftast teamet som arbetar agilt inte en förbestämd plan från början till slut i ett agilt projekt. En löpande planering görs som betyder att projektet och teamet ofta ändrar riktning beroende på olika kravförändringar som sker från kundens sida. Inayat et al. (2015) nämner också att den löpande planeringen ger skäl till att en kravprioritering hela tiden kan göras i agila systemutvecklingsprojekt. Prioriteringen av krav är något som sker efter varje iteration tillsammans med planeringen. Prioriteringen görs endast en gång i de mer traditionella linjära metoderna, innan systemutvecklingen börjar. Om kunden fokuserar för mycket på affärsvärdet av utvecklingen kan det uppstå problem om t.ex. kunden tillåts prioritera för mycket, då kan de prioritera fel pga. okunskap i de tekniska ämnesområdena. Om det finns en teknisk okunskap hos kunden, t.ex. för arkitekturen för systemet, ökar risken för att prioriteringarna som görs inte går att genomföra av projektgruppen (Inayat et al. 2015). Inayat et al. (2015) beskriver att det hela tiden tillkommer förändringar av krav i projekt, och agila arbetsmetoder är dynamiska i sin natur och accepterar därför kravförändringar. En ständig kommunikation mellan kunden och de som utför arbetet gör att kravförändringarna kan genomföras i olika steg. Genom verifieringar mot kund och skapande av prototyper av det som ska levereras, för att få snabb feedback från kunden på de framtagna delarna, blir det läggare att hantera förändring (Inayat et al. 2015). 8

15 2.3 Metodval och planering i agila projekt Inför ett projekt väljs det att arbeta enligt ett specifikt sätt, enligt en metod (Tonnquist, 2014). Antingen genomförs projektet helt enligt en specifik projektmetodik som valts med tillhörande tidsplan och schema med aktiviteters längd, eller så genomförs det med agila arbetsmetoder, d.v.s. mer flexibelt (Tonnquist 2014). Både Tonnquist (2014) och Campanelli och Parreiras (2015) antyder att valet av arbetsmetod är att välja hur resultatet ska tas fram, d.v.s. att välja arbetsmetod är ett strategiskt beslut som bestämmer vilka resurser som behövs och när de behövs. Campanelli och Parreiras (2015) skriver att det idag finns ett stort behov av att skräddarsy arbetsmetoder inför varje projekt som ska genomföras då flertalet startade projekt bevisats bli misslyckade pga. att valda metoder inte passat in på det projekt som ska genomföras. Tonnquist (2014) nämner att agila projekt också behöver planeras och budgeteras. Utan någon form av styrning är chansen stor att projektet inte lyckas. Enligt Tonnquist (2014) passar det bra att tillämpa agila arbetsmetoder på projekt när det är svårt att se hur slutprodukten kommer se ut, kraven har en chans att bli eller redan är otydliga samt när det finns chans för att situationer inom projektet förändras. Tonnquist (2014) framhäver att det passar mindre bra att applicera agila arbetsmetoder när kraven är många och tydliga, det finns en deadline och fast kontrakt över utförandet, det finns geografiska skillnader på placering av dem som ska genomföra projektet, de flesta i projektet arbetar deltid samt när kostnaderna för ändringar är höga. Tonnquist (2014) framhäver att en kombination av metod är att rekommendera för att få en struktur över projektet under hela genomförandet samt för att kunna svara på förändringar snabbt. Denna lösning passar ofta bra när projektgruppen eller kunden inte vet hur slutprodukten ska se ut i ett projekt. Detta ställer dock större krav på att projektet har en styrning och att uppföljningar hela tiden genomförs. Det är idag vanligt med att krav förändras under ett projekts genomförande. Och det är även viktigt att hela tiden planera hur arbetet är tänkt att genomföras i projektet (Tonnquist, 2014). 2.4 Svårigheter med agila arbetsmetoder Ramesh et al. (2010) framhäver att de agila arbetsmetodernas styrkor som t.ex. flexibilitet och kundinvolvering kan bidra till problem. Några av dessa problem listas nedan (Ramesh et al. 2010): Kostnad och planering På grund av att ett agilt projekt ofta genomför kravförändringar, stora eller små, är det svårt att genomföra en planering i början av ett projekt jämfört med de traditionella. Kravförändringar bidrar till fler aktiviteter i projektet. Dessa aktiviteter bidrar till att mer resurser behövs för att slutföra projektet. Detta resulterar ofta i brusten tidsplanering eller budgetöverskridning. Kundens tillgänglighet Det är ofta svårt för kunden att vara tillräckligt tillgänglig för att ständigt kunna kommunicera med projektgruppen samt delta i utvecklingen. 9

16 Förståelse för vad som ska utvecklas, d.v.s. kraven, och det agila arbetssättet är vitalt för att kunden ska kunna vara tillgänglig och delaktig i systemutvecklingsprojektet. Minimal dokumentation Det agila arbetssättet fokuserar mycket på kommunikation istället för dokumentation av kravförändringar. Den minimala dokumentationen kan göra det svårt att motivera och förstå de förändringar som genomförts i ett senare skede i projektet. 2.5 Roller i agila projekt Nedan presenteras roller som kan finnas i projekt som använder sig av agila arbetsmetoder. Motivering till varför just dessa roller valdes finns i metodkapitlet (avsnitt 3.1) Produktägare Enligt Tonnquist (2014) är det produktägarens uppgift att tillsammans med teamet styra, prioritera och sätta upp mål. Det är samtidigt nödvändigt att produktägaren är engagerad i projektet under genomförandet. På detta sätt kan projektägaren besluta om att fortsätta till nästa steg om det precis har gjorts en delleverans eller liknande. Det är också projektägaren som förväntas ställa krav på resultatet. Produktägare kan genom att vara engagerade och kunniga bidra till att kvaliteten på slutresultatet blir högre och kostnaden för hela projektet minskar (Tonnquist, 2014). Produktägaren ansvarar för vad som ska utvecklas samt i vilket ordning detta utvecklas under projektets gång. Produktägaren är också ansvarig för att bestämma vilken funktionalitet som ska finnas med i produkten, se till att alla projektmedlemmar är tydligt informerade om vad syftet med projektet är. I stort är produktägaren ansvarig för hur väl projektet lyckas gentemot sina förväntningar (Rubin, 2012). Rubin (2012) menar också att produktägaren ska ha en ständig kommunikation mot projektgruppen och tillräckligt avsatt tid för detta då det ofta är en väldigt tidskrävande uppgift Projektledare Tonnquist (2014) nämner att projektledaren ska ha ett nära samarbete mot kunden för att förstå kundens behov. Detta samarbete sker oftast mellan produktägaren, som oftast är från kundens sida, och projektledaren. Projektledaren kommunicerar vad som ska göras, d.v.s. uppgifter från produktägaren, till projektgruppen och dess medlemmar. Tonnquist (2014) framhäver samtidigt att projektledaren ska förstå och ha kompetens inom den projektmetodik som används, intresse för människor men också ha en högt utvecklad kompetens att kommunicera med alla projektets olika intressenter. Det är också av yttersta vikt att projektledaren har en förmåga att leverera resultat som faktiskt går att använda (Tonnquist, 2014). 10

17 2.5.3 Projektgrupp Projektgruppen består av personer som ska utföra aktiviteterna inom projektet. Kompetensen är något som ska byggas fram under projektets genomförande även om det är viktigt med en grundkompetens hos deltagarna. För att få ut det bästa slutresultatet, t.ex. ett system, måste projektgruppens medlemmar ledas och ha ett samspel som planeras. Desto snabbare det skapas en teamkänsla i projektgruppen, desto snabbare kommer projektgruppen komma igång med projektet och samarbetet (Tonnquist, 2014). 11

18 3 Metod Detta avsnitt berör olika delar av genomförandet för denna specifika undersökning. Det ges en inblick i hur teorin tagits fram, vilken ansats som valts för datainsamlingen, hur datainsamlingen gjorts med tillhörande delar som t.ex. urval och hur analysen gjorts. Det genomförs också en diskussion kring tillförlitligheten för studien, vilka etiska överväganden som tagits samt metodreflektion. 3.1 Litteraturstudie Litteraturstudien som genomförts innan undersökningen påbörjades, för att kunna utgå från en deduktiv ansats (förklaras i avsnitt 3.2), har gjorts genom att försöka hitta samband mellan litteratur som eftersökts. För att hitta litteratur av användning för studien användes sökorden agile requirement engineering challenges. Dessa sökord framkom efter att ha granskat litteratur kring området agile requirement engineering, som är huvudområdet för uppsatsen. Genom att sedan söka vidare på agile requirement engineering challenges kunde jag sedan ta de översta sökresultaten, som baserades på antalet andra uppsatser som använt dessa i sina uppsatser, och fortsätta letandet av relevant litteratur neråt i kedjan. Det har också använts diverse kurslitteratur och metodböcker som använts under utbildningen som ansetts vara relevanta för studiens syfte. Det ska också nämnas att avsnitten som behandlar roller i agila projekt i teoriavsnittet (avsnitt 2.4) togs fram efter att intervjuerna genomförts. Detta beror på att samtliga respondenter pratade om hur viktiga rollerna produktägare, projektledare och projektgruppen var i agila systemutvecklingsprojekt. 3.2 Vetenskaplig ansats Det finns olika strategier för att samla in data om hur någonting verkligen är, d.v.s. data från verkligheten, t.ex. ett systemutvecklingsprojekt (Jacobsen, 2002). Jacobsen (2002) framhäver att det finns två strategier, deduktiv och induktiv datainsamling. En deduktiv datainsamling betyder att den som ska utföra undersökningen först införskaffar sig kunskap om ämnet, för att sedan genomföra undersökningen. En induktiv är istället tvärtom, forskarna försöker införskaffa sig kunskap genom att inte ha någon förkunskap eller förväntningar innan undersökningen genomförs, för att sedan först studera data från den genomförda undersökningen och sedan studera relevant teori. Innan denna studiens undersökning påbörjades genomfördes det litteraturstudier (avsnitt 3.6, Litteraturstudie) för att försöka bilda en uppfattning av hur ämnesområdet ser ut idag, därför har undersökningen genomförts med deduktiv ansats. Mitt syfte grundar sig i att få en förståelse av verkligheten, därför lämpar det sig också bra att först införskaffa en grundkunskap om området för att i ett senare skede bygga på den och utveckla förståelsen på en djupare nivå. Den deduktiva ansatsen och kunskapen som fanns innan undersökningen påbörjades har färgat undersökningens utformning. Delar av undersökningen är baserad på teori, därför har och den deduktiva ansatsen påverkat undersökningens utformning. Genom den deduktiva ansatsen har jag försökt rama in ämnesområdet och bygga på den kunskap som införskaffats 12

19 från teorin med de data som samlats in genom undersökningen. På detta sätt fick jag den kunskap jag behövde för att förstå ämnet innan undersökningen påbörjades och genomfördes. Samtidigt fick jag också chansen att försöka införskaffa data som kunde förändra min redan befintliga uppfattning om ämnet. Kopplingen kring att förstå den kunskap som redan finns i teorin för att sedan fördjupa den kunskapen kan göras mot studiens syfte, som var att skaffa så djup kunskap som möjligt om ämnesområdet. Enligt Jacobsen (2002) finns det beskrivande (deskriptiva) och förklarande (kausala) problemställningar. Beskrivande problemställningar inriktar sig främst mot att ge en inblick i ett fenomen eller säga något om ett tillstånd vid en specifik tidpunkt. Förklarande problemställningar inriktar sig istället in på att ge förklarande svar, d.v.s. varför någonting sker och orsaken till detta. De beskrivande kontra förklarande problemställningarna leder till beskrivande eller förklarande kunskap. En undersökning som har en beskrivande problemställning ska bidra med beskrivande kunskap, genom en undersökning och vice versa när det berör en förklarande problemställning (Jacobsen 2002). Min problemställning har ett syfte att skapa en beskrivande kunskap. Detta beror på att jag är intresserad av att undersöka hur kravförändringar hanteras och hur dessa kravförändringar påverkar projektets resultat. Därför är min problemställning ett försök i att ge en beskrivande kunskap. Att vara öppen för ny kunskap, något som är överraskande eller inte förväntat anser Jacobsen (2002) är något som kännetecknar kvalitativa metoder. För att öka förståelsen för ett fenomen används ofta kvalitativa metoder där också öppenhet anses som en viktig faktor. Öppenhet i det kvalitativa anseendet betyder att den som undersöker inte försöker ge den undersökta fördefinierade svarsalternativ. Den undersökta ska istället försöka ge svar på vad som är den bästa förståelsen för ett fenomen eller situation. De data som undersökaren får in kan på så sätt bli djupa och nyanserade. En kvantitativ metod ger istället mer exakta svar, är inriktad på många enheter, innehåller oftast fördefinierade svarsalternativ i form av enkäter. Genom kvantitativa undersökningar är det svårt att få djup kunskap eller förståelse för ämnesområdet (Jacobsen, 2002). Mitt val blev därför att genomföra en kvalitativ ansats av undersökningen. Det hade helt enkelt blivit svårt att få in data som kan ge ett svar på min frågeställning som är av beskrivande karaktär. Creswell (2014) skriver att en kvalitativ studie inriktar sig på att förstå ett fenomen eller ett socialt sammanhang. Frågor kan därför utvecklas och sammanhang kan förstås på en annan nivå. För att få fram en beskrivande kunskap, d.v.s. hur något fungerar, behövde jag genomföra en kvalitativ undersökning. Detta kan samtidigt kopplas till mitt syfte där jag genom undersökningen vill få en djupare förståelse för kravhantering och kravförändringar. 3.3 Datainsamling Valet att genomföra en kvalitativ undersökning för att kunna ge beskrivande kunskap till en deskriptiv problemställning gjorde att val som att t.ex. göra en enkätundersökning, som ofta är en kvantitativ undersökning (Jacobsen, 2002), inte var aktuell. Enligt Jacobsen (2002) kännetecknas enkätundersökning av att ge den undersökta fördefinierade svarsalternativ, därav ytliga svar till den undersökande. Mitt val att genomföra en kvalitativ datainsamling 13

20 möjliggjorde att djupare svar och förståelse för kravförändringar kunde insamlas. Det ökade också möjligheten att hitta nya samband kring ämnesområdet vilket var viktigt i denna studie. En kvalitativ undersökning kan genomföras på olika sätt, som kan vara värt att nämna för att motivera mitt val. Nedan presenteras och förklaras några av de vanligaste sätten att genomföra kvalitativa undersökningar (Jacobsen, 2002): Individuell/gruppintervju Den individuella intervjun kännetecknas genom att den undersökande och den undersökte har en dialog om ett fenomen. Data som erhålls av den undersökande har inga begränsningar då den undersökte kan säga vad den känner och tycker. I en gruppintervju intervjuas istället en grupp och de som deltar försöker diskutera ämnet för att skapa nya funderingar och värderingar. Undersökaren fungerar mer som en debattledare. Observation Innebär att den undersökande iakttar vad människor gör i specifika situationer. Dokumentundersökning Den undersökande studerar t.ex. offentliga dokument eller företags årsredogörelse i jakt på sekundär data. Jag valde att genomföra individuella intervjuer. Jacobsen (2002) antyder att individuella intervjuer passar bäst när det är få enheter som undersöks och när det är viktigt att förstå vad det sägs under intervjun. De individuella intervjuerna möjliggjorde djupare kunskap för ämnesområdet kravförändring och på det sättet en större möjlighet att kunna besvara min frågeställning på ett bättre och mer motiverat sätt. Relaterat till de tidigare redogjorda kvalitativa sätten att undersöka så anser Jacobsen (2002) att dokumentstudier lämpar sig bäst när det inte är möjligt att samla in primärdata. Det fanns därför ingen anledning att genomföra dokumentstudier då tillräcklig data erhölls från intervjuerna. Gruppintervjuer anser Jacobsen (2002) ha en stor spridning i synpunkterna. Målet med intervjuerna var att samla in data som förklarade hur deltagarna i ett projekt upplever problemen med kravförändringar vid ett användande av agila arbetsmetoder. Därför kan det ha stor spridning av synpunkter, beroende på en hel del faktorer som t.ex. tidigare erfarenhet av agila arbetsmetoder, vilken kund som deltagit i projektet eller också sammansättningen av projektgruppen. Dock hade gruppintervjuer ändå kunnat vara aktuellt för att skapa en djupare diskussion om ämnet, men det kräver också att det samordnas, d.v.s. att alla är på samma ställe och att alla deltagare var tillgängliga samtidigt, och det var inte möjligt i detta fall. Observation är främst, enligt Jacobsen (2002), användbar för att se vad människor gör i vissa sammanhang. Detta hade kunnat genomföras då det hade skapat användbar data tillsammans med genomförda intervjuer för att stärka det som sägs. Dock ser jag det som svårt att kunna genomföra värdefulla observationer när t.ex. en kravförändring sker, då detta inte kan förutspås i förhand när det ska ske. De som deltog hade heller inte några aktuella projekt som pågick just nu som var aktuella att observera i detta sammanhang. 14

21 3.3.1 Urval Jacobsen (2002) framhäver att när det ska genomföras en kvalitativ undersökning är det den specifika åsikten och kunskapen som eftersöks. Därför är det svårt att genomföra en kvalitativ undersökning på mer än ca tjugo enheter, dels beroende på den stora mängd material som fås genom den kvalitativa studien, men också för att det försöks att få tillgång till det specifika och inte generella. Det följdes en process från Jacobsen (2002) som återges nedan, detta tillsammans med förklaring för hur arbetet fortlöpte kring urvalet i undersökningen: Skaffa överblick Den totala mängden av enheter i populationen bestäms som är av intresse att undersöka (Jacobsen, 2002). Tillsammans med handledaren från företaget togs en lista fram på personer som kunde vara av intresse att intervjua. Listan med personer grundade sig i att de arbetade antingen som projektledare, systemutvecklare, systemarkitekt eller någon form av verksamhetskonsult. Dessa arbetsområden identifierades som lämpliga att beröra för att få en helhetsbild av ämnesområdet kravförändringar. Listan bestod av sex personer som ansågs vara lämpliga att intervjua, d.v.s. de sågs som lämpliga att undersöka för att kunna besvara frågeställningen. Det ska också nämnas att dessa sex personer var nära placerade geografiskt sett. De personer som fanns på listan arbetar på företaget just nu men har också erfarenheter från andra företag. Välj kriterier för urval Ett sätt att välja ut respondenter för undersökningen är att välja personer som det finns en kännedom om som kan ge oss mycket och trovärdig information, d.v.s. personer med god kunskap (Jacobsen, 2002). Med hjälp av handledaren på företaget gjordes ett urval på fem personer som ansågs vara bäst lämpade att intervjua och störst chans att få bra information från. Det utformades också kriterier inför valet av enheter. Dessa kriterier bygger runt erfarenhet och därför förklaras vad erfarenhet innebär i denna studie: o Erfarenhet Erfarenhet i denna studie betyder att det ska finnas en kompetens kring agila systemutvecklingsprojekt, d.v.s. personen har deltagit i agila systemutvecklingsprojekt, denna erfarenhet ska vara flerårig. Detta för att säkerställa att de som deltog var kvalificerade nog. Urvalet gjordes utifrån erfarenhet och kunskap. Detta betyder att det måste finnas ett säkerställande av kunskapen för respondenterna. För studien gjordes ett urval enligt följande utformade kriterier: Respondenten ska ha flerårig erfarenhet av att arbeta i agila systemutvecklingsprojekt. Respondenten ska ha haft någon av rollerna projektledare, utvecklare, arkitekt eller verksamhetskonsult i dessa projekt. Genom att välja fem undersökningsenheter täcktes hela ämnesområdet in, d.v.s. alla roller som ansågs vara nödvändiga för att genomföra studien. Anledningen till att de ansågs nödvändiga var att de projektroller som identifierats, tillsammans med handledaren från företaget, täcker ett stort område av de roller som finns i agila systemutvecklingsprojekt. Hur rollerna ser ut i ett projekt beror på behovet i projektet (Tonnquist, 2014), och genom 15

22 de roller som identifierats ökar chansen att få en helhetsbild kring problemområdet. Den person som inte valdes att genomföra studien hade en liknande roll i jämförelse med en annan analysenhet, dock med mindre erfarenhet. Det var därför en av anledningarna till att det genomfördes en sållning bland respondenterna. Det var också pga. att det inte skulle inhämtas stora mängder data då tidsperioden var begränsad för studien Genomförande Inför intervjuerna som genomfördes skickades det ut information till den berörda respondenten i form av mail. Mailen bestod av information kring vad intervjun skulle beröra för område, så att intervjupersonerna kunde förbereda sig. Dock lämnades inte några förberedande frågor, därför minskade risken för att låsa in intervjupersonen på ett specifikt förberett svar. Mailet innehöll också information om att det var frivilligt att delta. För den intresserade, finns mailhistorik kvar för att stärka detta. Utformandet av intervjufrågorna delades in i temana bakgrund, agila arbetsmetoder i projekt, konkreta projektfrågor och erfarenheter samt egna tankar och idealbilden. Detta var endast för att strukturera intervjun och inte enligt någon teori. Genom att strukturera intervjun fick jag ett enklare sätt att genomföra efterarbetet på, d.v.s. jag kunde lättare urskilja den data som insamlats gentemot de andra temana. Intervjumallens teman användes också när sammansättningen gjordes i empiriavsnittet för att enklare skilja på data. Läsaren hänvisas till bilaga A där intervjumallen samt frågor som varje intervju innehöll återges. Intervjuerna hade syftet att återge så djup information som möjligt, vilket medförde att sättet som intervjuerna genomfördes på var semi-strukturerade. Jacobsen (2002) menar att semistrukturerade intervjuer innebär att det ställs frågor från en intervjumall med öppna frågor. Öppna frågor betyder att det inte ges några svarsalternativ och det finns inga begränsningar för respondenten att svara på frågan. Jacobsen (2002) nämner att om intervjuaren har en för strukturerad intervjuguide så finns risken att det blir alltför komplext och svaren kan bli svåra att analysera. Med semi semi-strukturerad intervju, där deltagaren får prata öppet, dock mot specifika frågor, ökade chansen att få tillräcklig kvalitet och tillräcklig volym av data. Valet att genomföra semi-strukturerade intervjuer gav därför respondenterna möjligheten att ge djupa svar, samt svar som den anser vara korrekta och som stämmer överens med verkligheten. Det ska nämnas att det genomfördes totalt fyra intervjuer, med fem respondenter. Alltså bestod en av intervjuerna av två respondenter. Dock skapades det inga diskussioner eller debatter i den intervjun, som inte heller var syftet. Därför ser jag inte intervjun som en gruppintervju. Anledningen till att de deltog i samma intervju var att de har arbetat tillsammans i många projekt, i olika roller. Detta sågs som något positivt för att få en helhetsbild av genomförda projekt, där undersökaren kunde se projektet från olika perspektiv. Dels var också tidsbrist från deras sida något som också påverkade valet att genomföra detta tillsammans. 16

23 En av intervjuerna var en telefonintervju. Detta genomfördes pga. geografiska skillnader mellan undersökaren och respondenten. Övriga intervjuer är genomförda ansikte mot ansikte. Jacobsen (2002) nämner att fysiska intervjuer är bra för intervjuer med många öppna frågor, och mindre lämpligt i telefonintervjuer. Det är dock lättare att genomföra ett öppet samtal vid fysisk intervju än vid telefonintervju. Jag gjorde därför valet att genomföra alla intervjuer, utom en, med fysisk närvaro. Den intervju som inte genomfördes med fysisk närvaro, d.v.s. telefonintervjun, innehöll istället videokonferens. Detta med anledningen till att inte missa kroppsspråk eller en undanhålla en fysisk, men virtuell, kontakt helt. Alla intervjuer spelades också in med diktafon i samtycke med alla deltagare för att på så sätt kunna bearbeta insamlad data, men också för att kunna fokusera helt på vad respondenten sa. Transkriberingen genomfördes också i ett senare skede där jag lyssnade på vad som sagts, och skrev ner det om sagts. Anteckningar fördes också under intervjun för att lättare kunna återkoppla till det som sagts men också för att ge en chans att förstå mina egna tankar som jag hade mitt under intervjuerna vid ett senare tillfälle. Längden för intervjuerna var mellan 45 och 85 minuter. Transkriptioner finns kvar för granskning. 3.4 Analys Analysen har genomförts enligt olika steg som anges i Jacobsen (2002): Beskrivning Målet för undersökaren i denna fas är att skapa en detaljerad beskrivning av insamlad data. Systematisering och kategorisering Efter genomförd beskrivning genomförs en systematisering och kategorisering av det material som finns i beskrivningen. Kombination Fasen innebär att undersökaren tolkar den data som kategoriserats och se fenomen utöver det som sagts, d.v.s. försöker se nya samband och nyanseringar inom ämnet. Beskrivningen gjordes genom ett antal steg. Det inspelade materialet låg som grund och bidrog till det transkriberade materialet. Att jag transkriberade den datainsamling som genomförts betyder att jag skrev ner det som sagts som i ett dokument. Jacobsen (2002) nämner att en enorm fördel med att transkribera är att vi lättare kan kategorisera och hitta samband i det som sagts i undersökningen. Genom denna transkription skapades sammanfattningar är uppsatsens empiriska data. Systematisering och kategorisering genomfördes genom färgkodning av det som sammanfattats. D.v.s. jag färgkodade de områden som kunde urskiljas i sammanfattningen och bildade på det sättet teman som återfinns i resultatkapitlet (avsnitt 4.2). Att markera text eller skriva en siffra där undersökaren hittar en kommentar som kan delas in i en möjlig kategori anser Jacobsen (2002) är ett mycket effektivt sätt att arbeta och minimerar risken för att missa viktig information samtidigt som att chansen att få med allt nödvändigt ökar. Genom färgkodning ökade möjligheten att inte missa information som samlats in och det blev enklare att försöka se samband i insamlad data. 17