Urani alkuvaiheessa, vastikään nimitettynä apulais-tuotepäällikkönä, kuulin ensimmäisen kerran teknisestä velasta (eli teknisestä velasta), enkä ollut aivan varma, mitä se tarkoitti. Huvittavaa kyllä, luulin sen tarkoittavan lainaa, jonka olimme ottaneet kolmannen osapuolen ohjelmiston ostamista varten, ja käytin tätä termiä itsevarmasti väärin kahden tai kolmen viikon ajan. Kuvitelkaa nolostumiseni, kun insinöörimme ottivat minut sivuun päivittäisen tilannepalaverin jälkeen korjatakseen ystävällisesti käsitykseni!

Jotta säästyisimme kaikki työpaikalla nolostumiselta ja voisimme kasvattaa uskottavuuttamme insinööriemme silmissä, perehdytään siihen, mitä tekninen velka on ja miksi meidän tuotepäälliköiden pitäisi välittää siitä.

Mitä tekninen velka on ja milloin siitä tulee ongelma?

Ohjelmistokehityksessä on kyse tuotteen toiminnallisuuden laajuuden tasapainottamisesta laadukkaan koodin kanssa. Matkan varrella oikaisemme joskus mutkia nopeuttaaksemme kehitysprosessia – näitä oikoteitä kutsutaan tekniseksi velaksi tai teknologiavelaksi.

Milloin teknisen velan ottaminen on hyvä idea, ja milloin siitä tulee tikittävä aikapommi? Vastataksemme tähän kysymykseen tarkastelemme ensin teknologiavelan historiaa.

Mitä tekninen velka on?

Ward Cunningham, termin kehittäjä, vertaa teknistä velkaa taloudelliseen velkaan – tulevaa nopeutta ja vakautta vastaan on hyväksyttävää lainata, mutta velka on maksettava lopulta takaisin. Tämä on käsite, joka jokaisen kehitystiimin tulisi ymmärtää ja jota jokaisen tuotepäällikön tulisi harkita tehdessään tuotteeseen liittyviä päätöksiä.

Teknologiavelka auttaa meitä julkaisemaan tuotteita aikataulua edellä ja saamaan tuotteet nopeammin asiakkaiden käyttöön. Meidän on kuitenkin lopulta ”maksettava velka pois” investoimalla koodikantamme laatuun.

Parhaassa tapauksessa päätämme aktiivisesti, haluammeko hyödyntää teknistä velkaa vai välttää sitä. Taloudellisen velan tavoin emme halua joutua myöhemmin yllätetyiksi odottamattomista kustannuksista!

Teknisen velan yksinkertaistettu määritelmä

Tekninen velka (josta jotkin tiimit käyttävät myös nimitystä koodivelka) tarkoittaa tulevaisuudessa tarvittavan uudelleentyöstön piileviä kustannuksia silloin, kun valitset lyhyen aikavälin oikotien pidemmän mutta paremman lähestymistavan sijaan. Se on kuin lainan koron maksamista – teknisen velan kustannukset kasvavat ajan myötä.

Yksi käyttämäni vertauskuva on parran ajaminen. Jos minulla on kiire ja ajan parran nopeasti, lopputulos ei luultavasti ole kaikkein siistein, ja joudun palaamaan myöhemmin siistimään sen.

Molempiin ajoihin – ensimmäiseen ajoon ja myöhempään siistimisajoon – kuluu yhteensä enemmän aikaa ja vaivaa kuin siihen, että olisin ajanut parran kunnolla heti ensimmäisellä kerralla.

Mutta joskus, kun aika on loppumassa, meidän on tyydyttävä nopeaan ajoon!

Taloudellisen velan vertaaminen tekniseen velkaan

Jotta tämä käsite konkretisoituisi, perehdytään hieman tarkemmin taloudellisen velan ja teknisen velan vertailuun. Tuotepäälliköiden on nimittäin ymmärrettävä sekä liiketoiminnan rahoitukseen että tekniseen koodaukseen liittyviä käsitteitä!

Taloudellisen velan edut: Taloudellinen velka mahdollistaa vipuvaikutuksen. Rahan lainaaminen voi tarjota pääomaa, jota tarvitaan kasvumahdollisuuksiin investoimiseen. Lisäksi taloudellinen velka mahdollistaa resurssien tai omaisuuden välittömän käytön ilman ennakkomaksua.

Taloudellisen velan haitat: Taloudelliseen velkaan liittyy monenlaisia kustannuksia. Taloudellisen velan korkomaksut voivat kertyä ajan mittaan ja heikentää kokonaiskannattavuutta. Lisäksi taloudellisen velan puutteellinen hallinta voi johtaa taloudelliseen epävakauteen.

Velka voi myös rajoittaa taloudellista joustavuutta ja estää meitä tavoittelemasta tiettyjä suuntia tulevaisuudessa. Taloudellisten velvoitteiden laiminlyönti voi myös vahingoittaa organisaation mainetta.

Teknisen velan edut: Tekninen velka mahdollistaa tuotteen nopeamman alkuvaiheen kehityksen, mikä auttaa noudattamaan tiukkoja määräaikoja tai hyödyntämään markkinamahdollisuuksia. Taloudellisen vipuvaikutuksen tavoin teknisen velan ottaminen voi pienentää alkuvaiheen kehityskustannuksia.

Teknisen velan haitat: Aivan kuten korkoa kertyy taloudelliselle velalle, tekninen velka kasvaa korkoa korolle, kun olemassa olevien oikoteiden päälle rakennetaan uusia ominaisuuksia tai muutoksia. Tämä tekee tulevasta kehityksestä monimutkaisempaa ja kalliimpaa. Lisäksi tekninen velka johtaa usein koodin heikompaan laatuun, mikä kasvattaa ylläpitokustannuksia ajan mittaan.

Tekninen velka voi vaikeuttaa tuotteen kykyä mukautua muuttuviin markkinaolosuhteisiin tai ottaa käyttöön uusia ominaisuuksia. Käsittelemätön tekninen velka voi myös johtaa järjestelmävirheisiin, tietoturva-aukkoihin tai suorituskykyongelmiin, jotka vaikuttavat tuotteen elinkelpoisuuteen.

Mitä tämä tarkoittaa meille? Taloudellisen velan ja teknisen velan kohdalla tavoitteena ei ole välttää velkaa kokonaan. Sen sijaan ratkaisevaa on harkittu hallinta.

Vaikka tietty määrä velkaa voi tukea strategisesti kasvua, meidän on seurattava ja hallittava velkaa huolellisesti pitkäaikaisten kielteisten seurausten minimoimiseksi.

Esimerkkejä teknisestä velasta

Ohjelmistotekniikan alalla kehitystiimit kohtaavat säännöllisesti teknistä velkaa. Keskustellaan muutamasta yleisimmästä esimerkistä.

Vanha koodi

Jotkin tiimit saattavat käyttää vanhentunutta perintökoodia saadakseen ominaisuuden nopeasti julkaistua. Tämä voi tarjota välitöntä toiminnallisuutta, mutta myöhemmin se saattaa vaatia huomattavaa uudelleenrakentamista, etenkin kun uusia ominaisuuksia lisätään. Muinaisen käsikirjoituksen tavoin perintökoodi on siirtynyt kehittäjäsukupolvelta toiselle ja kerännyt ylleen historian painolastia.

Vaikka se on aikanaan saattanut palvella tarkoitustaan erinomaisesti, aika heikentää sen mukautuvuutta ja ylläpidettävyyttä. Tuotantoympäristön käyttökatkoja ja virheitä alkaa yleensä ilmetä, kun luotamme liikaa perintökoodiin!

Kovakoodaus

Kovakoodauksella tarkoitetaan käytäntöä, jossa tietyt arvot tai vakiot upotetaan suoraan koodiin sen sijaan, että käytettäisiin määritettäviä asetuksia.

Vaikka tämä lähestymistapa voi nopeuttaa kehitystä lyhyellä aikavälillä, se johtaa usein myöhemmin ongelmiin. Kuvitellaan tilanne, jossa kovakoodattu arvo, kuten tiedostopolku tai aikakatkaisun raja-arvo, on muutettava laajassa koodikannassa. Tästä voi nopeasti muodostua aikaa vievä ja virhealtis tehtävä, joka vaarantaa ohjelmiston ylläpidettävyyden ja joustavuuden.

Tämän ongelman välttämiseksi kehittäjien tulisi valita määritettävät asetukset, jotka parantavat koodin mukautuvuutta.

Koodin monistaminen

Koodin monistamista tapahtuu, kun samankaltaisia tai identtisiä koodinpätkiä esiintyy useissa kohdissa projektia. Aluksi se saattaa vaikuttaa kätevältä oikotieltä, joka säästää aikaa kehityksen aikana. Ohjelmiston kehittyessä ja vaatimusten muuttuessa yhdenmukaisuuden säilyttäminen ja päivitysten tekeminen muodostuvat kuitenkin monimutkaiseksi tanssiksi.

Koodin monistaminen ei ainoastaan lisää virheiden riskiä, vaan myös moninkertaistaa tuleviin parannuksiin ja virheenkorjauksiin tarvittavan työn määrän. Koodin uudelleenkäytettävyyden tavoittelu ja tarpeettoman koodin poistaminen ovat keskeisiä periaatteita tämän ongelman ratkaisemiseksi.

Dokumentaation puute

Dokumentaatio toimii opastavana lankana, joka valaisee nykyisten ja tulevien kehittäjien polkua. Kattavan dokumentaation puuttuminen muistuttaa monimutkaiselle matkalle lähtemistä ilman karttaa. Kaikki voi alkaa siitä, että koodissa ei ole kommentteja, jotka selittäisivät tiettyjen koodivalintojen perusteet, tai edetä puuttuviin käyttöoppaisiin ja järjestelmäarkkitehtuurin dokumentaatioon.

Vaikka alkuvaiheen kehitys saattaa edetä sujuvasti, pitkän aikavälin seuraukset voivat olla vakavia. Virheenkorjauksesta tulee salaperäinen yritys, tiedon siirtäminen tiimin jäsenten välillä vaikeutuu, ja projektin skaalaaminen muistuttaa usein pimeässä sokkelossa suunnistamista. Perusteellisen dokumentaation omaksuminen on majakka, joka valaisee tietä ohjelmistokehityksessä eteenpäin.

Automaattisten testien puute

Automaattisten testien puuttuminen muistuttaa veneellä purjehtimista tarkistamatta ensin, onko siinä vuotoja. Automaattiset testit, kuten yksikkö-, integraatio- ja regressiotestit, ovat koodin laadun ja vakauden valppaita vartijoita.

Kun testit jätetään pois, seuraukset eivät välttämättä näy heti. Aluksi kehitys saattaa edetä nopeasti ja ohjelmisto vaikuttaa toimivalta. Koodikannan laajentuessa ja kehittyessä alkaa kuitenkin ilmetä odottamattomia ongelmia. Regressiovirheistä, joissa aiemmin toimineet ominaisuudet rikkoutuvat uusien muutosten myötä, tulee arkipäivää.

Ilman automaattisia testejä tarjoamassa turvaverkkoa kehitystiimin on turvauduttava manuaaliseen testaamiseen, joka on aikaa vievä ja virhealtis prosessi. Automaattisen testauksen käyttöönotto heti alusta alkaen varmistaa tasaisen etenemisen ohjelmistokehityksen myrskyisällä merellä.

Mikä on teknisen velan rooli ketterässä kehityksessä?

Ah, ketterä kehitys! Sen scrum-menetelmät ja ketterän kehityksen manifestista peräisin olevat periaatteet omaksuvat muutoksen ja nopeuden. Mutta miten tekninen velka sopii tähän? Teknistä velkaa ei nimittäin käsitellä nimenomaisesti ketterän kehityksen perustamisasiakirjoissa.

Star Warsista löytyy tähän sopiva vertaus: Han Solo ja Chewbacca huolsivat Millennium Falconia jatkuvasti pitääkseen sen huippukunnossa seikkailujaan varten. Samoin ketterä tuote­tiimi hallitsee teknistä velkaa ylläpitääkseen ohjelmiston laatua ja mahdollistaakseen sankarilliset seikkailut asiakkailleen! 

Kuinka teknistä velkaa käytetään ja hallitaan

Ketterissä tiimeissä ymmärretään, että joskus teknistä velkaa kertyy, jotta liiketoiminnan tarpeisiin voidaan vastata nopeasti. Muista, ettei velan kertyminen ole aina huono asia. Martin Fowler, ketterän ohjelmistokehityksen ajatusjohtaja, huomauttaa, että kyse on kompromisseista. Voit hyväksyä jonkin verran velkaa ohjelmistotuotteen elinkaaren alkuvaiheessa konseptin validoimiseksi tai markkinoille pääsemiseksi nopeammin.

Avainasemassa on teknisen velan hallinta. Tekninen velka tulisi dokumentoida backlogiin, priorisoida ja käsitellä tulevissa sprinteissä. Jotta tämä olisi mahdollista, tuotepäälliköiden on hyödynnettävä vahvaa projektinhallintaa ja ymmärrettävä hyvin tähän mennessä kertyneen teknisen velan määrä.

Milloin tekninen velka on ongelma?

Kun sidosryhmät eivät tiedosta teknistä velkaa tai kun kehitysprosessi perustuu vahvasti kiertoratkaisuihin, silloin hälytyskellojen pitäisi alkaa soida. Miksi?

1. Se on näkymätöntä: Ilman mittareita tai säännöllisiä koodikatselmointeja piileviä haavoittuvuuksia voi ilmaantua.
2. Se vaikuttaa käyttäjäkokemukseen: Jos taustalla olevat ongelmat alkavat vaikuttaa toiminnallisuuteen, kyse ei ole enää vain kehittäjän ongelmasta, vaan liiketoimintaongelmasta.
3. Se vaikeuttaa uusien ominaisuuksien kehittämistä: Huonoon koodiin juuttuneet ohjelmoijat ovat vähemmän tuottavia, ja luovuus vähenee.
4. Se ei ole mukana etenemissuunnitelmassa: Tiimien tulisi tiedostaa tekninen velka ja laatia sille strategia. Älä epäröi hyödyntää ulkopuolisia webinaareja ja resursseja toimintasuunnitelman laatimisessa.

Miten teknistä velkaa mitataan

DevOps-käytäntöjen ja automaation kaltaisten työkalujen avulla tiimit voivat seurata koodikantaansa ja pysyä ajan tasalla tähän mennessä kertyneestä teknisestä velasta. Alla olen koonnut kaksitoista erilaista tapaa seurata teknistä velkaa.

Sinun ei tarvitse käyttää niitä kaikkia! Ajattele tätä luetteloa sen sijaan lähtökohtana. Valitse yksi tai kaksi tapaa otettavaksi käyttöön seuraavan kuukauden aikana ja kehitä sitten vähitellen tiimisi kyvykkyyttä teknisen velan seuraamisessa ja ratkaisemisessa.

1) Staattinen koodianalyysi: SonarQuben, ESLintin tai FindBugsin kaltaiset työkalut voivat analysoida koodia automaattisesti erilaisten ongelmien, kuten koodin monimutkaisuuden, koodin hajujen ja mahdollisten virheiden, löytämiseksi. Ne tarjoavat ennalta määritettyihin sääntöihin ja kynnysarvoihin perustuvia määrällisiä mittareita koodin laadusta ja teknisestä velasta.

2) Koodikattavuus: Voimme arvioida, kuinka suuri osa koodikannasta on automaattisten testien kattama, mittaamalla koodikattavuutta JaCoCon tai Istanbulin kaltaisilla työkaluilla. Vähäinen koodikattavuus voi viitata testauksen puutteeseen ja mahdolliseen tekniseen velkaan.

3) Vertaiskoodikatselmoinnit: Vertaiskoodikatselmointien tekeminen antaa kehittäjille mahdollisuuden tunnistaa ja käsitellä mahdollisia teknisen velan kohteita. Kaksi päätä on parempi kuin yksi – se on loistava tapa välttää huonoja koodimalleja! Tiimit voivat käyttää tarkistuslistoja tai ohjeita koodin laadun arviointiin ja tunnistettujen ongelmien dokumentointiin. Katselmoinneissa löydettyjen ongelmien määrä ja vakavuus voivat toimia teknisen velan laadullisena mittarina.

4) Manuaaliset kooditarkastukset: Kehittäjät ja tiimit voivat tehdä manuaalisia kooditarkastuksia tai koodin läpikäyntejä tunnistaakseen koodikannan alueita, jotka voisivat hyötyä uudelleenjärjestelystä. Tämä prosessi sisältää usein kokeneiden kehittäjien tekemän koodin tarkastelun ja ongelmien dokumentoinnin, sillä heillä on yleensä paras käsitys teknisen suunnittelun velasta. 

5) Teknisen velan työlista: Tuotetyölistan ylläpitäminen tai tunnistettujen teknisen velan kohteiden luettelointi on yleinen käytäntö. Jokaisen työlistan kohteen tulisi sisältää kuvaus, vaikutustenarviointi ja prioriteettiluokitus. Työlistan kohteiden määrä ja prioriteetti tarjoavat teknisen velan laadullisen mittarin.

6) Virheiden ja ongelmien seuranta: Virheiden priorisointiprosessin analysointi voi paljastaa tekniseen velkaan liittyvien ongelmien esiintymistiheyden ja vakavuuden. Suuri virheraporttien määrä tai samojen ongelmien toistuva esiintyminen voi viitata taustalla olevaan tekniseen velkaan.

7) Arviointi ja tarinapisteet: Suunnitellessaan uutta työtä tai käyttäjätarinoita kehitystiimit voivat arvioida teknisen velan kohteiden käsittelyyn tarvittavan työn määrää. Tämä työmääräarvio, usein ketterissä menetelmissä tarinapisteiden muodossa, määrittää teknisen velan ratkaisemiseen tarvittavan työn määrän.

8) Koodin monimutkaisuusmittarit: Syklomaattisen monimutkaisuuden, koodirivien määrän ja koodin muuttuvuuden kaltaiset mittarit voivat antaa tietoa koodikannan monimutkaisuudesta ja ylläpidettävyydestä. Suurempi monimutkaisuus ja tietyille koodialueille tehdyt liialliset muutokset voivat viitata tekniseen velkaan.

9) Käyttäjäpalaute: Käyttäjäpalaute ja tukipyynnöt voivat tuoda teknisen velan esiin epäsuorasti. Toistuvat käyttäjävalitukset järjestelmän suorituskyvystä, luotettavuudesta tai odottamattomasta toiminnasta voivat olla merkki taustalla olevista ongelmista, jotka on ratkaistava.

10) Automaattisen testauksen mittarit: Automaattiseen testaukseen liittyvien mittareiden, kuten testien suoritusaikojen, testien epäonnistumisasteiden ja epävakaiden testien, seuranta voi auttaa arvioimaan testausinfrastruktuurin tilaa ja tunnistamaan teknisen velan vaikutusalueita.

11) Kyselyt ja haastattelut: Kehitystiimien kyselyt ja haastattelut voivat tarjota laadullista tietoa koetusta teknisen velan määrästä ja sen vaikutuksesta tuottavuuteen ja koodin laatuun. Lisäksi sidosryhmien palautteen kerääminen voi auttaa selvittämään, missä uudelleentyöstö saattaa olla tarpeen.

12) Teknisen velan nelikenttä: Yksi erityisen hyödyllinen työkalu on teknisen velan nelikenttä, jonka esitteli Martin Fowler. Se luokittelee teknisen velan syyt tarkoituksellisiin ja tahattomiin sekä harkitsemattomiin ja harkittuihin, mikä auttaa tiimejä ymmärtämään kompromisseja.

Näiden kahdentoista teknisen velan mittaamistavan lisäksi voit huoletta käyttää tuotehallintatyökaluja tiimisi teknisen velan seurannan ja ratkaisemisen hallintaan!

Teknisen velan maksaminen pois

Olemme puhuneet paljon teknisen velan syntymisestä, mutta emme ole vielä käsitelleet sen maksamista pois. Tuotepäällikköinä vastuullamme on ohjata tiimejämme päättämään, milloin velka maksetaan pois ja milloin teknistä lisävelkaa otetaan.

Maksamme teknistä velkaa pois, kun insinöörit päivittävät koodikantaa aiemmin tunnistettujen teknisen velan kohteiden korjaamiseksi. Tähän voi kuulua toiminnallisuuden uudelleensuunnittelu tehokkaammaksi, automaattisten testien käyttöönotto tai koodin perusteellinen dokumentointi.

Yksi parhaista tavoista vähentää sitä on varata jokaisessa sprintissä aikaa koodikannan vahvistamiseen ja velan vähentämiseen. Ajattele tätä kuukausittaisten asuntolainan lyhennysten tavoin: mitä nopeammin pystymme lyhentämään lainaa, sitä vähemmän korkoja meidän on maksettava kokonaisuudessaan!

Hyvä nyrkkisääntö on 80/20-sääntö. Käyttäkää siis jokaisessa sprintissä noin 80 % ajasta uusien ominaisuuksien rakentamiseen ja 20 % ajasta teknisten investointien ja parannusten priorisointiin.

Kun suunnittelet teknisen velan vähentämistä, harkitse sen sisällyttämistä asianmukaisesti tuotteen etenemissuunnitelmaan.

Loppupohdintoja teknisestä velasta

Yhteenvetona voidaan todeta, että teknisen velan hallinta ei ole vain kehittäjien tehtävä. Tuotepäälliköillä, ketterillä tiimeillä ja liiketoiminnan sidosryhmillä on kaikilla oma roolinsa.

Lopullinen tavoite? Laadukkaan ohjelmistotuotteen toimittaminen liiketoiminnan tavoitteet täyttäen ilman kestämättömän velan syntymistä.

Joten riippumatta siitä, sukellatko ohjelmistokehityksen syviin vesiin vai yritätkö vain ymmärtää, miksi kehitystiimisi puhuu jatkuvasti uudelleenmuokkauksesta, teknisen velan ymmärtäminen ja hallinta on kompassi, jota tarvitset.

Olitpa vasta aloittamassa uraasi tuotetehtävissä tai jo kokenut tuotepäällikkyyden konkari, hyödyt lähes aina teknisen sanaston ymmärryksen syventämisestä.

Toivon, että vältät tekemästä samaa virhettä, jonka itse tein urani alkuvaiheessa – älä luota pelkästään asiayhteyden vihjeisiin yrittäessäsi arvata tuntemattomien teknisten käsitteiden merkitystä!

Käytä sen sijaan aikaa tutkimiseen, tutustu tällaisiin ulkopuolisiin oppaisiin ja vietä aikaa insinööriesi kanssa kartuttaaksesi arvokasta osaamista.

Jos haluat lisää tuotepäällikkyyteen liittyviä näkemyksiä ja oppaita, muista tilata uutiskirjeemme!