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:
- 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.
- 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.
- 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.
- 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.
March 10th, 2010 at 00:23
Hea lühiülevaade lepingu variantidest. Ise olen kokku puutunud ja kasutanud kõiki kirjeldatud lepinguid välja arvatud nr 2. Kas fikseeritud eelarve ja tähtajaga lepingut on reaalselt Eestis kasutatud ka, hea meelega kuulaks mõnest sellisest näitest täpsemalt. See tundub teoorias päris mõistlik mudel, aga kuidas selle elluviimisega lõpuks ikkagi kujuneb?
PS. Artikli 2 lause vajaks veidi lihtsustamist, tõeliselt pikk ja mõte läheb kaduma
March 11th, 2010 at 16:10
Martin, sellise lepinguga olen kokku puutunud küll. Projekti maht jäi vahemikku 3000-4000 tundi ning pikkus oli 6 kuud.
Lepinguga fikseeriti eelarve ja lõpptähtaeg, samuti esimeste iteratsioonide sisu ja ülejäänud iteratsioonide ärieesmärgid. Ülejäänud iteratsioonide sisud täpsustusid projekti jooksul. Kasutati Scrumi, mille protsessis osales ka tellija (paraku pole see mitte alati nii), toimis küll.
Nagu öeldud, vajab see mudel pooltevahelist usaldust ning seda, et mõlemad keskenduks parima võimaliku tulemuse saavutamisele eelarve ja tähtaja piires. Teatud läbirääkimised selle üle, mis mahub skoopi ja mis mitte, on töö käigus loomulikud, aga sellest hetkes, kui tellija hakkab tarnijat kasumi liigses optimeerimises kahtlustama, laguneb protsess ebakonstruktiivsetes vaidlustes laiali.
2. lause jaotasin kaheks, tänud.