Ketterät ohjelmistotoimitukset ovat saaneet viime vuosina paljon huomiota osakseen. Ketteriin toimituksiin erikoistuneet IT-alan toimijat ovat jopa sitä mieltä, että perinteinen lineaarinen vesiputoustoimitusmalli on tiensä päässä ja että ketterillä menetelmillä toimitusprojektien onnistuminen voidaan varmistaa huomattavasti aiempaa paremmin.
Vaikka ketteristä toimitusmenetelmistä on jo saatu hyviä kokemuksia, ei ketteryys kuitenkaan ole automaattinen tie onnistuneisiin toimitusprojekteihin. Ketterät toimitusmenetelmät vaativat onnistuakseen paljon lineaarisista toimitusprojekteista poikkeavia elementtejä, ja erityisesti ketterää toimitusta koskevan sopimuksen merkitys on huomattava. Ilman selkeää ja molempien osapuolten toimintaa ohjaavaa ketterään toimitukseen tarkoitettua sopimuksellista viitekehystä ketterä toimitusprojekti voi johtaa perinteistäkin toimitusmallia suurempaan epäonnistumiseen.
Huomiota pitää kiinnittää erityisesti siihen, että sopimuksen sisältö vastaa valittua prosessimallia. Mikäli sopimuksella sovitaan lineaarisesta toimitusmallista, vaikka projekti tosiasiassa etenee iteratiivisesti, saattaa ristiriitatilanteessa olla vaikea selvittää, mistä osapuolet ovat tosiasiassa tarkoittaneet sopia. Samanlainen ongelma on silloin, kun iteratiiviseksi sovittu toimitus toteutetaan lineaarisesti.
Ketterien toimitusprojektien suurimpia haasteita on se, ettei ketteriin toimituksiin tarkoitettuja sopimuksia ole alalla yleisesti käytettävissä. Tämä johtuu pääosin siitä, että toimittajaosapuolet käyttävät ketterissä toimituksissa mieluiten perinteisiä aikaveloitusperusteisia asiantuntijapalvelusopimuksia, kun taas asiakasosapuolet käyttävät mielellään asiakasystävällisiä perinteisen vesiputousmallin mukaisia toimitussopimuksia. Kumpikin osapuoli pyrkii siis optimoimaan omaa juridista asemaansa sen sijaan, että käyttäisi juuri ketterän toimitusmallin tarkoituksiin tehtyä sopimusta.
Mitä on ketterä ohjelmistokehitys?
Ketterän ohjelmistokehityksen (”agile software development”) käsitteellä ei ole yksiselitteistä määritelmää. Tyypillisesti kyse on kuitenkin siitä, että ohjelmistoa rakennetaan iteratiivisesti ja inkrementaalisesti sen sijaan, että edettäisiin perinteisen ”vesiputousmallin” mukaisesti 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 siten, että seuraavan iteraation tulos sisältää sekä edellisessä että kyseisessä iteraatiossa tuotetut ominaisuudet. Näin menetellen jatketaan, kunnes ohjelmisto toteuttaa kaikki asiakkaan asettamat vaatimukset.
Millainen on oikein tehty ketterän toimitusmallin mukainen sopimus?
Koska ketterä toimitus edellyttää asiakkaalta merkittävää panosta projektin operatiiviseen työskentelyyn, molempien sopimusosapuolten vastuisiin ja velvoitteisiin tulee kiinnittää yhtä paljon huomiota. Onnistunut ketterä toimitus edellyttää, että myös asiakas tietää tarkasti, mikä sen rooli toimituksessa on ja miten sen tulee toimitus omalta puoleltaan resursoida.
Toimittaja ei kuitenkaan voi siirtää kaikkea vastuuta asiakkaalle, vaan toimittajan velvoitteisiin on syytä kirjata aktiivinen ja tarvittaessa asiakasta valvova projektin johtaminen. Toimittajan tulee vastata siitä, että se tuo projektiin ketterässä toimittamisessa tarvittavan menetelmäosaamisen. Tämän menetelmäosaamisen puitteissa toimittajan on aktiivisesti huolehdittava siitä, että myös asiakas täyttää omat velvollisuutensa projektissa.
Oikean hinnoittelumekanismin valitseminen ketterään toimitusprojektiin on yksi suurimmista haasteista. Kiinteähintainen hinnoittelu on hyvin haasteellinen ja rajoittaa helposti projektin ketteryyttä vieden terää ketterien toimitusmenetelmien parhaimmilta puolilta. Täysin puhtaasti aikaveloitusperusteinen hinnoittelu on puolestaan riskialtis budjettiylityksille. Ketterän toimitusprojektin hinnoittelun tulisikin olla voimakkaasti projektin tuloksiin sidottu, tavoitehintainen ja hyvin läpinäkyvä, jotta molemmat osapuolet voivat nopeasti puuttua tilanteisiin, joissa hinta uhkaa karata käsistä.
Ketterät toimitukset ovat korostetusti riippuvaisia projektissa työskentelevien henkilöiden asiantuntemuksesta. Tästä syystä sekä toimittajan että asiakkaan projektihenkilöstön valintaan tulee kiinnittää huomiota. Lisäksi sopimuksessa tulee varmistaa, että projektihenkilöstön vaihtuvuus minimoidaan.
Muutoshallinta on kaikissa projekteissa merkittävässä asemassa, mutta etenkin ketterissä toimituksissa, joita leimaa jatkuva muutos, muutoshallintaan liittyvät mekanismit tulee kuvata sopimukseen hyvin konkreettisesti. Ketteryydestään huolimatta projektin hintaan, aikatauluun ja lopputuloksiin olennaisesti vaikuttavat muutokset tulisi alistaa erilliselle projektin ohjausryhmälle, jotta vältytään ikäviltä yllätyksiltä. Ketterästä toimitusmenetelmästä huolimatta asiakkaalla on viime kädessä oltava mahdollisuus päättää projektinsa koosta, aikataulusta ja kustannuksista.
Myös immateriaalioikeuksien jakautumisesta projektityön tuloksiin tulee sopia kattavasti ja yksiselitteisesti. Näin on erityisesti ketterissä toimitusprojekteissa siksi, että asiakas osallistuu projektissa syntyvien lopputulosten tekemiseen huomattavasti perinteistä mallia enemmän. Ilman nimenomaista sopimusehtoa osapuolille voi jäädä epäselväksi kenelle esimerkiksi projektin lopputuotosten tekijänoikeus kuuluisi suoraan lain nojalla.
Ketterä toimitusprojekti on jatkuvan muutoksen alla ja sen puitteissa syntyy koko ajan lopullisia tuotoksia. Tästä huolimatta tulisi ketteräänkin toimitusprojektisopimukseen tuoda mukaan hyväksymismenettelyä koskevat ehdot, jotta osapuolet voivat varmistua siitä, että toimituksen lopputuotokset vastaavat sekä ennen projektia että projektin kuluessa sovittua. Hyväksymismenettelyyn liittyen sopimuksessa tulisi myös ottaa kantaa siihen, minkälainen vastuu toimittajalla on toimituksessa havaituista virheistä. Kuuluuko virheiden korjaus normaaliin (ja veloitettavaan) iteratiiviseen projektityöskentelyyn, vai onko toimittaja perinteiseen tapaan velvollinen korjaamaan virheet omalla kustannuksellaan? Tämän asian ratkaisuun vaikuttaa olennaisesti myös toimitukselle sovittu hinnoittelumekanismi.
(Artikkeli on julkaistu Helsingin tietojenkäsittely-yhdistyksen HETKY-julkaisussa 4/2011.)