Agiilne tarkvaraarendus sobib ebamugavalt lepingutega, kus lõpptulemus, ülesande ulatus ja tarnekuupäev on eelnevalt kindlaks määratud. Agiilses projektis töötavad osapooled lühikeste sprintide, kindlaksmääratud tööperioodide kaupa ja toote sisu kohandatakse projekti edenedes.
See pakub paindlikkust, aga tekitab ka juriidilisi küsimusi. Kes seab prioriteedid? Millal sprindi tulemust aktsepteeritakse? Ja millal toob üleandmiskuupäeva hilinemine kaasa lepingu rikkumise? See artikkel kirjeldab, kuidas pooled saavad neile küsimustele lepinguliselt vastata.
Agiilse lepingu all peame edaspidi silmas kokkulepete kogumit, millega pooled registreerivad agiilse koostöö. Praktikas toimub see koostöö raamlepingu vormis, millel on iga ülesande jaoks eraldi rakenduslepingud.
Paindlik töö ja lepingute sõlmimine
Traditsioonilises IT-projektis lepivad osapooled eelnevalt kokku funktsionaalse ja tehnilise disaini. Seejärel kohustub tarnija selle tulemuse kindlal hetkel tarnima. Agiilses arenduses see kindel sihtkoht teadlikult puudub: tulemus on liikuv eesmärk.
Iga sprint annab tulemuseks toimiva ja kasutatava tarkvaraosa. Klient kohandab kurssi demonstratsioonide ja kasutajakogemuse põhjal. Kui traditsioonilises lepingus on kirjas projekti lõpp, siis agiilses töös jääb see lahtiseks.
Seega peavad pooled lepinguliselt lahendama selle, mis traditsioonilise projekti puhul tavaliselt juba spetsifikatsioonist ilmneb. Silma paistavad neli teemat:
- kes määrab spetsifikatsioonid ehk kes täidab tooteomaniku rolli (isik, kes seab kliendi nimel prioriteedid);
- kuidas muudatused kantakse backlogi (veel ehitamata funktsionaalsuse prioriteetide loend), planeerimine ja hind;
- millal komponenti loetakse valmis olevaks, lähtudes valmimise definitsioonist (kokkulepitud kriteeriumid lõpptulemuse kohta) ja vastuvõtukriteeriumidest (nõuded, mille alusel tarnet testitakse);
- kas kokkulepitud tarnekuupäevad on ranged või soovituslikud.
Üks praktiline tagajärg: agiilset töötamist on raske kombineerida hankemenetlusega, mille puhul ülesande ulatus on täielikult eelnevalt kindlaks määratud. Hanke-eeskirjadele allutatud poolel, kes soovib siiski agiilset arendust, on soovitatav pakkumisdokumentides ruumi luua raamlepingule paindlikult määratletud rakendusülesannetega.
Parimad pingutused või tulemuste saavutamise kohustus?
Parima võimaliku tulemuse andmise kohustuse kohaselt ei garanteeri tarnija konkreetset tulemust. Ta kohustub rakendama hoolsust, mida võib oodata mõistlikult pädevalt ja mõistlikult tegutsevalt professionaalilt. Tulemuskohustuse kohaselt kohustub ta saavutama konkreetselt kirjeldatud tulemuse.
Lepingus olev nimetus ei ole määrav. Isegi kui lepingus viidatakse tulemuskohustusele, võib kohus kokkulepete sisu ja konteksti põhjal leida, et tegemist on tegelikult parimate pingutuste tegemise kohustusega ja vastupidi. Seega on poolte tegelik koostööviis vähemalt sama oluline kui valitud sõnastus.
See eristamine on praktikas oluline, sest tulemuskohustuse puhul on kesksel kohal kokkulepitud tulemus, samas kui parimate pingutuste kohustuse puhul tuleb hinnata, kas tarnija rakendas nõutavaid pingutusi. See erinevus määrab, mille üle pooled vaidluses vaidlevad ja mida nad peavad tõendama.
Siin kordub kaks seadusesätet. Hollandi tsiviilseadustiku artikkel 6:74(1) sätestab aluse kahju hüvitamiseks kohustuse rikkumise korral. See ei ütle aga, millal on tegemist rikkumisega; see sõltub kohustuse kvalifikatsioonist ja kokkulepete sisust. Artikkel 6:248 sätestab, et lepingul on ka mõistlikkusest ja õiglusest tulenevad tagajärjed. See jätab ruumi agiilse koostöö olemuse arvessevõtmiseks poolte kohustuste tõlgendamisel.
Lepinguline alus: raam- ja rakenduslepingud
Praktikas toimub agiilne koostöö kihtidena. Raamleping reguleerib üldist raamistikku: kohaldatavaid tingimusi, vastutust, konfidentsiaalsust ja koostöö viisi.
Iga ülesande puhul sõlmivad pooled rakenduslepingu, milles sätestatakse selle osa ulatus, planeerimine, meeskonna koosseis, hind ja vastuvõtukriteeriumid. Seega jääb õigussuhe stabiilseks, samas kui sisu saab iga sprindi või väljalaskega edasi liikuda.
Ilma selgete vastuvõtukriteeriumideta puudub dokument selle kohta, mille alusel tulemust testida tuleb. Vaidlused sprindi õnnestumise üle tekivad siis kergemini. Seega on iga sprindi konkreetsed ja mõõdetavad vastuvõtukriteeriumid olulisemad kui silt, mille pooled kohustusele omistavad.
Üks teema, mis väärib agiilsetes lepingutes rohkem tähelepanu kui traditsioonilistes IT-lepingutes, on ennetähtaegne lõpetamine. Kuna agiilne projekt on järjestikuste sprintide jada ilma kindla lõpp-punktita, peab leping reguleerima, millal pool võib lepingu lõpetada, mis juhtub juba tarnitud komponentide ja lähtekoodiga ning kuidas toimub üleandmine teisele tarnijale.
Siinkohal on olulised ka üldised tingimused. NLdigitali tingimused 2025 asendavad 2020. aasta väljaannet, lisades muu hulgas peatükke vastavuse, küberturvalisuse, andmete jagamise, tehisintellekti ja veebiplatvormide kohta. 2020. aasta tingimused jäävad jõusse seal, kus pooled neis kokku leppisid, seega kontrollige, milline versioon teie lepingule kehtib. Need käsitlevad agiilsete aspektide eripära vaid piiratud ulatuses; pooled peavad need rakenduslepingus lahendama.
Tähtaegu ja koostööd käsitlevad kohtupraktikad
Kohtupraktika ei näita üldist reeglit, et agiilne tarnekuupäev ei saa kunagi olla range. Kvalifikatsioon sõltub lepingu sisust, valitud töömeetodist ja poolte tegelikust koostööst. Seda illustreerivad kolm juhtumit.
Midden-Nederlandi ringkonnakohus, 26. juuli 2023 (ECLI:NL:RBMNE:2023:5936). Tarnija IPS arendas kliendile Synergy kaalutarkvara, kasutades Scrum'i. Lepingus oli sätestatud umbes 24-nädalane teostusaeg. Sellest ei peetud kinni; uus tähtaeg lükati edasi ja seda ei täidetud uuesti. Kui 2020. aasta detsembri keskel oli kümnest kokkulepitud nädalaplokist üheksa kohale toimetatud, tühistas Synergy lepingu. Kohus leidis, et lubatud teostusaeg loeti rangeks tähtajaks, seega oli tegemist lepingu rikkumisega. Lepingu tühistamine aga ei jäänud jõusse: arvestades koostöö olemust, kus tähtaegade ületamisel sõlmitakse uued kokkulepped, ja arvestades, et projekt oli peaaegu valmis, ei õigustanud see rikkumise tagajärg lepingu tühistamist. Praktiline tähtsus: isegi agiilse koostöö raames võib lubatud teostusaeg olla range, kuid rikkumise tagajärjel ei teki tühistamisest automaatselt õigust.
Ringkonnakohus Amsterdam, 22. aprill 2026 (ECLI:NL:RBAMS:2026:3930). Klient väitis, et arendaja DTT oli uue mobiilirakenduse tarninud hilinenult, ületanud eelarvelisi kulusid ja teinud olemasolevate rakenduste hooldustöid ebapiisavalt. Kohus jättis kõik nõuded rahuldamata. Ranged tähtajad puudusid: hinnapakkumises ja kirjavahetuses nimetatud tarnekuupäeva tuli vaadelda kui parimate pingutuste kohustust agiilse või scrum-töömeetodi raames, kus paindlikkus ja arenev arusaamine on kesksel kohal. Praktiline tähtsus: pool, kes soovib ranget kuupäeva, peab selle selgesõnaliselt registreerima; hinnapakkumises olevast kuupäevast üksi ei piisa.
Amsterdam Apellatsioonikohus kohtuasjas On Airi ja Triple IT vahel. Pooled olid kokku leppinud töötada agiilselt või scrum-meetodil ilma lõpptulemusi määratlemata. Selles kontekstis tähendab kohustus vaid pädevate arendajate kättesaadavaks tegemist, kes rakendavad oma panust vastavalt projektile ja hoolsa töövõtja hoolsuskohustusele. Kui tarnitav ei vasta nõuetele, on selle vastavusse viimiseks tehtavad pingutused põhimõtteliselt lisatöö. See võib olla teistsugune juhul, kui tarnija ei ole kokkulepetest või oma hoolsuskohustusest kinni pidanud, kuid selle tõendamise kohustus lasub kliendil. Seega ei ole ainuüksi asjaolu, et lõpptoote toimivus ei vasta kliendi soovidele, piisav ebaõnnestumise tuvastamiseks. Käesolevas menetluses määras kohus ka IT-eksperdi, et selgitada selliseid termineid nagu scrum master, sprint ja done. Praktiline tähtsus: kui määratletud lõpptulemused puuduvad, langeb parandustöö kliendi kanda.
Tühistamisnõude hindamisel võib kohus seega kaaluda iga poole rolli viivituses ja projekti läbiviimises. Pool, kes ei soovi üksikjuhtumil sellele kaalumisele loota, peab ise registreerima, millal on tähtaeg range ja millal on ennetähtaegne lõpetamine võimalik.
Kaheksa punkti, mida lepingus käsitleda
Agiilse lepingu koostamisel töötage läbi järgmised punktid. Iga teema kohta sõnastage vastus lisatud küsimusele.
- Ulatus: milline funktsionaalsus kuulub sprindi alla ja mis jääb sellest selgelt välja?
- Prioriseerimine: kes võib mahajäämust muuta ja kas sellel isikul on volitus seda kliendi nimel teha?
- Vastuvõtmine: millise aja jooksul peab klient testi tegema ja vastama ning mis saab siis, kui ta seda ei tee?
- Tähtajad: kas kuupäev on nimetatud soovituslikuks või rangelt kindlaksmääratud ja kas lepingus on see sama sõnas kirjas?
- Hind: kas makstakse sprindi, funktsioonipunkti, töötundide või tulemuse kohta?
- Omandiõigus ja kasutamine: millal saab klient juurdepääsu lähtekoodile ja dokumentatsioonile?
- Lepingu lõpetamine: mis ennetähtaegse lõpetamise korral üle kantakse ja millise makse vastu?
- Järjepidevus: kas teine tarnija saab tööd jätkata ja millist dokumentatsiooni ning koodi ülekantavust see nõuab?
Lisage ka valmisoleku definitsioon, mis pole mitte ainult funktsionaalne, vaid seab ka nõuded koodi kvaliteedile, dokumenteerimisele ja ülekantavusele. Vastasel juhul tekib pärast lepingu lõpetamist ikkagi vaidlus selle üle, kas tarnitud töö on kasutatav.
Järeldus
Agiilne töö pakub paindlikkust, kuid nõuab lepingut, mis erineb põhimõtteliselt traditsioonilisest mudelist. Otsustava tähtsusega on parimate pingutuste ja tulemustele keskendumise kohustuste eristamine, selged vastuvõtukriteeriumid ja ennetähtaegse lõpetamise kord. Arutatud juhtumid näitavad, et tulemus sõltub suuresti konkreetsetest kokkulepetest ja tegelikust koostööst. Neid punkte käsitlev leping on paremini kooskõlas poolte tegeliku töökorraldusega ja vähendab vaidluste riski.
Law & More Abistab IT-tarnijaid ja kliente raamistiku koostamisel, läbivaatamisel ja läbirääkimistel ning lepingute rakendamisel ning nõustab kohustuste kvalifitseerimise, vastuvõtukriteeriumide ja lõpetamise korralduse osas. Kas teil on vaidlus agiilse projekti viivituse, tulemuste või lõpetamise üle? Võtke meiega julgelt ühendust, et saada personaalset nõu.
Korduma kippuvad küsimused
Allpool vastame küsimustele, mida meile sellel teemal kõige sagedamini esitatakse.
Mis on agiilne leping?
Kokkulepete kogum, mille alusel pooled registreerivad agiilse koostöö. Praktikas koosneb see raamlepingust, mis kehtestab üldise raamistiku, ja iga ülesande rakenduslepingust, mis hõlmab selle osa ulatust, planeerimist, hinda ja vastuvõtukriteeriume.
Kas agiilses projektis on tarnekuupäev range tähtaeg?
Mitte automaatselt. Üldreeglit pole; see sõltub lepingust, töömeetodist ja tegelikust koostööst. Kui soovite täpset kuupäeva, siis pange see kirja võimalikult lühikese sõnaga. Pakkumises olevat kuupäeva on peetud ebapiisavaks.
Mis vahe on parimate pingutuste ja tulemustele keskendumise kohustusel?
Tulemuskohustuse puhul on kokkulepitud tulemus kesksel kohal. Parima pingutuse kohustuse puhul tuleb hinnata, kas tarnija rakendas nõutavaid pingutusi. See erinevus määrab, mille üle pooled vaidluses vaidlevad.
Kas lepingus olev silt on määrav?
Ei. Isegi kui lepingus viidatakse tulemuskohustusele, võib kohus sisu ja konteksti põhjal leida, et tegemist on tegelikult parimate pingutuste tegemise kohustusega ja vastupidi. See, kuidas pooled tegelikult toimivad, on vähemalt sama oluline.
Kes võib mahajäämust muuta?
Tooteomaniku rolli täitja. Pange kirja, kes see on ja kas tal on volitus seda kliendi nimel teha. Ilma selle kokkuleppeta tekivad vaidlused selle üle, kes vastutab prioriteetide muutmise eest.
Miks on vastuvõtukriteeriumid nii olulised?
Ilma selgete vastuvõtukriteeriumideta puudub arvestus selle kohta, mille suhtes tulemust tuleb testida. Vaidlused sprindi õnnestumise üle tekivad siis kergemini. Praktikas on need olulisemad kui kohustusele lisatud silt.
Kes maksab parandustööde eest, kui tarne ei vasta nõuetele?
Kui lõpptulemusi ei ole määratletud, langevad kliendi soovide täitmiseks tehtavad pingutused põhimõtteliselt kliendi kanda lisatööna. Teisiti on lood juhul, kui tarnija ei ole kokkulepetest või oma hoolsuskohustusest kinni pidanud, kuid selle tõendamise kohustus lasub kliendil.
Kuidas toimub maksmine agiilses töös?
Makse sidumine ühe kindla tarnehetkega ei sobi kokku meetodiga, millel pole fikseeritud lõpptulemust. Levinud alternatiivid on maksmine sprindi, funktsioonipunkti või töötundide eest. Salvestage valitud alus selgelt.
Kas ma saan agiilset tööd ühendada avaliku hankega?
See nõuab kohandatud lähenemist, sest täielikult fikseeritud ulatusega hange eeldab eelnevalt teadaolevat tulemust. Pakkumisdokumentides tuleks ette näha raamlepingu võimalus paindlikult määratletud rakendusülesannetega.
Mida peaksin ennetähtaegse lõpetamise osas korraldama?
Millistel tingimustel võib osapool töö peatada, mis juhtub juba tarnitud komponentide ja lähtekoodiga, millise makse vastu toimub ja mida teine tarnija töö jätkamiseks vajab.
Kas NLdigitali tingimused 2025 pakuvad piisavalt juhiseid?
Ainult piiratud ulatuses. Need asendavad 2020. aasta väljaannet ja lisavad muu hulgas peatükke vastavuse, küberturvalisuse, andmete jagamise, tehisintellekti ja veebiplatvormide kohta, kuid ei käsitle konkreetseid agiilseid aspekte. 2020. aasta tingimused jäävad kehtima seal, kus need kokku lepiti. Need peate ise rakenduslepingus lahendama.
Kas teil on vaidlus IT-tarnijaga või soovite, et IT-leping üle vaadataks? Meie IT-juristid aitavad teid hea meelega.
Kuidas Law & More saab teid sellega aidata, on selgitatud meie lehel IT-jurist lehel.
