Sovelluskehitys on sinänsä jännää puuhaa, että lähes poikkeuksetta kaikki tunnistavat, että se on kompleksia ja sen tekeminen vaatii taitoa, mutta samanaikaisesti itse kehittämistä pidetään itsestäänselvyytenä. Tämän lopputuloksena päädytään tilanteisiin, missä komplekseihin ongelmiin koitetaan soveltaa yksinkertaisia menetelmiä ja saatetaan eksyä kaaoksen puolelle.
Hyvin suunniteltu on vain hyvin suunniteltu
“Hyvin suunniteltu on puoliksi tehty” on ihan kiva sanonta ja ihan päteväkin, kunhan toimitaan ympäristössä, missä kaikki on selkeää. Kuitenkin mitä enemmän työhön liittyy epävarmuutta, niin sitä suuremmalla todennäköisyydellä missä tahansa tehdyssä suunitelmassa on aukkoja ja joudutaan varautumaan yllätyksiin.
Erityisesti sovelluskehityksessä yllätykset ovat enemmänkin sääntö kuin poikkeus. On siis turha tuudittautua ajatukseen että kun käytetään ensiksi puoli vuotta tarkan suunnitelman tekemiseen, niin toteutus on aina helppo nakki. Tämä ei tietenkään tarkoita, että suunnittelu olisi huono asia. Päinvastoin, suunnittelua kannattaa tehdä ja paljon. Erona vaan on se, että suunnittelua kannattaa tehdä pienissä osissa, jatkuvasti ja muutoksiin reagoiden sen sijaan, että aluksi suunnitellaan paljon ja sitten nojataan koko ratkaisu tehtyyn suunnitelmaan.
Eihän tuohon voi nyt mennä enempää kuin..
– Douglas Hofstadter
Työmääräarvioinnit ovat sinänsä jännä juttu, koska puhutaan pitkälti tietoon pohjautuvista arvauksista, mutta silti niitä kohdellaan kuin kiveen hakattua totuutta. Ei siis ihme, että useammallakin sovelluskehittäjällä nousee niskakarvat pystyyn kun pyydetään arviota. Usein pelätään, että annettua lukua pidetään absoluuttisena totuutena, joka toki saa jää pienemmäksi, mutta auta armias jos työhön meneekin enemmän kuin on arvioitu.
Totta kai arvioitavan ongelman kompleksisuus ja myös koko vaikuttaa tähän. Eli yksinkertaisten, aina samalla tavalla toistuvien tehtävien arviointi on helppoa ja mitä pienemmästä kokonaisuudesta on kysymys, sen helpompi tarvittava työ on eristää ja arvioida. Mutta kun koko ja epävarmuustekijät kasvavat, muuttuu arvioitava kokonaisuus kompleksisemmaksi ja arvion haarukka kasvaa. Eli mitä selkeämmin tarve on kuvattu ja mitä pienempiin kokonaisuuksiin se on pilkottu, niin sitä helpompi se on arvioida. Kunhan muistetaan, että arvio on vain arvio.
Käytännöt kunniaan
Työmääräarvioita vertaillessa usein vertaillaan lukuja ilman että perehdytään tarkemmin siihen mitä on arvioitu. Jos esimerkiksi yksi henkilö arvioi työn kestoksi yhden päivän, mutta sisällyttää siihen vain ohjelmoinnin. Toinen taas arvioi kaksi päivää, mutta sisällyttää siihen yksikkötestauksen, sen automatisoinnin, arvioinnit ja koodin refaktoroinnin. Kumpi on lopulta kalliimpi?
Hyvät tekniset käytännöt auttavat yksinkertaistamaan kompleksien ratkaisujen kehitystä ja myös niiden ylläpitoa. Siinä missä kehityksen alkutaipaleella niiden kautta varmistetaan sovelluksen laatu, niin pitkällä tähtäimellä ne mahdollistavat paremman elinkaaren hallinnan ja tällä tavalla myös paremman sijoituksen takaisinmaksun.
Eli kun vertaillaan työmääriä, niin on oikeasti hyvä tarkastella, että millä kriteereillä vertailu tehdään. Halutaanko maksaa nopeasta ja halvasta kehityksestä, jonka lopputuloksena on kalliilla ylläpidettävä ja kompleksi ratkaisu, vai halutaanko maksaa laadullisesta kehityksestä, jonka lopputuloksena on selkeämpi kokonaisuus ja helpommin ylläpidettävä ratkaisu?
CI/CD, automatisoitu testaus, pariohjelmointi ja refaktorointi voivat vaikuttaa turhanpäiväiseltä ohjelmointihömpötykseltä, mutta ne auttavat vähentämään kehitystyön kompleksisuutta ja takaavat, että toteutus on laadukasta.
Cynefin
Kompleksisuuden ymmärrys on avainasemassa kun puhutaan nykypäivän sovelluskehityksestä. Olen itse löytänyt apua aiheen käsittelyyn Dave Snowdenin Cynefin viitekehyksestä. Alunperin malli kehitettiin tiedonhallinnan apuvälineeksi, mutta nykypäivänä siitä on tullut myös erittäin suosittu työkalu johtamiseen. Aiheesta kiinnostuvan kannattaa tutustua Harward Business Reviewssä jo 2007 julkaistuun artikkeliin.
Pähkinänkuoressa Cynefin lähtee liikkeelle vallitsevan tilanteen ymmärtämisestä ja siitä, että sovelletaan oikeanlaisia menetelmiä oikeanlaisissa tilanteissa. Mallin keskiössä on viisikenttä, joka kuvaa mahdolliset erilaiset tilanteet ja niihin soveltuvat käytännöt ja toimintamallit:
Ilmiselviin tilanteisiin lasketaan ne, missä kaikki tarvittava tieto on saatavilla ja tehtävät ovat yksinkertaisia ja toistettavia. Näissä tilanteissa voidaan soveltaa jo ennestään parhaiksi tunnistettuja käytäntöjä.
Monimutkaisissa tilanteissa tarvitaan jo jonkin verran enemmän erikoisosaamista ja kykyä analysoida tilannetta. Ratkaisut syntyvät analysoinnin ja tunnettujen hyvien käytäntöjen soveltamisen kautta.
Kompleksit tilanteet vaativat luovuutta. Ne edellyttävät ongelman tarkempaa tutkimista sekä mahdollisten kokeiluiden tekemistä ennen kuin ratkaisu löytyy.
Kaootiset tilanteet edellyttävät ensisijaisesti toimintaa. Ongelma vaatii välitöntä toimintaa ilman, että välttämättä tiedetään täysin miten toiminta vaikuttaa. Tärkeintä on kuitenkin toimia ja sitten tarkastella toiminnan vaikutusta ja edetä sen mukaan, että auttoiko tämä vai ei.
Epäjärjestyksen alueelle päästään kun ei tiedetä missä edellisestä neljästä toimitaan.
Työkalut tilanteen mukaan
Nykypäivän sovelluskehitys on lähtökohtaisesti kompleksia ja se edellyttää oikeiden toimintamallien hyödyntämistä. Vanhan ajan vesiputousmallissa ei sinänsä ole mitään vikaa, mutta se soveltuu parhaiten ilmiselvien ja osittain monimutkaisten tilanteiden hallintaan.
Ketterät sovelluskehitysmallit on suunniteltu kompleksien ongelmien hallintaan.
Ymmärretään minkälaisten ongelmien kanssa ollaan työskentelemässä. Pilkotaan ongelmat pienemmiksi kokonaisuuksiksi. Suunnitellaan, arvioidaan ja parannetaan jatkuvasti. Hyödynnetään hyviä teknisiä käytäntöjä. Lopputulos voi yllättää positiivisesti.
Hyvää kesää!
