Examensarbete på kandidatnivå, 15 hp
Systemvetenskapliga programmet med inriktning mot design, interaktion & innovation
UTMANINGAR I
KRAVHANTERING INOM
AGILA IT-PROJEKT
Identifiering av förekommande
utmaningar och vad som ligger
till grund för dessa
”Vi vill tacka vår handledare Henrik Wimelius som stöttat oss och varit vår högra hand genom studien. Vi vill samtidigt ägna ett stort tack till vår uppdragsorganisation XLENT Sundsvall och speciellt vår kontaktperson Johan Moritz som med sin kompetens
Abstract
Many IT-projects becomes complicated to an unnecessary level since the requirements hasn´t been worked through correctly. In fact, bad requirements engineering is one of the most expensive errors within IT-projects. This thesis presents a qualitative study on the challenges associated with requirements engineering in the context of agile software development. The reason for that, is because challenges in the requirement process in traditional IT-projects are well-known. But they are less known within agile IT-projects. The purpose is therefore to gain knowledge so that the study can help and inspire upcoming IT-projects so that success is easier to achieve in the future. The study is performed together with an IT-consultant company which seeks to find answers and solutions to this complex process. The methods used to collect data in order to create more ground for the subject is done through qualitative interviews and through one observation.
Today we can display the evidence of what kind of challenges that exists and potentially how to avoid them during the beginning-face of a project. The result show tendencies of challenges that stands in the way for successful end-results within the requirement engineering area in agile IT-projects. The main findings are three major categories of challenges in agile IT-projects that are enriched with earlier research within the subject of the study. These challenges can cause even bigger issues if not considered correctly in the planning process before the start of a project. The project will demand more resources in order to reach completion and a successful product for the customer.
Innehållsförteckning
1. INLEDNING ... 1
1.1PROBLEMFORMULERING ... 2
1.2SYFTE ... 2
2. RELATERAD FORSKNING ... 3
2.1KRAV & KRAVHANTERING I IT-PROJEKT ... 3
2.2AGILA PROJEKT ... 5
2.3KRAVHANTERING I AGILA PROJEKT ... 6
3. METOD ... 9 3.1METODVAL ... 9 3.2DATAINSAMLING ... 11 3.2.1 Observationer ... 11 3.2.2 Intervjuer ... 12 3.3URVAL... 14 3.4DATAANALYS ... 15
3.5BEGRÄNSNINGAR &FORSKNINGSETISKT FÖRFARANDE ...18
1. Inledning
Krav, vilka utformas av behov läggs till grund för att en systemutvecklingsprocess ska kunna genomföras och bli så lyckad som möjligt. En väl utförd kravhantering är avgörande, det är inte alltid projekt lyckas och det är ofta bristande kravhantering som ligger till grund för det (Eriksson, 2008). Det finns flertalet faktorer och anledningar till detta, bland annat värdet av förberedelse innan ett projekt (Robertson & Robertson 2013). När den levererade produkten inte motsvarar förväntningarna hos beställaren blir projektet mer kostsamt i både tid och pengar för båda parterna och projektet kan anses misslyckat. Det är ofta förekommande att IT-projekt och dess resultat inte uppfyller de krav eller behov som beställaren ställt eller försökt ställa. Det kan röra sig om att utvecklingen och förvaltningen av systemet blir dyrare än väntat och det resulterar i att kund och användarna inte blir nöjda (Eriksson, 2008). Det är därför viktigt att utföra kravhantering med mycket kunskap i bakgrunden samt omvårdnad.
Inom IT-projekt återfinns vanligtvis en kund och en leverantör, dessa beskriver inom vilka ramar projektet ska vara. De här rollerna ser dock inte alltid samma behov, svårigheter kan därför uppstå i kravställningen då leverantör och kund har olika intressen (Gustavsson, 2016). De två olika parterna kan alltså med andra ord ha varierande prioriteringar av krav, kund är expert gällande sin egen organisation och utformar krav därefter. Samtidigt är leverantör mer specialiserad gällande teknik och vad ett väl fungerande system är. Denna form av problematik inom kravhanteringen i IT-projekt är omfattande, det kan handla om utspridda intressen som beskrivits ovan, men även att de olika aktörerna inte är tillräckligt insatta i varandras vardagliga arbete. Kund kan utforma och ställa krav på egen hand, även leverantören kan bli ansvarig för att utforma kraven. I många fall arbetar de båda parterna tillsammans och således läggs ansvaret på dem båda. Det är av stor vikt att leverantören förstår kundens arbetsprocesser och således deras behov. Samtidigt som det underlättar otroligt om kunden har förståelse för IT (Gustavsson, 2016; De Lucia & Qusef, 2010). Kravhanteringen är alltså en komplicerad process som bör beaktas i allra högsta grad.
2016). Ett agilt arbetssätt gör organisationen mer flexibel och lösningar blir lättare att hitta på ett effektivt sätt (Gustavsson, 2016). Tidigare forskning har företrädesvis fokuserat till stor del på att undersöka effekten av ett agilt arbetssätt kontra ett mer traditionellt arbetssätt, samt existerande brister i kravhanteringen i det traditionella arbetssättet. Mer aktuell forskning inom agil projektledning framhäver däremot mer förekommande även utmaningar och brister inom agil kravhantering. Avgörande faktorer kan bestå av resurser, bristande planering och dokumentation. Noterbart är dock att det finns en större brist av forskning som explicit undersöker kravhantering i agila kontexter. Vilket därför behandlas i denna uppsats i större utsträckning.
1.1 Problemformulering
De agila arbetssättet är en framgångsrik och hyllad projektmetodik, många anser att det är det sätt man bör sträva efter att använda då formen adresserar förändring på ett effektivt sätt. Men det agila arbetssättet är inte heller helt felfritt. Dessa metoder anses vara lösningen på många utmaningar (Gustavsson, 2016), samtidigt som problematik ändå existerar i viss utsträckning. Projekt har fortfarande en tendens att misslyckas (Wiktorin, 2018), kan bristande kunskap gällande utmaningar i agil kravhantering vara anledningen till varför många IT-projekt fortfarande inte räknas in som lyckade? Finns det ytterligare fallgropar i de agila arbetssättet, gällande kravhantering, än vad som tidigare visats i forskning?
Detta har undersökts genom en djupdykning i vad som gör det agila arbetssättet så framgångsrikt, och utifrån det undersöka vad som ligger till grund för misslyckande. Detta eftersom att många IT-projekt, trots ett agilt arbetssätt, faktiskt fortfarande misslyckas i viss utsträckning. Detta utfördes genom tidigare, relaterad forskning inom området, samt genom en kvalitativ studie där undersökning gällande vad individer, verksamma inom krav och IT-systemutveckling, faktiskt tycker och vad de anser ligga bakom problemen i kravhanteringsprocessen i agila projekt. Frågeställningen lyder:
• Vilka utmaningar uppstår inom ramarna för kravhantering i agila utvecklingsprojekt?
I denna studie används begreppet utmaningar, vilket i denna kontext ska tolkas som problem eller hinder.
1.2 Syfte
Som tidigare nämnts är det många projekt som misslyckas på grund av att kravhanteringen missköts av flera anledningar, både i traditionellt utförda projekt och i agila projekt. Syftet med studien är att skapa djupare kunskap om vilka utmaningar kring kravhantering som uppstår i agila projekt samt varför och hur dessa materialiseras och potentiellt adresseras. Ett bidrag till högre fokus på kravhanteringen i agila projekt är viktigt, speciellt eftersom forskning inte existerar i lika stor utsträckning gällande det givna området. Det är av stor betydelse att utförandet av kravhanteringen är ordentligt och noggrant gjort, därför finns det ett ytterligare behov av kunskap och förståelse för att i överlag göra processen enklare att lyckas med i framtiden.
produceras genom att göra denna studie kommer förhoppningsvis lägga grunden till en bättre förståelse kring kravhantering i agila projekt. Genom att lägga fokus på utmaningar kan en ny dörr öppnas inom detta område och att kunskapen nyttjas så att färre projekt misslyckas.
I samarbete med ett IT-konsultföretag har vi forskare haft möjligheten att följa kravhanteringsprocessen i agila projekt, samt fått goda förutsättningar för att samla in data. Syftet är således även att bistå dem med ny kunskap för att underlätta deras framtida kravarbete.
2. Relaterad forskning
I denna sektion görs en redogörelse över definitionen krav och kravhanteringens betydelse i IT-projekt utifrån tidigare forskning. Vidare tydliggörs det även mer specifikt för hur krav hanteras i agila projekt, samt om kända fallgropar i den agila kravhanteringen.
2.1 Krav & kravhantering i IT-projekt
Alla har vi varit med om att ställa någon typ av krav på saker och ting. Det kan handla om att ställa ett krav till kocken på hur välstekt min köttbit ska vara, eller att ställa ett krav på att butiker måste sälja ekologiska varor för att jag ska handla där.
Detta är exempel på hur ordet krav oftast upplevs och vilken betydelse det kan ha. Eftersom att studien ämnat undersöka kravens betydelse i IT-projekt, studerades litteratur som behandlar krav utifrån det perspektivet. Begreppet krav är ett mångfacetterat begrepp som inrymmer en mängd olika definitioner. Standarden IEEE 610.122-1990 beskriver ett krav utifrån ett IT-perspektiv genom tre punkter:
1.A condition or capability needed by a user to solve a problem or achieve an objective.
2.A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents.
3.A documented representation of a condition or capability as in (1) or (2).
Dessa tre punkter beskriver grundläggande vad ett krav innebär rent generellt och de kan likväl appliceras på vad ett krav innebär i ett systemutvecklingsprojekt. Det beskrivs att ett krav är innebörden av det tillstånd som krävs för att en användare ska kunna lösa ett problem eller uppgift, vilket är en tydlig beskrivning av hur krav bör uppfattas.
Krav delas upp i tre olika typer, funktionella, icke-funktionella och situationskrav (Sawyer et al., 2007). Där funktionella krav exempelvis kan vara att när en kund loggar in i systemet ska denne välkomnas med ett personligt meddelande. Ett funktionellt krav är alltså ett krav på systemets funktionalitet. Ett icke funktionellt krav är istället krav på systemets egenskaper såsom prestanda, tillförlitlighet och säkerhet. Det sistnämnda, situationskrav syftar istället till att fastställa val av utvecklingsmetoder, utvecklingsmiljö och andra krav som tider och budget exempelvis.
formuleras behov som sedan måste mötas av ett flertal lösningar. För att uppfylla dessa lösningar formuleras till sist krav. Wiktorin (2018, 193) använder sig av ett ordspråk; som man frågar får man svar. Det han menar är att arbetet med krav och hur dessa formuleras är betydande för hur lyckat ett IT-projekt blir. Det finns även ett samband som ser ut så här: Intressent → Mål → Behov → Krav → IT-system (Wiktorin, 2018). Krav är alltså en
del i en stor process, en mycket betydande del i arbetet.
Som tidigare nämnts i inledningen är en väl utarbetad kravbild avgörande för hur lyckat och framgångsrikt ett systemutvecklingsarbete blir. Wiktorin noterar att det finns många svårigheter med arbete inom IT-utveckling och att kravhanteringen är ett centralt problem. Ett exempel på en vanligt förekommande utmaning som kravhanteringen i IT-projekt för med sig är att “den första kravspecifikationen är sällan mer än 50 procent fullständig” - (Wiktorin, 2018, 193). Vilket innebär att kravarbetet ständigt måste prioriteras och finnas med genom projektets gång. Det kan även leda till en otydlig bild av vad som faktiskt ska produceras. En ytterligare, välkänd utmaning, är att god kravhantering i IT-projekt oftast kräver en hög nivå av samarbete mellan de olika intressenterna vilka är inblandade i systemets uppbyggnad och som i ett senare skede använder systemet. Anledningen till detta är att en bra relation och en bra kommunikation mellan intressenterna leder till färre missförstånd samt att oklarheter kan redas ut på ett mer effektivt sätt. Hög nivå av samarbete mellan kund och leverantör är alltså avgörande (Holtkamp et al., 2015). Det är heller inte tillräckligt att endast hitta, formulera och dokumentera krav. Det är viktigt att hela tiden arbeta med att prioritera, spåra och ändra dem under arbetets gång. Till slut måste man även klargöra att slutresultatet uppfyller de krav man satt (Wiktorin, 2018).
Eriksson (2008) anser att kravhanteringen är en omfattande process och att hela arbetet med krav genomgår flera steg. Han använder en unik metod för att beskriva kravhanteringsprocessen som kallas “Stjärnan”. Den består av de olika stegen; samla in,
strukturera, prioritera, dokumentera, kvalitetssäkra, och förvalta krav. Dessa steg sker
inte sekventiellt, istället för att göra varje steg färdigt innan man går vidare till nästa steg, arbetar man med flera av stegen samtidigt. Kravhanteringsprocessen är väldigt tidskrävande och att arbeta steg för steg gör processen ännu långsammare. För att uppnå högre effektivitet arbetar man därför ofta iterativt med kravhanteringsprocessen (Eriksson, 2008).
När det kommer till utveckling av IT-system har denna process historiskt sett alltid tagit form innan projektets start, krav fastställs och sedan strävar man efter att följa dem genom projektets gång (Wiktorin, 2018). Att arbeta på detta sätt kan upplevas som icke-flexibelt och kan vara en av många faktorer till varför kravhanteringen är en orsak till att projekt misslyckas. I de mer moderna utvecklingsmetoderna, de agila metoderna, så som exempelvis i Extreme Programming (t.ex. Beck & Andres, 2005) och i Scrum (t.ex. Vanderjack, 2015), utförs kravarbetet mer kontinuerligt och iterativt genom hela projektet, vilket innebär att tidigare ställda krav återbesöks. Till skillnad från de mer traditionella utvecklingsmetoderna där kravhanteringsarbetet ofta har en start- och slutpunkt, arbetar man här med kraven genom hela projektet (Gustavsson, 2016). Fördelen med detta kan vara att kraven kan styras och ändras genom projektets gång om oförväntade händelser dyker upp, det är alltså ett mycket mer flexibelt sätt att genomföra IT-projekt på.
vara att systemet inte blir klart i tid, det blir mer kostsamt och kunden blir missnöjd. En korrekt kravhantering är således avgörande för hur lyckat ett IT-projekt blir, därför är det viktigt att denna omfattande del får tillräckligt med tid och att arbetet utförs på ett riktigt och korrekt sätt i alla IT-projekt och i alla organisationer. Goda krav är väldigt betydande och ett helt projekt och dess slutprodukt kan stå lutandes mot dem. Kraven lägger grunden för systemets totala kvalitet (Holtkamp et al., 2015).
Flertalet forskare och författare belyser problem som bristande kravhantering i IT-projekt, vilket redovisats ovan. De bryter även ner problemet i mindre delar och belyser aspekter som tidsbrist, bristande kommunikation och samarbete, för låg flexibilitet och att kund inte riktigt vet vad dem egentligen vill ha.
2.2 Agila projekt
Att vara agil eller att arbeta agilt i projekt innebär i stora drag att man kan leverera i en snabb takt samt att förändringar är lätta att göra (De Lucia & Qusef, 2010).I agila projekt skiljer sig, som tidigare nämnts, arbetssättet jämfört med i projekt där traditionella metoder som vattenfallsmetoden tillämpas (t.ex. Gustavsson, 2016). Det finns även olika agila tillvägagångssätt, exempelvis Scrum och Extreme Programming. Genom en agil projektform kanske inte systemet kan levereras snabbare än om en traditionell projektform tillämpas, men ett viktigt delmål uppnås här. Delmålet i fråga handlar om möjligheten att kunna leverera en del av systemet i ett tidigt skede. Detta för att kunna gå genom test så att kund kan avgöra om projektet är på väg åt rätt håll och att deras krav efter behov möts (Wiktorin, 2018).
Det flesta agila utvecklingsmetoderna bygger på ett antal grundläggande principer, dessa bör tillämpas för att det agila tillvägagångssättet ska vara så effektivt som möjligt (Gustavsson, 2016). Dessa ska även efterlevas för att följa värderingarna som finns i det agila manifestet (Gustavsson, 2016). Principerna berör för det mesta begreppen programvara och utvecklare i dess ursprungsform, detta på grund av att de är formulerade av metodutvecklare som är aktiva inom IT. Dock är det möjligt att ersätta begreppen mot något mer generellt som projektresultat och projektdeltagare. Flexibilitet inom olika områden är alltså fullt möjligt. De generaliserade agila principerna ser ut som följande (Gustavsson, 2016):
1. Lägga högt värde i projektresultat.
2. Värdera förändring i krav även sent i utvecklingsprocessen. 3. Leverans av projektresultat som är användbara.
4. Kompetenta projektdeltagare.
5. Engagemang hos individer i projektet. 6. Bra kommunikation inom projektgruppen.
7. För att nå framsteg krävs användbara projektresultat. 8. Hållbarhet, alltså hålla ett jämnt tempo genom projektet.
9. Uppmärksamhet över nya innovationer som levereras kontinuerligt. 10. Hålla saker enkla.
Förändring och flexibilitet utmärker agila projekt, alla projekt utsätts för förändring under tid och att detta kan skapa problem då det i många fall blir svårt att uppdatera och ändra i planeringen (Gustavsson, 2016). I ett agilt arbetssätt ligger arbete i korta sprintar i fokus, dessa är ofta kortare än en månad vilket medför att förändrade planer och krav kan mötas på ett effektivare sätt. Allmänt i projekt anses det vara väldigt viktigt med en hög grad av beställarmedverkan, vilket är lättare att lyckas med i agila projekt. Detta är möjligt eftersom att resultat levereras i korta sprintar, vilket medför att kunden lätt kan komma in med åsikter efter varje leverans. Till skillnad från vattenfallsmodellen, vet beställaren i agila projekt att den kan påverka och förändra och tydliggöra krav vid varje sprint. Detta gör att flexibiliteten blir högre, vilket är fördelaktigt då krav och mål nästan alltid förändras över tid i alla IT-projekt. Att arbeta agilt är alltså ett bra tillvägagångssätt för att lättare uppnå ett mer lyckat slutresultat i IT-projekt (Gustavsson, 2016). Även om det existerar brister inom agil systemutveckling.
Paquette & Frankl (2016) styrker även dem att ett agilt tillvägagångssätt i organisationer är avgörande för att leverera framgångsrika produkter. Agila metoder höjer prestandan i IT-projekt genom intressenternas återkoppling som ingår i det agila arbetssättet. Agila metoder ger också organisationen en konkurrensfördel samtidigt som riskerna sänks på grund av att verksamhetens värde ökas kontinuerligt genom hela projektlivscykeln. Det finns en stor mängd fördelar med agila metoder, genom agila projekt blir större delar av organisationer förstärkt gentemot om ett traditionellt tillvägagångssätt hade använts.
Det är betydande att arbeta agilt idag då alla verksamheter och projekt verkligen måste vara flexibla. Det går det nästan aldrig att förutspå framtiden för projekt. Detta eftersom att vi lever i en värld som präglas av ständig förändring och innovation. Detta leder till en ökad komplexitet i hur projektarbete måste bedrivas för att kunna möta dessa krav. För att lyckas på ett framgångsrikt sätt är ett agilt arbetssätt att föredra, enligt Project Management Institute Corporate Author (2013).
Existerande forskning lyfter fram många fördelar med agila metoder, exempelvis att dylika ökar graden av motivation i utvecklingsteam (Chin, 2013). Detta, kombinerat med hur ett agilt projekt bedrivs, kan öka chanserna till att kravställningsarbetet och hela projektet underlättas. Eftersom projektgruppen är mer positivt inriktade och har en hög kreativitet, blir arbetet mer genomarbetat och problem kan lättare förebyggas. Vilket minskar risken för uppkommande problem och ökar chanserna till ett mer lyckat resultat. Det finns många anledningar att fatta tycke för det agila sättet att arbeta på då inte minst den betydande kravhanteringen går att utföra på ett mer effektivt sätt. Flertalet författare (t.ex. Gustavsson, 2016; Chin, 2013; Paquette & Frankl, 2016) understryker att ett agilt arbetssätt underlättar kravhanteringen och att det således är lättare att lyckas med projekt.
2.3 Kravhantering i agila projekt
upp kundens krav på produkten, vilket kan försvåras om förändringar inte möts på ett bra sätt. Att arbeta agilt ger bättre förutsättningar för att lyckas med förändring i projekt och med kravhanteringsprocessen i stort och således att kunna möta upp kundens ställda krav. I figur 1 visas kostnadskurvor vid kontinuerliga förändringar av krav under ett projekts gång i traditionella- och i agila projekt. Kurvorna visar tydligt att ett agilt arbetssätt är mer flexibelt och mer fördelaktigt i en kravhanteringskontext (Duka, 2012).
Figur 1. Kostnaden av kravförändringar under projektets gång (Duka, 2012).
Idag ser man ett mönster i att krav mer förekommande inte är fastställda i början av ett agilt projekt och att de tydliggörs mer under fortsättningen projektet samt att det dyker upp fler med tiden (Cao & Ramesh, 2008). Det skapas alltså endast en övergripande bild av det framtida systemet och vilka de kritiska delarna påstås vara. Anledningen till detta tankesätt grundas i att tid inte skall gå till spillo i ett tidigt skede. Detta tillämpas för att övergripande krav anses otydliga, samt att ingen tydlig kunskap kring tekniken för utvecklingen existerar och kunden hävdar ofta att de kommer upptäcka resterande krav i utvecklingsprocessen.
Vid agila kravhanteringsprocesser talar man om utvecklingssprintar (Cao & Ramesh, 2008). Vid starten av de enskilda sprintarna träffar kunden utvecklingsteamet eller leverantören. Vid dessa möten delges ytterligare information angående funktioner leverantören konstaterar måste innefattas för en fungerande produkt. Diskussion mot mer tydliga krav påbörjas också på dessa möten samt att mer designfrågor besvaras. Resultatet av detta är att mer finkorniga krav framställs vilket framhäver bilden av resultatet på ett mer tydligt sätt.
Tidigare har vi nämnt att det agila arbetssättet i IT-projekt är fördelaktigt av flera anledningar, inte minst kravhanteringen påverkas på ett positivt sätt. Då en hög nivå av agilitet välkomnar förändring gör det att kravhanteringen övergår till att vara mer flexibel, speciellt i jämförelse med i de traditionella metoderna. Trots de övervägande fördelarna existerar det även i dessa metoder fallgropar och utmaningar. Kostnad och schemaläggning är två aspekter som kategoriseras mer förekommande som utmaningar i agila projekt (Cao & Ramesh, 2008). Dessa utmaningar uppstår i till följd av att ingen formell kravhanteringsprocess följs av de två parterna: kund och leverantör, istället estimeras planeringen i form av user stories. Dessa user stories kräver förnyelse under tid då de anses vara otillräckliga när projektet sträckt sig längre in i utvecklingen.
applikationen uppstår. Vid bristfällig dokumentation vid något av dessa tillfällen kan en rad problematiska incidenter uppstå. Det kan vara väldigt allvarligt och projektet kan gå förödande konsekvenser till mötes. Inom agila projekt finns det en stor risk att detta problem uppstår, vilket signalerar om att kravhanteringen i agila projekt kan vara utmanande (Lindblom et al., 2017).
Ytterligare en utmaning i agila projekt är att projektgruppen ofta är för stora. På grund av att den traditionella synen på projektformen i viss mån lever kvar, består projektgruppen ibland av ett för högt antal individer. Agilitet står för flexibilitet och kontinuerlig kommunikation mellan olika intressenter, vilket enligt statistik inte fungerar i samma utsträckning i större agila projektgrupper (De Lucia & Qusef, 2010).
Diagram 1 visar på storlekens betydelse i agila projektgrupper (De Lucia & Qusef. 2010).
3. Metod
Att forska kring kravhantering i agila projekt var ett beslut som togs i första hand av oss men även i samverkan med en IT-konsultverksamhet. De såg ett behov av att reda ut befintliga problem med krav i IT-projekt då de anser att bristande kravhantering leder till onödiga kostnader och tidsfördröjningar. Denna verksamhet har cirka 40 anställda, varav ett flertal är inriktade och arbetar dagligen med krav. Detta har under hela arbetet varit fördelaktigt då vi kunnat närvara på kravmöten, haft intellektuella diskussioner samt haft kunniga deltagare involverade genom hela studien.
Företaget arbetar ständigt med kravhantering i IT-projekt och har erfarenhet av det, vilket har givit upphov till att identifiera utmaningar gällande kravhantering i agila projekt. Detta för att kunna presentera vad som ofta brister och eventuellt vad som bör utföras för att undvika fallgroparna för de som arbetar inom företaget, men även för andra verksamheter vilka arbetar med krav. Denna studie har därför varit givande för oss författare och förhoppningsvis även för uppdragsverksamheten. Kravhantering inom IT-system förhåller sig inom informatikämnets ramar och av dessa anledningar har detta samarbete varit passande.
I en studie är data och datainsamling grunden till hela resultatet. I en kvalitativ studie, som vi valt att utföra, är intervjuer, observationer, insamling samt granskning och känslointryck vanliga exempel på datainsamlingstekniker (Yin, 2013). I denna studie har vi valt att samla in data, främst genom intervjuer och observationer. Hela processen startade med att vi utförde observationer, dessa gjordes i samband med kravhanteringsmöten mellan uppdragsverksamheten och kunder. Dessa analyserades sedan för att framställa en övergripande bild av hur kravhanteringsprocessen fungerar. Efter detta utfördes sedan sju intervjuer med olika deltagare vilka arbetar och är kunniga inom området. Intervjuerna, likt observationerna, analyserades i ett senare skede för att söka svar på den givna forskningsfrågan.
3.1 Metodval
Inom forskningsmetodik existerar två kategorier, kvalitativ eller kvantitativ (Keegan, 2009). Kvantitativa forskningsansatser är rimliga att använda när syftet för studien handlar om att ta reda på vad en viss folkmängd tycker om exempelvis en viss produkt. Poängen är att kunna generalisera från en statistiskt säkerställd grupp till en större grupp, exempelvis en hel befolkning. För att säkerställa ett resultat söker man efter distinkta svar från en större mängd personer för att sedan kunna se vad just den folkgruppen tycker. Typiska karaktärsdrag för kvantitativ forskning är enligt Repstad (1993) att dessa studier ofta omfattar ett stort antal deltagare, innehåller noggrant förberedda frågor samt mindre flexibilitet för förändring.
19) styrker dessa synpunkter, han väljer även att “definiera” denna typ av forskning genom olika karaktärsdrag, han menar att kvalitativ forskning;
1. studerar den mening som kan tillskrivas människors liv under verkliga förhållanden
2. återger de människors åsikter och synsätt som ingår i studien 3. täcker in de sammanhang och omständigheter människor lever i
4. ger insikter om rådande och framväxande begrepp som kan förklara mänskligt socialt beteende
5. strävar efter att använda många källor i stället för en enda typ av belägg.
Kvalitativa och kvantitativa studier skiljer sig alltså väsentligt på många punkter. Det är däremot vanligt att kvantitativ forskning utförs och att den läggs till grund för en studie, och att man sedan styrker resultatet ytterligare genom att utföra kvalitativ forskning (Yin, 2013).
I denna studie har vi författare valt att utföra enkvalitativ studie med fokus på framför allt intervjuer och observationer. Detta då vi anser att det lämpar sig bäst utifrån den givna frågeställningen; att problematisera och identifiera de främsta utmaningarna inom kravhanteringsprocessen i agila IT-projekt, samt vad som potentiellt orsakar dessa utmaningar. För att lyckas besvara dessa frågor och således få ett lyckat studieresultat, behöver djup kunskap produceras, vilket görs genom att samla deltagarnas åsikter utifrån deras erfarenheter. När det rör sig om grundläggande eller särpräglade insikter inom ett specifikt område samt över hur tinget har utvecklats över tid, är det essentiellt att utföra observation och kvalitativa intervjuer. Detta utifrån att intresset för hur ofta något förekommer eller hur vanligt det är, inte är det som eftersöks i huvudsak. Utan enligt kvalitativa mått rör det mer det som faktiskt redan finns (Repstad, 1993). Då kvalitativ forskning lämpar sig vid undersökning av ett fenomens egenskaper är denna forskningsansats passande (Widerberg, 2002).
Visserligen finns det begränsningar inom kvalitativ forskning och de metoder vi tillämpat. Kvalitativa metoder medför i regel en mycket högre tidsåtgång än vid kvantitativ forskning, de är även ofta mer kostsamma att utföra (Maher & Dertadian, 2018). Detta grundar sig exempelvis i att en dialog och diskussion kräver mer tid än helstrukturerade intervjuer, vilka ofta används i kvantitativa studier. Givet den befintliga tidsomfattningen för denna studie var detta en tydlig begränsning i valet av forskningsmetod. De tidskrävande intervjuerna resulterade i sju till antalet, vilket eventuellt kunde blivit fler vid val av annan forskningsansats givet den totala tiden vi erhöll för denna studie.
3.2 Datainsamling
I denna sektion redogörs de datainsamlingstekniker som används i denna kvalitativa studie, samt att vidare ges motivering kring varför just de valen gjorts.
3.2.1 Observationer
Observationer kan vara en ovärderlig metod för att samla data. Detta på grund av att man använder sina egna sinnen för att förstå och det man registrerar är helt ofiltrerat (Yin, 2013). Ofiltrerat i bemärkelsen att ingen annan sett, hört och känt det du faktiskt upplever under observationen. Observationer ses som ett tillvägagångssätt där forskaren förhåller sig fullt ut passiv.
Yin (2013) beskriver också vikten av medvetenheten i dina egna beslut och att förstå dess konsekvenser. Det som observeras och dokumenteras behöver inte vara det viktigaste som händer i situationen. Här gäller alltså att vara uppmärksam på en större del av fältmiljön. Detta kan fångas upp genom noteringar kring tid och plats för observationerna och även inkludera vilka deltagare som finns på fältet. Det rekommenderas också att göra en kortare notering som beskriver händelsen som observeras. Det kan också anses som fördelaktigt att göra en allmän bedömning innan observationen och efter det schemalägga de tillfällen då observationer utförts.
Det är betydande att observera rätt saker i denna aktivitet, samtidigt som det är viktigt att inte missa betydande faktorer. Alltså att hålla utkik efter mer än bara verbala reaktioner, det är det som kan vara av värde för ämnet i den kvalitativa forskningen. Det kan röra sig om gester och icke-verbala beteenden. Handlingar och händelser kan även ha betydande roll i en observation. Det är också viktigt att lägga värde i omgivningen och att lägga en fokus på visuella och ljudmässiga kännetecken (Yin, 2013).
Det finns fyra vitala roller en forskare kan inta i samband med utförandet av observationer (Baker, 2006). Den första kallas “non-participation” och innebär att man helt enkelt inte alls deltar i vad de involverade personerna faktiskt gör. “Observer-as-Participent” är den andra rollen, vilken beskrivs som mer observerande än deltagande (Baker, 2006). Den tredje rollen kallas “moderate membership”. Här innebär det att forskaren faktiskt är en aktiv deltagare i observationen. Den sista identifierade rollen kallas för “complete observer”, den här rollen är lik non-participation-rollen i det att forskaren har en passiv roll i observationen. Skillnaden mellan de två rollerna är att “complete observer” befinner sig på platsen där observationen sker, dock förs inget deltagande från forskaren.
var att endast en observation utfördes vilket utgör att utvunna data inte kan återspegla ett faktum kring hur kravhantering i agila IT-projekt går till.
Tabell 1. Tabellen beskriver samtliga deltagare i observationen med referens och deras roller.
I tabell 1 ovan framgår de olika deltagarna i förhållande till rollerna vilka befanns sig på mötet. Mötet varade ungefär i en timme och 15 minuter och innehöll en genomgång från leverantör och kund i projektet och deras egna uppfattningar över vad som bör finnas i åtanke för utvecklingen. Mötet startade med att leverantörerna visade upp hur produkten såg ut för tillfället, detta i och med att ett förslag hade levererats från kund vid ett tidigare tillfälle. Under det här tillfället ber de kunden komma med vidare synpunkter och låter dem föreslå förändringar och tillägg. Med tiden tar projektledaren ansvar att visa upp den dåvarande kravlistan som de tillsammans gick igenom punkt för punkt.
Det fanns två mål med observationen, dels att utvinna mer kunskap över hur ett sådant möte går till och dels för att samla underlag för att kunna besvara den givna frågeställningen.
3.2.2 Intervjuer
Att utföra intervjuer innebär att man samlar in information genom kommunicering med ett antal intressenter för att besvara det man undersöker. Man kan dela upp intervjuformen i strukturerade, ostrukturerade samt halvstrukturerade intervjuer (Yin, 2013).
Strukturerade intervjuer innebär att en person intervjuar en deltagare med stöd av ett väldigt detaljerat manus. Detta medför att intervjun följer ett antal frågor och att intervjuaren på ett formellt sätt vill ta fram svar från intervjupersonen (Yin, 2013). Fördelarna med denna typ av intervju är att den ofta är effektiv och systematisk. Strukturerade intervjuer kan också vara lönsamt i en tidsaspekt om tanken är att samma frågor ska ställas till flera personer (Eriksson, 2008). Nackdelarna är istället att intervjun blir väldigt oflexibel, vilket kan leda till att viktig och relevant information utelämnas.
att styra intervjun i rätt riktning så att icke-relevanta ämnen lämnas utanför. Även dokumentationen kan bli bristande.
Det finns även en intervjuform som placerar sig mellan strukturerade och ostrukturerade intervjuer, dessa kallas halvstrukturerade intervjuer. Det innebär att intervjuaren använder ett manus som stöd för frågor, men att man samtidigt kan komplettera med öppna frågor och även mer öppna svar från intervjudeltagaren. Denna typ av intervju är vanligt förekommande vid insamling av krav då den stora fördelen är att dessa, trots att det existerar en struktur, blir mer flexibla än strukturerade intervjuer. En viktig aspekt när denna form används är att inte förlita sig och följa sitt manus till punkt och pricka. För att uppnå flexibilitet bör även frågorna och samtalet förbli flexibla (Eriksson, 2008).
Kvalitativa intervjuer skiljer sig rejält från de strukturerade intervjuerna och dessa är den helt klart vanligaste formen i kvalitativ forskning (Yin, 2013). Det påminner om den strukturerade intervjun då intervjuaren här inte följer manus i samma utsträckning, istället finns syftet och målet som underliggande vetskap hos intervjuaren. Vid kvalitativa intervjuer är det viktigt för intervjuaren att vara väldigt fokuserad så att de varierande intervjuerna kan förstå det deltagarna berättar. Något som vidare utmärker denna typ av intervju är att frågorna och samtalen är öppna, detta för att få ut deltagarnas egna ord och tankar i så hög grad som möjligt. Magnusson och Marecek (2015) styrker tesen om att kvalitativa intervjuer bygger på öppenhet. Det unika med dessa är även att deltagaren kan ställa motfrågor till intervjuaren (Yin, 2013). Nackdelen med denna typ av intervjuer är att de är betydligt mer tidskrävande än strukturerade intervjuer.
Ostrukturerade och halvstrukturerade intervjuer går hand i hand med vad kvalitativ forskning innebär, med exempel på öppna frågor och dialoger. Kvalitativa intervjuer är den bästa formen att använda för att förstå och ta in vad människor verkligen tycker och står för, att få fram känslor och åsikter utifrån deras egna erfarenheter (Magnusson & Marecek, 2015). Det finns flera viktiga aspekter att ha i åtanke när man ska utföra kvalitativa intervjuer (Yin, 2013). Det första är att som intervjuare inte tala för mycket, utan låta deltagaren få ordet i största utsträckning. Intervjuaren ska inte heller vara alltför styrande, utan istället försöka förbli så neutral som möjligt. Det är viktigt att upprätthålla en bra relation med deltagarna för att få så riktiga och trovärdiga svar som möjligt. Trots att man utför en kvalitativ intervju som anses vara ostrukturerad bör ett intervjuprotokoll finnas som stöd för intervjuaren. Slutligen är det fördelaktigt att analysera vad deltagaren säger medan intervjun fortlöper.
att viktiga frågor exkluderas under vissa intervjutillfällen då dialogen är relativt öppen och kan styras åt olika håll (Repstad, 1993). Vidare eftersom att kvalitativa intervjuer, i synnerhet ostrukturerade, är väldigt öppna kan det leda till att fokus hamnar på fel frågor vilket försämrar värdet av det som samlas in givet studiens frågeställning och syfte. Som tidigare nämnts är kvalitativa intervjuer tidskrävande vilket även var en begränsning då antalet intervjuer blev relativt litet, givet tidsomfattningen.
Alla intervjuer som utförs skiljer sig från varandra, då det stora målet med en kvalitativ intervju är att uppnå ett öppet samtal med varje deltagare. Intervjuprocessen genomfördes med hjälp av ljudinspelning som verktyg för att i ett senare skede kunna transkriberas och skapa fundament till analysfasen. Deltagare samt roll kopplade till respondenterna har konkretiserats i tabell 2 nedan. Referering används för att binda respondenten till de påståenden som är kopplade till dem, detta går att utläsa i referensspalten inom parentesen.
Tabell 2. Tabell som beskriver samtliga respondenter i intervjuerna med referens och roller.
Relaterad forskning och den genomförda observationen lade grunden till frågorna i intervjuerna. Ett löst manus innehållandes riktlinjer som stöd genom intervjuerna skapades. Detta gav oss och respondenterna möjligheten till interaktiva diskussioner. Vi som intervjuare följde Yin’s (2013) fem ståndpunkter om att “tala måttligt mycket”, “var
inte styrande”, “förbli neutral”, “upprätthåll en god relation” samt “använd ett intervjuprotokoll”. Intervjuer utfördes på sju olika respondenter vid olika tillfällen där alla
innehar rollen som IT-konsult, däremot arbetar de inom olika specialistområden. Samtliga respondenter har erfarenhet och arbetar aktivt med kravhantering i IT-system. Omfånget på respektive intervju varierade men den genomsnittliga längden var cirka 30 minuter. Den kunskap som fångats genom dessa aktiviteter ansågs värdefulla i relation till den givna frågeställningen för studien. Det som undersökts är utmaningar inom kravhanteringen i agila IT-projekt, vilket tillsammans med grundläggande kunskap underlättade intervjuerna genom att lättare rikta dem mot vad som eftersöktes.
3.3 Urval
som vid namn kallas avsiktliga urval, bekvämlighetsurval, snöbollsurval och
slumpmässiga urval. De olika namnen för metoderna talar ganska tydligt om hur urvalen
går till, med undantag för snöbollsmetoden. Att göra urval för sin studie genom ett snöbollsurval innebär att man väljer deltagare som blivit rekommenderade av tidigare deltagare i studien. De urval som görs ska helst spegla det bredaste skalan av information kring studiens ämne och av den anledningen är detta ett viktigt beslut för studien (Yin, 2013).
De urval vi tillämpat är en kombination av ett avsiktligt urval, bekvämlighetsurval och ett snöbollsurval. Vi har utifrån tillgänglighet från uppdragsgivaren avsiktligt valt deltagare till vår studie, men där de första deltagarna tipsat och lett oss vidare till andra deltagare med erfarenhet och kompetens inom området. De avsiktligt valda deltagarna är individer med lång erfarenhet vilka besitter mycket kunskap givet studiens område. Urvalen präglades som nämnt i viss utsträckning av bekvämlighet, vilket kan begränsa studiens trovärdighet. Den urvalskombination som vidtogs grundar sig i avsiktliga urval vilket i sin tur tagit oss vidare, genom rekommendationer, till individer vilka också besitter hög nivå av kunskap och erfarenhet inom området. Trots att bekvämlighets- och snöbollsurval kan ifrågasättas är dessa i detta fall pålitliga i hög utsträckning. Genom kommunikation mellan oss och uppdragsorganisationen skapades en tydlig bild över deltagare som skulle inkluderas i forskningen. Denna kombination av urval är därför rimlig utifrån förutsättningarna och tillgångarna.
3.4 Dataanalys
När det kommer till analys av den insamlade kvalitativa data, gäller det att inte nöja sig för snabbt med de resultat man fått in. Här handlar det om att kritiskt granska den rådata som samlats. Det här görs för att upptäcka nya dimensioner i svaren och nya kategorier bör utformas för att kunna tyda svaren ännu bättre (Larsson, 1986). Det viktigaste verktyget som bör användas i analysen är jämförelsen mellan olika svar. Jämförelsen i det här fallet gör att arbetet går framåt och skapar en förståelse samtidigt som de mer subtila skillnaderna kommer fram.
En observation utfördes under studiens gång, denna utfördes i samband med ett kravmöte mellan kund och leverantör, där flera individer innehavandes olika roller närvarade. De observerade ombads att hålla deras möte precis som om vi inte var där. Som forskare hade vi rollen att endast observera, ta anteckningar och även att spela in deras samtal. Mötestillfället blev vi informerade om innan och därför fanns vetskap över att innehållet skulle handla om kraven för ett system.
Observationen analyserades i förhållande till de fem steg som beskrivits ovan. Efter mötet sammanställdes anteckningar och inspelningen, vilken senare transkriberades. Dessa organiserades i nästa skede för att vidare ta analysen framåt. Genom detta bröts sedan data ner i mindre delar för att här ta fram värden kopplade till säregna meningar utifrån den kodade data som framställts. Detta följdes upp av remontering av data. Under denna fas sattes koder ihop utifrån olika mönster som uppmärksammades genom iterationer av demonteringen och slutligen remonteringen. Efter tre varv av iterering framställdes till sist olika teman vilka var tydlighet, förberedelser, kunskap,
kommunikation samt intresse. Dessa var satta i en kontext i meningen att de uppkommer
både i en positiv och negativ utsträckning. En slutgiltig tolkning utfördes och fragment till en slutsats kopplat till studiens syfte uppdagades.
Den totala analysen grundar sig alltså i en observation och i de sju utförda intervjuerna. Kvalitativa intervjuer är, som tidigare nämnts, den huvudsakliga datainsamlingstekniken som använts i denna studie. Analys av insamlade data utfördes även här med stöd av Yins (2013) analytiska ramverk.
Vi som forskare skiftade mellan våra roller vid de olika intervjutillfällena, rollerna innebar att vara mer eller mindre ledande samt att anteckna och observera. Transkribering gjordes av oss forskare tillsammans för att skapa en tydlig struktur samt effektivitet. Detta utfördes manuellt av oss forskare för att senare komma i bruk vid analysfasen. Transkripten framställdes i takt med att varje intervju utfördes, vilket resulterade i ett underlättat arbete då den insamlade informationen var aktuell vid varje transkriberingstillfälle. Tydliga radbrytningar och numreringar utgjorde att transkripten kom att bli väldigt överskådliga och lätthanterade. Ord och andra inslag som exempelvis “mmh” och “eeh” vilka användes i ett överflöd av nästan samtliga deltagare och även av oss forskare utelämnades från transkripten i de lägen de inte ansågs relevanta och tillförande till studien. Andra inslag som känsloutspel och stämningsbilder noterades där de uppstod vilket underlättade för oss forskare att sätta oss in i varje unikt intervjutillfälle.
Manipulation av data kan förekomma omedvetet, medvetenhet bör därför beaktas kring den data som samlas in från intervjuer då manipulation ska undvikas till högsta grad (Denscombe, 2018). Specifika meningar och uttryck kan påverkas av transkribering i det utförandet att de anses praktiskt taget osynliga i textform (Denscombe, 2018). Detta anses ha beaktats då insamlad data tagits väl hand om, samt att beskrivningar kring uttryck har gjorts för att bevara det ursprungliga värdet i informationen.
sin form, det som sedan följde var att varje sammansatt text bröts isär och delades upp i olika stycken, kopplade till varje unik kategori som kom att framställas vid intervju ett.
Kategorierna framställdes genom att likheter eftersöktes utifrån alla svar från de sju respondenterna, dessa kom även att influera resterande intervjuer. Kategorierna tydliggjorde uttalanden från intervjuerna vilka skrevs in i ett Excel-ark. De kategorier som framställdes var utmaningar, förutsättningar samt mål. För att tydligt följa dessa genomsöktes transkripten i förhoppning att identifiera svar på den givna frågeställningen.
Syftet med att framställa kategorier var att hitta gemensamma uttalanden kopplade till studiens frågeställning för att skapa en helhet av de totala svaren utifrån respektive respondents åsikter och svar. Detta gjordes för att sammanfatta och addera liknande stycken med varandra för att i ett senare skede underlätta arbetet med resterande del av analysen. Syftet var även att genom dessa kategorier anpassa studiens innehåll efter vad som ansågs relevant. Utöver kategorierna framställdes sedan nyckelord från de relevanta citaten, genom färgkodning. Syftet med färgkodning var att skapa tydlighet och underlag för nästkommande fas. Denna fas itererades ett flertal gånger vilket resulterade i att onödig information utelämnades och relevanta data uppdagades. Fasen i fråga motsvarar Yin’s (2013) andra steg kallad demontering.
Fas tre innebär remontering, där nyckelorden som framställts genom iteration av demonteringsfasen placerades in under respektive kategori. Dessa applicerades och behandlades i ett Excel-ark för att skapa enhetlighet och tydlighet. Varje kategori fylldes med en mångfald av nyckelord trots att dessa remonterades i detta skede. Dessa gav upphov för vidare tolkning. Tolkning är en av de viktigaste delarna i analysen, det kan anses som ett hantverk. För att tolka på ett korrekt sätt bör fem kriterier uppfyllas, dessa är;
fullständighet, skälighet, empirisk korrekthet, mervärde och trovärdighet (Yin, 2013).
Tolkning var en del av hela analysarbetet från start till mål.
Genom hela analysprocessen, alltså genom de tydligt utförda stegen där kategorier samt nyckelord brutits ut och identifierats, utfördes vidare tolkning av information i enlighet med de fem kriterier som nämndes ovan. Baserat på det som hittills framställts kunde flertalet faktorer urskiljas, vilka varierade mycket och uppkom i stor omfattning. Den enhetlighet som går att urskilja från alla deltagare är att kravhanteringen fungerar betydligt bättre i agila projekt, men att det existerar vissa utmaningar. Utmaningarna inom kravhantering, tolkad från insamlade data, anses vara många, samtidigt som korrelationer gick att tyda mellan dem. Ett utdrag från respondent 4 (R4): “ja det kan det absolut, att
dem blir överarbetade och att det är ju alltid så svårt att hitta det här good-enough för att alla vill ju göra så bra ifrån sig och ingen vill lämna ifrån sig något som är halvfärdigt...”. Här svarar R4 på frågan och belyser överarbete av krav som ett problem i
agila IT-projekt. I likhet med denna svarar R7 att det finns en risk för överarbete, hen säger: “att man liksom inte känner att nu är vi klar någon gång. För att man kan alltid skruva
på någonting mer liksom.” Dessa två uttalanden är jämförbara och kan placeras under
överarbete. De sju olika respondenternas svar och definitioner skiljer sig i flertalet
aspekter, men kan i många fall knytas och korreleras i form av de tre huvudfaktorerna som tagits fram. Det analysarbetet framställde korrelerar samt skapar tydligt uppsåt till uppbyggnaden av dessa tre specifika huvudkategorier av utmaningar som identifierats. Ansenligen kan dessa faktorer ses som extensiva till en positiv nivå. Mer övergripande vad dessa utmaningar innebär och behandlar redogörs i resultatsektionen.
De begränsningar som kan anses existera inom denna analys är att en minoritet av data inte faller under de givna huvudkategorierna och har därför utelämnats ur analysen och studien (Yin, 2013). En kvalitativ studie och således en kvalitativ analys begränsas i att en specifik mängd inte kan styrka att dessa utmaningar uppkommer i flera fall på ett empiriskt sätt. Studien är baserad på ett unikt fall vilket således begränsar resultatet. Vidare kunde eventuellt en ytterligare analysmetod ha nyttjats för att således lägga en starkare grund för analysen.
3.5 Begränsningar & Forskningsetiskt förfarande
Uppdragsorganisationen har under studiens gång varit väldigt hjälpsamma och tillgängliga. De har givit oss råd och ställt upp vid de olika aktiviteterna vi utfört på ett mycket tillfredsställande sätt. Det som begränsat oss gällande datainsamling är dels den relativt korta tidsramen vi haft, men även att uppdragsorganisationen är ett företag med cirka 40 anställda och därmed inte har kapacitet att erbjuda oss tid för exempelvis workshops. En observation och sju intervjuer har utförts, anledningen till det specifika antalet är dels att det är rimligt för vår studie, men även att uppdragsorganisationen inte haft möjlighet att tillstå oss mer. För att förtydliga detta vill vi lyfta att detta inte varit till någon nackdel, uppdragsorganisationen har verkligen mött våra tänkta behov och de aktiviteter vi utfört är väl utförda med kompetenta personer.
Studien följer även de forskningsetiska principer från vetenskapsrådet (2002) inom humanistisk-samhällsvetenskaplig forskning. Dessa principer och krav finns till för att forskning är viktigt för att ett samhälle och dess individer ska utvecklas samtidigt är det väldigt viktigt att följa för att skydda individer från bland annat psykisk eller fysisk skada. Det handlar om fyra olika krav som ska följas och i sin tur även regler. Kraven är informationskravet, samtyckeskravet, konfidentialitetskravet och nyttjandekravet. Dessa är konkretiserade på åtta olika regler. Informationskravet går hand i hand med den första regeln som pekar på vikten av tydlig information som ska framgå från forskaren till undersökningsdeltagare. Det är viktigt att upplysa detta och även att deltagandet är frivilligt och att det går att avbryta sin medverkan när som helst. Informationen i fråga ska innehålla allt som kan komma att påverka deltagarens villighet att delta i studien.
eller påverkan om de väljer att delta eller avsluta sin medverkan, bör också undvika beroendeförhållanden mellan forskaren och deltagare.
Konfidentialitetskravet byggs på två regler och omfattar vikten av största möjliga konfidentialitet över personens uppgifter i undersökningen och även att de personuppgifter som inkommer måste förvaras så att obehöriga ej kan ta del av dem. Alltså handlar regel fem om användningen av etiska uppgifter som anses känsliga. Tystnadsplikt ska därför förbindas till identifierbara personer i studien. Regel sex innebär värdet av att uppgifter om identifierbara personer ska antecknas, lagras och slutligen avrapporteras, detta för att dessa personer inte ska kunna bli identifierade av utomstående personer.
Slutligen skriver vetenskapsrådet om nyttjandekravet, denna existerar i syftet att insamlad data endast ska användas till forskningsändamålet. Det här kravet konkretiseras av regel sju och åtta. Dessa två regler täcker saker som att uppgifter som samlats under undersökningen/studien inte får användas eller utlånas till kommersiella bruk och inte heller andra syften som inte rör vetenskapen. Personuppgifterna det rör sig om får heller inte brukas i syftet om beslut eller åtgärder som påverkar den enskilde direkt.
Applicering av dessa principer har gjorts genom hela datainsamlingen. Detta i form av tydliggörelse över den deltagandes rättigheter i studien. Vi har innan intervjuerna och observationen informerat dem kring anonymitet och rätt att avbryta när de själva känner för det.
4. Resultat
I denna sektion redogörs och visas de resultat som producerats från analysen av empiriska data. Här redovisas alltså resultatet av data insamlat från observationer samt intervjuer. Observationen resulterade i en betydligt tydligare bild över hur kravhanteringen i ett agilt IT-projekt kan utformas. Att få bevittna ett möte gällande kravhantering och hur det utspelar sig i praktiken i ett konkret projekt mellan kund och leverantör resulterade i en ökad förståelse. Observationen var väldigt givande som ett underlag för det fortsatta arbetet i studien, samt för att vidare kunna besvara frågeställningarna på ett lämpligt sätt. I och med att detta var ett ömsesidigt agilt fungerande projekt resulterade det i att vi kunde relatera informationen direkt till vår studie samt att detta gav underlag att bygga vidare på inför kommande aktiviteter.
Utifrån analysen av empiriska data, identifierades tre primära kategorier av utmaningar.
4.1 Agil obalans
Utifrån analyserade, insamlade data har agil obalans skapats som en kategori av utmaningar i relation till kravhantering i agila IT-projekt. Vad detta begrepp innebär i denna kontext är kortfattat att det ofta existerar en obalans i nivå av agil mogenhet mellan de olika intressenterna, kund och leverantör. Denna typ av komplexitet som återfinns i agila IT-projekt är en bidragande faktor till varför problem kan uppstå samt till att projekt misslyckas.
sig vara en bidragande faktor till detta var att många leverantörer och kunder för den delen gärna uttalar sig och vill vara agila i hög grad, och att det i denna situation kan uppstå förvirring och oklarheter hur det gemensamma arbetet ska fortlöpa. R3 uttrycker sig:
”...satt även om, många vill ju kalla sig agila men det är inte alltid man i praktiken är så agil satt”. I denna kontext beskriver R3 att detta kan leda till att kravhanteringen påverkas
negativt då exempelvis leverantör vill arbeta väldigt tätt och enligt de agila principerna, samtidigt som kund vill arbeta mer traditionellt och fastställa kraven tidigt för att sedan gå vidare. R3 uttrycker vidare att: “ibland så har det ju varit att man kanske bestämmer sig
för att vi ska jobba agilt men omgivningen är inte agil och då blir det lite bara på låtsas alltså”. R3 menar på att detta bland annat leder till för få “feedback-loopar”, att kraven
återbesöks för sällan. Vilket blir problematiskt då leverantör vill förankra och förtydliga under projektet gång.
En agil obalans mellan kund och leverantör är onekligen problematiskt, R5 styrker detta genom att berätta att “...det finns ju sådana som alltså i ett omoget agilt projekt då kan
man ta som ursäkt att för att jag inte behöver bestämma mig”. Det som komplicerar vägen
till ett lyckat projekt i det här fallet är att kund beskriver sig vara agila och att de bestämmer att projektet ska influeras av ett agilt arbetssätt i hög grad, men att de i själva verket inte arbetar på det sättet som förväntas och istället skapas en obalans. När detta uppstår kan kravhanteringen i projektet upplevas instabil, vilket i sin tur bidrar till en ökad problematik då leverantör vill komma framåt på ett sätt och kund på ett annat. R3 och R5 upplever, i vår tolkning, samma utmaning men i en olik kontext, vilket ger intryck för att detta är något som bör beaktas.
Om en ett agilt arbetssätt tillämpas bör alla intressenter arbeta efter likgiltiga principer för att undvika att projektet blir haltande. En obalans mellan kund och leverantör är skadligt för projektet och således slutprodukten. R6 säger däremot att: “delvis kan man ju
jobba agilt fast än resten inte gör det. Men väldigt mycket blir ju haltande”. Hen menar
på att en obalans kan mötas upp med att båda parter sköter sin del av uppdraget på sitt sätt i viss utsträckning utan att det fallerar totalt. Men som R6 säger ordagrant, mycket blir ju haltande. En kund som är omogen i sitt agila arbetssätt kan bevisligen medföra utmaningar. Ett projekt där ett agilt arbetssätt tillämpas är beroende av att rätt personer besitter rätt roller. R6 uttrycker sig vidare: “om du tar en PO (product-owner) som inte
alls vill vara involverad i processen och bara vill haspla ur sig “one-liners” så vill man få det gjort då kan det ju bli jättesvårt och få en sån verksamhet att fungera”. Även detta
grundar sig i obalans i hur olika intressenter uppfattar hur ett agilt projekt ska bedrivas. Denna form av problematik kan uppstå genom att de olika parterna ingår i en medveten “överenskommelse” om att arbeta agilt, och att det i ett senare skede visar sig att den agila nivån är ojämn mellan dem. Av naturliga skäl kan agil obalans befinna sig redan innan projektets start då vetskap om att exempelvis kund inte har erfarenhet av IT-projekt och framför allt inte av en agil arbetsform. R2 säger; “...man är inte van å jobba med
kravställning mot IT-system.”. Det R2 menar i sammanhanget är att det saknas kunskap
Samtliga respondenter (1–7) påvisar och uttrycker i viss utsträckning att agil obalans är något som kan vara en negativ bieffekt, till följd av ett agilt arbetssätt. R2, R3, R5 samt R6 ger exempel och uttrycker sig tydligt kring både medveten och omedveten agil obalans, vilket är bevisat tidigare i texten. Vikten av dessa uttalanden kombinerat med den tolkning som utförts visar på att agil obalans är en existerande och betydande utmaning inom agila projekt gällande kravhantering.
4.2 Bristande struktur
En mängd uttalanden från respondenterna ligger till grund för uppkomsten av kategoriseringen bristande struktur. Mindre samt obundna kategoriseringar har skapats inom denna utmaning och där kan det röra sig om dålig planering, bristfällig dokumentation eller fokus på fel saker. Dessa är alla bidragande till en stor utmaning vilken ökar risken för att misslyckas med kravhantering i agila projekt.
Påvisning på uttalanden som tillför utmaningen bristande struktur är som tidigare nämnt många, här uppvisas några av dessa. R3:“...ett exempel på sånt som inte fungerar
och att man kanske sitter på möten och diskuterar saker men man diskuterar inte rätt prylar liksom, kan vara lite såhär det finns väl begrepp såhär cykelställsbegrepp så här diskussion att man har en tendens att vilja diskutera sånt som man känner till å de man inte det man tycker är svårt och komplext det undviker man så istället för å liksom ta itu med dom riktigt jobbiga problemen så pratar man om vilken färg vi ska ha på cykelskjulet liksom” här har vi ett påstående som tydligt påvisar fokus på fel saker, alltså
bristande struktur. R3 menar på att detta är en vanligt uppkommande utmaning i kravhantering idag. Hen anser även att det är ett allvarligt problem och att det kan skapa stor oreda i projektet man befinner sig i.
Ett uttalande från respondent 4 uppmärksammas då det specifikt beskrivs utmaningar rörande kategorin bristande struktur, och då speciellt värdet av dokumentation. Uttalandet i fråga: ”... det är ett annat sätt å jobba på men visst har väl det också sina problem att
det kanske kommer in nån ny eller så då finns det inte dokumenterat utan då sitter det liksom i teamets huven vad som är gjort...” (R4). Detta tyder på ännu ett allvarligt problem
som kan uppstå i agila projekt i kravhanteringsfasen. Värdet av dokumentation belyser sig självt i uttalandet och risken om en deltagare i teamet försvinner tillfälligt anstiftar till att ytterligare problem uppstår. Den här nämnda utmaningen är därför allvarlig då hela projektet kan bli lidande. Här görs därför en tydlig markering för värdet av dokumentation för att uppnå tydlig struktur. Specifika problem i ett agilt arbetssätt kan enligt R3 också vara att dokumentation utelämnas eller blir bristfällig. Mer specifikt innebär det att dokumentation ofta inte utförs i samma utsträckning som i de traditionella metoderna. Problemet innebär även att den dokumentation som existerar blir väldigt utspridd, vilket är tidsödande och leder till förvirring eftersom att “får man lägga ett pussel som
utvecklare”. R3 ser även en risk i att ett agilt arbetssätt kan leda till dålig struktur eftersom
att “vid agil får du göra vad du vill...,”. Hen menar att “om man implementerar en agil
process på fel sätt så då är det ju kasst”. Uppenbarligen har R3 erfarenheter där utveckling
av IT-system i agila projekt varit bristande på flera vis.
Vikten av kundens förarbete uppdagades då det i tidigt skede kan skapa oreda och struktur i ett tidigt skede, detta är något som påpekas av R1“...en industriell ekonom har ju
kanske inte är så lätt att översätta för en utvecklare sen…”. Det respondenten menar på
här är att det ibland i projekt kan röra sig om att fel personer har fel roller. Som uttalandet säger så är det enklare för utvecklarna att begripa kraven då de är formulerade på ett språk som anses mest tydligt för dem. Bristande struktur uppstår då utvecklarna får en otydlig kravspecifikation vilket resulterar i en otydlig målbild, vilket skadar planeringen i ett agilt projekt.
Dessa uttalanden och erfarenheter uppmärksammas i olika utföranden men från alla sju respondenter. De uttalanden som visas upp i denna resultatdel är de som vi anser väger tyngst för att beskriva problematiken eller utmaningen kopplat till kravhantering. De faktorer som summerar bristande struktur är framför allt bristande dokumentation, utebliven planering samt att fokus lätt kan glida iväg på fel saker. Vi vill samtidigt inte nonchalera de uttalanden som kan anses som mer kryptiska, då dessa kan vara mest värdefulla. De kryptiska uttalandena är därför fullt inkluderade i vår resultatdel. Vi har därför valt att sätta bristande struktur som en huvudsaklig utmaning då det i mångt och mycket nämnts av alla respondenter i olika utföranden. I detta skapas en tydlig bild över vikten av tydlig struktur i agila projekt och dess kravhantering.
4.3 Överarbete
Denna definition framställdes i relation till att majoriteten av respondenterna påvisade och uttryckte bevis för olika former av onödigt arbete i agila IT-projekt. Överarbete i den här kontexten innebär att ett agilt arbetssätt i vissa fall kan leda till att tid och kapital spenderas på onödigt arbete gällande kravhanteringen. Bevisen till detta är flera, vilket redovisas nedan.
Enligt R7 finns det en risk för överarbete i agila projekt, hen uttrycker “...att man liksom
inte känner att nu är vi klar någon gång. För att man alltid kan skruva på någonting mer liksom”. Hen menar att det finns en risk för överpolering av kraven i agila projekt och att
lösningen på detta är att det måste finnas riktlinjer för vad som bör prioriteras. Det måste finnas en gräns för hur mycket arbete som bör läggas på att förfina och definiera krav i agila projekt. R7 uttrycker vidare: “...Men finns det oändligt mycket tid och oändligt mycket
pengar då kan ju folk sitta å jobba hur länge som helst med samma sak ... bollen blir inte rundare hur länge man än håller på med att försöka få den rund”. Ett agilt arbetssätt
tillåter förändringar och är en flexibel metod, vilket i många kontexter är positivt. Däremot beskriver R7 i det här fallet att flexibiliteten kan nyttjas på fel sätt och överarbete av krav uppstår. Både R4 och R7 är eniga om att ett agilt arbetssätt kan medföra längre kravhantering i form av överarbete. Respondent 4 lyfter följande i denna kontext: “...dem
blir överarbetade och att det är ju alltid så svårt att hitta det här good-enough för att alla vill ju göra så bra ifrån sig och ingen vill lämna ifrån sig något som är halvfärdigt...”. I
den här synvinkeln uppstår överarbete i form av att kravställare har svårt att färdigställa kraven, då ett agilt arbetssätt välkomnar förändringar uppstår överarbete då kraven förfinas allt för återkommande och ofta. Denna synvinkel ligger i enlighet med vad både R4 och R7 tycker. Även R2 ställer sig bakom dessa uttalanden och påstår att överarbete av kraven inte är fördelaktigt. R2 citerar: “...Så att överarbeta en kravbild det kan vara i ja
med både R4 och R7, men att det samtidigt måste finnas en balans mellan över- och underarbete i relation till vad det unika projektet handlar om.
Överarbete är något som alla vill undvika då det innebär merkostnader och kan leda till misslyckanden. Det finns enligt respondenterna olika ingångar på hur överarbete uppstår. Det kan som R2, R4 och R7 menar på ske av den anledningen att onödigt mycket resurser och tid läggs på att ställa kraven. Det kan däremot även uppstå genom att alldeles för lite tid läggs på att ställa dem. Ytterligare en respondent, R6, ger sin syn på detta: “Ja men ett
vanligt problem är att man får en väldigt otydlig beskrivning och så försöker man bryta ner det till någonting och så säger man: är det de här du vill ha? ja. sen när man väl har kommit så långt så att man har gjort någonting så och visar. Nej men det var inte det vi ville ha…”. Här fångas ett problem upp som nämns av R6 där bristande kravarbete uppstår,
vilket i sin tur kan skapa överarbete. Det skapas överarbete på det viset att om ett resultat från utvecklingen uppvisas och inte stämmer överens med kundens förväntningar tvingas projektet gå tillbaka och på så vis förlora tid. Utmaningen berör mest kunden då denne bör ha en tydlig idé och kravställning för att skicka vidare idén till utvecklingsfasen. Något som bör noteras är att krav under projektets gång kan och bör enligt de agila principerna förfinas och förändras i viss mån, så att stora förändringar kan undvikas och således även överarbete vid omstart. Här kan ett påstående uppmärksammas med innebörden att kunden har ett stort ansvar i agila projekt och då speciellt i kravhanteringen, i anseende att minimera överarbete och på så sätt sänka kostnaden för slutprodukten.
Digniteten av agil balans uppdagas här, vilket kräver precision för att uppnå då alla projekt ser relativt olika ut. Det vi ser här då är att överarbete kan ha många olika skepnader. Från att kravhanteringen ska vara ordentligt planerad för att inte skapa överarbete till att inte överarbeta kraven då det nästan alltid ändras över tid i ett agilt projekt. Tydlighet uppfinns i resultatet och detta kan summeras som en allvarlig utmaning då överarbete skapar onödiga kostnader i både tid och pengar, vilket ingen kund vill slösa med. Planering som även nämndes i bristande-struktur-delen bör även beaktas i denna del för att minimera riskerna för överarbete. Samt att hitta punkten då produkten faktiskt är klar så att man inte försöker “polera” vidare på den, då detta oftast orsakar förseningar.
5. Diskussion
I relation till den givna frågeställningen har tre huvudsakliga kategorier av utmaningar identifierats inom kravhantering i agila IT-projekt. Det som framför allt har legat till grund för framtagandet av dessa utmaningar är insamlade data och vår analys som influerats av Yin’s (2013) fem faser. De utmaningar som identifierats och framställts är agil obalans,
bristande struktur samt överarbete, vilka grundar sig i flertalet underaspekter som
