Agiilne arendus ja lepingud

Hiljuti pidasime ühe Eesti tarkvaraarendusfirmast kliendiga seminari, teemaks agiilne arendus ja lepingud. Praeguseks on pea igaüks - nii tellijad kui täitjad - nõus, et 90% juhtudest on erinevate agiilse arenduse elementide kasutamine tarkvaraarenduses hea mõte, mis hoiab kokku nii aega, raha kui kõigi asjaosaliste närve.

Nendest elementidest vast tähtsaim on põhjaliku detailanalüüsifaasi asendamine paindlikuma mudeliga, kus projekti skoop saab pidevalt täieneda ja muutuda vastavalt tellija tagasisidele.

Seda teoorias. Praktikas tekib tavaliselt küsimus, kuidas seda lepingu vormi valada, nii et riskid mõlema poole jaoks (eeldades välist partnerit) maandatud oleks. Variante on mitmeid, allpool mõned näited:
 

1. Time and material. Siin ostab tellija täitjalt sisuliselt ressurssi tööde läbiviimiseks ning maksab, tavaliselt igakuiselt, vastavalt reaalselt kulunud ajale. See lepinguvorm on lihtne ja administratiivselt mugav ning sobib väga hästi tööde läbiviimiseks olukorras, kus nõudmised võivad pidevalt muutuda ning vajalik on kiire reageerimine.
   
   Miinuspoolelt eeldab see suurt tellijapoolset usaldust täitja suhtes, samuti ei ole siin täitjal välist motivatsiooni oma tööd efektiivsemaks muuta.
    
2. Fikseeritud kogumaksumus ja tähtaeg. Siin teadvustavad osapooled, et etteantud eelarve raames tuleb kindlaks tähtajaks süsteem valmis saada. Projekti alguses fikseeritakse süsteemi visioon, ärieesmärgid, põhifunktsionaalsused ja kasutajagrupid, aga funktsionaalsused täpsustuvad ja (vahel ka) muutuvad töö käigus.
   
   Selle, tellijale rohkem kaitset pakkuva, lepingumudeli edukus sõltub sellest, kui hästi suudetakse viimatimainitud protsess paika panna. Kui poolte vahel on mõistlik usaldus, mõlemad peavad silmas projekti alguses paika pandud ärieesmärke ja töötavad skoobi täpsustamise ja iteratsioonidesse planeerimise nimel ühiselt (milleks agiilmetoodikates, nt Scrumis, on õnneks üsna täpsed juhised olemas), töötab ta väga hästi.
    
3. Osade kaupa tellimine raamlepingu alt. Selles mudelis sõlmitakse poolte vahel raamleping ning töide tellitakse fikseeritud hinnaga osade kaupa, mis vormistatakse lepingu lisadeks. Osade suurus sõltub situatsioonist, aga reeglina jääb nende arendusaeg paari nädala ja kolme kuu vahele.
   
   See lepingumudel pakub mõlemale poolele mõistlikku kaitset ning sobib hästi nt olemasoleva süsteemi edasiarenduseks ja avalikus sektoris kasutamiseks. Probleemid võivad tekkida erimeelsuste tõttu selle osas, kas osadesse mineva töö mahtude hindamine (mis reeglina eeldab teatud määral analüüsi teostamist) on tasustatav töö või mitte.
    
4. Fikseeritud skoop, maksumus ja tähtaeg. Olude sunnil kasutatakse seda mudelit endiselt üsna palju avaliku sektor hangetes. Probleemiks on siin mõistagi vajadus kogu skoop täpselt spetsifitseerida juba projekti alguses, mis on teadupärast väga keeruline ja aeganõudev (ressurssi raiskav).
   
   Sellised projektid muutuvad sageli vaidlusteks skoobi tõlgendamise teemal, kus arendaja püüab läbi saada kõige lihtsamate lahendustega ning tellija omakorda tahaks viimseni välja nõuda kõik, mis hankedokumentides kirjas, isegi kui seda projekti käigus selgunu põhjal reaalselt vaja pole.
   
   Selliste projektide edu sõltub poolte võimest üksteist usaldama hakata ning projekti tegeliku eesmärgi saavutamise nimel tihedat koostööd teha, vormistades vajalikud muudatused tagantjärgi (sisuliselt, kuigi mitte juriidiliselt, liigutakse 2. punktis kirjeldatud mudelisse).
    

Ülaltoodu ei olnud mõistagi lõplik loetelu, täpne mudel sõltub lõpuks ikkagi situatsioonist. Rohkem lugemist leiab nt Alistair Cockburni blogist.