Requirements risk management in agile software development projects

Abstract

Erilaisten ketterien järjestelmäkehitys menetelmien kasvanut suosio on vaikuttanut perinteiseen tapaan ymmärtää järjestelmävaatimusten hallintaa. Ketterissä järjestelmäkehitys projekteissa vaatimusmäärittely prosessin täytyy mukautua kehitysympäristöön, jossa keskitytään pienempiin osakokonaisuuksiin valmiiden tuotteiden asemesta, joissa muutos on jatkuvaa ja missä asiakkaan odotetaan olevan vahvasti osallisena. Tämä vaikuttaa luonnollisesti myös järjestelmävaatimuksiin liittyviin riskeihin. Tämä pro gradu tutkielma selvittää kuinka järjestelmävaatimusten riskejä hallitaan ketterissä järjestelmäkehitysprojekteissa, sekä miten ketterän järjestelmäkehitys filosofian valinta vaikuttaa projektin järjestelmävaatimusten riskikenttään. Tutkielman teoreettinen osuus tarkastelee järjestelmäkehitys alan ajankohtaista kirjallisuutta. Yhdistämällä tietoa järjestelmäkehityksen yleisestä riskien hallinnasta, vaatimusten riskien hallinnasta ja ketterästä järjestelmäkehityksestä, kirjallisuuskatsaus muodostaa kuvan järjestelmävaatimusten riskien hallinnan keskeisitä ominaisuuksista ketterissä kehitysprojekteissa: Näissä projekteissa myös itse vaatimusten riskien hallinnan täytyy sopeutua iteroivaan toimintatapaan ja jatkuviin muutoksiin. Tämä lisää myös riskien muutosalttiutta ja samalla tarvetta muokata riskianalyysin laajuutta sopimaan kulloiseenkin kehitys iteraatioon. Samoin kirjallisuuskatsaus paljastaa kuinka järjestelmävaatimusten riskien hallinnan pitää olla läpinäkyvää ja mahdollisuuksien mukaan ottaa mukaan myös projektin muita sidosryhmiä varsinaisen kehitystiimin lisäksi. Empiirisessä osuudessa kirjallisuuskatsauksen tuloksia rikastetaan tapaustutkimuksella. Siinä Requirements Risk Prioritization -metodia käytetään vaati-musten riskien hallintaan ketterässä järjestelmäkehitysprojektissa. Tapaustutkimus paljastaa kuinka ylätasolla myös ketterät projektit kohtaavat saman tyyppisiä haasteita kuin perinteisempiä kehitysmenetelmiä käyttävät projektit. Tapaustutkimuksesta kuitenkin selviää neljä riskiryhmää, jotka tulosten mukaan ovat keskeisessä roolissa ketterissä projekteissa. Nämä riskiryhmät liittyvät asiakkaan rooliin ja käyttäjäkokemukseen, ketterän järjestelmäkehityksen prosesseihin, järjestelmävaatimusten laajuuteen ja projektitiimiin. Tapaustutkimus myös korostaa kuinka tärkeää ketterissä projekteissa on pystyä kommunikoimaan järjestelmävaatimusten riskeistä siten, että kaikki sidosryhmät pystyvät niitä ymmärtämään – erityisesti asiakas, jonka odotetaan olevan aktiivinen osallistuja projektissa. Tässä kommunikaatiossa ketterät projektit voivat hyötyä erilaisten työkalujen käytöstä, kuten Requirements Risk Prioritization menetelmä, jota tässä tapaustutkimuksessa testattiin Yleisesti tämän tutkimuksen tulokset korostavat kuinka järjestelmävaatimusten riskien arviointi on haastavaa ketterissä projekteissa erityisesti koska sen tekeminen vaatii laajaa tietoa projektista itsestään sekä sitä ympäröivästä organisaatiosta. Henkilön tai henkilöiden, jotka kyseistä analyysiä tekevät täytyy päästä käsiksi tähän tietoon. Samaan aikaan ketterä prosessi pakottaa analysoijan keskittymään riskeihin pienemmässä laajuudessa kerrallaan kuitenkaan unohtamatta niiden riippuvuuksia projektin kokonaisriskiympäristöön. Vaikka järjestelmävaatimusten riskit ovat erittäin tärkeitä, niitä ei kuitenkaan koskaan voida arvioida ja hallita irrallisena projektin muusta riskikentästä.

The grown popularity of agile development methods has affected the traditional understanding of requirement management. In these kinds of projects, requirement engineering process needs to adapt to an agile environment where the focus on development is in smaller iterations instead of ready products, changes happen often, and a customer is expected to be highly involved in the process. This naturally effects on requirement related risks that agile projects may face. This Master’s thesis investigates how the requirements risk management is done in agile projects and how selecting an agile development method affects requirement risks. The theoretical part of this study reviews contemporary research literature from the IS field. By combining knowledge from IS development risk management, requirement risk management, and agile development it was possible to summarize some key attributes of requirement risk management in agile projects. In these projects also, requirement risks management needs to adapt to the iterative development cycles and constant changes. This increases the volatility of the requirement risks as well as the need to adjust the scope of the risks assessment to fit the size of the development scope of any given time. Similarly, the prominent role of the customer in agile IS projects emphasize how also the requirements risk management should be transparent and involve, not only the project team but also different project stakeholders. The empirical part of this study further enriches these finding by testing the Requirements Risk Prioritization method in a case study, in an agile project where it was used as a tool to identify and prioritize requirement related risks. The case study revealed how in higher level agile projects face similar risks as projects where more structured methods are used. However, this study identified four other types of risks that seem to play an increasingly important role in the agile projects. These types related to customer’s role or user experience of the system, agile development process itself, requirements scope as well as projects team. The case study also highlights the importance of communication about requirement related risks in a way that it is understandable for all the stakeholder – especially when the customer is expected to be involved. Lastly, it showcases how agile projects could benefit from having a tool to support this kind of communication. Results of this study also show how assessing requirements risks is challenging in agile projects since the people doing that needs to have a wide range of knowledge from the project as well as the organization where it exists. This individual or individuals should have also an access to that information. At the same time the agile process forces them to be able to do a similar assessment for risks on a smaller scale while not still forgetting to consider requirement risks as a part of project’s overall risk environment: No matter how important requirements risks are, those never exist in a vacuum and should not be managed as such.