7 Reflektion, kritik och fortsatta studier
7.3 Fortsatta studier
Att utföra kravhantering i utvecklingsprojekt som arbetar efter Scrum är något vi anser vara ett tämligen specificerat område men att möjlighet till fortsatta undersökningar finns. Under studiens gång har det uppkommit nya intressanta områden som skulle kunna ligga till grund för fortsatta studier. Eftersom Arris är ett globalt företag med kontor över hela världen anser vi att det skulle vara av intresse att analysera hur andra kontor inom organisationen arbetar med kravhantering och hur personer med annan kultur, bakgrund och erfarenhet ser på och arbetar med agil kravhantering inom utvecklingsprojekt.
Ytterligare ett område som är av intresse att undersöka är tredjepartsaktörens roll vid utvecklingsprojekt. Eftersom det har i vår studie uppkommit viss problematik när andra aktörer inkluderas i utvecklingsprojekt vore det intressant att undersöka vad som orsakar denna problematik och hur arbetet kan förbättras. Vi har i såväl litteratur som empiri hittat starka kopplingar mellan kund och de som bedriver kravhantering inom agila utvecklingsprojekt. Fortsatta studier skulle kunna undersöka kundens roll i denna process.
59
Det vore även intressant att undersöka hur kravhantering inom andra agila arbetsmetoder bedrivs i praktiken jämfört med vad som står i litteraturen. En jämförelse mellan olika metoder, exempelvis Scrum och Kanban, skulle också vara intressant att undersöka för att se om det finns tydliga skillnader trots att de båda ryms inom den agila arbetsmetodiken. Då det inom litteraturen finns ett uttryckt behov av ytterligare studier som ställer praktik mot litteratur inom området skulle fler liknande studier som denna kunna utföras för att fylla denna kunskapslucka.
Sammanfattningsvis ser vi agil kravhantering som ett relativt brett område där många intressanta studier skulle kunna genomföras. Exempel på vidare frågeställningar vi identifierat är:
Hur ser kravhanteringsprocessen ut i den agila metoden Kanban i jämförelse med kravhanteringsprocessen inom Scrum?
Vilken inverkan har tredjepartsaktörer på agila utvecklingsprojekt?
60
Referenser
Achimugu, P., Selamat, A., Ibrahim, R. & Mahrin, N. M. (2014). A systematic literature review of software requirements prioritization. Information and Software Technology, 56, ss. 568–585.
Ali, N. & Lai, R. (2016). A method of requirements change management for global software development. Information and Software Technology, 70, ss. 49–67.
Aurum, A. & Wohlin, C. (2005). Engineering and Managing Software Requirements. Berlin: Springer-Verlag.
Balaji, S. & Sundararajan Murugaiyan, M. (2012). Wateerfall Vs V-Model Vs Agile: A Comperative Study On SDLC. International Journal of Information Technology and Business
Management, 2(1).
Baruah, N. (2015). Requirement Management in Agile Software Environment. Procedia
Computer Science, 62, ss. 81–83.
Bass, M. J. (2016). Artefacts and agile method tailoring in large-scale offshore software development programmes. Information and Software Technology, 75, ss. 1–16.
Bassil, Y. (2012). A Simulation Model for the Waterfall Software Developement Life Cycle.
International Journal of Engineering & Technology, 5(2).
Bazeley, P. (2009). Analysing Qualitative Data: More Than ‘Identifiying Themes’. Malaysian
Journal of Qualitative Research, 2, ss. 6-22.
Beck, K. et al. (2001). Manifest för Agil systemutveckling. Hämtat från Agile Manifesto http://agilemanifesto.org/iso/sv/manifesto.html Hämtad [2016-04-04]
Bjarnason, E., Unterkalmsteiner, M., Borg, M. & Engström, E. (2016). A multi-case study of agile requirements engineering and the use of test cases as requirements. Information and
Software Technology, 000, 1–19.
Boehm, B. (2000). Requirements that handle IKIWISI, COTS, and rapid change. IEEE
Computer, 33, ss. 99–102.
Bryman, A. (2011). Samhällsvetenskapliga metoder. 2. uppl., Malmö: Liber AB.
Campanelli, S. A. & Parreiras, S. F. (2015). Agile methods tailoring – A systematic literature review. The Journal of Systems and Software, 110, ss. 85–100.
61
Cao, L. C. L., & Ramesh, B. (2008). Agile Requirements Engineering Practices: An Empirical Study. IEEE Software, 25(1), ss. 60–67.
Carrizo, D., & Dieste, O. & Juristo, N. (2014). Systematizing requirements elicitation technique selection. Information and Software Technology, 56(6), ss. 644–669.
Chin, G. (2004). Agile Project Management: How to Succeed in the Face of Changing Project
Requirements. Amacom.
Chow, T. & Cao, D. (2007). A survey study of critical success factors in agile software projects. The Journal of Systems and Software, 81, ss. 961–971.
Daneva, M., van der Veen, E., Amrit, C., Ghaisas, S., Sikkel, K., Kumar, R., Ajmeri, N., Ramteerthkar, U & Wieringa, R. (2013). Agile requirements prioritization in large-scale outsourced system projects: An empirical study. The Journal of Systems and Software, 86, ss. 1333–1353.
De Lucia, A. & Qusef, A. (2010). Requirements Engineering in Agile Software Development.
Journal of Emerging Technologies in Web Intelligence, 2(5).
Dingsøyr, T., Nerur, S., Balijepally, V. & Moe, N, B. (2012). A decade of agile
methodologies: Towards explaining agile software development. The Journal of Systems and
Software, (85), ss. 1213–1221.
El Emam, K. & Koru, A.G. (2008). A replicated survey of IT software project failures. IEEE
Software, 25(5), ss. 84–90.
Elshandidy, H. & Mazen, S. (2013). Agile and Traditional Requirements Engineering: A Survey. International Journal of Scientific & Engineering Research, 4(9), ss. 473.
Erickson, J., Lyytinen, K. & Siau, K. (2005). Agile modeling, agile software development, and extreme programming: the state of research. Journal of Database Management, 16, ss. 88–99.
Gustavsson, T. (2013). Agile: Konsten att slutföra projekt. Karlstad.
Hasnain, E. (2010). An overview of published agile studies: A systematic literature review. In
Proceedings of the national software engineering conference, (3), ss. 1–6.
Hazzan,O. & Dubinsky, Y. (2014). Agile Anywhere, Essays on Agile Projects and Beyond. Springer Briefs in Computer Science.
Henderson-Sellers, B. & Serour, M.K. (2005). Creating a dual-agility method: the value of method engineering. Journal of Database Management, 16, ss 1–23.
62
Highsmith, J. (2002). Agile Software Development Ecosystems. Indianapolis: Pearson Education.
Highsmith, J. & Cockburn, A. (2001). Agile software development. 1. The business of innovation. IEEE Computer, 34, ss. 120–127.
Hossain, E., Babar, A. M. & Paik, H-Y. (2009). Using Scrum in Global Software
Development: A Systematic Literature Review. Fourth IEEE International Conference on
Global Software Engineering.
Huckabee, W. A. (2015). Requiremenrs Engineering in an Agile Software Development Environment. Defense Acquisition Research Journal, 22(4), ss. 394-415.
Hull, E., Jackson, K. & Dick, J. (2011). Requirements Engineering. 3. uppl., London: Springer.
Inayat, I., Salim, S., Marczak, S., Daneva, M. & Shamshirband, S. (2015). A systematic literature review on agile requirements engineering practices and challenges. Computers in
Human Behavior, 51, ss. 915–929.
Larman, C. (2004). Agile and Iterative Development - A Manager’s Guide. Boston, Massachusetts: Addison-Wesley.
Larman, C. & Basili, V. (2003). Iterative and Incremental Development: A Brief History.
IEEE Computer Society Press. (36), ss. 47-56.
Lee, G. & Xia, W. (2010). Toward agile: an integrated analysis of quantitative and qualitative field data on software development agility. MIS Quarterly, 34, ss. 87–114.
Liu, S. (2015). How team risk and planning and control risk moderate the effects of clan and self control on the process performance of IT projects: the perspective of user liaisons.
Information Development, 31(1).
Maiden, N., Jones, S., 2010. Agile requirements: can we have our cake and eat it too? IEEE
Software, 27(3), ss. 87–88.
Martin, R. C., & Martin, M. (2006). Agile principles, patterns, and practices in C#. Pearson Education.
Myers, M. (1997). Qualitative Research in Information Systems. MIS Quarterly, 21(2), ss. 241-242.
63
Myers, M. & Newman, M. (2007). The qualitative interview in IS research: Examining the craft. Information and Organization, 17(1), ss. 2-26.
Orr, K. (2004). Agile requirements: opportunity or oxymoron? IEEE Software, 21, ss. 71–73. Patel, R. & Davidson, B. (2011). Forskningsmetodikens grunder – Att planera, genomföra
och rapportera en undersökning. Lund: Studentlitteratur AB.
Ramesh, B., Cao, L & Baskerville, R. (2010). Agile requirements engineering practices and challenges: an empirical study. Information Systems Journal, 20, ss. 449–480.
Rubin, S. K. (2013). Essential Scrum: A Practical Guide to the Most Popular Agile Process. Upper Saddle River, NJ: Addison-Wesley.
Ryan, G. & Bernard, R. (2003). Techniques to Identify Themes. Field Methods, 15(1), ss. 85- 109.
Schwaber, K. & Sutherland, J. (2013). The Definitive Guide to Scrum: The Rules of the Game. http://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf (Hämtad 2016- 04-22).
Sewell, L. (2012). Agile Software Development. Dehli: Research World.
Sims, C. & Johnson, L. H. (2012) Scrum: A Breathtakingly Bried and Agile Introduction. Dymaxicon.
Söderström, J. (2010). Jävla skitsystem! Hur en usel digital arbetsmiljö stressar oss på jobbet
- och hur vi kan ta tillbaka kontrollen. Publit, Stockholm.
Thurén, T. (2013). Källkritik. 3. uppl., Stockholm: Liber.
Tonnquist, B. (2012), Projektledning. Fjärde upplagan, Stockholm: Sanoma utbildning AB. Trkmana, M., Mendling, J. & Krisper, M. (2016). Using business process models to better understand the dependencies among user stories. Information and Software Technology. 71, ss. 58–76.
Turk, D., France, R. & Rumpe, B. (2005). Assumptions underlying agile software development process. Journal of Database Management, 16, ss. 62–87.
VerisonOne. (2013). 7th Annual State of Agile Development Survey. Hämtat från http://www.versionone.com/pdf/7th-Annual-State-of-Agile-Development-Survey.pdf (Hämtad 2016-04-22).
64
Williams, M. (2000). Interpretivism and generalisation. Sociology. 34, ss. 209-224. Zave, P. (1997). Classification of Research Efforts in Requirements Engineering. ACM
Computing Surveys, 29(4), ss. 315‐321.
Åsberg, R. (2001). Det finns inga kvalitativa metoder - och inga kvantitativa heller för den delen. Den kvalitativa-kvantitativa argumentets missvisande retorik. Pedagogisk Forskning i
65
Bilagor
Dessa bilagor är de som ligger till grund för den insamling av empiri som har ägt rum. Varje intervjuguide är specifik för den roll som intervjuobjektet har i sitt arbete till vardags. Flertalet frågor är samma för alla intervjuobjekt samtidigt som det finns mer rollspecifika frågor. Intervjuerna som har genomförts har varit av semi-strukturerad karaktär och därmed ska dessa intervjuguider endast ses som riktlinjer för intervjun. De formulerade frågorna har därmed i vissa fall formulerats om och nya frågor har tillkommit under intervjuernas genomförande. Intervjuerna varade i snitt i en timme och spelades in via två mobiltelefoner och dess
inspelningsfunktion. Respondenterna kommer att vara anonyma i det att endast deras roll på företaget anges.
66
Bilaga 1: Intervjuguide - Produktägare
Bakgrundsfrågor
1. Vad är din befattning?
2. Hur länge har du arbetat på Arris och hur länge på din nuvarande position? 3. Kan du beskriva vad du arbetar med?
4. Vad har du för utbildning?
Frågor
Vad innebär kravhantering för dig?
Hur ser arbetet med kravhantering ut för din del? Berätta gärna utförligt om hur du arbetar med krav och så vidare.
Var kommer kraven ifrån?
Hur ser kontakten ut med kund/marknad/säljare?
Hur realiserar ni de krav som samlas in?
Hur ser kontakten/samarbetet/relationen ut med andra inom företaget vad gäller ditt arbete med krav? (Systemarkitekten, mjukvaruutvecklaren & projektledaren)
Vem har du mest kontakt/arbetar du främst med i kravhanteringsprocessen? Hur ser detta arbete ut?
De krav som du tillsammans med kund/marknad/säljare tar fram. Hur står de sig under arbetets gång? Ändras de?
Om kraven ändras, hur arbetar du för att möta dessa förändringar?
Var/hur samlar ni de krav som tas fram? I ett system? Vilket? Beskriv gärna systemet/systemen som ni arbetar med.
Vad är viktigast i kravhanteringen enligt dig när man arbetar agilt? Varför? Utveckla gärna utförligt.
Vilka svårigheter/problem kan uppkomma i ditt arbete med kravhantering?
Varför har ni (företaget) valt Scrum som arbetsmetod?
Följer ni det som står om Scrum i teorin/litteraturen?
Vad ser du för problem och fördelar med den valda metoden.
Hur tycker du personligen att det är att arbeta agilt med kravhantering?
Hur tycker du personligen det är att arbeta med Scrum? Är det en bra metod att arbeta efter i din roll på företaget?
67
Bilaga 2: Intervjuguide - Systemarkitekt
Bakgrundsfrågor
1. Vad är din befattning?
2. Hur länge har du arbetat på Arris och hur länge på din nuvarande position?
3. Kan du beskriva vad du arbetar med?
4. Vad har du för utbildning?
Frågor
Vad innebär kravhantering för dig?
Hur ser arbetet med kravhantering ut för din del? Berätta gärna utförligt om hur du arbetar med krav och så vidare.
Hur ser kontakten/samarbetet/relationen ut med andra inom företaget? (Produktägaren, mjukvaruutvecklaren & projektledaren)
Vilka arbetar du främst med i din roll som systemarkitekt?
Du tar emot kravspecifikationen från produktägaren. Hur interagerar ni tillsammans och hur jobbar ni med de krav som finns specificerade?
Utifrån den kravspecifikation du tar emot. Formulerar du om de kraven? Hur går det arbetet till? Vilka/vem samarbetar du med i detta arbete?
Var/hur samlar ni de krav som du tar emot? I ett system? Vilket? Beskriv gärna systemet/systemen som ni arbetar med.
Hur vet ni att kravställningen är uppfylld när ni anser att ni är klara? Projektet avslutat, produkten släppt.
Vad är viktigast i kravhanteringen enligt dig när man arbetar agilt? Varför? Utveckla gärna utförligt.
Vilka svårigheter/problem kan uppkomma i ditt arbete med kravhantering?
Varför har ni (företaget) valt Scrum som arbetsmetod?
Följer ni det som står om Scrum i teorin/litteraturen?
Vad ser du för problem och fördelar med den valda metoden.
Hur tycker du personligen att det är att arbeta agilt vid arbete med kravhantering?
Hur tycker du personligen att det är att arbeta med Scrum? Är det en bra metod att arbeta efter i din roll på företaget?
68
Bilaga 3: Intervjuguide - Utvecklingschef &
Mjukvaruutvecklare
Bakgrundsfrågor
1. Vad är din befattning?
2. Hur länge har du arbetat på Arris och hur länge på din nuvarande position? 3. Kan du beskriva vad du arbetar med?
4. Vad har du för utbildning?
Frågor
Vad innebär kravhantering för dig?
Hur ser arbetet med kravhantering/krav ut för din del? Berätta gärna utförligt om hur du arbetar med krav och så vidare.
Hur ser kontakten/samarbetet/relationen ut med andra inom företaget? (Systemarkitekten, produktägaren & projektledaren)
Vilka arbetar du främst med i din roll som mjukvaruutvecklare?
När du tar emot de krav som ska uppfyllas, hur går arbetet till när de sedan bryts ner till uppgifter?
Vem är ansvarig för att kraven/uppgifterna uppfylls?
Hur delar ni upp kraven/uppgifterna mellan er utvecklare?
Hur verifierar ni att kraven verkligen är uppfyllda?
Var/hur samlar ni de krav som ni tar emot? I ett system? Vilket? Beskriv gärna systemet/systemen som ni arbetar med.
Vad är viktigast i kravhanteringen enligt dig när man arbetar agilt? Varför? Utveckla gärna utförligt.
Vilka svårigheter/problem kan uppkomma i ditt arbete med kravhantering?
Varför har ni (företaget) valt Scrum som arbetsmetod?
Varför har ni (företaget) valt den metoden?
Följer ni det som står om Scrum i teorin/litteraturen?
Vad ser du för problem och fördelar med den valda metoden?
Hur tycker du personligen att det är att arbeta agilt vid arbete med kravhantering?
Hur tycker personligen att det är att arbeta med Scrum? Är det en bra metod att arbeta efter i din roll på företaget?