Mitä eroa on iteratiivisella ja inkrementaalisella kehityksellä?
Koulutuksissani huomaan usein, että opiskelijat sekoittavat iteratiivisen ja inkrementaalisen kehityksen (IID) toisiinsa. Tämän artikkelin tavoitteena on auttaa ymmärtämään inkrementaalisen ja iteratiivisen kehityksen välistä suhdetta.
Aloitan vesiputous- ja ketterän lähestymistavan vertailulla käyttäen esimerkkinä maksusovelluksen toimittamista. Näistä lähestymistavoista on mukana myös vastaava miniverkkoseminaari. Artikkelin toisessa osassa sijoitan vesiputousmallin ja ketterän lähestymistavan matriisiin, joka näyttää inkrementaalisen ja iteratiivisen kehityksen leikkauspisteen, ja selitän kaikki matriisin neljä neljännestä.
Ketterä lähestymistapa ja vesiputousmalli: maksusovelluksen kehittäminen
Vesiputousmalli
Jos tämä esimerkkisovellus kehitetään perinteisen vesiputousmallin mukaisesti, kuvassa 1 voidaan havaita seuraavat vaiheet.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Kuva 1: Kaavio esittää tyypillisen vesiputousmallisen elinkaaren käyttäen esimerkkinä sovelluksen toimittamista.
Projektin käynnistäminen
Kaikki alkaa markkinointiosaston projektin sponsorista, joka onnistui vapauttamaan sovellusta varten tarvittavat varat. Hän oletti, että sovellus parantaisi asiakkaiden pysyvyyttä ja uusien asiakkaiden määrää. Hän hahmotteli kolme korkean tason toimintoryhmää.
Kun projekti on hyväksytty, sille nimetään projektipäällikkö ja kootaan projektiryhmä. Lukuisten keskustelujen ja vaatimusten keräämistä koskevien työpajojen jälkeen sovittiin, että toimitetaan maksusovellus, jossa on 250 toiminnallisuutta. Kaikki nämä ominaisuudet kirjataan laajaan ja erittäin yksityiskohtaiseen ohjelmistovaatimusasiakirjaan, jonka projektin sponsori ja asiakkaan edustaja sekä muut keskeiset sidosryhmät allekirjoittavat.
Projektin suunnitteluvaihe
Seuraavassa vaiheessa projektiryhmä muuntaa vaatimukset sovelluksen suunnitelmaksi. Arkkitehti tarkistaa suunnitelman suunnitteluperiaatteita vasten. Hän tarkistaa myös, ovatko kaikki vaaditut tieto-ominaisuudet saatavilla taustajärjestelmässä.
Projektia on nyt kulunut kaksi kuukautta, eikä asiakas ole vielä nähnyt mitään toimivaa, ainoastaan joitakin edistymisraportteja. Näihin edistymisraportteihin liittyy todennäköisesti jonkinlaista ’vesimeloni’-raportointia, minkä vuoksi asiakkaalle ei selviä, onko projekti aikataulussa vai ei.
Projektin kehitysvaihe
Sovelluksen kehittäminen kestää kuusi kuukautta, ja kun se on valmis, asiakkaan edustajaa pyydetään toimittamaan henkilöitä, jotka voivat auttaa käyttäjähyväksyntätestauksessa. Testin aikana käy ilmi, etteivät useat ominaisuudet toimi.
Projektiryhmä ei ymmärrä miksi. Kaikki on kuvattu täsmälleen samalla tavalla vaatimusasiakirjassa. Tämä johtaa lukuisiin keskusteluihin, uudelleentyöhön ja viivästyksiin, eivätkä asiakkaat ole tyytyväisiä tuloksiin. Lisäksi lopputulosta tarkasteltaessa saatamme huomata, että asiakas ei käytä monia kehitetyistä vaatimuksista lainkaan tai käyttää niitä vain harvoin.
Tilanne voisi olla vieläkin huonompi. Oletetaan, että sovelluksen kehittäminen kesti 1,5 vuotta ja toinen pankki toimittaa maksusovelluksen, kun oma sovelluksesi on puolivälissä. Mitä tekisit tuossa tilanteessa? Olisiko sinulla silloin edelleen toteuttamiskelpoinen liiketoimintaperuste oman sovelluksesi kehittämisen ja viimeistelyn jatkamiselle?
Kuvaa 1 tarkasteltaessa käy selväksi, että vesiputousmallissa laajuus ja taustalla olevat laatukriteerit ovat kiinteitä, ja toimitus tapahtuu kerralla. Kaikki vaiheet suoritetaan kerran koko projektin aikana, ja johdon valvonta keskittyy kustannuksiin ja aikaan. Arvon toimittaminen asiakkaalle tapahtuu vasta koko sovelluksen käyttöönoton jälkeen.
Ketterä lähestymistapa
Jos kehitämme sovellusta ketterän projektinhallinnan lähestymistapaa käyttäen, näemme seuraavanlaisen toimintamallin:
- Kehitystiimi ilmoittaa pystyvänsä toimittamaan tuoteomistajan ensimmäisessä iteraatiossa priorisoimat kaksi ensimmäistä ominaisuutta.
- Projektiryhmä toimittaa kolmen viikon välein (sprintissä, iteraatiossa tai aikarajatussa jaksossa) tuotteen uuden inkrementin.
- Ensimmäisten toimitusten eli inkrementtien jälkeen näemme asiakkaan, joka luottaa projektin onnistuvan. Hänellä on jo toimiva sovellus ja hän ymmärtää, etteivät kaikki ominaisuudet ole vielä mukana, mutta mukana olevat ominaisuudet toimivat.
Viimeisintä julkaisua ja sen sisältämiä ominaisuuksia tarkastellessaan asiakas mainitsee täysin uuden ominaisuuden. Kukaan ei ollut ajatellut sitä projektin alussa, mutta se voisi tehdä asiakkaan työstä tuottavampaa.
Jokaisen inkrementin jälkeen asiakkaan palaute johtaa uusiin toiminnallisuuksiin, joita ei ollut alkuperäisessä luettelossa, tai mahdollisten ominaisuuksien mukautuksiin. Tuote kypsyy jatkuvasti. Jokaisen inkrementin myötä asiakas saa uuden version ja on tyytyväisempi.
Kuva 2: Kaavio esittää ketterän kehityksen syklin käyttäen samaa sovelluksen toimitusesimerkkiä.
Kun tarkastelemme kuvaa 2, näemme toimitusten tasaisen virran kiinteän ajanjakson aikana ja pysyviä ketteriä tiimejä käyttäen (nämä ovat kiinteitä kustannuksia). Laajuus ja taustalla olevat laatukriteerit ovat joustavia (dynaamisia), ja pieniä toimituksia tehdään usein (nämä ovat inkrementtejä).
Kaikki ominaisuuden tai käyttäjätarinan toimittamiseen tarkoitetut vaiheet suoritetaan toistuvasti (eli prosessi on iteratiivinen), kunnes vaadittu laatu saavutetaan. Johdon valvonta keskittyy asiakasarvon toimittamiseen. Asiakasarvoa toimitetaan jokaisen inkrementin käyttöönoton jälkeen.
Vesiputousmalli vai ketterä kehitys: toimitusten tulokset
Kun tarkastelemme lähemmin vesiputousmallilla ja ketterällä ohjelmistokehitysmenetelmällä toteutettuja kahta tuotetta, näemme tuotteen, jossa on 250 ominaisuutta ja melko tyytymätön asiakas, sekä tuotteen, jossa on vain 150 ominaisuutta ja erittäin tyytyväinen asiakas (katso kuva 3).
Kuva 3: Tässä kaaviossa verrataan vesiputousmallin ja ketterien menetelmien eroja ajan, ominaisuuksien määrän ja asiakastyytyväisyyden osalta.
Jos tarkastelemme ketterällä menetelmällä toimitettua tuotetta vielä yksityiskohtaisemmin, näemme alkuperäisestä luettelosta vain 100 ominaisuuden osajoukon sekä 50 uutta tai mukautettua ominaisuutta. Tämä vastaa joitakin periaatteita, jotka sisältyvät ketterän kehityksen manifestiin, kuten:
- Yksinkertaisuus, joka tarkoittaa tekemättä jätettävän työn määrän maksimointia: vain 150 ominaisuutta 250:n sijaan
- Muuttuvien vaatimusten hyväksyminen myös myöhäisessä kehitysvaiheessa: asiakaspalautteeseen mukautuminen jokaisen iteraation ja inkrementin jälkeen
Ketterät kehitysprosessit hyödyntävät muutosta asiakkaan kilpailueduksi (50 uutta tai mukautettua ominaisuutta toimitettiin). Tämän seurauksena asiakas on erittäin tyytyväinen. Tiimin tärkein tavoite on asiakkaan tyytyväisyyden varmistaminen arvokkaiden ohjelmistojärjestelmien varhaisella ja jatkuvalla toimituksella.
Lyhyt webinaari: vesiputousmallin ja ketterän kehityksen toimitukset
Tässä on lyhyt webinaari, jossa käsitellään tarkemmin vesiputousmallin ja ketterän kehityksen toimitusten eroja.
Iteratiivisen ja inkrementaalisen kehityksen erot
Nyt kun olen käsitellyt vesiputousmallin ja ketterän lähestymistavan eroja maksusovelluksen luomista koskevan esimerkin avulla, sijoitan vesiputousmallin ja ketterän kehityksen matriisiin, jossa verrataan iteratiivista ja inkrementaalista kehitystä.
Viimeisenä vaiheena käsittelen kelvollista vähimmäistuotetta (MVP) ja markkinoille vietävää vähimmäistuotetta (MMP) sekä osoitan, miten ne sijoittuvat eri lähestymistapoihin ja tarinakarttaan. Olen sisällyttänyt mukaan myös asiaa käsittelevän lyhyen webinaarin.
Iteratiivisen ja inkrementaalisen kehityksen matriisi
Kuten todettua, huomasin, että opiskelijat sekoittavat usein iteratiivisen ja inkrementaalisen kehityksen keskenään. Kuvassa 4 on neljä neljännestä, jotka muodostuvat vaakasuorasta linjasta, joka kuvaa inkrementaalisuutta tai sen puuttumista, sekä sen leikkaavasta pystysuorasta linjasta, joka kuvaa iteratiivisuutta tai sen puuttumista. Katso tämä YouTube-video, jossa kuva esitetään hyvin yksinkertaisessa muodossa.
Kuva 4: Tämä matriisi esittää erilaisia kehityslähestymistapoja sekä sen, tarvitseeko näitä lähestymistapoja noudattavien tiimin jäsenten iteroida ja/tai työskennellä inkrementteinä.
Alempi vasen neljännes
Vasemmassa alakulmassa näemme lähestymistavan, jossa ei ole iteraatioita eikä inkrementtejä. Tämä on vesiputousmalli. Kaikki toiminnot (suunnittelu, analysointi, rakentaminen, testaus ja käyttöönotto) suoritetaan kerran koko projektin aikana.
Tässä tapauksessa näemme kiinteään laajuuteen perustuvan lopputuotteen kertatoimituksen. Asiakasarvo voidaan saavuttaa vasta lopputuotteen toimituksen jälkeen. Yksi tämän lähestymistavan keskeisistä tavoitteista on kustannusten hallinta.
Alempi oikea neljännes
Oikean alaneljänneksen alueella näemme inkrementaalisen lähestymistavan ilman iteraatioita. Kyseessä on tuotteen pienempien osien vaiheittainen tai inkrementaalinen toimittaminen. Kaikki tietyn vaiheen toiminnot (suunnittelu, analysointi, rakentaminen, testaus ja käyttöönotto) suoritetaan kerran.
Tietyn vaiheen laajuus on kiinteä, mutta koko tuote perustuu dynaamisempaan tai joustavampaan laajuuteen. Asiakasarvoa voidaan saavuttaa jokaisen tuotetoimituksen jälkeen. Yksi tämän lähestymistavan keskeisistä tavoitteista on toimituksen nopeus.
Ylävasen neljännes
Vasemman yläneljänneksen alueella näemme spiraalimaisen tai iteratiivisen lähestymistavan ilman inkrementtejä. Kyseessä on yksi toimitus, jossa lopullinen tuote luodaan useiden iteraatioiden kautta. Hyvä esimerkki tästä lähestymistavasta on muotoiluajattelu. Kaaviossa näet toimintojen sarjan: kehystys, analysointi, ideoiden tuottaminen, toteutus ja reflektointi.
Tämä sarja suoritetaan toistuvasti eli iteratiivisesti, jolloin jokaisen iteraation aikana päästään lähemmäs lopullista, oikeaa tai vaadittua tuotetta. Monissa tapauksissa tämä lopullinen tuote on prototyyppi tai malli. Tässä spiraalimaisessa lähestymistavassa laajuus on dynaaminen tai joustava. Asiakasarvoa voidaan saavuttaa vasta lopullisen tuotteen toimituksen jälkeen. Yksi tämän lähestymistavan keskeisistä tavoitteista on ratkaisun oikeellisuus.
Yläoikea neljännes
Oikean yläneljänneksen alueella näemme ketterän lähestymistavan, jossa käytetään inkrementtejä ja iteratiivista menetelmää. Scrum on hyvä esimerkki tästä lähestymistavasta.
Jokaisen inkrementin lopussa, jota kutsutaan usein sprintiksi tai aikarajaukseksi, toimitetaan tuotteen inkrementti. Tämä inkrementti on tulos useista iteraatioista, joiden aikana kehitetään tuotteen pieniä mutta oikeellisia osia, joita kutsutaan usein käyttäjätarinoiksi tai työjonon kohteiksi. Lopullinen iteratiivinen projekti toimitetaan osa kerrallaan.
Tässä ketterässä lähestymistavassa laajuus on dynaaminen tai joustava. Asiakasarvoa voidaan saavuttaa jokaisen tuotetoimituksen jälkeen. Yksi tämän lähestymistavan keskeisistä tavoitteista on asiakasarvon tuottaminen tiheiden toimitusten ja käyttäjäpalautteen avulla.
MVP vai MMP?
Kuvassa 4 näet myös lyhenteet MVP ja MMP. MVP tarkoittaa pienintä toimivaa tuotetta (minimum viable product), joka on uudesta tuotteesta tai palvelusta julkaistu versio ja jonka avulla tiimi voi kerätä mahdollisimman paljon tietoa asiakkaista sekä validoida oletukset mahdollisimman vähäisellä vaivalla. Dropbox-palvelun MVP oli yksinkertainen video. Tämä tarkoittaa, että MVP:n P voi olla täysin eri tuote kuin lopulliseksi tuotteeksi päätyvä tuote.
MVP:tä ja MMP:tä havainnollistava esimerkki
Käytän usein seuraavaa esimerkkiä uudesta rahoitustuotteesta. Innokkaalla myyntipäälliköllä on loistava idea uudesta rahoitustuotteesta. Hän uskoo, että tuotetta voidaan myydä vähintään 100 000 kappaletta.
Yhdessä joidenkin rahoitusalan asiantuntijoiden kanssa he suunnittelevat tuotteen muutamassa kuukaudessa. Tuotteelle osoitetaan kehitystiimi, ja sen kehittäminen vie tiimiltä 4 kuukautta. Samanaikaisesti laaditaan kaupalliset esitteet, ja tuote julkaistaan suuressa tapahtumassa.
Valitettavasti vain muutama ihminen ostaa tuotteen. Jos noudatamme MVP-lähestymistapaa, voimme olettaa, että 10 % verkkokäyttäjistä on kiinnostunut tästä tuotteesta. Kehittäisimme sen jälkeen MVP:n tämän hypoteesin testaamista varten.
Tässä tapauksessa MVP voisi olla yksinkertainen painike etusivulla. Kun painiketta napsautetaan, näytölle tulee tätä uutta tuotetta koskeva viesti sekä mahdollisuus lisätä sähköpostiosoite, jos käyttäjä on kiinnostunut. Oletetaan, että alle 1 % kävijöistä painoi painiketta — tuotetta ei olisi kehitetty, ja yritys olisi säästänyt paljon niukkoja resursseja.
Kun tarkastelemme kuvaa 4 lähemmin, näemme MVP:iden mahdollisen käytön kaikissa neljänneksissä. Vesiputousmallia käytettäessä voitaisiin luoda MVP ohjelmiston ensimmäisessä suunnitteluvaiheessa, jotta voidaan tarkistaa, onko projektille liiketoiminnallisia perusteita.
Sama voidaan tehdä ensimmäisen inkrementin ensimmäisessä vaiheessa vaiheittaista toimitusta noudatettaessa. Joissakin tapauksissa muotoiluajatteluun perustuvan lähestymistavan tulos voi olla MVP. MVP:stä voi olla hyötyä myös ketterän lähestymistavan alussa.
Monet pitävät ensimmäistä vaiheittaisen toimituksen lopussa toimitettua tuotetta MVP:nä. Näin voi olla, mutta useimmissa tapauksissa kyseessä ei ole MVP vaan MMP. MMP eli pienin markkinoille soveltuva tuote (minimum marketable product) on pienin tuote, joka voi tuottaa asiakkaalle arvoa.
Miltä ketterä toimitus näyttää?
Nyt kun on selvää, että inkrementaaliset ja iteratiiviset mallit eivät ole sama asia ja ymmärrämme MVP:n ja MMP:n käytön, voimme tarkastella yksityiskohtaisemmin sitä, miltä inkrementaalinen ja iteratiivinen toimitus näyttävät.
Olet todennäköisesti nähnyt Jeff Pattonin kuuluisan esimerkin Mona Lisasta, jossa maalaus luodaan pala palalta (vaiheittainen toimitus). Toinen tapa toteuttaa tämä on aloittaa ensimmäisestä inkrementistä, jossa luodaan vain karkea luonnos, ja lisätä luonnokseen uusia yksityiskohtia jokaisen uuden iteraation myötä, kunnes lopulta käytössäsi on valmis maalaus (inkrementaalinen ja iteratiivinen eli ketterä toimitus).
Ensimmäisessä tilanteessa sinulla on oltava jo alussa yksityiskohtainen käsitys lopullisesta tuotteesta, kun taas toisessa tilanteessa tarvitset vain pääpiirteittäisen hahmotelman, koska muutoksia on paljon helpompi tehdä. Kun tarkastelemme kuvaa 5, näemme uuden ABC-nimisen tuotteen tarinakartan.
Kuva 5: Esimerkki tiettyä tuotetta koskevasta tarinakartasta.
Tuotteen omistaja suunnitteli tälle tuotteelle seitsemän ominaisuutta. Ensimmäiset neljä ominaisuutta ovat pakollisia. Ominaisuudet 5 ja 6 ovat tärkeitä, ja viimeinen ominaisuus on mahdollinen. Monet kutsuisivat tätä MoSCoW-priorisoinniksi (pakolliset, tärkeät, mahdolliset ja sellaiset, joita ei toteuteta).
Jokainen ominaisuus voidaan itsessään pilkkoa pienempiin osiin. Kuvassa näet ominaisuuksia eli käyttäjätarinoita, jotka ovat pakollisia, tärkeitä tai mahdollisia. Ominaisuus voi olla pakollinen, mutta se ei tarkoita, että kaikki sen taustalla olevat käyttäjätarinat olisivat myös pakollisia. Ominaisuus voi myös olla tärkeä, mutta jos toteutat kyseisen ominaisuuden, jotkin käyttäjätarinat ovat pakollisia ja toiset tärkeitä tai mahdollisia.
Tämän ABC-tuotteen toteuttamiseksi näet viisi inkrementtiä eli julkaisua. Ensimmäinen niistä on markkinoille soveltuva vähimmäistuote. Tämä MMP koostuu ominaisuuden 1 kahdesta ensimmäisestä pakollisesta käyttäjätarinasta sekä ominaisuuksien 2 ja 3 ensimmäisistä pakollisista käyttäjätarinoista.
Julkaisu 2 sisältää ominaisuuksien 1, 2 ja 3 seuraavat kaksi pakollista käyttäjätarinaa (iteratiivinen kehitys). Tuotekehitys jatkuu toteuttamalla seuraavat julkaisut. Jokaisen julkaisun myötä asiakkaalle tuotettava arvo kasvaa.
Julkaisun 5 jälkeen tuotteen omistaja lopettaa käyttäjätarinoiden toteuttamisen. Asiakkaalta saatu palaute osoitti hänelle, että ABC-tuote on ”tarkoitukseensa sopiva”, ja hän ottaa huomioon ketterän manifestin yksinkertaisuuden periaatteen ja lopettaa jatkokehityksen.
Miniverkkoseminaari: iteratiivinen ja inkrementaalinen kehitys
Tässä on perusteellinen verkkoseminaari iteratiivisesta ja inkrementaalisesta ohjelmistokehityksestä.
Lopuksi
Onko ohjelmistokehitystiimillesi selvää, mitä iteratiivinen ja inkrementaalinen kehitys tarkoittavat? Miten sovellat niitä ketterissä tai vesiputousmenetelmissäsi?
Kerro meille kommenteissa tai liity DPM-jäsenyysohjelmaamme ja keskustele muiden jäsenten kanssa yksityisellä keskustelufoorumillamme!
