Oletko joskus työskennellyt osana yrityksen tai muun organisaation ohjelmistokehitysyksikköä, joko johtotehtävissä tai teknisenä henkilönä, ja tiennyt, ettei kaikki ole pohjimmiltaan kunnossa? Ovatko deadlinet paukkuneet jatkuvasti huomattavalla marginaalilla ja pienetkin muutokset ohjelmistoon vaatineet käsittämättömän suuria työmääriä? Kenties lopputuote on ollut läpeensä buginen ja vaatinut lennosta paniikinomaista laastaripaikkailua. Tai ehkä yksikkö on kärsinyt suuresta kehittäjien vaihtuvuudesta, jolloin työt ovat vuorostaan kaatuneet muiden niskaan.

Projektijohdolla on taipumus reagoida näihin haasteisiin hyvin samantyylisesti. Ohjelmistokehittäjiä piiskataan painamaan töitä yhä kovemmin – vianhan täytyy olla ohjelmistokehityksessä, eikö niin? Kaikki turhanaikainen piiperrys teknisen velan karsimiseksi pudotetaan pois, jotta voidaan keskittyä ainoastaan feature-työhön. Loppuasiakas halusi nämä ominaisuudet valmiiksi jo eilen! Viimeisenä oljenkortena projektissa saatetaan alkaa nipistää aikataulupaineessa laadunvarmistuksesta siinä toivossa, että purkalla ja jeesusteipillä päästäisiin vauhdikkaammin pinteestä.

Kaikki nämä lähestymistavat osoittautuvat usein vääriksi ja saattavat jopa pahentaa ongelmia.

Juurisyy vaikeuksiin on monesti syvemmällä. Esittelemme alla neljä eri kysymystä, joihin johdon ja ohjemistokehittäjien kannattaisi ensimmäiseksi pyrkiä vastaamaan.

 

Miten ohjelmiston arkkitehtuuria hallitaan?

Aikaisemmassa blogitekstissämme käsittelimme arkkitehtuurivastuita. Ohjelmistoarkkitehtuurilla tarkoitetaan karkeasti ohjelmiston ja sen komponenttien rakennetta sekä niitä yleisiä periaatteita, jotka ohjaavat ohjelmiston suunnittelua ja kehitystä. Hyvin suunniteltu arkkitehtuuri auttaa hallitsemaan kompleksisen ohjelmistoprojektin riskejä ja kustannuksia sekä tuottamaan sellaisen järjestelmän, joka aidosti vastaa loppukäyttäjien tarpeisiin.

Ongelmat arkkitehtuurin parissa tiivistyvät yleensä siihen, että kokonaiskuva ohjelmiston kehittämisestä on hukassa eikä kenelläkään ole todellista vastuuta siitä, miten arkkitehtuuria pitäisi kehittää. Tavanomainen seuraus on se, että jokainen ohjelmistokehittäjä puuhaa omiaan siten kuin parhaaksi näkee, ja lopputuloksesta muodostuu kaoottinen. Todelliset loppukäyttäjien tarpeet, joita arkkitehtuurin pitäisi heijastella, eivät myöskään ole välttämättä ajantasaisesti tiedossa.

Erityisesti muutoksien tekeminen ohjelmistoon voi olla hyvin haastavaa, jos kokonaisuutta ei ole alusta alkaen suunniteltu mahdolliset muutokset huomioiden eikä kukaan pidä huolta siitä, että muutoksia voidaan toteuttaa myös jatkossa. Softwaresta muodostuu näin käytännössä hardwarea.

 

Olennaisia kysymyksiä arkkitehtuurin suhteen ovat muun muassa:

• Kuka on vastuussa arkkitehtuurista?
• Millaista arkkitehtuuria ohjelmisto noudattaa?
• Mahdollistaako arkkitehtuuri ohjelmiston muokattavuuden ja ylläpidettävyyden kohtuullisin kustannuksin pitkällä aikavälillä?
• Miten arkkitehtuuria suunnitellessa huomioidaan loppukäyttäjien tarpeet?
• Miten arkkitehtuurista jaetaan tietoa ja osaamista tiimin sisällä?
• Miten arkkitehtuurin noudattamista seurataan?

 

Jos vastaus johonkin näistä kysymyksistä uupuu, sireenien pitäisi pärähtää soimaan. 

 

Miten ohjelmiston tekninen velka pidetään kurissa?

Ohjelmiston tekninen velka viittaa ohjelmistokehityksen yhteydessä tehtyihin lyhyen aikavälin kompromisseihin ja valintoihin, jotka mahdollistavat nopean etenemisen mutta jotka aiheuttavat lisää työtä, riskejä tai ongelmia tulevaisuudessa. Teknistä velkaa kertyy, kun ohjelmistoa rakennetaan tavalla, joka ei ole optimaalinen pitkäaikaisen ylläpidettävyyden, suorituskyvyn, turvallisuuden tai muun laadullisen näkökohdan kannalta. Siksi velkaa pitää säännöllisesti karsia, jolloin koodista muodostuu pitkällä tähtäimellä kestävämpää.

Teknisen velan laiminlyömisellä on lukuisia tutkittuja negatiivisia vaikutuksia. Se kasvattaa usein merkittävästi ohjelmistokehittäjien kehitystyöhön kuluvaa aikaa. Viimeaikaisten tutkimusten mukaan keskimäärin jopa 25 % ohjelmistokehitysprojekteihin käytetystä ajasta hukkaantuu teknisestä velasta johtuviin ongelmiin, kuten bugeihin ja niiden jäljittämiseen. Se vaikuttaa myös negatiivisesti ohjelmistokehittäjien työtyytyväisyyteen. 

Haastavana puolena teknisen velan karsiminen voi olla kallista. Mitä pidempään sitä kuitenkin lykkää, sitä kalliimmaksi karsiminen muodostuu ja velan seuraukset pahenevat.

 

Teknisen velan osalta tiimin kannattaa esittää itselleen ainakin seuraavat kysymykset:

• Miten teknisen velan kertymistä seurataan?
• Millaista teknistä velkaa ohjelmistoon on kertynyt ja mikä sen vaikutus on?
• Omistetaanko teknisen velan karsimiselle aikaa?
• Millainen suunnitelma teknisen velan karsimiseksi on tehty?

 

 

Millä tasolla ohjelmistokehityksen käytännöt, työkalut ja prosessit ovat?

Ammattimainen ohjelmistokehitys on vuosikymmenien aikana tullut huomattavasti eteenpäin menneisyyden villistä lännestä. Enää energiajuomalla eteenpäin painavat oman elämänsä ohjelmoijagurut eivät hakkaa koodia eteenpäin luolissaan ad hoc -menetelmin ilman minkäänlaista yhteistä kommunikaatiota, laadunvarmistusta tai työläimpien prosessien automaatiota kuka milläkin työkaluin. Nykyisin esimerkiksi ohjelmistoa, jota ei ole kattavasti testattu, ei voi pitää edes puolivalmiina.

Aidosti ammattimaiseen ohjelmistokehitysprosessiin kuuluukin, että työtä koordinoidaan yhdessä, sen tuloksia arvioidaan tiimissä säännöllisesti ja tekemistä kehitetään palautteen kautta järjestelmällisesti. Ohjelmistokehitysprosessin hallintaan on useita menetelmiä, joista viime vuosikymmeninä eniten nostetta ovat saaneet eri ketterän kehityksen menetelmät, kuten Scrum. Tärkeintä ei ole kuitenkaan tietty menetelmä vaan se, että valittu tapa työskennellä aidosti toimii. Se, että pidetään dailyt silloin tällöin (usein ylipitkinä) ja kutsutaan sitä Scrumiksi, ei tarkoita, että ohjelmistokehitysprosessi on kunnossa.

Yhtälailla tärkeätä on, että tiimillä on käytössään ajantasaiset työkalut ja että niiden hyödyntämisessä noudatetaan hyviä käytäntöjä. Jokaisen tiimin ohjelmoijan tulee esimerkiksi ymmärtää, miten tuotetaan muille ymmärrettävää ja ylläpidettävää koodia projektiin valituilla ohjelmointikielillä.

Nykypäivänä ohjelmistokehittäjien kannattaa myös automatisoida ohjelmistonsa laadunvarmistus mahdollisimman pitkälle hyödyntäen esimerkiksi kattavaa automaatiotestausta, jatkuvaa integraatiota, staattisia analyysityökaluja sekä automaattista monitorointia. Tällä yritys voi säästää huomattavasti esimerkiksi manuaalisen testaamisen ja ylläpidon kustannuksissa. Muun muassa automaatiotestaamisen on tutkittu tuottavan säästöjä ohjelmistokehitykseen, rajoittavan siihen kuluvaa aikaa sekä parantavan lopputuotteen laatua.

 

Muutamia kysymyksiä, joita tiimin on hyvä kysyä itseltään:

• Käytetäänkö tiimissä jotain yhdessä sovittua ohjelmistoprojektinhallinnan kehystä ja noudatetaanko sitä siten, että se tosiasiallisesti edistää tiimin työskentelyä?
• Noudatetaanko tiimissä yhdessä sovittuja ja hyväksi todettuja ohjelmointikäytäntöjä ja valvotaanko niitä sekä automatisoidusti että yhteisin koodikatselmoinnein?
• Ovatko tiimin käyttämät työkalut ajantasaiset ja yhdenmukaiset?
• Kuinka pitkälle ohjelmistokehitysprosessin toistuvat rutiinit ja laadunvarmistus on automatisoitu?
• Hyödynnetäänkö projektissa esimerkiksi kattavaa automaatiotestausta, jatkuvaa integraatiota sekä tuotantoympäristön automaattista monitorointia?
  

Millainen ohjelmistokehityksen kulttuuri tiimissä vallitsee?

Millään ylläolevista kohdista ei ole merkitystä, jos tiimin ohjelmistokehityskulttuuri on retuperällä. Huono kulttuuri tarkoittaa sitä, että tiimissä vallitsee ohjelmistokehityksen ammattimaisuuden suhteen hälläväliä-asenne. Hälyttävää on, jos tiimin jäseniä ei aidosti kiinnosta esimerkiksi hyvien käytäntöjen noudattaminen, kestävän ja ylläpidettävän koodin tuottaminen sekä lopputuloksen laatu ja sen varmistaminen.

Tyypillistä ongelmalliselle ohjelmistokehityskulttuurille on ihmisten kyynistyneisyys vallitsevaan tilanteeseen sekä kokemus siitä, ettei millekään edes kannata yrittää tehdä mitään, koska muutosta ei kuitenkaan saada aikaan tai siitä ei ole hyötyä. Samoin tiimissä voi vallita, niin itse kehittäjien kuin projektijohdonkin suhteen, vanhakantaisia asenteita: asiat tehdään, kuten on ennenkin tehty, eikä niitä ole syytä kehittää eteenpäin. Tiukassa istuva muutosvastarintaisuus on tällaiselle tilanteelle tyypillistä, mikä estää tiimiä oppimasta uutta.

Siksi onkin elintärkeää, että ohjelmistokehitysprosessin kehittämiseksi on olemassa asianmukaiset palautekanavat ja palautteeseen myös reagoidaan säännöllisesti. Muussa tapauksessa kulttuurilliset ongelmat saattavat alkaa näkyä kohoavana vaihtuvuutena. Usein myös yrityksestä poistuvat ensimmäisenä kaikkein pätevimmät henkilöt.

 

Ohjelmistokonsultointi avuksi ongelmiin

Saivatko ylläolevat kysymykset hälytyslamput syttymään? Niihin vastaaminen ja ratkaisujen löytäminen voi onnistua organisaatiolta myös itsenäisesti. Joskus kuitenkin ongelmat kasautuvat niin, että ulkoisen avun hankkiminen on paikallaan.

Ohjelmistokonsultointi voi tuoda tarjota merkittävää apua ohjelmistokehitysprojektien vaikeuksiin monella eri osa-alueella. Buutti yrityksenä on ollut mukana sadoissa ohjelmistoprojekteissa ja tukenut asiakkaitaan lukemattomissa eri haasteissa. Kaikki konsulttimme ovat käyneet läpi tiukan rekrytointiseulan sekä kattavan perehdytysprosessin, joissa annetaan vahva painoarvo hyville ohjelmistokehityksen käytännöille. Konsulteillemme muodostuu myös projekteissaan kattava ja ammattimainen näkemys siitä, miten asiakkaalle tuotetaan pitkäjänteisesti arvoa.

Arkkitehtuurillisten ongelmien ratkaisemiseen voimme tuoda syvällistä asiantuntemusta ja tuoreita näkökulmia, jotka auttavat suunnittelemaan kestävämpiä järjestelmiä.Teknisen velan hallinnassa osaamme tunnistaa kriittisiä parannuskohteita ja luoda toteutuskelpoiset suunnitelmat sen vähentämiseksi. Prosessien, käytäntöjen ja työkalujen kehittämisessä kykenemme analysoimaan yrityksen nykytilan sekä suosittelemaan sellaisia käytäntöjä ja työkaluja, jotka lisäävät tiimien onnistumismahdollisuuksia. Lisäksi pystymme konsultoimaan ohjelmistokehityksen kulttuurin parantamisessa sekä tiimien yhteistyön ja kommunikaation vahvistamisessa.

Ohjelmistokonsultoinnin etu on siinä, että se tarjoaa sellaista näkemystä, jota organisaation sisältä ei jo valmiiksi löydy, sellaiselta taholta, jolla on hyvin laaja kokemus erilaisten ohjelmistokehityssudenkuoppien ratkomisesta. Meidän kokemuksemme mukaan IT-alojen projekteissa toistuvat usein hyvin samankaltaiset hankaluudet, minkä vuoksi niiden laivan kääntämisessä auttavat usein myös samankaltaiset lääkkeet. Tiimi voikin hyötyä ulkoisen ohjelmistokonsultin mukanaan tuomasta osaamisesta jo varhaisessa vaiheessa projektia, kun kauaskantoisia päätöksiä vasta tehdään. Eikä johdonkaan pidä pelätä hankkia projektin vetämiseen asiantuntijanäkemystä yrityksen ulkopuolelta!

 

Lähteet

1. Bass L., Clements P., Kazman R. (2012) “Software Architecture in Practice, Third Edition”
2. Poort E.R., van Vliet H. (2012) “RCDA: Architecting as a risk- and cost management discipline”
3. Besker T., Martini A., Bosch J. (2019) “Software Developer Productivity Loss Due to Technical Debt”
4. Stripe, (2018) “The Developer Coefficient: Software engineering efficiency and its $3 trillion impact on global GDP”
5. Ramač et al. (2022) “Prevalence, common causes and effects of technical debt: Results from a family of surveys with the IT industry”
6. Besker et al. (2020) “The influence of Technical Debt on software developer morale”
7. Kumar D., Mishra K.K. (2016) “The Impacts of Test Automation on Software’s Cost, Quality and Time to Market”