Kravhantering vid agil mjukvaruutveckling är en utmaning som allt fler företag ställs inför.Prototyper, modeller som liknar tilltänkta slutprodukter, kan användas för att inhämtaviktig information om det som ska utvecklas. För att beskriva hur lik en prototyp är dentilltänkta slutprodukten används begreppet verklighetsfaktor. Studiens syfte är dels attöka kunskapen kring prototypanvändning i agil mjukvaruutveckling, dels att undersökavilken effekt en prototyps verklighetsfaktor har då prototyper används i diskussioner inomkravhantering. En fallstudie görs på företaget Exsitec där personal intervjuas angående prototypanvändning i mjukvaruprojekt. Två prototyper utvecklas sedan med låg respekti-ve hög verklighetsfaktor och används som diskussionsunderlag i intervjuer. Studien visar att användning av prototyper i mjukvaruprojekt kan bidra till ökat förtroende hos kun-der, förbättrad kommunikation med kunder och kan förenkla att uppnå konsensus mellan olika intressenter. Vidare kan de, beroende av hur de används, bidra till helhetsbilden avprodukten och fungera som dokumentation. Studien påvisar även några, om än subtila, skillnader i den information som samlas in med hjälp av prototyper med låg respekti-ve hög verklighetsfaktor. Hög verklighetsfaktor tycks medföra att fler krav samlas in, men göra respondenter mindre benägna att vilja komma med förslag på mer omfattandeförändringar. / Requirements Engineering (RE) in Agile Software Development (ASD) is a challenge thatmany face and several techniques exist when doing so. One such technique is prototyping, when a model of a product is used to gather important information in software develop-ment. To describe how much a prototype resembles the product the notion of fidelity is used. The aim of this study is to contribute to research regarding prototyping in ASD,and to examine the effect of a prototype’s fidelity when using prototypes in discussionsduring RE. A case study is performed at the company Exsitec where staff are interviewedregarding prototyping in software development. Thereafter, two prototypes of low andhigh fidelity are developed and used in interviews as a basis for discussion. Based on thisstudy, the use of prototypes in software projects can help customers trust the process,improve communication with customers, and facilitate when trying to reach consensusamong different stakeholders. Furthermore, depending on how they are used, prototypescan contribute to understanding the big picture of the requirements and can also serve asdocumentation. The study also shows some, albeit subtle, differences in the informationcollected using prototypes with low and high fidelity. The use of a high fidelity prototypeseems to generate more requirements, but makes interviewees less likely to come up withlarger, more comprehensive requirement changes.

Distribuerade agila mjukvaruutvecklings-metoder har aldrig varit mer populärt. Att kunna arbeta hemifrån för att undvika den dagliga pendlingen eller för att samarbeta med utvecklare utomlands har aldrig varit enklare. Tredjepartsverktyg som Zoom och Google Meet förenklar kommunikationsprocessen, och med introduktionen av verktyg som Visual Studio’s “liveshare” som möjliggör realtids-kodning, har agila metoder verkligen flyttat ut från kontoren. Dock är en av de viktigaste komponenterna av att arbeta agilt att arbeta ansikte mot ansikte, vilket innebär att en av de effektivaste metoderna för kommunikation nu förloras när man flyttas till att arbeta med distribuerade metoder. Att övergå till nya metoder är aldrig enkelt, och när företag övergår till en distribuerad framtid kan mjukvaruutvecklare potentiellt drabbas av denna förändring i miljö och metod. Om företag har riktlinjer för övergången till distribuerade metoder kan det potentiellt göra förflyttninen enklare.Problemet är att det inte finns några sådana riktlinjer. Syftet med denna rapport är att skapa riktlinjer med målet att hjälpa organisationer övergå till distribuerade agila metoder från lokala agila metoder. Metoden i denna rapport är en kvalitativ utforskande litteraturstudie tillsammans med utforskande intervjuer som utforskar de positiva och negativa erfarenheterna utvecklare möter när de gör en övergång till distribuerade metoder. Litteraturstudien användes för att formulera forskningskriterierna och intervjufrågorna. Totalt tillfrågades åtta personer som hade erfarenheter av att göra en övergång till distribuerade agila metoder. Dessa intervjuer resulterade i tre generella riktlinjer som kan användas för att förenkla övergången mellan lokala-och distribuerade agila metoder. / Distributed agile software development has never been more popular. Being able to work at home to avoid the commute or simply collaborating with developers abroad has never been easier. Third party tools such as Zoom and Google Meet makes communication easier than ever, and with the introduction of Visual Studio’s live share that enables real-time collaborative coding, distributed agile development truly has moved out of the offices. Yet, one of the core components of the agile working method is working face to face, meaning that one of the most efficient methods of communication is lost upon moving development into a distributed setting. Transitions towards new methods and settings are never easy, and as companies transition towards a remote and distributed future, software developers are potentially burdened by this change in environment. If companies had access to guidelines they could potentially experience a smoother transition. The problem is that there currently do not exist such guidelines. The purpose of this report is to create such guidelines with the goal of helping organizations transition towards distributed agile methods. In this report, the method utilized is a qualitative and explorative literature study, coupled with interviews aimed to explore the positive and negative experiences developers face when transitioning towards distributed methods. A literature study was used to help formulate the research criteria and the interview questions. In total, eight people that had experienced a recent transition towards distributed agile methods were interviewed. These interviews resulted in three general guidelines that can be used to ease the transition between a local and distributed work environment.

Syfte - Att skapa en djupare förståelse för hur kulturskillnader påverkar arbetet med scrum, med specifikt fokus på psykologisk säkerhet. Metod – En kvalitativ fallstudie med induktiv ansats har gjorts där semistrukturerade intervjuer tillsammans med observationer har använts för att samla in data. Tillsammans med litteratur har sedan en innehållsanalys gjorts.  Resultat – Studien har identifierat tre dimensioner som är viktiga att beakta vid arbetet med scrum. Dessa dimensioner är Inställningen till människan, Hanteringen av människan och Beteenden av människan, och belyser hur kulturskillnader skapar olika förutsättningar för psykologisk säkerhet i scrum-team. Vidare kan dessa insikter leda till ett förbättrat arbete med scrum och i förlängningen skapa mer innovativa och konkurrenskraftiga scrum-team och organisationer.  Teoretiska implikationer – Studien bidrar till litteraturen om psykologisk säkerhet med en empirisk förankrad teori som visar hur kulturskillnader skapar olika konsekvenser för psykologisk säkerhet. Mer specifikt visar den hur dessa kulturskillnader hänger samman och påverkar varandra. Ett andra bidrag som den här studien gör är att skapa djupare förståelse för hur implementering av scrum och agil övergång med fördel bör ske i en ny kultur, som karaktäriseras av hög maktdistans, osäkerhetsundvikande och kollektivism. Praktiska implikationer – Studiens resultat visar att de identifierade kulturskillnaderna hänger ihop vilket innebär att samtliga behöver adresseras för att skapa ett psykologiskt säkert scrum-team i en ny kultur. Psykologisk säkerhet är en förutsättning för självorganiserade team, så som scrum-team, och därmed är studiens resultat av intresse för gruppchefer på samtliga företag som arbetar med scrum, både i olika nationella kontexter och med multinationella team samt i globala virtuella team. / Purpose – To create a deeper knowledge for how cultural differences influences the work with scrum, with specific focus on psychological safety. Method – A qualitative case study with an inductive approach have been carried out where semi-structured interviews together with observations have been used to collect data. Together with literature a content analysis was then preformed. Result – The study has identified three dimensions that are important to consider when working with scrum. These dimensions are Attitude to the human, Managing the human and Behaviors of the human, and these show how cultural differences creates different basis for psychological safety in scrum teams. Moreover, these insights can lead to improved work with scrum and in turn create more innovative and competitive scrum teams and organizations. Theoretical implications – The study contributes to the literature about psychological safety with empirical theory that shows how cultural differences creates different consequences for psychological safety. More specifically, it shows how these differences in culture are related to one another and affects each other. Another contribution of this study is that the result creates a deeper understanding of how the implementation of scrum and agile transitioning best can be done in a new culture, specifically that is characterized by high power distance, uncertainty avoidance and collectivism. Practical implications – The study shows that the identified differences in culture are related to each other, which means that all needs to be addressed to create a psychological safe scrum team in a new culture. Psychological safety is a prerequisite for self-organized teams, such as scrum teams, and thus the result is of interest for group managers in all companies and organizations working with scrum, both in different cultural contexts and with multinational teams as well as in global virtual teams.

Kravprioritering är ett av de viktigaste och mest inflytelserika stegen vid tillverkning av en mjukvaruprodukt. Processen är iterativ; den sker under hela produktens agila mjukvaruutvecklingsprocess. Genom kravprioritering beslutas det om vilka krav som ska utvecklas, i vilken ordning och varför.  Målet med denna studie är att undersöka hur mjukvaruutvecklande företag gör för att kravprioritera, samt identifiera vilka prioriteringsmetoder de eventuellt använder sig av. Studiens syfte är att få en förståelse för varför en väl avvägd prioritering är viktig, vilka särskilda prioriteringsfaktorer som ger värde till en produkt och att se hur dessa faktorer är relaterade till resultatet. Syftet är även att undersöka vilka svårigheter som finns i en prioriteringsprocess, samt att skapa en översikt över några av de mest vedertagna prioriteringsmetoderna inom agil mjukvaruutveckling.  Studien utförs i samarbete med mjukvaruföretaget Monitor ERP för att analysera företagets prioriteringsprocesser som används för att utveckla deras affärssystem Monitor. Metoden som används är en kvalitativ undersökning som består av observationer av möten kring prioriteringsarbete och semi-strukturerade intervjuer. Bearbetning av insamlat material skedde genom att organisera, analysera och sammanställa resultat enligt begrepp och kategorier som framkom utifrån litteraturstudien. Resultatet redovisar arbetsprocesser, gemensamma mål, prioriteringsaspekter och utmaningar i prioriteringsarbetet hos Monitor ERP. En väl avvägd prioritering visade sig vara viktigt för att kunna leverera rätt funktionalitet i tid, för att kunna ge trovärdiga estimeringar om utvecklingen och det i sin tur leder till att kunder får förtroende för både produkten och företaget. En rad olika prioriteringsfaktorer som ger värde till programvaran Monitor identifierades, varav många bidrar till att öka kundnöjdheten och kvaliteten på produkten. Monitor ERP använder inte några särskilda prioriteringsmetoder, utan utvecklingsfilosofin Minimum Viable Product används som grund till deras prioriteringsval. Under prioriteringsarbetet upplevdes utmaningar såsom begränsade resurser, oförutsägbara uppgifter, svårigheter med tidsestimering och en utmaning i balansen mellan kundnytta och kundfokus. / Prioritizing requirements is one of the most important and influential steps in the creation of a software product. The process is iterative; it takes place during the entire agile software development. Through prioritizing requirements, it is decided which requirements are to be developed, in which order, and why.  The aim of this study is to investigate how companies that design software prioritize requirements and to identify which prioritization methods they might use during this process. The purpose of this study is to gain an understanding for why a well-balanced prioritization is important, which specific prioritization factors give value to a product, as well as identifying how these factors are related to the result. The purpose is also to investigate the difficulties that exist in a prioritization process, and to create an overview of some of the most used prioritization methods in agile software development.  This study is conducted in collaboration with the software company Monitor ERP in order to analyze the company's prioritization processes used to develop their business management system Monitor. The method used is a qualitative study that consists of observations of meetings about prioritization processes, and semi-structured interviews. Processing of collected material was done by organizing, analyzing, and compiling results according to concepts and categories that emerged from the literature study. The results documents work processes, common goals, prioritization aspects and challenges in the requirements prioritization at Monitor ERP.  A well-balanced prioritization proved to be important to be able to deliver the right functionality on time and to be able to provide dependable estimates of development, which in turn leads to customers gaining confidence in both the product and the company. A number of prioritization factors that give value to the Monitor software were identified, many of which contribute to increasing customer satisfaction and product quality. Monitor ERP does not use any specific prioritization methods, but the development philosophy Minimum Viable Product is used as a basis for their prioritization choices. During the prioritization process, challenges such as limited resources, unpredictable tasks, difficulties with time estimation, and a challenge in balancing customer value and customer focus were experienced.

Studier visar på att Agila IT-projekt har en större lyckandegrad än traditionella IT-projekt där ett mer vattenfallsorienterat arbetssätt anammats. Trots att den agila approachen i många avseenden har bidragit till att fler projekt anses framgångsrika är det långt ifrån alla projekt som färdigställs i tid, inom budget och till rätt kvalité. Sedan det agila manifestet utgavs i början av 2000-talet har en rad faktorer, såsom kundinvolvering och teamets förmåga, identifierats som avgörande för agila IT-projekt. Trots att de inom teorin i stor utsträckning råder konsensus kring dessa så kallade framgångsfaktorer är forskningen begränsad när det kommer till effekterna av dessa framgångsfaktorer och relationen mellan framgångsfaktorer och effekter. Problemet som denna studie syftar till att adressera är således avsaknaden av en konkretisering av effekter kopplade till framgångsfaktorer för agila IT-projekt och hur dessa relaterar till varandra. För att adressera detta problem, är syftet med studien att utforska och kartlägga kritiska framgångsfaktorer inom agila IT-projekt. För att sedan undersöka de effekter som respektive faktor medför och dess inverkan på projektframgången. För att samla in data, genomfördes totalt fyra semistrukturerade intervjuer, hos SEB Kort AB, Pulsen Omsorg AB och IT avdelningen hos Högskolan i Borås. Respondenterna som intervjuats besitter praktiskt erfarenhet och kunskap av agila- och traditionella utvecklingsmetodologier. Bland respondenterna återfinns roller som Scrum Master, Release Train Engineer, Project Manager och System Developer. Intervjumaterialet transkriberades och analyserades. Analysen av befintlig teori och de empiriska fynden resulterade i en framgångsmodell bestående av organisatoriska, mänskliga, process och tekniska framgångsfaktorer tillsammans med dess tillhörande effekter. Resultatet från studien och den föreslagna modellen kan vara användbart för studenter, yrkessamma och organisationer som önskar få en ökad förståelse för kritiska framgångsfaktorer inom agil mjukvaruutveckling och vilka effekter dessa faktorer medför. Likaså kan modellen fungera som inspiration för framtida forskare som vill forska vidare i denna riktning.

Agile methodologies have become the modern approach to solve the problem of delivering high quality software in a constantly changing business environment. But still many agile software projects have difficulties in meeting the customer needs. This raises questions about how requirements are handled. Therefore, this thesis investigates the requirement engineering process to find challenges companies meet in practice. The study present results from a case study including one company specialized on defense systems, one finance technology company, one robotics company, and one software development company. Based on nine qualitative interviews we discuss the requirement engineering in agile software development and challenges that arise within this process. These challenges relate to a non-agile surrounding, stakeholders insufficient knowledge about their processes, lack of understanding the customer, and incomplete planning of development. We conclude that when using agile methods, development need to focus more on analyzing customers who derive value from the system and how to adapt the requirement engineering to an non-agile surrounding. / Agila metoder har blivit ett modernt verktyg till att lösa vår tids stora utmaning att leverera kvalitativ mjukvara i en ständigt föränderlig affärsmiljö. Trots att agila metoder hanterar snabba förändringar, står de agila mjukvaruprojekten inför utmaningar med att möta kundbehov. Det väcker frågor om hur kravarbetet går till i agil mjukvaruutveckling. Denna uppsats undersöker kravarbetet i agila mjukvaruprojekt och vilka utmaningar som dessa står inför i praktiken. Studien presenterar resultat från en fallstudie bestående av fyra företag verksamma inom: försvarsindustrin, finans, robotik respektive mjukvaruutveckling. Baserat på nio kvalitativa intervjuer diskuteras kravarbetet i agil mjukvaruutveckling och utmaningar som uppstår inom denna process. Dessa utmaningar är kopplade till en icke-agil omgivning, kunders bristande vetskap om deras processer, låg förståelse av kunden och ofullständig planering av utvecklingsarbetet. Vi konstaterar att det agila arbetet behöver fokusera mer på att analysera de värden kunder drar nytta av från ett system och hur kravarbetet ska hanteras när det möter en icke-agil omgivning.

Distributed methods of working with software development grow larger each and every day. One of these methods is distributed pair programming. The problem is that because of the large amount of different tools there is to choose from when working remotely, it may be difficult for developers to know what they should pick, in order for their work to be as effective and enjoyable as possible, when working with distributed pair programming. This thesis investigates how different tools and practices used when working with distributed pair programming has been experienced previously by people working or studying in areas related to software development. Further the goal is to also provide recommendations about what tools and practices should be used for future work with distributed pair programming. From the results of this thesis the following recommendations could be made. Discord is recommended for communication if the use of face cam is not very important, and Zoom is recommended if it is. These tools are also recommended for screen sharing. For code sharing Git should be used, and it is also strongly recommended that the developers get comfortable with using Git as early as possible. For a shared text editor Visual studio live share or Teletype for Atom is recommended, however one should not put to much work into making the shared text editor function, since this does not necessarily have a large positive impact on the development. / Användning av distribuerade metoder under mjukvaruutveckling ökar för var dag. En av dessa metoder är distribuerad parprogrammering. Problemet är att på grund av den stora mängd olika verktyg som finns att välja bland när man arbetar på distans, så kan det vara svårt för utvecklare att veta vilka verktyg de bör välja, för att deras arbete ska vara så effektivt och en så bra upplevelse som möjligt, när de arbetar med distribuerad parprogrammering. Denna uppsats undersöker hur olika verktyg och metoder som används vid arbete med distribuerad parprogrammering upplevs av utvecklare som arbetar med eller studerar inom ett fält relaterat till mjukvaruutveckling. Målet är att ge rekommendationer om vilka verktyg och metoder som bör användas i framtiden när man arbetar med distribuerad parprogrammering. Från resultatet i denna uppsats kunde följande rekommendationer göras. Discord rekommenderas för kommunikation ifall utvecklarna inte känner starkt behov av att kunna se varann, och Zoom rekommenderas ifall utvecklarna känner att dem har ett stort behov av detta. Dessa verktyg rekommenderas även för skärmdelning. För koddelning så rekommenderas Git, och det rekommenderas även starkt att utvecklarna lär sig detta så tidigt som möjligt. För en delad textredigerare så rekommenderas Visual studio live share eller Teletype för Atom, men utvecklarna bör inte lägga för mycket tid på att försöka få detta att fungera, då detta inte nödvändigtvis har en stor positiv inverkan på arbetet.

Agile software development aims to minimize risk by using a short and iterative process, a test-centric development approach by continuous integration, and test automation. Scrum aims to maximize collaboration and collective responsibility for quality by using a team approach. Regardless of this, the risk of project failure due to budget and time overruns is still a severe problem in software development projects. Despite the power that testing offers to mitigate these risks, testing remains a challenge to implement in agile teams regarding a test first or a test early context. This qualitative case study of two agile teams with differing approaches to agile methodology aims to provide some clarity on what driving forces contribute to an agile teams’ possibilities or what impediments contribute to an agile teams’ challenges pertaining to “why do we test software”.

Agile principles for software development are now the industry standard for innovative projects. Agile is often hailed for being flexible, but there is also a commonly held 'truth' that agile principles and software security do not work well together. For this reason it is not uncommon to place all security responsibilities with a separate team, which goes against the agile principles of being team-centered and may affect flexibility or timeframe of a project. Additionally, software security is difficult and requires extensive experience and knowledge, something that varies a lot among software developers. This study presents a threat modeling process tailored for the specific needs and capabilities of the agile developer team. The process combines features of attack trees and abuser stories with other supplementary techniques in a pedagogical instruction manual to create an accessible and easy-to-get-started method intended to be driven by the developers themselves. The process has been developed through extensive review of extant threat modeling methods and the circumstances of the agile team, and trialed through user tests at an agile ITorganization in the financial services. / Agila principer för mjukvaruutveckling är nu industristandard för innovativa projekt. Agila metoder hyllas ofta för sin flexibilitet men det finns också en vidspridd uppfattning att agila metoder och mjukvarusäkerhet inte går bra ihop. Av den anledningen är det inte ovanligt att säkerhetsansvar och -uppgifter drivs av en separat säkerhetsgrupp, vilket går emot de agila principerna om fokus på utvecklarteamet. Detta kan få effekter både för projektets flexibilitet och dess tidsram. Dessutom är IT-säkerhet ett svårt ämne som kräver både erfarenhet och avsevärd kunskap, något som funnits variera mycket bland mjukvaruutvecklare. Den här studien presenterar en hotmodelleringsprocess som skräddarsytts för utvecklarteamets specifika behov och styrkor. Processen kombinerar funktioner från attackträd och abuser stories med andra, komplementära tekniker i en pedagogisk instruktionsmanual för att leverera en lättillgänglig och snabbstartad metod menad att drivas av utvecklarna själva. Processen har utvecklats genom omfattande studier av etablerade hotmodelleringsprocesser, samt den agila teammiljön, och testats och vidareutvecklats genom användartester hos en agil IT-organisation inom finansbranschen.

Denna studie problematiserar icke-funktionella krav (IF krav), även benämnt kvalitetskrav, i svenska mjukvaruutvecklingsprojekt. Kravhantering anses vara den mest avgörande delen i mjukvaruutveckling för att lyckas, vilket än idag är en utmaning i majoriteten av projekten. Särskilt svårt är det att lyckas med IF krav, då tvetydigheter leder till brist på dokumentation och slutligen bortprioriteras de. För att adressera dessa problem syftade denna studie att besvara hur väl de IF kraven dokumenteras inom svenska mjukvaruutvecklingsprojekt samt vem som kan ansvara för att kvalitetssäkra de IF kraven. En mixed-method har genomförts med både en kvalitativ litteraturstudie av tidigare forskning samt en kvantitativ studie. Datainsamlingen i den kvantitativa studien har skett med webbaserad enkätundersökning med 24 frågor. Enkäten skickades ut till 72 företag i Sverige vars huvudsyssla var mjukvaruutveckling. Sammanlagt samlades 43 svar in och en univariat analys genomfördes. Enkätundersökningen indikerade att respondenterna är positivt inställda till dokumentation av IF krav. De flesta saknar dessutom gedigen kunskap om IF krav. Vidare saknas tydliga ansvarsroller för dokumentationen av IF krav. En lösnings- eller mjukvaruarkitekt är bäst lämpad för att kvalitetssäkra de IF kraven. Denna studie är skriven på svenska och kan främja studenter, forskare och yrkesverksamma då den nyanserar vikten av IF krav och hur existerande brister kan förbättras. / This study examines non-functional requirements (NFRs), also known as quality requirements, in Swedish software development projects. Requirements engineering is considered the most crucial part of software development, which is still a challenge in the majority of projects today. In particular, the NFRs are the most challenging seeing as there are ambiguities concerning their definition. This in turn leads to lack of documentation and, ultimately, their deprioritization. To address these issues, this study aimed to answer how well NFRs are documented in Swedish software development projects and who can be responsible for ensuring the quality of these NFRs. A mixed-method was conducted with both a qualitative literature review of previous research and a quantitative study. The data collection in the quantitative study was conducted using a web-based survey with 24 questions. The survey was sent to 72 software development companies in Sweden. A total of 43 responses were collected, and a univariate analysis was performed. The survey indicated that respondents have a positive attitude towards documenting. Additionally, most respondents lack comprehensive knowledge about NFRs and clear roles for the NFRs are missing. Standardization, better guidelines, and clear roles are needed to ensure the quality of NFRs, which are currently lacking. A solution or software architect is best suited to ensure the quality of NFRs. This study, written in Swedish, can benefit students, researchers, and professionals as it highlights the importance of NFRs and suggests improvements for existing deficiencies.