Ketterät menetelmät ovat yleistyneet laajasti ohjelmistokehityksessä. Viimevuotisen ohjelmistoyrityskartoituksen mukaan suomalaiset ohjelmistoyritykset ovat ottaneet ketterän kehityksen periaatteet laajasti käyttöön: ketterä kehitys on jo alan normi. TIVIA-blogi, kirjoittajana Jyrki Kontio.

Ketterät menetelmät ovat yleistyneet laajasti ohjelmistokehityksessä. Viimevuotisen ohjelmistoyrityskartoituksen mukaan suomalaiset ohjelmistoyritykset ovat ottaneet ketterän kehityksen periaatteet laajasti käyttöön: ketterä kehitys on jo alan normi.

Ketterät kehitysmenetelmät tarjoavat monia ilmeisiä etuja ohjelmistokehitykseen: kehitys on joustavampaa, ohjelmisto saadaan käyttöön nopeammin ja sovitut budjetit ja aikataulut pitävät paikkansa.

Ohjelmiston laadun osalta ketterät menetelmät ovat kaksiteräinen miekka – monessa ketterässä kehitystiimissä on tässä kohdassa porsaan mentävä aukko, koska laatuun liittyviä asioita ei ole otettu kehitystiimin agendalle.

Ketterät menetelmät tuovat toki mukanaan kolme tärkeää periaatetta, jotka parantavat ohjelmistojen laatua: automaattinen testaus, asiakkaan aktiivinen osallistuminen ja jatkuvan kehittymisen käytäntö retrospektien kautta. Nämä eivät kuitenkaan riitä, sillä useimmissa ketterissä installaatioissa laatutavoitteita ei ole määritelty, ne eivät ole backlogissa mukana, eikä ennakoivia – proaktiivisia – laatuun liittyviä varmistuksia ei suunnitella eikä tehdä lainkaan. Tilannetta pahentaa vielä se, että ketterässä kehityksessä on aina lyhyen tähtäyksen fokus ja kiire: pitkän tähtäyksen laatutavoitteet, kuten ylläpidettävyys, arkkitehtuuri tai integroitavuus, jäävät usein huomiotta. Kun ketterän kehityksen kulttuuri vielä hyljeksii vanhanaikaiselta näyttävää perinteistä laadunhallintaa, moni hyvä laatukäytäntö jää vanhojen vesiputoustekniikoiden roskalaatikkoon.

Laadun saattaminen ketterän kehitystiimin agendalle onnistuu kuitenkin helposti muutamalla yksinkertaisella keinolla. Ensinnäkin, laatutavoitteet kannattaa määritellä hankkeen alussa ja niiden tulee vaikuttaa jokaisen sprintin aikana backlogin sisältöön. Tämän lisäksi jonkun organisaatiossa tulisi ottaa vastuu ketterän kehityskyvyn parantamisesta: ketterälle kyvykkyydelle pitäisi piirtää kehittymisen roadmap, joka ohjaa retrospektien ideoiden priorisointia. Kun tälle kyvykkyyksien kehittymiselle tehdään vielä oma, aktiivinen backlog, jonka mukaan kehityskäytäntöjä parannetaan jatkuvasti – saadun kokemuksen ja bisneksen tarpeiden mukaan – laatuun liittyvät aukot pystytään aika hyvin tukkimaan.

Hyvä laatu ei synny itsestään tai vahingossa – ei edes ketterässä kehityksessä.

Jyrki Kontio on entinen ohjelmistotuotannon ja -liiketoiminnan professori, joka nykyään toimii ICT-alalla konsulttina ja sarjayrittäjänä. www.jyrkikontio.fi

Jyrki toimii myös kouluttajana TIVIAn Ketterät laadunhallinnan tekniikat -koulutuksessa.