Ketterästä kehityksestä puhutaan paljon ja sillä tarkoitetaan yleisesti iteratiivisia kehitysmenetelmiä. Toisinsanoen järjestelmää rakennetaan pienissä kehitysjaksoissa tai osakokonaisuuksissa perinteisen projektiajattelun sijaan, jossa järjestelmä pyyritään suunnittelemaan ja määrittelemään alkuun kokonaisuudessaan.
Tämä kirjoitus ”Määrittelyn ja arvioinnin haasteet ohjelmistokehityksessä” keskittyy projektien suunnitteluun ja määrittelyyn. Pyrin osoittamaan käytännön esimerkeillä, miksi kannattaa lähteä liikkeelle ketterästi perinteisen vesiputousmallin sijaan. Kuulisinkin mielelläni kuinka moni tämän lukijoista on ollut mukana keskisuurissa tai suurissa projekteissa, joissa homma aloitetaan useita kuukausia ja joskus jopa vuosia kestävällä määrittelyvaiheella?
Entä kuinka monelle on näistä projekteista jäänyt sellainen fiilis, että määrittelyvaiheen voidaan katsoa onnistuneen? Speksi osui nappiin ja matkalla ei tarvinnut vääntää kättä muutoksista ja asiakas sai just sen, mitä halusi? Mikään tarve ei muuttunut projektin aikana ja rahaa ei kulunut turhaan? Mitä suurempaa kokonaisuutta yritetään määritellä kerralla, sitä suuremman riskin kanssa ollaan liikenteessä. Muuttuvassa maailmassa on yhä haastavampaa kertoa mitä yrityksen liiketoiminnassa tapahtuu esimerkiksi vuoden päästä.
Tehdään pikainen käytännön harjoitus:
-
Pyydän kirjoittamaan käyttämääsi hakukoneeseen sanan kaupunki. Avaa ensimmäinen hakutulos ja tutkaile hetki kuvaa ja kerro kuinka monta ihmistä tuossa kuvassa näkyvissä rakennuksissa asuu.
-
Seuraavaksi kirjoita hakukoneeseen sana pilvenpiirtäjä. Toista sama prosessi ja kirjoita ylös kuinka monta ihmistä siinä asuu tai työskentelee päivittäin.
-
Kolmanneksi hae sanalla kerrostalo. Tässä vaiheessa uskaltaisin väittää, että arviointi helpottuu. Todennäköisesti kuvasta hahmottuu kerrosten määrä ja pystyt arvioimaan ydinperheen koon mukaan (2+2 hlö) asukkaiden määrää. Arvio ei kuitenkaan ole kovin tarkka.
-
Neljänneksi hae sanalla rivitalo. Nyt todennäköisimmin liikutaan tuossa ydinperhe luokassa ilman suurempia muuttujia ja pystyt antamaan suhteellisen tarkan arvion asukkaiden määrästä.
-
Viimeiseksi hae sanalla yksiö. Väitän, että Suomessa voidaan arvioida että asunnossa asuu 1-2 henkilöä.
Yllä olevasta harjoituksesta saa käytännönläheistä mielikuvaa siitä, kuinka hankalaa laajoja järjestelmäkokonaisuuksia on arvioida ja määritellä. Yritä määritellä isoon kaupunkiin kaikki palvelut (järjestelmän toiminnot), liikennesäännöt ja kaupunkikuva (navigointi ja käyttöliittymä), järjestyssäännöt ja lait (tietoturva ja hallinta) kerralla kuntoon. Muistithan ottaa huomioon kaikki poikkeustapaukset ja sen että kaupunki kehittyy ja laajenee vielä jatkossakin (jatkokehitettävyys ja koodin laatu)? Yhteydet viereisiin kaupunkeihin ovat toki myös tärkeitä, pitäähän ihmisten päästä liikkumaan! (integraatiot ja big data)
Eli kun seuraavaksi kysytte kehittäjiltänne tai ohjelmistotoimittajalta arvioita laajasta kokonaisuudesta, kauanko tämän toteutus nyt kestää, pohtikaa asiaa yllä olevan harjoituksen kautta. Oletteko aivan varmasti ottaneet kaiken huomioon?
Määrittelyt ja tarpeet varmasti muuttuvat matkan varrella, joten keskustellaan asioista yhdessä, opitaan tehdessä ja onnistutaan useita kertoja toteuttamalla pieniä osakokonaisuuksia. Näin tekeminen pysyy läpinäkyvänä ja virheiden mahdollisuus pienenee.
Kirjoittaja: Joonas Koski
Scrum Master, Projektipäällikkö ja HR-asiantuntija
[email protected] / 0400 293 636
