Vuosituhannen vaihteessa, kun paremmasta ei tiedetty, projektit vietiin läpi vesiputousmallilla, jossa projektin vaiheet seuraavat toisiaan lineaarisesti. Ai mitkä projektin vaiheet? Monelle VAMK:n tt-opiskelijalle tuttuakin tutumpi mantra, määrittely-suunnittelu-toteutus-testaus-käyttöönotto.
Lineaarinen malli tarkoittaa sitä, että vaiheet seuraavat toisiaan, seuraavaa vaihetta ei aloiteta ennen kuin edellinen vaihe on valmis ja vesiputouksen mukaisesti edelliseen vaiheeseen ei voida palata.
Mantran mukaisesti projekti siis aloitetaan määrittelyvaiheella, jossa selvitetään tarkasti projektin vaatimukset. Kun kaikki asiakkaan tarpeet on kirjattu ylös ja vaatimusmäärittely hyväksytty, voidaan aloittaa suunnitteluvaihe. Suunnitteluvaiheessa määritellään muun muassa käytettävä ohjelmointikieli ja kirjastot, suunnitellaan sovelluksen arkkitehtuuri, tarvittavat komponentit, rajapinnat ja tietokantarakenteet. Kaiken kattavan suunnitelman jälkeen voidaan vasta siirtyä toteutusvaiheeseen ja työntää kädet saveen, eli aloittaa se varsinainen koodaaminen. Kehittäjät tekevät suunnitelman mukaisesti toteutusta, testaavat, koodaavat, testaavat ja koodaavat. Valmista tuli! Testausvaiheessa huomataan että ei todellakaan tullut valmista, käytännössä aloitetaan uusi toteutusvaihe kun kaikki esille tulleet bugit korjataan ja toteuttamattomat vaatimukset kehitetään. Kun asiakas on hyväksynyt toimituksen, voidaan siirtyä käyttöönottovaiheeseen. Lyhyesti siis vesiputousmallissa koko ohjelmiston kehitystyö ja ohjelmiston ominaisuudet suunnitellaan etukäteen ja ne toteutetaan sellaisenaan.
Ensimmäinen oikea softaprojektini oli tilaustyökalun kehittäminen vaasalaiselle pörssiyhtiölle. Projekti vietiin vesiputousmallilla läpi, kollegani kehitti käyttöliittymää ja minä palvelinpuolta. Molempien työ eteni hyvin, valmista tuli. Päästiin testivaiheeseen ja asiakas pääsi ensimmäistä kertaa kokeilemaan työkalua – eihän se toiminut silloin ollenkaan! Me olimme kehittäneet ja testanneet omilla koneillamme, demot esiteltiin omilta koneilta ja sellainen pieni asia jäi huomioimatta kuin kommunikaatio asiakaspään ja palvelinpään välillä. Korjaus oli loppujen lopuksi helppo, mutta opettavainen, monessakin mielessä. Olimme junioreita kehittäjinä ja oletimme liikaa ja tiesimme liian vähän eikä ongelmat tulleet ajoissa esille kun asiakas sai kokeilla työkalua vasta testivaiheessa. Loppu hyvin, kaikki hyvin, 98% yrityksen tilauksista vietiin tuotantoon meidän työkalun kautta. Mutta se mitä alussa määriteltiin oli vain osanen siitä mitä oikeasti tarvittiin. Kun asiakas pääsi oikeasti kokeilemaan ja käyttämään työkalua, tuli esille uusia tarpeita ja vaatimuksia.
Mitä silloin olisi voitu tehdä paremmin? Montakin asiaa, mutta toisaalta on myös muistettava, että elettiin vuosituhannen vaihdetta, teknologiat asettivat rajansa ja toisaalta myös ympäristöt olivat huomattavasti muuttumattomampia kuin nykyään. Meidän ja asiakkaan näkökulmasta projekti oli onnistunut, ja siitä syntyi useiden vuosien yhteistyö, jossa työkalua kehitettiin ja muokattiin toimintaympäristön muuttuessa.
Mutta mitä jos projekti olisi aloitettu tällä vuosikymmenellä? Yksi vastaus parantamiseen olisi ketterien projektimenetelmien käyttö.
Ketterissä malleissa ohjelmistoja kehitetään pienissä palasissa ja lyhyissä ajanjaksoissa, eli sprinteissä.
Samat vaiheet on edelleen käytössä, määrittely-suunnittelu-toteutus-testaus-käyttöönotto(toimitus), mutta nämä vaiheet toistuvat jokaisessa iteraatiossa. Jos projekti kestää vuoden, on vesiputousmallissa näitä jokaista vaihetta vain yksi, ketterissä kehitysmalleissa niitä vaiheita on yhtä monta kuin on iteraatioitakin. Jos meidän projektia olisi aikanaan tehty ketterillä menetelmillä, olisi asiakas saanut jo ensimmäisen kahden viikon sprintin jälkeen jotain kokeiltavaa ja olisimme huomanneet että kommunikaatio ei toimi eri koneilta käytettäessä.
Ketterissä menetelmissä ohjelmistoja kehitetään siis pienissä palasissa ja lyhyissä ajanjaksoissa. Jokaisen kehitysjakson lopussa asiakkaalle toimitetaan uusi versio kehitettävästä ohjelmasta, jolloin myös testaaminen tehostuu ja asiakas pääsee antamaan palautetta. Tiheillä julkaisuilla voidaan varmistaa että lopputulos oikeasti täyttää sille asetetut tarpeet, ei alkuperäiset vaatimukset vaan ne, joita sovelluksen oikeasti tulee täyttää. Jokainen kehitysjakso siis aloitetaan suunnittelulla. Kehitettäväksi valitaan tärkeimpiä ominaisuuksia, ja jokaisen jakson päätteeksi asiakas saa uuden version ohjelmistosta kokeiltavakseen. Jokaisen kehitysjakson päätteeksi myös kehitystiimi analysoi omaa toimintaansa, mikä meni hyvin ja mitä pitäisi jatkossa parantaa. Asiakas saa muuttaa projektin vaatimuksia, tuoda uusia vaatimuksia ja myös poistaa tarpeettomia vaatimuksia projektin aikana. Vesiputousmalli tai näiden hybridimalli on tänäkin päivänä sopiva malli sellaisissa ohjelmistoprojekteissa, joissa asiakkaan tarpeet on hyvin tiedossa ja tarpeiden ei oleteta muuttuvan tai projekteissa joiden on pakko pysyä sille määritetyssä budjetissa. Mitä isompi projekti – sitä todennäköisempää muutokset ovat.
Ketterät kehitysmallit parantavat asiakastyytyväisyyttä, asiakas pääsee osallistumaan ja vaikuttamaan koko projektin ajan kehitykseen ja näin sitoutuu paremmin projektiin.
Ketterät kehitysmallit myös ovat läpinäkyvämpiä, ongelmat tulevat helpommin esille jolloin niihin on myös helpompaa löytää ratkaisuja. Yhteenvetona ketterät menetelmät minimioivat riskejä ja tekevät kaikkien elämästä helpompaa. Ohjelmistoprojekti on matka, jossa lähtöpisteessä harvoin tiedetään 100% varmasti millainen lopputuloksen pitää olla, ketterien menetelmien ansiosta meidän ei onneksi enää tarvitsekaan etsiä sitä täydellistä kristallipalloa.
