{"id":61460,"date":"2023-12-12T14:44:31","date_gmt":"2023-12-12T05:44:31","guid":{"rendered":"https:\/\/monolith.law\/et\/?p=61460"},"modified":"2024-06-04T11:04:08","modified_gmt":"2024-06-04T02:04:08","slug":"legal-and-contract-issues-of-agile-development","status":"publish","type":"post","link":"https:\/\/monolith.law\/et\/it\/legal-and-contract-issues-of-agile-development","title":{"rendered":"Agile arendusega seotud \u00f5iguslikud ja lepingulised probleemid"},"content":{"rendered":"\n<p>S\u00fcsteemiarenduse l\u00e4biviimiseks on olemas metoodikad. K\u00f5ige klassikalisem ja \u00fcldisem neist on veekeeris mudel (Waterfall model), millest paljud s\u00fcsteemiarendust k\u00e4sitlevad \u00f5igusraamatud l\u00e4htuvad. K\u00e4esolevas artiklis k\u00e4sitleme agiilse arendusmudeli p\u00f5hjal s\u00fcsteemiarendusega seotud \u00f5iguslikke probleeme, mille kohta on raamatutest ja muudest allikatest raske infot leida.<\/p>\n\n\n\n<div id=\"ez-toc-container\" class=\"ez-toc-v2_0_53 counter-hierarchy ez-toc-counter ez-toc-grey ez-toc-container-direction\">\n<div class=\"ez-toc-title-container\">\n<span class=\"ez-toc-title-toggle\"><\/span><\/div>\n<nav><ul class='ez-toc-list ez-toc-list-level-1 ' ><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-1\" href=\"https:\/\/monolith.law\/et\/it\/legal-and-contract-issues-of-agile-development\/#Agile_arendusmudel_ja_oigus\" title=\"Agile arendusmudel ja \u00f5igus\">Agile arendusmudel ja \u00f5igus<\/a><ul class='ez-toc-list-level-3'><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-2\" href=\"https:\/\/monolith.law\/et\/it\/legal-and-contract-issues-of-agile-development\/#Mis_on_susteemiarenduse_mudel\" title=\"Mis on s\u00fcsteemiarenduse mudel?\">Mis on s\u00fcsteemiarenduse mudel?<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-3\" href=\"https:\/\/monolith.law\/et\/it\/legal-and-contract-issues-of-agile-development\/#Agile_arendusmudeli_omadused\" title=\"Agile arendusmudeli omadused\">Agile arendusmudeli omadused<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-4\" href=\"https:\/\/monolith.law\/et\/it\/legal-and-contract-issues-of-agile-development\/#Dokumentide_haldamine_ja_muudatuste_juhtimine_Agile_arenduses\" title=\"Dokumentide haldamine ja muudatuste juhtimine Agile arenduses\">Dokumentide haldamine ja muudatuste juhtimine Agile arenduses<\/a><ul class='ez-toc-list-level-3'><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-5\" href=\"https:\/\/monolith.law\/et\/it\/legal-and-contract-issues-of-agile-development\/#Dokumentide_haldamise_tahtsus\" title=\"Dokumentide haldamise t\u00e4htsus\">Dokumentide haldamise t\u00e4htsus<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-6\" href=\"https:\/\/monolith.law\/et\/it\/legal-and-contract-issues-of-agile-development\/#Kontaktide_noupidamise_loomine_on_dokumentide_haldamisel_tohus\" title=\"Kontaktide n\u00f5upidamise loomine on dokumentide haldamisel t\u00f5hus\">Kontaktide n\u00f5upidamise loomine on dokumentide haldamisel t\u00f5hus<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-7\" href=\"https:\/\/monolith.law\/et\/it\/legal-and-contract-issues-of-agile-development\/#Kuidas_kasutada_kontaktide_konsultatsiooninoukogu_muudatuste_haldamiseks\" title=\"Kuidas kasutada kontaktide konsultatsioonin\u00f5ukogu muudatuste haldamiseks\">Kuidas kasutada kontaktide konsultatsioonin\u00f5ukogu muudatuste haldamiseks<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-8\" href=\"https:\/\/monolith.law\/et\/it\/legal-and-contract-issues-of-agile-development\/#Usalduskohustuse_ja_hea_usu_pohimotte_moistmine_on_oluline\" title=\"Usalduskohustuse ja hea usu p\u00f5him\u00f5tte m\u00f5istmine on oluline\">Usalduskohustuse ja hea usu p\u00f5him\u00f5tte m\u00f5istmine on oluline<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-9\" href=\"https:\/\/monolith.law\/et\/it\/legal-and-contract-issues-of-agile-development\/#Kokkuvote\" title=\"Kokkuv\u00f5te\">Kokkuv\u00f5te<\/a><\/li><\/ul><\/nav><\/div>\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Agile_arendusmudel_ja_oigus\"><\/span>Agile arendusmudel ja \u00f5igus<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/monolith.law\/wp-content\/uploads\/2019\/10\/shutterstock_321052328-1024x683.jpg\" alt=\"\" class=\"wp-image-5414\" \/><figcaption class=\"wp-element-caption\">Seletame Agile arenduse omadusi.<\/figcaption><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Mis_on_susteemiarenduse_mudel\"><\/span>Mis on s\u00fcsteemiarenduse mudel?<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>S\u00fcsteemiarenduse projektides on arendusmudelid raamistikud, mis aitavad j\u00e4lgida projekti edenemist. \u00dcks tuntumaid on nn &#8220;kosemudel&#8221;. See t\u00e4hendab, et nagu j\u00f5gi voolab &#8220;\u00fclevalt&#8221; &#8220;allapoole&#8221;, l\u00e4bitakse ka n\u00f5uete m\u00e4\u00e4ratlemise, disaini, rakendamise, testimise jne etapid \u00fche jutiga. See mudel on suunatud protsessi kordamise ja topeltt\u00f6\u00f6 v\u00e4hendamisele ning sobib h\u00e4sti planeeritud t\u00f6\u00f6de teostamiseks.<\/p>\n\n\n\n<p>Teisalt, Agile arendusmudelis rakendatakse ja testitakse v\u00e4ikseid programme korduvalt. Sellise korduva t\u00f6\u00f6 k\u00e4igus luuakse j\u00e4rk-j\u00e4rgult suurem s\u00fcsteem. T\u00e4psema selgituse s\u00fcsteemiarenduse mudelite kohta ja m\u00f5lema arendusmudeli eeliste ning puuduste v\u00f5rdluse leiate allpool toodud artiklist.<br><\/p>\n\n\n\n<p><a href=\"https:\/\/monolith.law\/corporate\/legal-merits-and-demerits-of-development-model\" target=\"_blank\" rel=\"noreferrer noopener\">https:\/\/monolith.law\/corporate\/legal-merits-and-demerits-of-development-model[ja]<\/a><\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Agile_arendusmudeli_omadused\"><\/span>Agile arendusmudeli omadused<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>Agile arendusmudeli suur eelis on v\u00f5ime kiiresti t\u00f6\u00f6d alustada. N\u00f5uete m\u00e4\u00e4ratlemise ja disainidokumentide loomise &#8220;\u00fclemise astme&#8221; t\u00f6\u00f6d ning programmi rakendamise t\u00f6\u00f6d ei ole eraldatud, mis v\u00f5imaldab paindlikult juhtida funktsioonide lisamist, parandamist, spetsifikatsioonide muutmist jne. \u00d5iguslikust vaatepunktist on Agile arendusmudeli edukaks juhtimiseks eriti oluline, kuidas dokumentide ja muudatuste haldamist korraldada. Agile arendusmudelis ei ole rollid ja vastutus nii selgelt jaotatud kui kosemudelis. Lisaks, kuna see meetod keskendub &#8220;tegevusele&#8221; ja &#8220;kiirusele&#8221;, mitte &#8220;haldamisele&#8221;, v\u00f5ib see viia disaini- ja spetsifikatsioonidokumentide ning koosolekute protokollide puudulikkuseni.<\/p>\n\n\n\n<p>Lisaks, seoses muudatuste haldamisega, kuna Agile arendusmudel v\u00f5imaldab muudatustele sujuvalt reageerida, v\u00f5ib projekt p\u00f5leda l\u00e4bi, kui spetsifikatsioonide muutmise taotlusi rahuldatakse kohapeal, m\u00f6\u00f6da minnes heakskiidu protsessist otsustajate tasandil. Sellisel juhul v\u00f5ib &#8220;sujuv reageerimine hilisematele muudatustele&#8221; &#8211; arendusmudeli eelis &#8211; muutuda projekti l\u00e4bip\u00f5lemise riskiks.<br><\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Dokumentide_haldamine_ja_muudatuste_juhtimine_Agile_arenduses\"><\/span>Dokumentide haldamine ja muudatuste juhtimine Agile arenduses<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/monolith.law\/wp-content\/uploads\/2019\/10\/pixta_50106785_M-1024x768.jpg\" alt=\"\" class=\"wp-image-5416\" \/><figcaption class=\"wp-element-caption\">Mis on dokumentide haldamise ja spetsifikatsioonimuudatuste juhtimise meetodid Agile arendusmudelis?<\/figcaption><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Dokumentide_haldamise_tahtsus\"><\/span>Dokumentide haldamise t\u00e4htsus<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>Agile arendusmudelil p\u00f5hinevates arendusprojektides on seaduslik murekoht see, et suuline suhtlus koguneb ja see toob kaasa dokumentide puuduse. Selle punkti osas, miks dokumentide haldamine on s\u00fcsteemiarendusprojektides \u00fcldse oluline, selgitame \u00fcksikasjalikult j\u00e4rgmises artiklis.<br><\/p>\n\n\n\n<p><a href=\"https:\/\/monolith.law\/corporate\/the-minutes-in-system-development\" target=\"_blank\" rel=\"noreferrer noopener\">https:\/\/monolith.law\/corporate\/the-minutes-in-system-development[ja]<\/a><\/p>\n\n\n\n<p>Selles artiklis selgitame dokumentide haldamise t\u00e4htsust s\u00fcsteemiarendusprojektides kahest vaatenurgast: vaidluste ennetamine (st &#8220;ennetav \u00f5igusteenus&#8221;) ja t\u00f5endite s\u00e4ilitamine vaidluse korral (st &#8220;kriisijuhtimine&#8221;).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Kontaktide_noupidamise_loomine_on_dokumentide_haldamisel_tohus\"><\/span>Kontaktide n\u00f5upidamise loomine on dokumentide haldamisel t\u00f5hus<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>Kui kasutatakse Agile arendusmudelit, ei ole erinevalt Waterfall mudelist ette valmistatud selget plaani. Seet\u00f5ttu ei piisa ainult plaani ja tegelikkuse erinevuse haldamisest, vaid on oht, et kui k\u00f5ik j\u00e4tta t\u00f6\u00f6koha otsustada, v\u00f5ivad nii ajalised kui ka rahalised kulud paisuda.<\/p>\n\n\n\n<p>Seet\u00f5ttu on t\u00f5hus meetod, kui vastutav isik korraldab regulaarselt kontaktide n\u00f5upidamisi projekti sujuva kulgemise nimel. Kui arenduse mastaap on v\u00e4ike, on t\u00f5epoolest eelistatud pigem selline l\u00e4henemine, kus vastutavad isikud kogunevad j\u00e4rjest, kui regulaarselt kontaktide n\u00f5upidamisi korraldada. Kuid Agile arendusmudeli puhul on eriti suur oht, et ajakohaseid probleeme ei k\u00e4sitleta koosolekul. Seet\u00f5ttu on regulaarsete kontaktide n\u00f5upidamiste korraldamine turvaline, kaasates need ka lepingutesse. Selle reguleerimise viis on n\u00e4idatud j\u00e4rgmiselt Jaapani Majandusministeeriumi (METI) lepingumudelis.<br><\/p>\n\n\n\n<blockquote class=\"wp-block-quote\">\n<p>(Kontaktide n\u00f5upidamise loomine)<\/p>\n\n\n\n<p>Artikkel 12. A ja B korraldavad kontaktide n\u00f5upidamise kuni projekti l\u00f5puni, et arutada projekti edenemist, riskijuhtimist ja aruandlust, \u00fchiseid ja individuaalseid t\u00f6\u00f6\u00fclesandeid, s\u00fcsteemi spetsifikatsioonide sisu, probleemide arutelu ja lahendamist ning muid vajalikke asju, et projekt sujuvalt l\u00e4bi viia. Kuid, (j\u00e4etakse vahele).<br><\/p>\n\n\n\n<p>2. Kontaktide n\u00f5upidamist korraldatakse p\u00f5him\u00f5tteliselt regulaarselt individuaalse lepingu sagedusega ja lisaks korraldatakse seda vajadusel A v\u00f5i B poolt.<br><\/p>\n\n\n\n<p>3. Kontaktide n\u00f5upidamisel osalevad m\u00f5lema poole vastutavad isikud, peamised vastutavad isikud ja need, keda vastutav isik peab sobivaks. Lisaks v\u00f5ivad A ja B n\u00f5uda teise poole esindajate osalemist kontaktide n\u00f5upidamisel ja teine pool peab sellele vastama, v\u00e4lja arvatud juhul, kui on m\u00f5istlik p\u00f5hjus.<br><\/p>\n\n\n\n<p>4. B loob kontaktide n\u00f5upidamisel eraldi A ja B vahel kokku lepitud vormis edenemisaruande ja esitab selle, kontrollib edenemise olukorda selle edenemisaruande alusel ning arutab ja otsustab vajadusel hilinemise olemasolu, hilinemise p\u00f5hjused ja meetmed, selle peat\u00fcki muudatused (personalimuudatused, suurendamine v\u00f5i v\u00e4hendamine, uue allt\u00f6\u00f6v\u00f5tja m\u00e4\u00e4ramine jne), turvameetmete t\u00e4itmise olukord, individuaalse lepingu muutmise vajadus, individuaalse lepingu muutmise p\u00f5hjused, kui need on olemas, ja muud k\u00fcsimused. <br><\/p>\n\n\n\n<p>(J\u00e4rgnevad punktid 5, 6 ja 7 on v\u00e4lja j\u00e4etud.)<br><\/p>\n<\/blockquote>\n\n\n\n<p>Kontaktide n\u00f5upidamise olemasolu annab lepinguklauslitele teatud \u00f5igusp\u00e4rasuse ja eristab seda teistest ad hoc koosolekutest.<br><\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Kuidas_kasutada_kontaktide_konsultatsiooninoukogu_muudatuste_haldamiseks\"><\/span>Kuidas kasutada kontaktide konsultatsioonin\u00f5ukogu muudatuste haldamiseks<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>Samuti, Agile arenduses, on eelduseks, et m\u00f5lemad pooled muudavad esialgselt kokkulepitud asju p\u00e4rast. Seet\u00f5ttu on v\u00e4ga oluline, kuidas p\u00e4rastl\u00f5unaseid spetsifikatsioonimuudatusi hallata.<\/p>\n\n\n\n<p>Sel juhul, kui kontaktide konsultatsioonin\u00f5ukogu korraldatakse regulaarselt, muutub ka muudatuste haldamine v\u00e4ga sujuvaks. N\u00e4iteks muudatuste arutelu toimub kontaktide konsultatsioonin\u00f5ukogus ja kui \u00fcks pool n\u00f5uab muudatuste arutelu, lisatakse lepingusse kohustus vastata sellele arutelule. (Allpool on v\u00e4ljav\u00f5te Majandusministeeriumi mudellepingu s\u00e4tetest.)<br><\/p>\n\n\n\n<blockquote class=\"wp-block-quote\">\n<p>(Muudatuste haldamise protseduur)<\/p>\n\n\n\n<p>Artikkel 37. Kui A v\u00f5i B saab teiselt poolelt (j\u00e4etakse vahele) muudatusettepaneku, peab ta <u>\u25cb p\u00e4eva jooksul<\/u> alates selle saamise kuup\u00e4evast andma teisele poolele kirjaliku dokumendi (edaspidi &#8220;muudatuste haldamise dokument&#8221;), milles on kirjas j\u00e4rgmised asjad, ja A ja B peavad <u>kontaktide konsultatsioonin\u00f5ukogus arutama selle muudatuse heakskiitmist v\u00f5i tagasil\u00fckkamist<\/u>. (J\u00e4rgnevad kirjeldused on v\u00e4lja j\u00e4etud)<br><\/p>\n<\/blockquote>\n\n\n\n<p>\u00dclaltoodud s\u00e4tete punktid v\u00f5ib kokku v\u00f5tta j\u00e4rgmiselt:<br><\/p>\n\n\n\n<ul>\n<li>Muudatuste taotluse vastuv\u00f5tmise meetod on \u00fchtlustatud &#8220;muudatuste ettepaneku&#8221; vormingus<br><\/li>\n\n\n\n<li>On olemas t\u00e4htaeg ettepaneku saamisest kuni selle arutamiseni \u2192 seda ei pea m\u00e4rkima &#8220;\u25ef p\u00e4eva jooksul&#8221;, vaid v\u00f5ib asendada s\u00f5nadega &#8220;kiiresti&#8221; jne.<br><\/li>\n\n\n\n<li>Muudatuste heakskiitmise v\u00f5i tagasil\u00fckkamise arutelu koht on \u00fchtlustatud &#8220;kontaktide konsultatsioonin\u00f5ukogu&#8221; koosolekuga<br><\/li>\n<\/ul>\n\n\n\n<p>Teisis\u00f5nu, nad on selgelt m\u00e4\u00e4ratlenud protseduuri, et v\u00e4ltida arusaamatusi, nagu &#8220;ma esitasin muudatuse, ma ei esitanud&#8221; v\u00f5i &#8220;ma vastasin muudatuse heakskiitmisele v\u00f5i tagasil\u00fckkamisele, ma ei vastanud&#8221; suulisel alusel.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Usalduskohustuse_ja_hea_usu_pohimotte_moistmine_on_oluline\"><\/span>Usalduskohustuse ja hea usu p\u00f5him\u00f5tte m\u00f5istmine on oluline<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p>Oleme siiani tutvustanud lepinguklausleid, mis puudutavad &#8220;kontakti konsultatsioonin\u00f5ukogu&#8221; ja &#8220;muudatuste arutelu&#8221;. Kuid nende p\u00f5hiolemuse m\u00f5istmiseks on oluline m\u00f5ista selliseid aspekte nagu &#8220;usalduskohustus&#8221; ja &#8220;hea usu p\u00f5him\u00f5te&#8221;. Alguses on Agile arendusmudel ilma tellija ja t\u00f6\u00f6v\u00f5tja vahelise usaldussuhteta sageli keeruline. Selle p\u00f5hjuseks on asjaolu, et t\u00f6\u00f6 alustamise kiirus on olulisem ja protseduurid enne t\u00f6\u00f6 alustamist on tavaliselt minimaalsed. Seet\u00f5ttu on tavap\u00e4rane lisada lepingusse klausel, mis kohustab teist poolt &#8220;usalduskohustuse&#8221; t\u00e4itmisele.<br><\/p>\n\n\n\n<blockquote class=\"wp-block-quote\">\n<p>Paragrahv 4, l\u00f5ige 3: Muudatuste aruteludes tuleb arutada muudatuste objekti, muudatuste v\u00f5imalikkust, muudatuste m\u00f5ju hinnale ja t\u00e4htajale ning m\u00f5lemad pooled peavad muudatuste tegemise \u00fcle siiralt arutlema.<br><\/p>\n<\/blockquote>\n\n\n\n<p>See on m\u00f5eldud selleks, et v\u00e4ltida olukorda, kus l\u00e4bir\u00e4\u00e4kimised, mis on algusest peale p\u00f5hinenud usaldussuhtel, muutuvad \u00e4kki selliseks, et &#8220;kas n\u00f5ustuda lepingu muutmisega v\u00f5i mitte, on ainult selle poole vabadus, kes pakkumise saab, ja ei ole kohustust sundida&#8221;. See peegeldab ka \u00f5igusprintsiipe, mis kehtivad eraisikute vahelistes tehingutes, mitte ainult s\u00fcsteemiarenduses.<br><\/p>\n\n\n\n<blockquote class=\"wp-block-quote\">\n<p>Tsiviilseadustiku paragrahv 1, l\u00f5ige 2<\/p>\n\n\n\n<p>\u00d5iguste kasutamine ja kohustuste t\u00e4itmine peavad toimuma <u>hea usu<\/u> p\u00f5him\u00f5tte j\u00e4rgi ja olema <u>siirad<\/u>.<br><\/p>\n<\/blockquote>\n\n\n\n<p>Seadus ei r\u00f5huta ainult &#8220;lepingu s\u00f5nastust&#8221; v\u00f5i &#8220;paragrahvi s\u00f5nastust&#8221;. Eriti tehingutes, kus on teine pool, tuleks seda kasutada paindlikult, kaasates tegelikku &#8220;hea usu&#8221; p\u00f5him\u00f5tet ja &#8220;siirust&#8221;. Lisaks selgitame \u00fcksikasjalikult j\u00e4rgmises artiklis, et &#8220;kohustus&#8221;, mida seadus kehtestab, ei p\u00f5hine alati &#8220;lepingul&#8221;.<\/p>\n\n\n\n<p><a href=\"https:\/\/monolith.law\/corporate\/system-development-unlawful-responsibility\" target=\"_blank\" rel=\"noreferrer noopener\">https:\/\/monolith.law\/corporate\/system-development-unlawful-responsibility[ja]<\/a><\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Kokkuvote\"><\/span>Kokkuv\u00f5te<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p>Agile arendusmudelil p\u00f5hinevates s\u00fcsteemiarendusprojektides on muidugi oluline m\u00f5ista riske, mis tulenevad asjaajamise ja juhtimiskorralduse j\u00e4rkj\u00e4rgulisest hooletusse j\u00e4tmisest. Kuid mitte ainult, on oluline m\u00f5ista ka \u00f5iguse paindlikke omadusi, mis p\u00f5hinevad p\u00f5him\u00f5tetel nagu &#8220;ausa m\u00e4ngu reegel&#8221;, ning suhtumist, mis rakendab neid praktikas, peetakse samuti oluliseks.<br><\/p>\n","protected":false},"excerpt":{"rendered":"<p>S\u00fcsteemiarenduse l\u00e4biviimiseks on olemas metoodikad. K\u00f5ige klassikalisem ja \u00fcldisem neist on veekeeris mudel (Waterfall model), millest paljud s\u00fcsteemiarendust k\u00e4sitlevad \u00f5igusraamatud l\u00e4htuvad. K\u00e4eso [&hellip;]<\/p>\n","protected":false},"author":32,"featured_media":64576,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[16],"tags":[19,31],"acf":[],"_links":{"self":[{"href":"https:\/\/monolith.law\/et\/wp-json\/wp\/v2\/posts\/61460"}],"collection":[{"href":"https:\/\/monolith.law\/et\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/monolith.law\/et\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/monolith.law\/et\/wp-json\/wp\/v2\/users\/32"}],"replies":[{"embeddable":true,"href":"https:\/\/monolith.law\/et\/wp-json\/wp\/v2\/comments?post=61460"}],"version-history":[{"count":2,"href":"https:\/\/monolith.law\/et\/wp-json\/wp\/v2\/posts\/61460\/revisions"}],"predecessor-version":[{"id":64577,"href":"https:\/\/monolith.law\/et\/wp-json\/wp\/v2\/posts\/61460\/revisions\/64577"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/monolith.law\/et\/wp-json\/wp\/v2\/media\/64576"}],"wp:attachment":[{"href":"https:\/\/monolith.law\/et\/wp-json\/wp\/v2\/media?parent=61460"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/monolith.law\/et\/wp-json\/wp\/v2\/categories?post=61460"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/monolith.law\/et\/wp-json\/wp\/v2\/tags?post=61460"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}