Useimmista ketteristä kehitysmalleista sanotaan, että ne ovat "iteratiivisia ja inkrementaalisia". Mutta mitä tämä oikein tarkoittaa? Usein näitä sanoja käytetään ristiin ja monille onkin hieman epäselvää mitä näillä tarkoitetaan. Molemmat termit liittyvät projektin elinkaaren hallintaan ja kummankin mallin käytöstä seuraa, että projektin suunnittelua (ehkä myös vaatimusten keräilyä) tapahtuu useaan otteeseen projektin aikana. Seuraavissa luvuissa on esitelty mitä eroja näillä on ja mitä näiden yhdistelmä tarkoittaa.

Inkrementaalinen kehitys

Inkrementaalisuus ei ole mitään uutta, vaan osatoimituksiin perustuvia malleja on ollut olemassa niin kauan kuin sovelluskehitystä on tehty. Usein näitä malleja on kutsuttu myös vaiheistetun toimituksen malleiksi. Ajatuksena on siis rakentaa suuri kokonaisuus pienistä palasista. Projekti saattaa koostua ikäänkuin useasta peräkkäin olevasta vesiputousmallista. Perinteiset vaiheistetut projektit saattoivat kuitenkin toimia niin, että ensin tehtiin täydellinen analyysi ja suunnittelu ja vain toteutusvaihe oltiin jaettu useampaan osatoimitukseen.

Osatoimituksilla saatava etu on siinä, että asiakas saa nopeammin jotain käyttökelpoista ja toisaalta projektiryhmä tottuu julkaisemaan tuotoksiaan säännöllisesti. Tapauksesta riippuen riskinä voi olla se, että projektin aikana tuleviin muutoksiin voi olla hankala reagoida ja toisaalta eri osatoimitusten toisiin liittämisestä voi aiheutua yllättäviä ongelmia.

Inkrementaalisia menetelmiä on erilaisia ja niissä on suuria eroja sen suhteen, mitä kaikkea projektissa tehdään inkrementaalisesti. Perinteisimmillään vain toteutus on inkrementaalista (analyysi ja suunnittelu on tehty etukäteen), toisessa ääripäässä on useiden vesiputousten jatkumo.

Inkrementaalisuudella tarkoitetaan siis kokonaisuuden toimittamista pienissä paloissa.

Iteratiivinen kehitys

Tämäkin on konseptina jo vanha, evolutiivisena protoiluna myöskin tunnettu. Äärimmilleen vietynä mallissa kehitetään hyvin nopesti ensimmäinen versio koko sovelluksesta ja tätä sovellusta sitten parannetaan iteroiden niin kauan, kunnes asiakas on tyytyväinen ja ottaa sovelluksen käyttöön.

Riskinä tässä mallissa on se, että se degeneroituu koodaa ja korjaa -menetelmäksi. Toinen huono puoli on se, että tuotteen käyttöönotosta voi muodostua suuri urakka siinä vaiheessa kun asiakas lopulta hyväksyy tuotteen käyttöönotettavaksi.

Hallitusti käytettynä iteratiivisuus on kuitenkin tehokas keino riskien hallintaan. Toteuttamalla nopeasti "karvalakkiversio" toiminnallisuudesta saadaan käsitys onko käytetty teknologia ja arkkitehtuuri toimivat ja tarvittaessa voidaan pyytää myös käyttäjäpalautetta. Seuraavassa iteraatiossa sitten toimintoa kehitetään eteenpäin.

Iteratiivisuudella tarkoitetaan siis saman asian tekemistä useaan kertaan.

Ketterä näkemys: iteratiivinen ja inkrementaalinen

Ketterässä kehityksessä yhdistetään usein molemmat edellä kuvatut mallit. Inkrementillä tarkoitetaan tarkoitetaan toiminnallisuuden palasta, mikä on tarvittaessa käyttöönotettavissa. Iteraatiolla taasen tarkoitetaan yhtä sykliä, jonka aikana inkrementti valmistetaan. On huomattava, että inkrementin valmistumisaika ei välttämättä ole sama kuin iteraation pituus. Scrumin tapauksessa näin on, ja yhtä iteraatiota / inkrementin valmistumisaikaa kutsutaan sprintiksi. On kuitenkin mahdollista, että yhden inkrementin aikana tehdään useampia iteraatioita.

Scrum ja XP ovat iteratiivisia, koska lähtökohtaisena tarkoituksena on jatkuvasti parantaa kehitettävänä olevaa sovellusta ja sen toimintoja paremmaksi. Inkrementaalisuus taas ilmenee siinä, että toimintoja julkaistaan pieninä palasina.

Oheisessa kuvassa on esitetty yksi esimerkki, miten projekti saattaisi jaksottua. Inkrementtien ja iteraatioiden lukumäärä tässä esimerkkiprojektissa on sattumanvarainen.

Julkaisemalla tuotoksia usein saavutetaan hyötyä siitä, että koko sovelluskehitysprosessi käydään läpi päästä päähän - vaatimusten keräämisestä aina julkaisuun asti. Kun julkaistava sovellus on vielä pieni, on mahdollisten ongelmien ratkaiseminen helpompaa. Kun projektin aikana tapahtuu useita julkaisuja, koko prosessin tehostaminen on mahdollista jo projektin aikana. Jos koko projektin tuotokset julkaistaisiin yhtenä suurena julkaisuna, julkaisuvaiheen ongelmiin ei osattaisi varautua etukäteen millään tavoin.

Iteroimalla julkaisun sisällä on saavutettavissa useita hyötyjä. Seuraavassa muutamia:

• Usein asiakkaan vaatimukset selkiytyvät vasta kun hän näkee ensimmäisen toimivan version. Ensimmäisen iteraation jälkeen on hyvä tilaisuus tarkentaa vaatimuksia ja tehdä toinen iteraatio, jossa on huomioitu asiakkaan kommentit.
• Joskus yhden asian tekemiseen on useita vaihtoehtoja ja ensin valittu vaihtoehto saattaa osoittautua toimimattomaksi. Iteroimalla ongelmaan löytyy parhaiten toimiva ratkaisu.
• Kun toiminnosta on tehty ensimmäinen versio nopeasti esiteltäväksi, voidaan toteutuksen laatua parantaa seuraavan iteraation kuluessa. Tämä parantaa järjestelmän ylläpidettävyyttä ja saa aikaan kustannussäästöjä tulevaisuudessa.
• Parantaa projektin näkyvyyttä ja tehostaa kommunikaatiota. Ennen julkaisua valmistuvat väli-iteraatiot mahdollistavat tiimin ulkopuolisten jäsenten nähdä, mitä tiimi on saanut aikaiseksi. Tarvittaessa myös käyttäjiltä voidaan saada palautetta jo ennen julkaisua.
• Iteroimalla voidaan varmistaa, että käyttäjien vaatimukset on oikein ymmärrettyjä. Toisaalta, käyttäjät voivat myös varmistua siitä, että toiminto on lopulta käytettävä ja kustannusten arvoinen.

"It's not the strongest of the species that will survive, or the most intelligent. It is the one most adaptable to change." - Charles Darwin

Inkrementit parantavat sovelluskehitysprosessin laatua ja iteraatiot parantavat sovelluksen itsensä laatua.