Toimiva, kestävä ohjelmisto

Markku Niemi Suomen Akatemiasta kirjoitti hyvän kommenttin aiempaan postaukseeni. Markun esille nostamat ongelmat ohjelmistotyössä ovat niin yleisiä, että päätin kirjoittaa vastaukseni tämän uuden artikkelin muotoon.

Markku mainitsee viestissään kaksi ohjelmistoprojektien ongelmaa:

• Liiallinen “ketteryys” alkuvaiheessa kostautuu myöhemmin, jos järjestelmä ei ole organisaation yritysarkkitehtuurin mukainen.
• Ohjelmiston sisäinen laatu heikkenee jatkuvasti kun sitä kehitetään. Tämän seurauksena sen korjaaminen, parantaminen ja muokkaaminen muuttuu hankalammaksi ajan kuluessa. Lopulta toimintaympäristön muutoksiin ei voida enää vastata ohjelmiston muutoksilla ja joudutaan kirjoittamaan uusi ohjelmisto alusta lähtien.

Olen Markun kanssa samaa mieltä näiden ongelmien merkittävyydestä. En kuitenkaan pidä niitä voittamattomina ongelmina. Itse asiassa, pidän juuri ketteryyttä näiden ongelmien ratkaisukeinona.

Aloitetaan liiallisesta “ketteryydestä” projektin alkuvaiheessa: olen Markun kanssa samaa mieltä tämän vaarallisuudesta, niin kauan kuin sana “ketteryys” pidetään lainausmerkkien välissä. On siis ketteryyttä ja “ketteryyttä”. Moni firma nimittää tekotapaansa “ketteräksi” ymmärtämättä mistä ketteryyden hyödyt lopulta tulevat.

Ketterässä kehityksessä suunnitteluvaihe, joka perinteisesti on projektin alussa, muutetaan koko projektin jatkuvaksi. Todellisessa ketteryydessä tämä ei kuitenkaan tarkoita, etteikö asioita suunniteltaisi huolella. Projektin toteutus aloitetaan mahdollisimman nopeasti projektin alussa, jotta suunnitelmien realistisuudesta saadaan varhain oikeaa palautetta. Esimerkiksi teknisen riskin minimoimiseksi voidaan käyttää walking skeleton -mallia, jossa projekti aloitetaan arkkitehtuurin oikeaksi osoittavalla minimaalisella ominaisuuskokonaisuudella. Tai sen kumoavalla! Tarkoitus on nimenomaan löytää mahdolliset ongelmat heti projektin alussa, ei sitten kun niitä on liian myöhäistä korjata.

Todellisuudessa myös perinteisissä ohjelmistoprojekteissa suunnittelutyö jatkuu loppuun asti – joka projektissa tulee yllätyksiä, ja niiden tultua esiin joudutaan asiat suunnittelemaan uudestaan. Tätä on jostain syystä ollut monissa projektisuunnitelmissa vaikea myöntää.

Oikeastaan jako “suunnittelun” ja “toteutuksen” välillä on siis keinotekoinen: ohjelmistotyö on luovaa suunnittelutyötä alusta loppuun. Välineet vain vaihtelevat; joskus asioita on helpointa suunnitella tussitaululla, joskus ohjelmointikielellä.

Palatakseni itse asiaan, eli yritysarkkitehtuurin huomioimiseen projektissa: Jatkuvan suunnittelun ohella ketteryyden vastaus tähän on, että olennaisten toimintojen kuuluu olla edustettuna joko järjestemää rakentavassa tiimissä tai sen asiakastiimissä (tätä kuvaavalle englanninkielen termille cross-functional team ei taida olla vakiintunutta suomennosta). Jos yritysarkkitehtuuri on olennaisessa osassa, tulee tiimiin kuulua joku joka hallitsee organisaation yleisarkkitehtuurin. Se, kumpaan tiimiin tämä kuuluu, riippuu yritysarkkitehtuurin merkityksestä tässä organisaatiossa ja tässä projektissa.

Käytännössä monissa organisaatioissa ei haluta irrottaa projekteihin niihin parhaiten sopivia ihmisiä. Sekin voi toimia, kunhan projektin alkuvaiheessa aikaa varataan tarpeeksi kommunikaatiolle tiimin ja näiden sidosryhmien välillä. Olennaista on, että nämä asiakaspään edustajat ovat aktiivisesti mukana projektissa. Tältä kannalta esimerkiksi se, miten Maa- ja metsätalousministeriön Tietopalvelukeskus oli järjestänyt teknisen arkkitehtuurin hallinnan, kuulosti minun korviini hyvältä.

Myös toinen Markun mainitsema ongelma, eli ohjelmistojen rapautuminen elinkaaren loppua kohden, on hyvin yleinen. Sekään ei ole kuitenkaan mikään luonnonlaki; sitä vastaan on mahdollista taistella. Tässä on pari tärkeää keinoa:

1. Laaditaan kattavat automaattiset hyväksymistestit ja ajetaan ne joka päivä. Kunnolla tehtynä nämä ovat järjestelmän todellinen tarkka määrittely. Uudet tulokkaat ymmärtävät järjestelmän halutun toiminnan näiden kautta tarkemmin kuin paperidokumentista. Lisäksi järjestelmän arkkitehtuuria voidaan muuttaa tarvittavaan suuntaan, kun automattisesti voidaan varmistaa, ettei olemassaoleva toiminnallisuus sen takia muutu.Itse alan olla monien kollegoideni tavoin sitä mieltä, että vähänkään pitkäkestoisempaa ohjelmistoprojektia ei voi tehdä ilman automaattisia hyväksymistestejä. Muuten seurauksena on juuri kuvaamasi ohjelmiston rapautuminen.
2. Panostetaan heti ohjelmiston alkuvaiheesta asti koodin ja dokumentaation laatuun – ei määrään. Pahin laadun este on keinotekoinen kiire. Usein ohjelmistoprojekteissa kuvitellaan, että hyvä suunnittelu on joitain, joka voidaan siirtää syrjään, kun on pidettävä kiirettä. Näin ei tietenkään ole. Hyvä suunnittelu auttaa projektia pitämään vauhtia yllä. Ohittamalla suunnittelun voi saada vain lyhytaikaisen nopeutuksen. Kun se on käytetty loppuun, on työ entistä hitaampaa.Toinenkin laadun este liittyy aikaan; se on tehtävien tarkka aikataulutus etukäteen pitkälle ajalle. Koska koko ohjelmistoprosessi on uuden suunnittelua, on ennalta vaikea arvata, mihin asiaan aika lopulta kuluu. Jos tehtävien aikataulut on lyöty lukkoon etukäteen, tulee jäljestä väistämättä vaihtelevaa. Asiat, jotka eivät menneetkään niin kuin alunperin oli suunniteltu, joudutaan paikkaamaan pikaisesti purukumilla. Lopulta suurin osa järjestelmästä on purukumia ja sen toiminnan selvittäminen käytännössä mahdotonta.

Deadlineja saa olla, ja esim. Scrumin voi sanoa jopa toimivan juuri niiden varassa. Aikataulut ja tavoitteet pitää kuitenkin määritellä oikealla tarkkuudella ja oikealla tavalla. Seuraavan päivän toimille voidaan asettaa tarkat tehtäväkohtaiset tavoitteet, mutta mitä pidemmälle tulevaisuuteen mennään, sitä epämääräisempi pitää suunnitelmankin olla. Ei ole järkevää asettaa tarkkaa määrittelyä vuoden päästä valmistuvalle järjestelmälle – sen sijaan voidaan arvioida esim. sitä kuinka paljon arvoa järjestelmä asiakkaalle vuodessa tuottaa ja seurata sitä. Näin tiimi ei ole sidottu yhteen suunnitelmaan vaan se voi tuottaa asiakkaalle arvoa parhaalla mahdollisella tavalla, kun se oppii järjestelmästä ja sen toimintaympäristöstä uutta.

Toki lopulta kaikkein tärkein laatuun vaikuttava tekijä on ohjelmistotiimin osaaminen. Hyvä tiimi tekee hyvää laatua ja on lopulta moninkertaisesti kustannustehokkaampi kuin keskinkertainen tiimi.

Tässä käsitellyt ongelmat liittyvät olennaisesti yhteen. Hyvää suunnittelua tarvitaan alusta loppuun asti. Muuten ongelmat kasautuvat, ja lopulta maksumieheksi joutuu tilaaja.