Suuret ohjelmistoprojektit ja Agile

Perinteinen suuri ohjelmistoprojekti alkaa yleensä määrittelyprojektilla, jossa pyritään määrittelemään mahdollisimman tarkasti, millaisen ohjelmiston tilaaja tarvitsee. Tässä vaiheessa tilaaja ideoi, esittää tarpeensa ja toiveensa ohjelmistosta, mahdollisesti näyttää tai antaa määrittelijälle pääsyn olemassa olevaan ohjelmistoon. Määrittelyssä luodaan siis raamit sille millainen ohjelmistosta tulee. Määrittelyprojektin jälkeen saadaan määrittelydokumentaatio eli speksi siitä, millainen ohjelmisto tarvitaan. Periaatteessa tilaaja voi ottaa tämän speksin ja mennä sen kanssa mihinkä tahansa ohjelmistotaloon ja tilata ohjelmiston. Tässä vaiheessa ne ongelmat yleensä alkavat. Tai no, ovathan ne alkaneet jo aikaisemmin.
Ongelmana suurien projektien määrittelyissä on, että kaikkia asioita ei vain voida tietää tai huomioida vielä määrittelyvaiheessa. Asiakkaan oma tarvemäärittely saattaa olla kesken tai domain-logiikassa eli bisneslogiikassa on puutteita. Usein liiketoiminnan ytimessä oleva domain-logiikka on vaikea viestiä kolmannelle osapuolelle, jolloin lopputulos voi olla väärä eikä sitä pahimmassa tapauksessa huomata ennen kuin vasta lopullisessa tuotteessa.  Domain-logiikka saattaa myös olla toimittajan mielestä hyvin monimutkainen. Tällöin on tietenkin äärimmäisen haastavaa luoda ohjelmisto, jota asiakas tarvitsee mutta toimittaja ei ymmärrä mitä asiakas tarvitsee.
Asiakas luulee saavansa valmiin tuotteen ja riskiä ei ole, koska sehän on tuotettu määrittelyn mukaan. Ongelma tulee esiin siinä vaiheessa kun tuote ei vastaakaan asiakkaan tarvetta. Kun tehdään suuria ohjelmistoja, joiden logiikka on haastava ja vaativa, olisi tärkeää edetä pienin askelin kehitettäessä, jotta saataisi riskit minimoitua. Pointtina ei ole, etteikö suunniteltaisi etukäteen mitä tehdään ja miten, mutta ei pidä suunnitella sitä liian tarkkaan, koska seuraavan vaiheen lopputulos ohjelmistokehityksessä ei ole yhtä yksinkertaisesti tiedossa kuin jonkin konkreettisen, fyysisen asian kehityksessä.
Miten sitten esimerkiksi julkishallinnot saataisiin avaamaan silmät sille, että vesiputousmallin projekteissa vääjäämättä riskit ovat sitäkin suuremmat mitä projekti on?
Sen sijaan, että asiakas määrittelisi etukäteen speksin ja odottaisi kunnes valmis tuote tulee ulos uunista, voisi asiakas tilata palvelun. Palvelulla tarkoitetaan tässä sitä, että sitoudutaan resurssein toimittamaan asiakkaalle hänen tarvitsemansa tuote. Asiakas voi myös hallita riskiä siten, että ketterän projektin voi keskeyttää mikäli ilmenee ettei ohjelmistoa voidakaan toteuttaa sellaiseksi kun asiakas on tarvinnut tai visioinut.
Ohjelmistokehityksessä tärkeintä on, että  tuote rakennetaan nimenomaan asiakkaalle hänen tarpeisiinsa ja toiveitansa kuunnellen. Tätä varten tarvitsemme tilaajan mukaan kertomaan, millaisen ohjelmiston he haluavat ja tarvitsevat. Siksi ketterä malli on oiva keino asiakkaan saada juuri se, mitä hän tarvitsee. Vain ja ainoastaan asiakkaan osallistumisella kehitykseen päästään pois ohjelmistokehityksen sudenkuopista, noista ”oho, emme tienneet tuota” –hetkistä. Tämä vaatii sitoutumista sekä asiakkaan että toimittajan puolelta yhteisen päämäärän saavuttamiseen.
Agiili kehitysmalli ei tarkoita sitä, etteikö tiedettäisi mitä ollaan kehittämässä. Projektissa pitää olla tietty tavoite ja tieto siitä, minkälaisissa vaiheissa kehitystä viedään eteenpäin. Oleellista on, että suunnitelmia pitää voida muuttaa sitä mukaa kun tietämyksemme seuraavasta kehitysaskeleesta varmistuu.

Miten tämä malli sitten integroituu suureen ohjelmistoprojektiin?

Suuressa ohjelmistoprojektissa voidaan eriyttää monet eri kokonaisuudet pienemmiksi ketteriksi projekteiksi, joita voidaan kehittää vaikka limittäin toistensa kanssa. Myös olemassa olevan järjestelmän korvaaminen uudella voidaan toteuttaa ketterästi. Pieni osa nykyistä järjestelmää voidaan korvata uudella ja hiljalleen siirtyä uudempaan, aina osanen kerrallaan. Tarkoituksena alunperin oli että kirjoitan miten ketterä soveltuu suuriin ohjelmistoprojekteihin, mutta tästä tulikin suurempi pohdinta agiilista. En näe oikeastaan mitään syytä miksi ketterä malli ei soveltuisi suuriin projekteihin, lähestymiskulman täytyy vain olla erilainen.
 
Jani Kärenaho, IT-rakennusmestarina vuodesta 2005