Ketterät ohjelmistokehittämisen menetelmät perustuvat periaatteisiin, jotka lin-jataan agile manifestossa. Itse manifesti on suomennettuna ”Löydämme parem-pia tapoja tehdä ohjelmistokehitystä, kun teemme sitä itse ja autamme muita siinä. Kokemuksemme perusteella arvostamme: Yksilöitä ja kanssakäymistä enemmän kuin menetelmiä ja työkaluja, Toimivaa ohjelmistoa enemmän kuin kattavaa dokumentaatiota, Asiakasyhteistyötä enemmän kuin sopimusneuvotte-luja, Vastaamista muutokseen enemmän kuin pitäytymistä suunnitelmassa. Jäl-kimmäisilläkin asioilla on arvoa, mutta arvostamme ensiksi mainittuja enem-män.” (agilemanifesto.org.) Vaikka myöhemmin ketteryyden perusperiaatteita on lisätty ja muokattu alkuperäisistä, ovat alkuperäiset silti hyvin osuvia (Wil-liams, 2012).
3.2.1 Scrum
Scrumin esitteli ensimmäisen kerran vuonna 1986 Takeuchi ja Nonaka artikkelis-saan ”The new new product development game”. Artikkelissa esitellään kolme muutosta, joita organisaation hallinnassa täytyy tehdä, jotta voidaan saavuttaa nopeutta ja joustavuutta. Ensimmäiseksi organisaatioiden täytyy omaksua johta-mistyyli, joka kannustaa prosessiin osallistumista. Toisena organisaatioiden tu-lee muuttaa oppimista. Kapean erikoistuvan syväoppimisen sijaan johdon tulisi
13
kerätä tietoutta laajemmin koko kentän laajuudelta. Kolmanneksi organisaatioi-den tulisi asettaa erilaisia tavoitteita tuotekehitykselle pelkän tuoton sijaan. (Ta-keuchi & Nonaka, 1986.)
Scrum voidaan määritellä projektin hallintapainotteisena ketteränä kehitys-metodina, joka on saanut inspiraatiota laaja-alaisesti esimerkiksi monimutkai-suusteoriasta, järjestelmädynamiikasta sekä Nonakan ja Takeuchin tiedon luon-nin teoriasta. Scrumissa on omaksuttu teorioita eri aloilta ja tuotu ne ohjelmisto-kehityksen kontekstiin. (Moe, Dingsøyr & Dybå, 2010.)
Rising ja Janoff kuvailevat Scrumia pienten tiimien kehitysprosessiksi, joka pitää sisällään lyhyitä kehitysjaksoja eli iteraatioita (”sprinttejä”). Scrum-tiimille annetaan merkittävästi vaikutusvaltaa ja vastuuta työnsä eri vaiheisiin, kuten suunnittelu, aikatauluttaminen, tehtäväjako jäsenten kesken ja päätöksenteko.
(Rising & Janoff, 2000.)
Itsensä ohjaaminen on Scrumin määrittelevä piirre. Verrattuna perinteiseen komento-ja-valvonta painotteiseen johtamiseen. Scrum edustaa radikaalisti uu-denlaista lähestymistä suunniteluun ja johtamiseen ohjelmistoprojekteissa, koska se tuo päätöksenteon vallan samalle tasolle operatiivisten ongelmien ja epävar-muuksien kanssa. (Moe, Dingsøyr & Dybå, 2010.)
3.2.2 Lean
Lean kehittäminen on tuotekehitysmalli, jossa on päästä päähän tavoitteena ar-vonluonti asiakkaalle, hukan eliminointi, arvonvirtojen optimointi, ihmisten val-tuuttaminen ja jatkuva kehitys. Lean-ajattelu on saanut alkunsa teollisuudessa ja se on omaksuttu useilla toimialoilla. (Ebert, Abrahamsson & Oza, 2012.)
Lean kehitys sekoittuu usein ketterän kehittämisen sekaan tai sen synonyy-miksi. Leanin voi erottaa muusta ketterästä kehittämisestä kolmella keskinäisellä osatekijällä: Lean konseptit, Lean periaatteet ja Lean käytänteet. (Wang, Conboy
& Cawley, 2012).
Olennainen käsite ohjelmistokehitykselle on se, että työ tulisi jakaa osissa eteenpäin välittömästi sekä myös palauttaa takaisinpäin tuotantoketjussa välit-tömästi, mikäli se on virheellistä tai puutteellista. Tällä tavoin työntekijät saavat välitöntä ja säälimätöntä palautetta suoriutumisestaan. (Middleton, 2001.)
Ohjelmistoalan näkökulmasta polku kohti Leania alkoi ohjelmoinnin kette-rillä menetelmillä. Viimeisen vuosikymmenen aikana suurin osa yrityksistä on omaksunut ketterän kehittämisen tavoitellakseen tehokkuutta ja vaikuttavuutta.
Vaikka se onkin auttanut valtavasti käyttäjäkeskeisen ja iteratiivisen kehityksen kanssa, sen yritystason soveltuvuus on seisahtunut. Liian usein ketterät käytän-teet rajoittuvat ryhmään tai projektiin. Keskittyessä liikaa lyhyeen aikaväliin, ku-ten dokumentaation ja tarpeettomien osien vähentämiseen huomataan kuiku-tenkin lopuksi, että vaikutus elinkaarikustannuksiin on ollut negatiivinen. Lean kehitys pyrkii korjaamaan tämän ongelman. (Ebert, Abrahamsson & Oza, 2012.) Ebert ym. myös argumentoivat, että jotkin Leanin periaatteet eivät sovellu ohjelmisto-kehitykseen.
14 3.2.3 ExtremeProgramming
Vuosituhannen alussa ExtremeProgramming (XP) on ollut suosituin ketterä me-netelmä. XP:ssä keskitytään käytettävän koodin ja automatisoitujen testien luon-tiin paperisten vaatimus- ja suunnitteludokumenttien sijasta. Tämä keskittymi-nen lähdekoodiin tekee XP:stä kiistanalaisen ja sitä verrataan jopa hakkerointiin.
Tämä vertaus on epäoikeutettu, sillä XP:ssä arvostetaan yksinkertaista suunnit-telua ja vastaa hakkerointiväitteisiin asettamalla painoarvoa refaktoroinnille, vahvalle regressiotestaukselle ja jatkuvalle koodin tarkastamiselle parikoodaa-misen kautta. (Maurer & Martel, 2002.)
Vaikka kehittäjät voivat käyttää erilaisia XP käytäntöjä, menetelmä yleensä pitää sisällään 12 peruskäytäntöä:
1. Pelin suunnittelu: Seuraavan julkaisun nopea suunnittelu yh-distämällä taloudelliset päämäärät ja tekniset arviot. Asiakas päättää laajuuden, tärkeysjärjestyksen ja päivämäärät talou-dellisesta näkökulmasta, kun taas tekniset työntekijät arvioi-vat ja seuraaarvioi-vat etenemistä.
2. Pienet julkaisut: Laitetaan yksinkertainen järjestelmä tuotan-toon nopeasti. Julkaistaan uusia versioita nopealla tahdilla (kahden viikon sykli).
3. Metafora: Johdetaan kaikkea kehittämistä yksinkertaisella jaetulla tarinalla siitä, kuinka koko järjestelmän tulisi toimia.
4. Yksinkertainen suunnittelu: Suunnitellaan niin yksinkertai-sesti kuin vain mahdollista sillä hetkellä.
5. Testaus: Kehittäjät jatkuvasti kirjoittavat yksikkötestejä, joi-den tulee suoriutua virheettömästi. Asiakkaat kirjoittavat tes-tejä, jotka havainnollistavat toimintojen olevan valmiita. ”Tes-tataan ja sitten koodataan” tarkoittaa, että epäonnistunut tes-titapaus on aloituskriteeri koodaamiselle.
6. Refaktorointi: Uudelleen rakennetaan järjestelmä muutta-matta sen käyttäytymistä toistojen poistamiseksi, kommuni-koinnin parantamiseksi, yksinkertaistamiseksi tai joustavuu-den lisäämiseksi.
7. Parikoodaaminen: Kaiken tuotantokoodin kirjoittaa kaksi oh-jelmoijaa yhdellä koneella.
8. Kollektiivinen omistajuus: Kaikki voivat parantaa järjestel-män koodia missä vain, milloin vain.
9. Jatkuva integraatio: Integroidaan ja rakennetaan järjestelmä monta kertaa päivässä (aina kun tehtävä saadaan valmiiksi).
Jatkuva regressiotestaus estää toiminnallisuuksien regression vaatimusten muuttuessa.
10. 40-tuntiset viikot: Työtä tulisi tehdä enintään 40 tuntia vii-kossa, mikäli mahdollista. Ylitöitä ei tulisi koskaan tehdä kah-tena peräkkäisenä viikkona.
15
11. Paikalla oleva asiakas: Ryhmässä tulisi olla todellinen loppu-käyttäjä täysipäiväisesti vastaamassa kysymyksiin.
12. Ohjelmointistandardit: Säännöt, jotka painottavat kommuni-kointia läpi koodin. (Paulk, 2001.)
XP:ssä kaikki kehittäjät työskentelevät läheisesti, jotta he voivat kommuni-koida informaalisti ja täten välttää ajan kulutusta suunnittelun ja päätösten do-kumentointiin. Kun organisaatio kasvaa, kuluu enemmän aikaa tuotetietouden levittämiseen ja uuden henkilöstön kouluttamiseen. Tämä usein tekee XP:stä kel-vottoman suurempiin ryhmiin. XP on ketterä ohjelmistokehitysprosessi, joka no-peuttaa kehitystä ja sallii ryhmien reagoida joustavammin vaatimusten muutok-siin, mutta sillä on myös ongelmansa. Yksi ongelmista on epävarma skaalautu-vuus. XPtä suositellaan 5–15 ihmisen ryhmille, mutta varmaa tietoa ryhmäkoon ylikasvamisesta ei ole. (Maurer & Martel, 2002.)
XP käytänteet eivät pidä sisällään laajamittaista vaatimus- ja suunnittelu-valmistelua ennen kehittämisen aloitusta. Sen seurauksena XP on hyvin riippu-vainen jatkuvasta kommunikaatioista sidosryhmien kesken sekä tiivistä palaute-kierrosta toimintojen toteutuksen selventämiseksi ja tarkentamiseksi ja muutok-siin vastaamiksesi. Tämä jatkuva kommunikaatio voi olla haaste globaaleille ryh-mille. (Layman, Williams, Damian & Bures, 2006.)
16
4 TULOKSET
Tässä luvussa tarkastellaan ohjelmistokehitystyypeille ominaisia teknisen velan tyyppejä ja niiden ilmentymistä. Teknisenvelan tyyppeinä käytetään Li ym., (2015) löytämiä kymmentä teknisen velan tyyppiä: vaatimus-, arkkitehtuuri-, suunnittelu-, koodi-, testaus-, rakenne-, dokumentaatio-, infrastruktuuri-, versio-hallinta- ja virhevelka (Alves ym., 2014; Benidris, 2018; Li ym., 2015.)
Näitä teknisen velan tyyppejä verrataan kehitysmenetelmien sekä velan ta-hallisuuden muodostamaan taulukkoon 1.
Taulukko 1 Kehitysmenetelmät sekä teknisen velan tyypit
Tahallista
& Nonaka, 1986; Vaatimus,
arkki-tehtuuri, Virhe (Alves
ym., 2014; Dokumentaatio (Al-ves ym., 2014;
17