Teknisen velan hallinnoinnin viitekehykset: tiimin näkökulma

Abstract

Teknisen velan (Technical Debt, TD) käsitteiden ja konseptin käyttö on lisääntynyt paljon viimeisinä vuosina, mikä kuvastaa myös yritysmaailman herännyttä kiinnostusta aiheeseen. Teknisen velan negatiivisten vaikutusten ulottuessa ohjelmistotuotantoyrityksistä ohjelmistojen käyttäjiin ja koko ympäröivään maailmaan, velan hallinnoinnin merkitys kasvaa. Ohjelmistojen jatkokehityksen hankaloituminen tai estyminen tarkoittaa ylimääräisiä kuluja. Samalla kun käytännön tekijöiden kiinnostus on herännyt, on myös syntynyt tarve erilaisille malleille, viitekehyksille ja esimerkkiratkaisuille, työvälineille, joiden avulla käytännössä teknisen velan hallinnointia voitaisiin tehdä. Teknisen velan hallin-nointia (Technical Debt Management, TDM) on parhaan kompromissin löytäminen kullekin projektille tai tuotteelle. Tämä tutkimus perustui oletetukseen, ettei kirjallisuudessa ole vielä tiimitasolle soveltuvaa, kokonaisvaltaista teknisen velan hallinnoinnin viitekehystä. Tutkimuksen tavoitteena olikin rakentaa kir-jallisuuskatsauksien ja empiiriseen osion perusteella alustavat teknisen velan hallinnoinnin yleinen ja tasoittainen (tiimi) viitekehys. Viitekehykset toimivat siten apuvälineinä rakennettaessa käytännön teknisen velan hallinnoinnin malleja tai prosesseja tiimitasolle. Tutkimusstrategiana käytettiin suunnittelutieteellistä tutkimusta ja lähestymistapana suunnittelutieteellistä prosessia (DSRM), jossa tutkittavia artefakteja rakennetaan iteratiivisesti. Tämän tutkimuksen artefakteja ovat yleinen ja tasoittainen (tiimi) viitekehys. Rakennetut viitekehykset sekä esimerkkimalliratkaisu arvioitiin asiantuntijoille suunnatulla kyselytutkimuksella. Viitekehykset ja esimerkkimalliratkaisu arvioitiin varsin toimiviksi ja käyttökelpoisiksi asiantuntijoiden kyselytutkimuksessa. Kyselytutkimuksen tuloksista esiin nousseet tärkeimmät havainnot muutettiin viitekehysten kehitystoimenpiteiksi, jotka seuraavalla iterointikierroksella toteutettiin. Kyselytutkimuksesta selvisi myös teknisen velan hallinnoinnin olevan vielä varsin puutteellista, eikä termin tuntemuskaan tiimeissä ole kattavaa.

The use of the concept of technical debt (TD) has increased remarkably in a few years, reflecting the growing and widespread interest of the business community towards the issue. Managing technical debt becomes more and more important, as its negative impacts hit globally, starting from software companies and ending up to single software users. The costs of software production raise as a result of complicated, or even blocked further development of software. Simultaneously with the awakened interest of the practitioners, there emerges a need for various models, frameworks and solution models – tools – that would enable proper management of technical debt in practice. Technical Debt Management (TDM) is about finding best available compromises for each project or product in question. This research was based on the assumption that in the literature there does not yet exist any comprehensive technical debt management framework applicable to team level. The aim of the study was to construct two frameworks, general and hierarchical (team) to manage technical debt, based on a literature review and an empirical study. The frameworks will thus serve as tools for further construction of practical technical debt management models and processes at team level. Design science research was used as research strategy, the approach being design science process (DSRM), according to which the artifacts are constructed iteratively. The artifacts produced by this research are the general and the hierarchical (team) frameworks. The constructed frame-works and the sample model solution were evaluated by an expert questionnaire, resulting as being functional and useful. Main findings emerging from the results of the questionnaire were further developed into development proposals and were accordingly implemented in the next iteration cycle of the process. The questionnaire also revealed that the existence of the management of technical debt is still quite deficient, and the knowledge of the definition itself is not yet sufficient in software development teams.