Joitakin vuosia sitten olin tietoiskussa, jonka aiheena oli ohjelmiston vaatimusmäärittelyiden laatiminen. Harjoitusaiheena oli laatia mahdollisimman hyvä määritelmä ostoslistaan omenoista. Osallistujat kirjoittivat hiki hatussa speksiä omenasta ja paras palkittiin. Toden totta, omenasta pystyy määrittelemään monen monta ominaisuutta, kun asiaan oikein perehtyy. Lähellekään täydellistä määrittelyä ei tehnyt kukaan.
Omenan ominaisuuksien speksaaminen havainnollistaa hyvin
kaikkea, mikä perinteisessä etukäteismäärittelyyn perustuvassa mallissa on vialla.
Ihan oikeasti, kuka meistä kirjoittaa ostoslistaan jotain muuta kuin omenia? Onko sinulla koskaan ollut tarvetta määritellä sen tarkemmin?
Paitsi, että ei ole tarvetta, ei ole myöskään mahdollista: ei omenan ominaisuuksia kotona speksatessa tiedetä, minkälaisia omenoita kaupassa on tarjolla ja millä hinnalla. Tämä ongelma on perinteisesti sivuutettu toteamalla, että toteutusyksityiskohdat, kuten mistä omena ostetaan, eivät saa vaikuttaa määrittelyyn. Määrittelyyn vain laitetaan mitä halutaan ja toteutusporukka sitten hoitaa loput.
Höpö höpö.
Tosielämässä se menee niin, että ostoslistaan laitetaan ‘Omenoita’, ehkä suullisesti täsmennetään mihin tarkoitukseen (sellaisenaan syötäväksi vai omenapiirakkaan) ja se on siinä. Kaupassa tehdään lopullinen päätös sen perusteella, mitä nyt sattuu olemaan tarjolla. Jos päättäminen ei ole mahdollista, niin sitten soitetaan kaupasta ja kysytään neuvoja.
Kukaan ei tee niin, että laatii ensin tarkan specifikaation omenoista, lähettää sen koko tiimille tutustuttavaksi, pitää kahden viikon valmistautumisajan jälkeen formaalin katselmoinnin, tekee korjaukset ja hyväksyttää ne esimiehellä. Ja aloita kokonaan alusta, kun kuuden kuukauden päästä huomataan, että raparperipiirakka maistuisikin paremmalta. Ei. Paitsi jos on laatimassa Singapore Airlinesin ruokalistaa seuraaviksi viideksi vuodeksi tai muonittamassa valtameriristeilijää.
Ei tämä malli ole ohjelmistotuotannossakaan järkevä. Parempi on laittaa ylös karkealla tasolla mitä pitäisi tehdä ja sitten kun toteutuksen aika tulee, liiketoimintavastaava ja toteutusporukka yhdessä pohtivat ja sopivat, miten tarkalleen ottaen on paras. Näin. Paitsi jos koodi on kriittinen osa 2 000 000 000 euron Mars-mönkijäprojektia.
Vastaa