Laatu vai ketteryys? PDF Tulosta Sähköposti
Kirjoittanut Kari   
21.09.2009 14:27

Ketterät kehitysprosessit ovat jo pitkälti arkipäivää monissa yrityksissä ja niiden mukanaan tuomat edut on havaittu ja raportoitu: kehityssyklit ovat nopeutuneet ja asiakaslähtöisyys parantunut. Ei pidä myöskään unohtaa vaikutusta ohjelmistokehittäjien työnkuvaan ja sitä kautta työtyytyväisyyteen: heistä on tehty aidosti tiimiläisiä eikä niskaan hengittävän projektipäällikön käskyläisiä.

Kuitenkin meillä on edelleen paljon saarekkeita, joissa ketteryyteen suhtaudutaan vähintäänkin epäilevästi. Onko tähän selkeitä fundamentteja syitä vai onko kyse ennakkoluuloloista? Vaatiiko paras laatu edelleen jäykkiä prosesseja?

Usein "jäykkyyteen" on ihan pragmaattiset syyt. Laadunvarmistus on ulkoistettu jolloin sen limittäminen kehityssykleihin täytyy tehdä harvemmin. Sertifiointia vaativia tuotteita ei kannata hyväksyttää useita kertoja johtuen operaation kestosta ja hinnasta. Sulautetuissa tuotteissa laitteistokehityksen syklit ovat hitaampia ja kalliimpia kuin ohjelmistokehitys.

Kaikessa ei kuitenkaan kannata ottaa oppia hitaimmasta; erilaiset "hybridiprosessit" ovatkin osoittautuneet ihan käyttökelpoisiksi vaikka ketteryyttä ei voikaan toteuttaa kaikilta osin niin kuin Extreme-opas kertoo. On esimerkiksi aivan mahdollista soveltaa Scrum-prosessia sulautetun ohjelmiston kehityksessä vaikka muu kehitys noudattaa perinteistä vaihejakomallia. Ulkoiset testausorganisaatiot osaavat tänä päivänä soveltaa iteratiivista mallia, jossa testattaviksi toimitetaan osakokonaisuuksia kunkin kehityssyklin jälkeen. Sertfikaattorit tosin eivät osaa näin toimia.

Onko laatu sitten vaarassa? Mielestäni ei. Kyse ei ole niinkään siitä tehdäänkö järjestelmää ketterällä prosessilla vaan siitä kiinnitetäänkö laatuun ylipäätään riittävästi huomiota. Ketterä malli tarjoaa kyllä mahdollisuuden testata järjestelmän ydintoiminnot kattavasti ja moneen kertaan. Jos yksikkötestit ja toiminnalliset testit ajetaan regressiona joka Sprintin yhteydessä, jotta varmistetaan että uusi toiminnallisuus ei ole rikkonut vanhaa, niin lopulta systeemissä tulee ajettua hyvin paljon testejä ja lopputuotteen laatu varmistettua. Tällainen malli edellyttää kohtuullista satsausta automaattiseen testaukseen ja jatkuvaan integraatioon, käsipelin testejä ei yksinkertaisesti saada ajettua riittävän kattavasti.

 

Lisää kommentti

Oma nimesi:
Aihe:
Kommentti:
  Vain pieniä kirjaimia, ei välilyöntejä.
Roskapostivarmennus::