Etusivu

Lataa PDF-versio

Sisällys:

  1. Johdanto
  2. Sulautettujen järjestelmien ketterät kehitysmenetelmät
  3. Tekniikkakatalogi
  4. Yritysesimerkit
  5. Lisätiedot

Keskustele ja kommentoi:

Johdanto

Ketterä kehitys

14212.png

Ketterä kehitys on yleisnimitys useille erilaisille ohjelmistokehitysmenetelmille. Yhteistä näille menetelmille on iteratiivisuus ja inkrementaalisuus. Toimivaa ohjelmistoa esitellään säännöllisin väliajoin, ja siihen lisätään ominaisuuksia vähitellen. Dokumentaatiossa keskitytään olennaiseen ja suunnitelmat muokkautuvat kehityksen edetessä. Vuorovaikutus johtoportaan, kehittäjien ja asiakkaan välillä on sujuvaa ja tiivistä.

Historia

Yleisesti ajatellaan, että iteratiiviset ja inkrementaaliset menetelmät ovat tulleet käyttöön 2000-luvun vaihteessa. Kuitenkin niillä on pohjansa jo kauempana ohjelmisto- ja tuotekehityksen historiassa.

Jo 1930-luvulla esitettiin syklien käyttöä laadunvarmistuksessa. Iteratiivisia ohjelmistonkehitysmenetelmiä oli käytössä myös mm. NASAssa ja IBM:ssä 1960- ja 1970-luvuilla.

1970-luvulla Winston Royce julkaisi artikkelin, jossa hän esitteli kokemuksiinsa perustuvan kehitysmenetelmän. Tässä vesiputousmallissa työvaiheet seuraavat toisiaan: vaatimusten määrittely, analyysi, suunnittelu, ohjelmointi, testaus sekä käyttöönotto. Itse asiassa Royce suositteli otettavaksi menetelmään mukaan mm. kyseisen syklin suorittamista kahdesti, eri vaiheiden välisiä iteraatioita sekä asiakkaan ottamista mukaan suunnittelutyöhön. Yleisesti mallia kuitenkin seurattiin virheellisesti yksinkertaisessa muodossaan, jonka jo Royce totesi artikkelissaan riskialttiiksi.

1970- ja 1980-luvuilla vesiputousmalli oli pääasiallinen ohjelmistokehitysmenetelmä. Rinnalla kuitenkin esiintyi jo monenlaisia iteratiivisempia menetelmiä. 1990-luvulla vesiputousmallia alettiin pitää ongelmallisena ja kehitettiin paljon erilaisia kevyempiä menetelmiä. Joissakin näistä taustalla oli tuotantoteollisuudesta tullut Lean-ajattelutapa .

Ketteryyden alkuperänä pidetään useimmiten ketterän ohjelmistokehityksen julistusta (Agile Manifesto), jonka 17 ohjelmistoalan ammattilaista kirjoittivat helmikuussa 2001 Utahissa. Julistus oli oikeastaan kokoelma niistä arvoista, jotka 1990-luvulla uusia menetelmiä kehittäneet ohjelmistoammattilaiset olivat kokeneet hyviksi. Julistus sisältää arvojen lisäksi 12 periaatetta.

Arvot

Arvot muodostavat pohjan ketterille kehitysmenetelmille ja niitä tulisi soveltaa silloin, kun menetelmä tai käytäntö ei suoraan vastaa ratkottavaan ongelmaan.

Ketterän ohjelmistokehityksen julistuksen arvot

Löydämme parempia 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 sopimusneuvotteluja

Vastaamista muutokseen enemmän kuin pitäytymistä suunnitelmassa

Jälkimmäisilläkin asioilla on arvoa, mutta arvostamme ensiksi mainittuja enemmän.

Yksilöt ja kanssakäyminen

Ketterissä menetelmissä annetaan kehittäjille vastuuta omasta työstään ja oman työnsä suunnittelusta. Toimivaan kommunikaatioon kiinnitetään huomiota niin oman tiimin sisällä kuin tiimin ulkopuolellakin. Tiimi sopii yhdessä työtehtävistä ja kehittää työmenetelmiään jatkuvasti. Tiimi ottaa kantaa paitsi tekniseen sisältöön, myös siihen, mitä on realistista saada toteutettua tietyssä ajassa. Käytännön työ pohjautuu toistensa kanssa kommunikoiviin yksilöihin, joita käytössä olevat työkalut ja menetelmät tukevat.

Toimiva ohjelmisto

Pääasiallinen kehityksen mittari ketterissä menetelmissä on säännöllisesti toimitettava toimiva ohjelmisto. Työ paloitellaan pieniin paloihin siten, että ohjelmistoon lisätään ominaisuuksia inkrementaalisesti ja jokainen lisätty osa on tehty ja testattu toimivaksi asti. Dokumentaatio ei ole itseisarvo, vaan tukee työn tekemistä.

Asiakasyhteistyö

Asiakas otetaan mukaan suunnitteluun koko ohjelmistokehityksen ajan sen sijaan, että alussa tehtäisiin tarkka sopimus ja vasta projektin lopussa asiakas näkisi valmiin tuotteen. Tiimi esittää asiakkaalle säännöllisin väliajoin työnsä tuloksia ja saa asiakkaalta palautetta. Näin kaikki osapuolet pyrkivät koko ajan kohti yhteistä tavoitetta. Tavoite muokkautuu matkan varrella täyttämään paremmin asiakkaan tarpeet, kun molempien osapuolien ymmärrys kehitettävästä tuotteesta lisääntyy.

Muutokseen vastaaminen

Kehitystyön aikana tuotteen vaatimukseen tulee muutoksia. Projektin edetessä sekä tiimi, että asiakas ymmärtävät paremmin, miten asiakkaan tarpeet saadaan parhaiten täytettyä. Myös ympäristö saattaa muuttua ja asettaa uusia vaatimuksia projektille. Alkuperäiset suunnitelmat eivät ole yksityiskohtaisia ja tarkkoja, vaan niitä muokataan projektin edetessä muutosten osoittamaan suuntaan. Suunnitelmia tehdään kullakin ajan hetkellä vain niin pitkälle kuin on tarpeellista työn etenemisen kannalta.

14222.png

Lisää aiheesta

Beck K. ym.: Agile Manifesto.
https://agilemanifesto.org/.

Larman C.: Agile and Iterative Development: A Manager’s Guide.

Kirjallisuusluettelo


Päivitetty: 22.01.15 13:33

Jaa: