Ketterän kehittämisen menetelmät ovat kokoelma periaatteita, joita noudattamalla pääsee hyvään lopputulokseen, eivät yksityiskohtaisia ohjeistuksia siitä, miten kehittämistyötä kannattaa tehdä. Kaikille ketterille menetelmille yhteisiä periaatteita ovat asiakastyytyväisyys, muutoksen hyväksyminen, julkaiseminen (aikaisin ja usein), tasainen tahti, tiivis yhteistyö, suora keskustelu välillisen viestinnän sijaan (kasvokkain), luottamus tekijöihin, tekninen loistokkuus, yksinkertaisuus, itseohjautuvuus ja itsetarkastelu. (Poimala & Tolvanen.) Ketterät menetelmät on kehitetty ensisijaisesti ohjelmistokehittämistä varten, mutta ne ovat sovellettavissa mukaillen myös muuhun kehittämiseen.
Ketterät menetelmät ovat syntyneet nimenomaan toteutusvaiheen ohjaukseen, eikä niihin ole rakennettu sisään hankevalmistelua, esitutkimusta tai tarpeen kartoitusta, jotka on aina tarpeen toteuttaa kaikissa kehittämishankkeissa. Periaatteena ketterissä menetelmissä on siis se, että vaikka ennen hankkeen varsinaista alkua on syytä tehdä esitutkimuksia ja kartoituksia liittyen tarpeisiin ja siihen mitä tavoitellaan, tarkempi suunnittelutyö ja tietysti varsinainen kehittämistyö on tehokkaampaa tehdä toteutusvaiheen aikana kuin paperityönä ennakkoon. Kehittämiskohteesta tuotetaan usein uusia versioita, ja uusien ominaisuuksien tärkeysjärjestys arvioidaan uudestaan kunkin kierroksen jälkeen. (Poimala & Tolvanen.)
Ketterien menetelmien käyttöä Suomessa edistää Agile Finland ry, ja maailmanlaajuisesti Agile Alliance -niminen voittoa tavoittelematon järjestö. ((Beck, Beedle, van Bennekum, Cockburn, Cunningham, Fowler, Grenning, Highsmith, Hunt, Jeffries, Kern, Marick, Martin, Mellor, Schwaber, Sutherland, & Thomas 2001.).
- Agile manifesto
Agile Manifesto on ketterien menetelmien puolestapuhujien periaatteellinen kannanotto ketterän kehittämisen puolesta. Vuonna 2001 eri menetelmien (esim. Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming) asiantuntijoita ja muita vaihtoehtoisesta, kevyemmästä ohjelmistokehittämisestä kiinnostuneita henkilöitä kokoontui yhteen tavoitteenaan löytää vaihtoehtoja dokumentointi edellä tehtäville raskaan sarjan kehittämisprosesseille. Tämän kokoontumisen tuotoksena syntyi Agile manifesto, ketterä manifesti. (Beck ym. 2001.)
Manifestissa todetaan, että kehittämistyössä tulee arvostaa yksilöitä ja vuorovaikutusta enemmän kuin prosesseja ja työkaluja, toimivaa tuotosta (yleisimmin ohjelmisto tai sovellus) enemmän kuin kokonaisvaltaista dokumentaatiota, asiakasyhteistyötä enemmän kuin sopimusneuvotteluita ja muutokseen reagoimista enemmän kuin suunnitelman noudattamista. Vaikka prosessit, työkalut, dokumentaatio, sopimukset ja suunnitelmat ovat myös tärkeitä, manifestin tekijät pitivät ihmisiä, vuorovaikutusta, yhteistyötä ja toimivaa lopputulosta niitä tärkeämpinä. (Beck ym. 2001.) Tuotos kehittyy siis parhaaksi mahdolliseksi ihmisten välisen vuorovaikutuksen ja yhteistyön sekä nopean muutoksiin reagoimisen seurauksena ja prosessit ja dokumentaatio pidetään kevyinä. Suunnitelmia on tietysti syytä tehdä, mutta niistä täytyy olla valmis joustamaan, mikäli kehittämisprosessi ja sen aikana ilmenevät muutokset sitä edellyttävät.
Tärkein tavoite on pitää asiakas (tai muu tilaaja) tyytyväisenä toimittamalla tämän tarpeet täyttäviä versioita ohjelmistosta tai muusta tuotoksesta jo aikaisessa vaiheessa ja tuottamalla asiakkaalle säännöllisesti päivitettyjä versioita. Muuttuvat vaatimukset on hyvä ottaa vastaan myös kehityksen myöhäisessä vaiheessa. Ketterät menetelmät hyödyntävät muutosta asiakkaan kilpailukyvyn edistämiseksi. (Beck ym. 2001.) Tuotoksen tekemisessä otetaan siis huomioon ajankohtaiset tilaajan toimintakentän muutokset ja niiden vaikutukset tuotokseen, jotta ei tehdä sokeasti alkuperäisen suunnitelman mukaista tuotosta, joka voi olla valmistuessaan jo lähtökohtaisesti hiukan vanhentunut.
Tärkeänä periaatteena on toimittaa versioita toimivasta ohjelmistosta säännöllisesti, parin viikon tai kuukauden välein, ja suosia lyhyempää aikaväliä. Tilaajan ja kehittämisprojektitiimin tulee työskennellä yhdessä päivittäin koko projektin ajan. Projektit tulee lähtökohtaisesti rakentaa motivoituneiden yksilöiden ympärille, joille annetaan puitteet ja tuki, jonka he tarvitsevat. Sitten täytyy luottaa siihen, että he saavat työn tehtyä. Tehokkain ja toimivin tapa tiedon välittämiseksi kehittämistiimille ja tiimin jäsenten kesken on kasvokkain käytävä keskustelu. Toimiva tuotos, oli se sitten ohjelmisto tai vaikka organisaation uusi tapa toimia, on edistymisen ensisijainen mittari. Ketterät menetelmät kannustavat kestävään toimintatapaan, jossa hankkeen omistajien, kehittäjien ja ohjelmiston (tai muun tuotoksen) käyttäjien tulisi pystyä ylläpitämään työtahtinsa hamaan tulevaisuuteen. Tähän liittyy oleellisesti dokumentoinnin ja etukäteen tehtävän työn keventäminen, tilaajan tarpeiden ehdoilla eteneminen ja tuotoksen muovaaminen vastaamaan näihin tarpeisiin. Yksinkertaisuus – tekemättä jätettävän työn maksimointi – on oleellista. Parhaat arkkitehtuurit, vaatimukset ja suunnitelmat syntyvät itseorganisoituvissa tiimeissä. Tiimi tarkastelee säännöllisesti, kuinka parantaa tehokkuuttaan, ja mukauttaa toimintaansa sen mukaisesti.(Beck ym. 2001.)
- Ketterät menetelmät käytännössä
Ketterät menetelmät noudattavat käytännössä viittä perusperiaatetta: 1. ennakkomäärittelyä ei tule tehdä liikaa, 2. toteutus aloitetaan vaikeimmista ja tärkeimmistä asioista, 3. ohjelmistoa (tai muuta kehittämistä) ei tehdä palasina, vaan jatkuvasti parantaen ja testaten, 4. testaus ei ole erillinen työvaihe projektin lopussa, vaan jatkuva toiminto ja 5. ennakkomäärittelyn käyttäjätarinat ovat teknisiä yksityiskohtia tärkeämpiä. (Poimala & Tolvanen.)
Ketterän kehityksen ideologiassa lähdetään siitä, että kaikkien vaatimusten kirjaaminen etukäteen ei useinkaan onnistu. Vaikka siinä näennäisesti onnistuttaisiinkin, projektin aikana törmätään kuitenkin moniin määrittelyn puutteisiin, muutostarpeisiin ja väärinymmärryksin. Kärjistetysti voikin todeta, että mitä vähemmän osaamme sanoa toteutettavan tietojärjestelmän yksityiskohdista ennakkoon, niin sitä todennäköisemmin projektissa kannattaa soveltaa ketteriä menetelmiä. (Poimala & Tolvanen.)
Toinen keskeinen teema on keskittyminen tekemään koko ajan korkeimman prioriteetin ominaisuuksia. Perinteisissä malleissa, missä toimintojen priorisointi jätetään vain ohjelmoijien päätettäväksi, toteutetaan usein ensin helpot toiminnot, jotta voidaan osoittaa projektin edistymistä. Näin projektin loppuvaiheessa on tekemättä vaikeimmat, suuririskisimmät toiminnot. Usein nämä olisivat asiakkaalle juuri niitä kaikkein tärkeimpiä. Perinteisiin menetelmiin verrattuna priorisoidun listan kautta toimiminen parantaa myös hankkeen ennustettavuutta kun vaikeisiin asioihin keskitytään heti alusta alkaen. (Poimala & Tolvanen.) Priorisointia voidaan soveltaa myös muuhun kuin ohjelmointikehittämiseen ja tarttua alusta alkaen nimenomaan kehittämisen niihin puoliin, joissa on suurin riski tai joiden onnistuminen on tuotoksen ja sen käyttöönoton kannalta oleellisinta.
Kolmantena ketteryyden teesinä pidetään koko ohjelmiston elinkaaren läpikäyntiä useita kertoja. Ketterissä menetelmissä projekti jaetaan pienempiin paloihin siten, että kaikki projektissa tarvittavat vaiheet on käyty läpi moneen kertaan. Näin vältytään ikäviltä yllätyksiltä projektin loppuvaiheessa.Tarkoituksena on siis, että ohjelmiston kaikkia osia parannetaan syklisesti useita kertoja, ennen kuin järjestelmä annetaan käyttöön loppukäyttäjille. Tätä voidaan pitää erityisesti laatua parantavana menetelmänä. (Poimala & Tolvanen.) Muussa kuin ohjelmistokehittämisessä tällainen syklinen, jatkuva kehittäminen on myös mahdollista, esimerkiksi siten, että jatkuvan laadunvarmistuksen ja testaamisen kautta saavutetun tiedon avulla.
Neljäntenä seikkana on jatkuva laadunvarmistus ja testaus. Perinteisesti testaus on ajoitettu projektin loppuun, hetkeen, jolloin ei enää olisi aikaa tehdä korjauksia. Jakamalla projekti pienempiin paloihin ja käymällä kaikki vaiheet läpi useasti varmistutaan siitä, että deadlinen koittaessa on jotain valmiina, ja kaikki mitä on valmiina, on jo testattua ja hyväksi todettua. (Poimala & Tolvanen.) Tätä laadunvarmistusmenettelyä voidaan soveltaa myös muuhun kuin ohjelmointikehittämiseen testaamalla esimerkiksi uusia menettelytapoja käytännössä jo kehittämisvaiheessa, työstämällä niitä eteenpäin käyttäjien kommenttien perusteella ja palauttamalla ne jälleen testaukseen. Tällaisella menettelyllä voidaan varmistaa myös tulevien käyttäjien sitoutuminen tuotoksen käyttöönottoon, sillä on todennäköisempää jalkauttaa pysyvästi käyttöön uusi toimintatapa, jonka kehittämiseen käyttäjät ovat saaneet jollain lailla osallistua.
Ketterissä menetelmissä yksityiskohtaisen vaatimusmäärittelyn sijasta suositaan käyttäjätarinoita, jotka keskittyvät siihen miksi järjestelmä on liiketoiminnallisesti tärkeä, ei siihen, miten järjestelmän halutaan täsmällisesti toimivan. (Poimala & Tolvanen.) Muussa kuin liiketoiminnallisessa tai ohjelmistokehittämisessä voidaan myös edetä tavallaan käyttäjätarinoiden kautta ja keskittyä siihen, miksi esimerkiksi jotain uutta toimintatapaa on tärkeää kehittää.
Ketterien menetelmien käytössä on myös haasteita, sillä ne ovat usein erilainen tapa tehdä, kuin mihin on totuttu. Nopea muutoksiin reagointi edellyttää, että muutoksia osataan tunnistaa ja arvioida niiden aiheuttamat muutokset kustannuksiin ja aikatauluihin sekä ajoittaa muutosten toteutus oikein. Myös jatkuvan testaamisen periaate edellyttää, että käytännön testaamiselle on luotu jonkinlaisia rakenteita ja se on prosessina automatisoitu (myös muissa kuin ohjelmistokehittämisessä, jossa testaamista on usein mahdollista automatisoida kirjaimellisesti). Testaaminen on siis syytä suunnitella huolellisesti. Koska ketterät menetelmät edellyttävät asiakkaan tiivistä sitoutumista kehittämiseen, riippuu menetelmien soveltuvuus ja onnistuminen paljon asiakkaasta (tilaajasta), ja erityisesti tilaajatahon johdon sitoutumisesta. Tilaajalla on omat työtehtävänsä, joiden lisäksi kehittäminen usein tulee. Myös tiimityöskentely, erityisesti eri organisaatioiden välillä, voi olla haastavaa, sillä näkökulmat ja osaaminen sekä koulutustarpeet voivat olla eri organisaatioissa erilaisia. Tiimityöskentelyssä täytyy myös pystyä antamaan oma tuotos toisten käsittelyyn, mikä voi joskus olla vaikeaa. Lisäksi rakentavan palautteen antaminen ja vastaanottaminen sekä siitä oppiminen on tärkeää toimivan tiimin kannalta. Haastavaa on myös pitää prosessi tarpeeksi yksinkertaisena, eli pitää mukana vain ne asiat, jotka tuovat lisäarvoa ja osata priorisoida dokumentointia niin, että kuvataan vain tärkeimmät asiat. (Holopainen & Hamina-Mäki 2003.)
Projektinhallinnan mallit
Ei ole yhtä mallia yli muiden, jokainen on omanlaisensa. On myös haastavaa käyttää yhtä tiettyä mallia käytännön työelämässä, jossa työorganisaatio, esimiehet, työtehtävät ja työkaverit muodostavat oman iloisen sekametelisoppansa. Käyttäjien kokemukset kolmesta eri projektimallista osoittivat, että kaikissa on hyvät ja huonot puolensa.
On hyvä tiedostaa vaikkapa näkyvyyteen liittyvät asiat: Vesiputous-mallissa tiimi työskentelee pitkään rauhassa keskenään, näkyvyys ulospäin huono ja Scrum-mallissa tiimin työtä muutetaan vähintään kolmen viikon välein, näkyvyys ulospäin hyvä. Käyttäjien kokemusten mukaan kumpikin vaihtoehto tuo omat haasteensa. Esimerkiksi Scrum-mallissa tämä jatkuva muuntautuminen jopa pidentää kokonaisprojektin kestoa, mutta toisaalta lyhentää tuotoksen näkymistä asiakkaalle. Työ ei kuitenkaan vähene, kun määrittelyt muuttuvat.
LÄHTEET
Beck, Kent, Beedle, Mike, van Bennekum, Arie, Cockburn, Alistair, Cunningham, Ward, Fowler, Martin, Grenning, James, Highsmith, Jim, Hunt, Andrew, Jeffries, Ron, Kern, John, Marick, Brian, Martin, Robert C., Mellor, Steve, Schwaber, Ken, Sutherland, Jeff & Thomas, Dave 2001. Agile Manifesto. WWW -dokumentti. www.agilemanifesto.org. Ei päivitystietoja. Luettu: 24.3.2015.
Beck, K. (1999). Embracing change with extreme programming. Computer, 32(10), 70-77. Luettu 20.4.2015.
Holopainen, Heini & Hamina-Mäki, Eija 2003. TE Object – Perinteinen ”oliomenetelmä” ketteräksi. TietoEnator Oyj/ Public & Healthcare/dGov. WWW -dokumentti. http://www.pcuf.fi/sytyke/syysseminaarit/risteily2003/AgileSytyke2003.pdf Ei päivitystietoja. Luettu 8.4.2015.
Juselius, Tomi 2012. Scrum-projektinhallintamenetelmä Laurea-ammattikorkeakoulu. Laurea Leppävaara. Tietojenkäsittelyn koulutusohjelma. Opinnäytetyö. http://www.theseus.fi/bitstream/handle/10024/39071/Juselius_Tomi.pdf?sequence=1. Ei päivitystietoa. Luettu 2.4.2015.
Kinnunen Matti 2007. Ketterien menetelmien vertailu ja analyysi UML/UP-viitekehyksen avulla. Ei päivitystietoja. Luettu 11.4.2015.
Lehtonen, Teijo, Tuomivaara, Seppo, Rantala, Ville, Känsälä, Marja,
Mäkilä, Tuomas, Jokela,Tero, Könnölä,Kaisa, Kaisti, Matti
Suomi, Samuli Minna Isomäki, Minna & Ylitolva, Marko 2014. Sulautettujen järjestelmien ketterä käsikirja. Turun yliopisto. Työterveyslaitos. TEKES. PDF-dokumentti. http://trc.utu.fi/embedded/kasikirja. Päivitetty 30.9.2014. Luettu 2.4.2015.
Leffingwell, D. (2007). Scaling software agility: Best practices for large enterprises.
Manninen, L. 2009. Palveluyritykselle soveltuva tuotekehitysmalli. Opinnäytetyö. Lahti: Lahden ammattikorkeakoulu. Luettu 15.4.2015.
Pappinen, E. 2010. Tiimin sisäiset ketterät viestinäkäytänteet Scrumin ja XP:n mukaisessa ohjelmistokehityksessä. Tietojärjestelmätieteen kandidaatin tutkielma. Jyväskylän yliopisto. Luettu 10.4.2015. https://jyx.jyu.fi/dspace/bitstream/handle/123456789/24669/Erno.Pappinen.pdf?seque
Poimala, Sami & Tolvanen, Perttu. Ketteryys haltuun: Ketterän kehityksen yleiset periaatteet. Sininen Meteoriitti. WWW -dokumentti. https://www.meteoriitti.com/Artikkelisarjat/Ketteryys-haltuun/Ketteryys-haltuun-Ketteran-kehityksen-yleiset-periaatteet/ Ei päivitystietoja. Luettu 2.4.2015.
Sininen Meteoriitti Oy, 2015. Ketteryys haltuun. E-artikkelisarja. https://www.meteoriitti.com/Artikkelisarjat/Ketteryys-haltuun/Ketteryys-haltuun-Yleisimmat-ketterat-kaytannot/. Ei päivitys tietoa. Luettu 1.4.2015.
The Standish Group Report (2014) Chaos. http://www.projectsmart.co.uk/docs/chaos-report.pdf. Ei päivitystietoja. Luettu 20.4.2015.
Yli-Huumo, Jesse 2011. Ketterät menetelmät ja laadunhallinta. Lappeenrannan teknillinen yliopisto. Tietotekniikan osasto. Kandidaatintyö. PDF-dokument-ti. http https://www.doria.fi/bitstream/handle/10024/73805/Kandity%C3%B6_JesseYli-Huumo.pdf?sequence=1. Ei päivitystietoa. Luettu 28.4.2015.
Wells, Don. Extreme Programming. Values. What has changed? Simple Rules. Luettu 14.4.2015. http://www.extremeprogramming.org/
0 kommenttia