Ketterä ohjelmistokehitys ja toimitussopimukset

(IPRinfo 3/2011)

Mistä on kyse, kun puhutaan ketteryydestä, ja miten se on otettava huomioon sopimuksia laadittaessa?

Viime vuosina ketterään ohjelmistokehitykseen on kiinnitetty paljon huomiota. Mainospuheiden mukaan se saattaa johtaa jopa ohjelmistotoimitusprojektin onnistumiseen. Ohjelmistoteollisuudessa näinkin varovaiselta kuulostava väite saattaa olla rohkea, sillä useiden tutkimusten mukaan jopa yli puolet ohjelmistotuotantoprojekteista epäonnistuu.

Ketterän ohjelmistokehityksen (agile software development) käsitteellä ei ole yksiselitteistä määritelmää. Tyypillisesti kyse on siitä, että ohjelmistoa rakennetaan iteratiivisesti ja inkrementaalisesti sen sijaan, että edettäisiin lineaarisesti koko toteutettavan ohjelmiston vaatimusmäärittelystä ja suunnittelusta toteutuksen ja testauksen kautta valmiin ohjelmiston luovuttamiseen asiakkaalle.

Ketterässä ohjelmistokehityksessä kaikki edellä mainitut vaiheet toistuvat monta kertaa siten, että jokaisen iteraation päätteeksi asiakkaalle voidaan esitellä toimiva ohjelma. Seuraavaan iteraatioon valitut toiminnallisuudet toteutetaan inkrementaalisesti edellisessä iteraatiossa tuotetun ohjelman päälle niin, että seuraavan iteraation tulos sisältää sekä edellisessä että kyseisessä iteraatiossa tuotetut ominaisuudet. Näin menetellen jatketaan, kunnes ohjelmisto toteuttaa kaikki asiakkaan asettamat vaatimukset.

Ketterän ohjelmistokehityksen lukuisista prosessimalleista tunnetuin lienee Scrum. Siinä ylläpidetään tuotteen kehitysjonoa (product backlog), joka sisältää priorisoidun luettelon kaikista lopulliselta tuotteelta mahdollisesti edellytettävistä toiminnoista.

Scrumissa iteraatioita kutsutaan pyrähdyksiksi (sprint). Jokaisen pyrähdyksen alussa asiakas valitsee tuotteen kehitysjonosta pyrähdyksen tehtävälistaan (sprint backlog) ne ominaisuudet, jotka hän haluaa toteutettavaksi seuraavan pyrähdyksen aikana. Vaatimuksia ja niiden tärkeysjärjestystä on lupa muuttaa pyrähdysten välissä. Näin asiakas usein haluaa tehdä kokeiltuaan edellisen pyrähdyksen tuloksena toimitettua ohjelmaa.

Mukana konkreettisempia menetelmiä
Varsinaisen prosessimallin lisäksi ketterään ohjelmistokehitykseen liitetään usein joitakin hieman konkreettisempia ohjelmistokehityksen menetelmiä, joiden noudattaminen saattaa prosessimallista riippuen olla pakollistakin. Tällaisia menetelmiä ovat muun muassa jatkuva integraatio, testilähtöinen ohjelmistokehitys (Test-Driven Development, TDD), pariohjelmointi, koko kehitystiimin työskentely samassa tilassa sekä asiakkaan jatkuva läsnäolo kehitystiimin työskentelytilassa.

Näistä menetelmistä erityisesti pariohjelmointi ja TDD saattavat aluksi kuulostaa nurinkurisilta. TDD:ssä ohjelmiston oikeaa toimintaa varmentavat (yksikkö)testit laaditaan ennen ohjelmakoodin kirjoittamista. Pariohjelmoinnissa kaksi ihmistä jakaa yhden tietokoneen, jonka ääressä toinen kirjoittaa ohjelmakoodia toisen seuratessa ja ohjatessa työskentelyn etenemistä. Tutkimustulokset menetelmien vaikutuksista ovat osin ristiriitaisia, mutta niitä joka tapauksessa käytetään usein ketterän ohjelmistokehityksen yhteydessä.

Ketteryys vähentää riskiä
Useimmiten ohjelmistolle asetetut vaatimukset muuttuvat tuotantoprojektin aikana. Alkuvaiheessa tehty, koko ohjelmistoa koskeva laaja vaatimusmäärittely ja suunnittelu eivät tuota parasta mahdollista lisäarvoa tilaajalle, koska osa työstä käy myöhemmin turhaksi. Lineaarisesti etenevä projekti, jossa koko ohjelmisto suunnitellaan ennen toteutuksen aloittamista, saattaa pahimmassa tapauksessa muodostua sopimustekniseksi illuusioksi, jossa myöhemmin ilmeneviä muutoksia tehdään tosiasiassa iteratiivisesti muutoshallintamenettelyn kautta.

Ketterien menetelmien käytöllä pyritään vähentämään muutosten mukanaan tuomaa riskiä ja tuottamaan lisäarvoa asiakkaalle mahdollisimman aikaisessa vaiheessa. Iteraatioissa toteutetaan ensin suuririskisimmiksi arvioidut toiminnallisuudet. Tavoitteena on, että projektin edetessä epävarmuus nopeassa tahdissa pienenee.

Esimerkiksi Scrum-prosessimallissa pidetään varsin yksinkertaisin ja kevein menetelmin jatkuvasti yllä arviota siitä, missä ajassa pyrähdyksen tehtävälistalla ja tuotteen kehitysjonossa yksilöidyt toiminnallisuudet saadaan toteutettua kehitystiimin työnopeudella. Asiakas saa läpinäkyvää tietoa projektin etenemisestä ja toimitettavan ohjelmiston tilasta iteraatioiden välissä ja mahdollisesti myös iteraatioiden aikana, kun hän on jatkuvasti läsnä kehitystiimin työtilassa. Muutokset ja muut riskit havaitaan varhaisessa vaiheessa ja niihin voidaan reagoida.

Tutkimusten mukaan tyypillisesti vain murto-osaa ohjelmiston ominaisuuksista käytetään jatkuvasti, ja jopa puolet ohjelmiston ominaisuuksista saattaa jäädä kokonaan käyttämättä. Tällaisten ominaisuuksien lisääminen ohjelmaan ei tuota asiakkaalle lisäarvoa. Ketterässä ohjelmistokehityksessä asiakas pääsee ennen jokaista iteraatiota valitsemaan toteutettavaksi ne ominaisuudet, jotka sillä hetkellä vaikuttavat hänen kannaltaan tarpeellisimmilta.

Yhteistyö asiakkaan kanssa avainasemassa
Usein lainatun ketteryyden julistuksen (the agile manifesto) mukaan yhteistyö asiakkaan kanssa on tärkeämpää kuin sopimuksesta neuvotteleminen. Tästä huolimatta jonkinlainen sopimus laaditaan säännönmukaisesti myös ketteriä menetelmiä käytettäessä. Huomiota pitää kiinnittää erityisesti siihen, että sopimuksen sisältö vastaa valittua prosessimallia.

Jos sopimuksella sovitaan lineaarisesta toimitusmallista, vaikka projekti tosiasiassa etenee iteratiivisesti, voi ristiriitatilanteessa olla vaikea selvittää, mistä osapuolten on ollut tarkoitus sopia. Samanlainen ongelma on, kun iteratiiviseksi sovittu toimitus toteutetaan lineaarisesti.

Immateriaalioikeuksista sopiminen korostuu ketterässä toimintamallissa. Ketterästi toimittaessa on tavallista epävarmempaa kenelle syntyy esimerkiksi tekijänoikeus ohjelmistoon tai sen osaan. Asiakkaan jatkuvan läsnäolon ja osallistumisen sekä pariohjelmoinnin ja testilähtöisen ohjelmistokehityksen johdosta teoksen tekijä saattaakin olla ohjelmoijaksi kutsutun henkilön sijasta asiakas tai testaaja.

Ketteriä menetelmiä käytettäessä laatutietoinen asiakas saattaa myös haluta sopia tavallista tarkemmin käytettävistä laadunvarmistusmenetelmistä. Toimittajaa saatetaan pyytää sitoutumaan siihen, että ohjelmistolle laadittavilla automatisoiduilla yksikkötesteillä on tietty rivi- ja haarakattavuus ja että niitä on vähintään tietty määrä jokaista ohjelman luokkaa ja metodia kohden. Laatukriteereistä sopiminen edellyttää ammattitaitoa sovittavien kriteerien valinnassa, ja tarjolla olevat mahdollisuudet vaihtelevat muun muassa käytettävästä ohjelmointikielestä riippuen.

Ketterä toimitus voi olla kiinteähintainen
Tilaajan halutessa toimituksensa kiinteään hintaan edellyttää järkevä toimittaja vastaavasti, että toimituksen laajuus sovitaan kiinteäksi. Kiinteä hinta on tavallaan ristiriidassa ketteryyden kanssa, sillä kiinteän hinnan tarjoaminen toimitukselle edellyttää toimituksen yksityiskohtaisten vaatimusten selvittämistä ennen varsinaiseen toteutustyöhön ryhtymistä. Näin menetetään osa ketterän toimitusmallin hyödyistä, kun projektin alussa tehty laaja selvitystyö käy turhaksi vaatimusten myöhemmin muuttuessa.

Tästä huolimatta kiinteähintainen toimitus ei kuitenkaan sulje pois ketterän prosessimallin käyttämistä. Osa ketteryyden väitetyistä eduista, kuten toimivan ohjelman varhainen toimitus ja riskien havaitseminen, voidaan saavuttaa myös kiinteähintaisessa toimituksessa. Ketterän toimitusmallin iteratiivisuutta ja iteraatioiden välissä tehtäviä muutoksia voidaan sopimuksessa käsitellä esimerkiksi projektin tavanmukaisena tapana sopia muutoksista. Muutoshallinnasta on sovittava myös lineaarisesti etenevässä projektissa.

Ohjelmistotuotantomenetelmän valitsemista vaikeuttaa se, että ketterien ja lineaaristen mallien eroista ja soveltuvuudesta erilaisiin tilanteisiin ei ole saatavilla kovin yksiselitteisiä empiirisiä tutkimustuloksia. Valintaa tehtäessä saatetaan olla kulloinkin kyseessä olevien toimijoiden omien kokemusten varassa. Valittavasta prosessimallista riippumatta projektin onnistumisen edellytyksenä ovat kuitenkin kaikkien osapuolten sitoutuminen projektin läpiviemiseen sekä toimiva kommunikaatio heidän välillään.

Risto Sandvik
lakimies, Bird & Bird

Manifesto for Agile Software Development (2001)
http://agilemanifesto.org/