Kartoitus mittareista osaksi Scrum-tiimin ohjelmistokehitystä

Abstract

Ohjelmistokehityksessä, kuten yleisesti liiketoiminnassa, on hyödyllistä käyttää mittareita toiminnan tukena. Ohjelmistokehityksessä käytetään nykyisin varsin usein niin sanottuja ketteriä ohjelmistokehitysmenetelmiä, joista yksi suosituimmista on Scrum. Ketterien menetelmien tueksi on listattu useita erilaisia ja paljon käytettyjä mittareita. Suosituimmat mittarit eivät välttämättä sovellu suoraan kaikkiin tilanteisiin, vaan käyttöön otettavat mittarit olisi hyvä valita kohdealueen ja tarpeiden mukaan. Tämän tutkimuksen tarkoituksena oli selvittää tutkimuksen kohteena olevan Scrum-tiimin näkökulmasta tiimin ohjelmistokehityksen tueksi käyttöönotettavia mittareita. Mittareiden selvittämisen pohjustukseksi toinen tutkimuksen tarkoitus oli kuvata kohdetiimin ohjelmistokehitysprosessia, jossa Scrumviitekehyksen ohella hyödynnettiin esimerkiksi DevOps-käytänteitä. Tutkimusmenetelmänä käytettiin iteratiivista design science -otetta, missä tuloksia täydennettiin vaiheittain tiimin kanssa keskustellen. Tutkimuksen tuloksena syntyi vuokaavioita tiimin ohjelmistokehitysprosessista ja mittarilistauksia. Tiimin ohjelmistokehitysprosesseissa kuvattiin tiimin kehitysjonon tehtävien etenemisen prosessi ja miten sen osana näkyy esimerkiksi koodien katselmointi pull request –pohjaisesti ja koodin automaattinen julkaiseminen. Automaatio on yksi DevOpsin ulottuvuuksista ja hyvä kohde mittareille esimerkiksi automaattisen ja ajantasaisen datan ansiosta. Kehitysjonotehtävien prosesseista kuvattiin featuren, user storyn, taskin ja bugin vaiheet sekä keskustelussa tärkeäksi nostettu release-suunnittelu yleisesti. Mittareita kerättiin useaa eri tiimin toimintaa koskettavan osa-alueen kirjallisuusviitteistä 226 mittarin listaukseen, josta iteratiivisesti rajattiin lopullinen 13 mittarin joukko, missä yhdeksän mittaria oli kirjallisuuden pohjalta kerätystä listasta ja neljä keskustelun pohjalta listaan lisättyä mittaria. Ohjelmistokehitysprosessien kuvaaminen ei vain pohjustanut mittarikeskustelua, mutta myös mahdollisti tiimille keskustelun oman ohjelmistokehitysprosessinsa tilasta ja sen tulevaisuudesta, sekä loi havainnollistavan kuvauksen kehitysprosessista tiimille. Iteratiivinen ja kirjallisuuteen pohjaava mittareiden kartoittaminen auttoi tiimiä rajaamaan usealta eri osa-alueelta joukon eniten tiimiä itseään kiinnostavia mittareita, joka ei vain ole listaus suosituimmista muualla käytössä olevista mittareista.

In software business, as in any business, metrics can be a useful tool to support managerial business decisions. Nowadays many of the methods used to build software products are part of agile development method family, out of which one of the most popular is Scrum. Several studies present metrics to support agile software development methods. However, these are often the most popular and most used metrics, which might not suit for every situation. Thus, metrics should be selected based on the target domain and observed needs. The purpose of this study is to determine metrics from the target Scrum team’s perspective to support the team in their software development process. In order to help mapping the metrics, another purpose for this study is to model the team’s software development process, which along with Scrum includes for example DevOps practices. Design science type method used builds the results iteratively based on discussions done with the team. The results of this study are software development process models and metrics lists. The process models describe the handling of the team’s backlog items and how are, for example, pull request based code review and continuous delivery included in the process. Automation is one of the main features of DevOps. Based on its automatic and timely data creation, it is a very suitable target for various metrics. Backlog item process models include models for feature, user story, task and bug iterations and a general process for release planning, which was brought up in the team discussions as an important process area. An original list of 226 metrics from articles categorized as coming from various sectors within the team’s area of operation narrowed down to a list of 13 metrics during the discussion. Nine of the final metrics are from the original article list and four new were suggested in the team discussions. Software process models, in addition to giving basis to the metrics discussion, also facilitated a discussion on how the team want to develop and run their software development now and in the future. It also forms a visualization for the team of their development process. Defining metrics iteratively from a list of metrics used in various agile software development sectors enabled the team to form a list of metrics that are suitable to the specific situation and to the needs of the team themselves. Not just a list of the most used metrics in the industry.