Moderni ohjelmistokehitys - vesiputousmalli vs. ketterät menetelmät

Ohjelmistokehitystä on yleensä hallittu kahdella eri tavalla - vesiputousmallillasekä ketterästi. Tiedätkö niiden erot ja mihin tarkoitukseen kumpikin soveltuu? Allavastaus pähkinänkuoressa ja rautalangasta väännettynä.<! data-preserve-html-node="true"--more-->

Vesiputousmalli

Vesiputousmalli on nimensä mukaisesti vaiheittainen suunnitteluprosessi, jossa yksi asia tehdään kerrallaan valmiiksi. Karkealla tasolla, homma menee näin: ensin suunnitellaan, sitten toteutetaan, sitten testataan ja lopuksi toimitetaan.

prosessimallit-02.png

Kun yksi asia on tehty, siirrytään seuraavaan eikä taakse katsota. On siis sanomattakin selvää, että suunnitelmien on tällöin oltava veden - tai oikeastaan vesiputousmallin kestäviä.

Vesiputousmalli soveltuu sellaisiin asioihin, joissa vaatimuksien ei oleteta muuttuvan kesken prosessin. Omakotitalon rakentaminen on hyvä esimerkki - huoneiden määrä harvoin muuttuu kesken rakennustöiden.

Vesiputousmallilla toteutettujen asioiden suunnitelmien on siis oltava tarkat. Niihin on kyettävä määrittelemään etukäteen jokaikinen yksityiskohta. Omakotitalon rakentamisessa tarkka suunnittelu on usein avain onnistuneeseen lopputulokseen. Ohjelmistokehityksessä liian yksityiskohtaiseen suunnitteluun kulutettu aika voi valua hukkaan, jos ohjelmistoa koskevat vaatimukset muuttuvat matkan varrella. Ja usko pois, ne muuttuvat.

Ketterät menetelmät

Ketterissä menetelmissä epäonnistumisen riskit minimoidaan kehittämällä ohjelmistoja pienissä osissa ja lyhyissä ajanjaksoissa. Näitä ajanjaksoja kutsutaan iteraatioiksi. Jokainen iteraatio sisältää samat asiat kuin vesiputousmalli (suunnittelu, toteutus, testaus, toimitus). Kehitystarpeet priorisoidaan kulloisenkin tarpeen mukaan. Ero on siinä, että vesiputousmallin päästä päähän eteneminen voi kestää vuosia ja ketterissä menetelmissä se kestää tyypillisesti 1-2 viikkoa.

prosessimallit-03.png

Lyhyt ajanjakso mahdollistaa, että asioita tulee jatkuvasti valmiiksi ja muutoksiin reagoiminen on helppoa. Muutostarpeita voi syntyä mistä tahansa - esimerkiksi liiketoiminnan fokuksen vaihtumisesta tai asiakkailta saadun palautteen perusteella. Jokaisen iteraation lopuksi koko projektin prioriteetit arvioidaan uudelleen ja niiden pohjalta suunnitellaan seuraavan iteraation sisältö.

Haluatko lukea lisää ohjelmistokehityksestä? Tilaa blogikirjoituksemme suoraan sähköpostiisi, eikä mikään kirjoitus mene sinulta ohi!

Edellinen
Edellinen

Johtaja, et voi ennustaa tulevaa – mutta voit varautua siihen

Seuraava
Seuraava

Tarina rekry­ilmotuksesta, joka keräsi viikonlopun aikana lähes 10 000 silmäparia