Ketterän ohjelmistokehityksen pyhä julistus Agile Manifesto julkaistiin 2001. Julistuksessa esiteltiin vaihtoehtoisia, ketterämpiä ja oletetusti tehokkaampia tapoja kehittää ohjelmistoja, kuin siihen asti enimmäkseen käytetyt perinteiset määrittely- ja prosessivetoiset kehitysmallit, kuten vaikkapa vesiputousmalli.

 Julistuksen sisältö tiivistyy neljään pääkohtaan:

• Yksilöiden ja heidän välisen vuorovaikutuksen korostaminen prosessien ja työkalujen sijaan
• Toimivan ohjelmiston korostaminen kaiken kattavan dokumentaation sijaan
• Asiakasyhteistyön korostaminen sopimusten sijaan
• Ohjelmistokehityksen aikana tapahtuvien muutosten hyväksyminen sekä niihin vastaaminen ennalta tehtyjen kiveen hakattujen suunnitelmien ja määrittelyjen seuraamisen sijaan

Tänä päivänä valtaosa ohjelmistokehityksestä tapahtuu ketterän ohjelmistokehityksen periaatteiden mukaisesti. Taustalla projekteissa käytettävät sopimusmallit ovat kuitenkin jääneet ketterän kehityksen luotijunan kyydistä, ja ketterät sopimusmallit ovat edelleen kohtuullisen harvinaisia.

Perinteiset sopimusmallit pyrkivät valamaan projektin neljä peruspilaria eli sisällön, kustannukset, aikataulun ja laadun sentilleen sovittuun kohtaan kolmen metrin syvyyteen. Perinteisillä toimialoilla, kuten esimerkiksi rakennusalalla, tämä malli toimii – tukevien peruspilarien päälle on turvallista lähteä rakennuttamaan vaikkapa sitä kuuluisaa unelmien omakotitaloa. Ketterä ohjelmistokehitys on kuitenkin kaukana perinteisistä ja vakiintuneista toimialoista, eivätkä perinteiset sopimusmallit ole välttämättä paras vaihtoehto toimivien sovellusten rakennuttamiseksi. Ohjelmistokehitys on usein hyvin epävarmaa ja monia muuttujia sisältävää jatkuvaa tutkimus- ja kehitystyötä. Perinteisten sopimusmallien heikkous on siinä, etteivät ne huomioi kovinkaan hyvin epävarmuutta, muutosta ja projektin aikana esiin nousevia mahdollisia yllätyksiä.

Entä jos asiakas toteaa matkan varrella, että haluaakin omakotitalostaan kaksikerroksisen yksikerroksisen sijaan? Tai urakoitsija toteaa olohuoneen valmistuttua, ettei makuuhuoneelle ja keittiölle jää sittenkään niille kaavailtua tilaa, sillä seinistä piti tehdä oletettua paksummat? Rakennusalalla kohtuullisen mahdottomia skenaarioita, mutta ohjelmistokehityksessä arkipäivää. Valettu perustus pilareineen joudutaan tällöin pistämään kokonaan uusiksi kustannuksia, aikatauluja ja sisältöä myöten. Pahimmillaan luottamus osapuolten kesken romuttuu ja erimielisyyksiä ratkotaan raastuvassa asti.

Hyötyä sekä asiakkaille että toimittajille

Ketterä ohjelmistokehitys pyrkii ennaltaehkäisemään edellä kuvattuja ongelmia esimerkiksi pilkkomalla suuria kokonaisuuksia pienemmiksi paremmin ymmärrettäviksi ja nopeammin toimitettaviksi osakokonaisuuksiksi. Lisäksi ketterä ohjelmistokehitys suosii mahdollisimman nopeita osatoimituksia, joiden kautta lopullinen toimitus rakentuu läpinäkyvästi pala palalta. Ketterät sopimusmallit mukailevat ketterää ohjelmistokehitystä ja sen perusperiaatteita. Ketterissä sopimusmalleissa pyritään korostamaan yhteistyötä ja vuorovaikutusta eri osapuolten kesken ja huomiomaan ohjelmistokehityksen dynaaminen luonne. Ketterät sopimusmallit rakennetaan yleensä osatoimitusten ympärille.

Ketterät sopimusmallit jättävät usein yhden tai useamman projektin peruspilareista valamatta. Esimerkiksi projektin tavoitteet ja laatutaso voidaan sopimusvaiheessa rajata, mutta projektin aikataulu ja kustannukset voidaan jättää osittain avoimiksi. Tällöin voidaan sopia, että toteutusta tehdään ketterälle ohjelmistokehitykselle ominaisissa sprinteissä, eli esimerkiksi kahden viikon kehitysjaksoissa. Jokaisen sprintin päätteeksi asiakkaalle tehdään osatoimitus, jonka asiakas katselmoi ja hyväksyy. Asiakas maksaa tällöin esimerkiksi sprintti kerrallaan projektin etenemisestä. Asiakas voi milloin tahansa puhaltaa pilliin ja keskeyttää pelin, mikäli projekti ei etene asiakkaan toivomalla tavalla. Lisäksi projektin sisältöä voidaan milloin tahansa muuttaa osapuolten ymmärryksen kasvaessa tai uusien tarpeiden ilmetessä.

Yleistä ketterille sopimusmalleille on myös se, että ne pyrkivät muodostamaan asiakkaasta ja toimittajasta yhtenäisen tiimin, joka puhaltaa samaan hiileen. Yksipuoliset bonukset ja sanktiot voidaan jättää kokonaan pois ja rakentaa sopimusmalli siten, että asiakas ja toimittaja jakavat niin hyvän kuin pahankin. Esimerkiksi tavoitehintasopimuksessa voidaan sopia, että mikäli alun perin suunnitellut tunnit alitetaan 15%, maksetaan toimittajalle toteutuneista tunneista 10% korkeampi tuntihinta. Asiakas saa tällöin tuotteensa halvemmalla ja mahdollisesti nopeammin kuin suunniteltu, ja toimittaja puolestaan korkeamman katteen työstään. Vastaavasti mikäli alun perin suunnitellut tunnit ylitetään 15%, maksetaan toimittajalle 10% pienempi tuntihinta. Tällöin asiakas maksaa hankkeesta suunniteltua enemmän ja toimitus mahdollisesti viivästyy. Toimittaja vastaavasti saa pienemmän katteen työstään.

Ketterien sopimusmallien käyttö tuo parhaimmillaan suurta hyötyä niin asiakkaalle kuin toimittajalle motivoiden heitä ja sitoen osapuolet yhteisiin tavoitteisiin jaetun hyödyn ja haitan kautta. Muutosten ja yllätysten huomiointi helpottuu huomattavasti, kun projektin etenemisen seuranta ja tarvittaessa suunnan muuttaminen on osatoimitusten ansiosta läpinäkyvää ja reaaliaikaista.

Ketterien sopimusmallien käytön ohjelmistokehityksessä soisi yleistyvän nopeammin. Kaikkien osapuolten olisi jo sopimusvaiheessa hyvä asennoitua siihen, että muutoksia ja yllätyksiä matkan varrella todennäköisesti tulee, eikä kaikkia pilareita ole viisasta valaa syvälle maahan heti alussa – eihän tässä taloa olla rakentamassa vaan sovellusta.

Ketteristä sopimusmalleista ja niiden hyödyntämisestä voi lukea enemmän esimerkiksi www.agilecontracts.com -sivustolta.