Ohjelmistojen kehittämiseen liittyy kahdenlaista teknistä velkaa: tietoisesti otettua ja tiedostamatonta. Jos ilmiöön ei kiinnitä riittävästi huomiota, harkittukin velka alkaa kasvaa liian kovaa korkoa.
Tiedostamaton tekninen velka tulee esiin yllättäen. Se näkyy pienimmillään yksittäisenä bugina, jonka takana on ontuvasti kirjoitettu koodinpätkä. Mittakaavan toisessa ääripäässä on arkkitehtuuritason ongelma, jossa valitut teknologiat ja ratkaisut eivät palvelekaan loppukäyttäjien tarpeita. Haasteet alkavat kertautua jokaisen tiketin ja käyttäjätarinan tasolle.
Tietoisesti otettu tekninen velka syntyy joskus jopa strategisena valintana. Startup-yritys haluaa ehkä satsata käyttöliittymäkerrokseen ja rakentaa Minimum Viable Product -tuotteen. Tavoitteena on saada uskottavuutta rahoittajien ja asiakkaiden silmissä, ja backend-tehtävät jätetään odottamaan vuoroaan. Toisaalta ohjelmistoalalla moni tunnistaa tilanteen, jossa dokumentaatiosta, testaamisesta tai koodin helppolukuisuudesta tingitään kiireen vuoksi. Tai sitten backlogille jätetään yhteisellä päätöksellä bugeja, joiden korjaamisen aika on vasta myöhemmin.
Lue myös: Tätä on backlog refinement -työskentely käytännössä
Miksi on niin tärkeää tehdä tekninen velka näkyväksi?
Teknisen velan ottaminen saattaa olla harkittu teko, mutta tilanteen korjaamiseen kannattaa silloinkin olla valmis suunnitelma. Ongelmat alkavat kasautua, jos velkaa ei tehdä näkyväksi. Vertaan tilannetta autokorjaamoon. Kun yksi jättää työkalut lattialle ja sammuttaa vielä valot, seuraava tekijä ei ehdi edes aloittaa töitä ennen kuin jo kompastuu tunkkiin.
Ketterässä ohjelmistokehityksessä kehittäjät eivät päätä yksin töiden priorisoinnista, vaan siihen tarvitaan muita avainhenkilöitä, kuten projektipäällikkö ja tuoteomistaja. Kehittäjillä on kuitenkin paras näkyvyys projektin päivittäiseen työhön.
Kun he kommunikoivat projektin tilasta ja ongelmista avainhenkilöille selkeästi ja tarkasti, he mahdollistavat samalla oikeiden päätösten tekemisen. Jos taas informaatio ei kulje vapaasti näiden sidosryhmien välillä, päätöksenteko vaikeutuu. Tämä kaikki kietoutuu yhteen ketterän ohjelmistokehityksen perusperiaatteista: läpinäkyvyyteen.
Jos tuloksia luvataan liian lyhyessä ajassa, laadun kustannuksella ja oikoteitä dokumentoimatta, yhteinen käsitys projektin valmiusasteesta sumentuu. Piiloon jäävä tekninen velka voi aiheuttaa ongelmia erityisesti silloin, jos päätöksistä vastaavilla avainhenkilöillä itsellään ei ole teknistä taustaa. Heidän on silloin vaikeaa ymmärtää kehittäjien kokemien haasteiden merkitystä ja kontekstia.
Velalta ei voi välttyä kokonaan, mutta siihen voi varautua
On olemassa alueita, joilla ammattitaitoiset ohjelmistokehittäjät eivät ikinä tingi koodin laadusta. Niitä ovat erityisesti tietoturvallisuuteen sekä sovelluksen toimintaan kriittisesti liittyvät asiat.
Muuallakin teknistä velkaa on tietysti järkevää karttaa. Mitä paremmin tiimi ymmärtää, millaisia hankkeen tavoitteet ovat ja mitä käyttäjät todella haluavat sovelluksella tehdä, sitä osuvampia ovat arkkitehtuurivalinnat. Alkumetreiltä asti tarvitaan tiivistä vuoropuhelua asiakkaan kanssa. Palvelumuotoilu auttaa rakentamaan yhteistä ymmärrystä.
Ketterän ohjelmistokehityksen projekteissa tärkeintä on löytää sovelluksen taustalle tekniset ratkaisut, jotka ovat valmiina muuttumaan ja joustamaan samalla, kun tulevaisuuden toimintaympäristöt muuttuvat.
Yllätyksiä saattaa aina olla edessä – sen suhteen kannattaa olla realisti. Esimerkiksi riippuvuuksia ei voi hallita aukottomasti tästä ikuisuuteen. Jos suuren, ulkopuolisen kirjaston ylläpito päättyy tai versio vaihtuu, arkkitehtuurin päivittäminen ajan tasalle voi vaatia paljon työtä. Kun riskin sanoittaa auki asiakkaalle jo varhaisessa vaiheessa, siihen osataan varautua.
Tietoisesta velasta voi tulla tiedostamatonta
Harkittua teknistä velkaa ottamalla kehitystiimi kasvattaa helposti myös tiedostamattoman velan määrää. Niin voi käydä, jos oikoteitä etsitään:
- jättämällä testaaminen, erityisesti yksikkötestaaminen, minimiin
- viemällä tuotantoon asti nopeasti tehtyä, jotakuinkin toimivaa koodia, joka ei noudata Clean Code -periaatteita
- nipistämällä dokumentointikäytännöistä.
Kaikkia äsken mainittuja yhdistää se, että ongelmat eivät näy tänään tai huomenna, mutta tulevaisuudessa ratkottavaa on edessä senkin edestä. Testaajan työpanoksen puute näkyy bugeina, joiden korjaamiseen menee paljon kehittäjien aikaa. Sotkuisella koodilla pärjää ehkä aluksi, mutta sovelluksen laajennusvaiheessa edessä on ongelmia. Henkilöt vaihtuvat, ja dokumentoinnin puutteet johtavat väärinkäsityksiin.
Clean Code -guru Robert C. Martin on sanonut, että kovassa kiireessä on erityisen tärkeää pitää kiinni prosessin kulmakivistä, kuten yksikkötestauksesta ja scrumin viitekehyksestä. Ilman ennakointia ja laatuvipua sekä työtunnit että kustannukset karkaavat korkeiksi.
Lue myös: 6 näkökulmaa koodin laatuun: Näin ohjelmistokehitystiimit sopivat yhteisistä käytännöistä
Varaa aikaa siivoamiselle
Pitkään jatkuvissa projekteissa olisi tärkeää varata jo ennakoiden aikaa ongelmien korjaamiseen sen sijaan, että tuottaa jatkuvasti vain uusia toiminnallisuuksia. Kartoittamiseen kannattaa ryhtyä viimeistään silloin, kun pitenevä bugiraportti kertoo hälyttävää kieltä arkkitehtuurin suorituskyvystä. Kaikkein fiksuinta olisi tehdä teknisen velan tarkastelusta säännöllinen käytäntö. Silloin asiakas tai projektipäällikkö saa jatkuvasti oikeaa tietoa päätöksenteon ja priorisoinnin tueksi.
Ketterän ohjelmistokehityksen etuna on, että tiimillä on valmiudet ja vapaus muokata käytäntöjä ja korjata esiin nousevia ongelmia.
Kehittäjä puolustaa sovelluksen laatua
Kehittäjän työtä on pitää sovellus kunnossa. Jos annetuilla resursseilla ei ole mahdollista tehdä tietoturvallista, vakaata ja käyttäjälle toimivaa lopputulosta, on syytä kertoa tilanteesta asiakkaalle realistisesti. Se edellyttää tietysti kulttuuria, jossa vuorovaikutus kehittäjien, projektipäälliköiden ja asiakkaiden kesken toimii.
Jokainen talo on omanlaisensa, mutta kokemuksen kautta olen huomannut, että meillä Cinialla:
- teknistä velkaa kirjataan ylös aktiivisesti
- teknisestä velasta pystyy keskustelemaan projektipäälliköiden ja liiketoiminnasta vastaavien henkilöiden kanssa vapaasti
- tekninen velka ei ole tabu eikä siihen liity häpeää.
Ongelmatilanteita ei kannata pelätä. Jokainen huomaa joskus virheitä omassa koodissaan tai yhteisissä suunnitelmissa. Tärkeintä on tunnistaa riskipaikat ja tehdä teknisen velan eri muodot näkyviksi.
