{"id":61456,"date":"2023-12-08T19:16:46","date_gmt":"2023-12-08T10:16:46","guid":{"rendered":"https:\/\/monolith.law\/nl\/?p=61456"},"modified":"2024-03-09T10:55:52","modified_gmt":"2024-03-09T01:55:52","slug":"legal-and-contract-issues-of-agile-development","status":"publish","type":"post","link":"https:\/\/monolith.law\/nl\/it\/legal-and-contract-issues-of-agile-development","title":{"rendered":"Wat zijn de juridische en contractuele problemen rond Agile-ontwikkeling?"},"content":{"rendered":"\n<p>Er zijn methodologie\u00ebn voor het voortzetten van systeemontwikkeling. De meest klassieke en algemene is het watervalmodel, en veel juridische boeken die systeemontwikkeling behandelen, worden besproken op basis van dit model. In dit artikel zullen we de juridische problemen bespreken die kunnen ontstaan bij systeemontwikkeling op basis van het Agile ontwikkelingsmodel, waarvoor het moeilijk is om informatie te verkrijgen uit boeken en dergelijke.<\/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\/nl\/it\/legal-and-contract-issues-of-agile-development\/#Agile_Ontwikkelingsmodel_en_Juridische_Zaken\" title=\"Agile Ontwikkelingsmodel en Juridische Zaken\">Agile Ontwikkelingsmodel en Juridische Zaken<\/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\/nl\/it\/legal-and-contract-issues-of-agile-development\/#Wat_is_een_model_in_systeemontwikkeling\" title=\"Wat is een model in systeemontwikkeling?\">Wat is een model in systeemontwikkeling?<\/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\/nl\/it\/legal-and-contract-issues-of-agile-development\/#Kenmerken_van_het_Agile_Ontwikkelingsmodel\" title=\"Kenmerken van het Agile Ontwikkelingsmodel\">Kenmerken van het Agile Ontwikkelingsmodel<\/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\/nl\/it\/legal-and-contract-issues-of-agile-development\/#Documentbeheer_en_verandermanagement_in_Agile-ontwikkeling\" title=\"Documentbeheer en verandermanagement in Agile-ontwikkeling\">Documentbeheer en verandermanagement in Agile-ontwikkeling<\/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\/nl\/it\/legal-and-contract-issues-of-agile-development\/#Belang_van_Documentbeheer\" title=\"Belang van Documentbeheer\">Belang van Documentbeheer<\/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\/nl\/it\/legal-and-contract-issues-of-agile-development\/#De_oprichting_van_een_communicatieoverleg_is_effectief_voor_documentbeheer\" title=\"De oprichting van een communicatieoverleg is effectief voor documentbeheer\">De oprichting van een communicatieoverleg is effectief voor documentbeheer<\/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\/nl\/it\/legal-and-contract-issues-of-agile-development\/#De_weg_naar_het_benutten_van_de_communicatiecommissie_voor_verandermanagement\" title=\"De weg naar het benutten van de communicatiecommissie voor verandermanagement\">De weg naar het benutten van de communicatiecommissie voor verandermanagement<\/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\/nl\/it\/legal-and-contract-issues-of-agile-development\/#Begrip_van_plicht_tot_oprechtheid_en_goede_trouw_wordt_in_vraag_gesteld\" title=\"Begrip van plicht tot oprechtheid en goede trouw wordt in vraag gesteld\">Begrip van plicht tot oprechtheid en goede trouw wordt in vraag gesteld<\/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\/nl\/it\/legal-and-contract-issues-of-agile-development\/#Samenvatting\" title=\"Samenvatting\">Samenvatting<\/a><\/li><\/ul><\/nav><\/div>\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Agile_Ontwikkelingsmodel_en_Juridische_Zaken\"><\/span>Agile Ontwikkelingsmodel en Juridische Zaken<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\">We zullen de kenmerken van Agile ontwikkeling uitleggen.<\/figcaption><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Wat_is_een_model_in_systeemontwikkeling\"><\/span>Wat is een model in systeemontwikkeling?<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>In systeemontwikkelingsprojecten bestaat er een ontwikkelingsmodel als een raamwerk voor het begrijpen van de algehele voortgang. Het meest bekende hiervan is het zogenaamde &#8216;watervalmodel&#8217;. Dit model is vergelijkbaar met het water van een rivier dat van &#8216;bovenstroom&#8217; naar &#8216;benedenstroom&#8217; stroomt, waarbij elke fase van de eisen, ontwerp, implementatie, testen, enz. in \u00e9\u00e9n keer wordt doorlopen. Het doel is om herhaling en dubbel werk zoveel mogelijk te verminderen en het werk op een geplande manier uit te voeren.<\/p>\n\n\n\n<p>Aan de andere kant, in het Agile ontwikkelingsmodel, wordt een klein programma ge\u00efmplementeerd en vervolgens getest, en dit proces wordt herhaald. Door deze iteratieve werkzaamheden van het implementeren en testen van kleine programma&#8217;s te herhalen, wordt geleidelijk een groter systeem opgebouwd. Voor een meer gedetailleerde uitleg van deze systeemontwikkelingsmodellen en een vergelijking van de voor- en nadelen van beide ontwikkelingsmodellen, zie het volgende artikel.<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=\"Kenmerken_van_het_Agile_Ontwikkelingsmodel\"><\/span>Kenmerken van het Agile Ontwikkelingsmodel<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>Een groot voordeel van ontwikkeling met het Agile model is dat je snel aan de slag kunt gaan met het daadwerkelijke werk. Omdat de &#8216;bovenstroom&#8217; taken zoals het defini\u00ebren van eisen en het maken van ontwerpen niet gescheiden zijn van de implementatie van het programma, is het geschikt voor flexibel sturen, inclusief het toevoegen en wijzigen van functies en het wijzigen van specificaties. Vanuit juridisch oogpunt zijn documentbeheer en wijzigingsbeheer bijzonder belangrijk voor het succes van het Agile ontwikkelingsmodel. In het Agile model zijn de rollen en verantwoordelijkheden niet zo duidelijk verdeeld als in het watervalmodel. Bovendien, omdat het een methode is die de &#8216;snelheid&#8217; van uitvoering en aanpak benadrukt in plaats van &#8216;beheer&#8217;, kan het gemakkelijk leiden tot onvolledige ontwerpen, specificaties en notulen.<\/p>\n\n\n\n<p>Verder, in relatie tot wijzigingsbeheer, omdat het Agile model soepel reageert op veranderingen, kan er een risico zijn dat het project in brand vliegt als het goedkeuringsproces voor de besluitvormer wordt overgeslagen en er op locatieniveau wordt gereageerd op verzoeken om specificatiewijzigingen. In dat geval kan het voordeel van het ontwikkelingsmodel, namelijk &#8216;soepele reactie op latere wijzigingen&#8217;, zelf een risico worden voor het in brand vliegen van het project.<br><\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Documentbeheer_en_verandermanagement_in_Agile-ontwikkeling\"><\/span>Documentbeheer en verandermanagement in Agile-ontwikkeling<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\">Hoe beheer je documenten en wijzigingen in de Agile-ontwikkelingsmodel?<\/figcaption><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Belang_van_Documentbeheer\"><\/span>Belang van Documentbeheer<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>In ontwikkelingsprojecten gebaseerd op het Agile ontwikkelingsmodel, is een juridisch punt van zorg dat mondelinge communicatie zich opstapelt, wat leidt tot een tekort aan documentatie. Overigens, waarom documentbeheer belangrijk is in systeemontwikkelingsprojecten in de eerste plaats, wordt in detail uitgelegd in het volgende artikel.<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>In het genoemde artikel wordt het belang van documentbeheer in systeemontwikkelingsprojecten uitgelegd vanuit twee perspectieven: preventie van geschillen (oftewel &#8216;preventief juridisch werk&#8217;) en het bewaren van bewijsmateriaal in geval van een geschil (oftewel &#8216;crisisbeheer&#8217;).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"De_oprichting_van_een_communicatieoverleg_is_effectief_voor_documentbeheer\"><\/span>De oprichting van een communicatieoverleg is effectief voor documentbeheer<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>Wanneer het Agile ontwikkelingsmodel wordt aangenomen, is er in tegenstelling tot het watervalmodel geen duidelijk plan vooraf voorbereid. Daarom is het niet voldoende om alleen de discrepantie tussen planning en prestaties te beheren, er is een zorg dat de kosten zowel financieel als in tijd zullen oplopen als het aan het veld wordt overgelaten.<\/p>\n\n\n\n<p>Daarom is het effectief om maatregelen te nemen zoals de projectleider regelmatig een communicatieoverleg laat houden voor een soepele voortgang van het project. Bij kleinere ontwikkelingsprojecten is het inderdaad vaak de voorkeur om bijeen te komen wanneer de verantwoordelijken elkaar kunnen ontmoeten, in plaats van regelmatig een communicatieoverleg te houden. Echter, in het geval van het Agile ontwikkelingsmodel is er een groter risico dat tijdige problemen niet worden aangepakt in vergaderingen. Daarom is het veilig om de regelmatige organisatie van een communicatieoverleg ook in contracten op te nemen. De manier van voorschrijven wordt als volgt aangegeven in het modelcontract van het Ministerie van Economie, Handel en Industrie (METI) van Japan.<br><\/p>\n\n\n\n<blockquote class=\"wp-block-quote\">\n<p>(Oprichting van een communicatieoverleg)<\/p>\n\n\n\n<p>Artikel 12 Partij A en Partij B zullen, tot de voltooiing van deze taak, een <u>communicatieoverleg houden<\/u> om de voortgang, risicobeheer en rapportage, gezamenlijk werk en de uitvoering van individuele taken door beide partijen, de inhoud die moet worden opgenomen in de systeemspecificaties, de bespreking en oplossing van problemen, en andere noodzakelijke zaken voor de soepele uitvoering van deze taak te bespreken. Echter, (weggelaten).<br><\/p>\n\n\n\n<p>2. Het communicatieoverleg zal in principe <u>regelmatig worden gehouden op de frequentie bepaald in het individuele contract<\/u>, en daarnaast zal het <u>op elk moment worden gehouden wanneer Partij A of Partij B dit noodzakelijk acht<\/u>.<br><\/p>\n\n\n\n<p>3. Aan het communicatieoverleg zullen <u>de verantwoordelijken van beide partijen, de hoofdverantwoordelijken en degenen die de verantwoordelijken geschikt achten, deelnemen<\/u>. Bovendien kunnen Partij A en Partij B de aanwezigheid van degenen die nodig zijn voor de discussies in het communicatieoverleg van de andere partij verzoeken, en de andere partij zal hieraan voldoen, tenzij er een redelijke reden is om dit niet te doen.<br><\/p>\n\n\n\n<p>4. Partij B zal <u>een voortgangsrapport opstellen in de vorm die apart is overeengekomen tussen Partij A en Partij B en dit indienen<\/u> bij het communicatieoverleg, en zal de voortgang controleren op basis van dit voortgangsrapport, en zal, indien nodig, de aanwezigheid van vertragingen, de redenen en maatregelen voor vertragingen, de noodzaak om de promotiestructuur zoals bepaald in dit hoofdstuk te wijzigen (verandering van personeel, toename of afname, verandering van onderaannemer, enz.), de uitvoering van beveiligingsmaatregelen, de aanwezigheid van redenen om het individuele contract te wijzigen, de inhoud van de redenen om het individuele contract te wijzigen, enz. bespreken, en zal de besloten zaken, de zaken die verder onderzocht moeten worden, en de planning en de partijen die het onderzoek zullen uitvoeren, bevestigen als er zaken zijn die verder onderzocht moeten worden.&nbsp;<br><\/p>\n\n\n\n<p>(De volgende paragrafen 5, 6 en 7 zijn weggelaten.)<br><\/p>\n<\/blockquote>\n\n\n\n<p>Het belangrijkste punt is dat de aanwezigheid van een communicatieoverleg een zekere legitimiteit geeft aan de contractclausules, en het een andere betekenis geeft dan ad hoc vergaderingen.<br><\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"De_weg_naar_het_benutten_van_de_communicatiecommissie_voor_verandermanagement\"><\/span>De weg naar het benutten van de communicatiecommissie voor verandermanagement<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>In Agile ontwikkeling is het een gegeven dat zaken waarover beide partijen aanvankelijk overeenstemming hadden bereikt, achteraf kunnen worden gewijzigd. Daarom is het ook uiterst belangrijk hoe je de situatie van dergelijke latere specificatiewijzigingen beheert.<\/p>\n\n\n\n<p>Als er regelmatig een communicatiecommissie wordt gehouden, wordt het verandermanagement en de manier waarop het wordt uitgevoerd zeer soepel. Bijvoorbeeld, het is afgesproken dat veranderingsdiscussies worden gevoerd in de communicatiecommissie, en als er een verzoek tot veranderingsdiscussie is van de ene partij, wordt de verplichting voor de andere partij om aan die discussie deel te nemen in het contract opgenomen. (Hieronder volgt een uittreksel uit de bepalingen van het modelcontract van het Japanse Ministerie van Economie, Handel en Industrie.)<br><\/p>\n\n\n\n<blockquote class=\"wp-block-quote\">\n<p>(Procedure voor verandermanagement)<\/p>\n\n\n\n<p>Artikel 37 Partij A of B, wanneer zij een wijzigingsvoorstel ontvangen van de andere partij (weglating)&#8230;, zal binnen <u>\u25cb dagen<\/u> na ontvangst van dit voorstel een document (hierna &#8220;veranderingsbeheerdocument&#8221; genoemd) met de volgende punten aan de andere partij overhandigen, en partij A en B zullen <u>overleggen over de goedkeuring van deze wijziging in de communicatiecommissie<\/u> zoals bepaald in artikel 12. (De volgende punten worden weggelaten)<br><\/p>\n<\/blockquote>\n\n\n\n<p>De belangrijkste punten van de bovenstaande bepaling kunnen als volgt worden samengevat:<br><\/p>\n\n\n\n<ul>\n<li>Het proces voor het accepteren van een wijzigingsverzoek is gestandaardiseerd in een &#8220;wijzigingsvoorstel&#8221; formaat.<br><\/li>\n\n\n\n<li>Er is een deadline gesteld voor de datum van ontvangst van het voorstel tot de datum van de discussie erover \u2192 Dit hoeft niet noodzakelijkerwijs te worden aangegeven als &#8220;binnen \u25ef dagen&#8221;, maar kan ook worden vervangen door woorden als &#8220;zo snel mogelijk&#8221;.<br><\/li>\n\n\n\n<li>De plaats voor het bespreken van de goedkeuring van de wijziging is gestandaardiseerd in de &#8220;communicatiecommissie&#8221;.<br><\/li>\n<\/ul>\n\n\n\n<p>Met andere woorden, om te voorkomen dat er misverstanden ontstaan zoals &#8220;Ik heb een wijzigingsverzoek gedaan, ik heb het niet gedaan&#8221;, &#8220;Ik heb gereageerd op de goedkeuring van de wijziging, ik heb het niet gedaan&#8221;, is de procedure duidelijk gemaakt.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Begrip_van_plicht_tot_oprechtheid_en_goede_trouw_wordt_in_vraag_gesteld\"><\/span>Begrip van plicht tot oprechtheid en goede trouw wordt in vraag gesteld<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p>We hebben tot nu toe modelcontractclausules ge\u00efntroduceerd met betrekking tot zaken als &#8216;communicatieoverleg&#8217; en &#8216;wijzigingsoverleg&#8217;. Echter, voor een fundamenteel begrip van deze zaken, is het belangrijk om aandacht te besteden aan zaken als &#8216;plicht tot oprechtheid&#8217; en &#8216;goede trouw&#8217;. De Agile ontwikkelingsmethode kan moeilijk vooruitgaan zonder een vertrouwensrelatie tussen de opdrachtgever en de opdrachtnemer. Dit komt omdat de nadruk ligt op de snelheid van het starten van het daadwerkelijke werk, en de procedures die leiden tot de start worden meestal tot een minimum beperkt. Daarom is het in de praktijk gebruikelijk om clausules op te nemen die de &#8216;plicht tot oprechtheid&#8217; opleggen aan de andere partij.<br><\/p>\n\n\n\n<blockquote class=\"wp-block-quote\">\n<p>Artikel 4, lid 3: Bij het overleg over wijzigingen zullen beide partijen te goeder trouw overleggen over het onderwerp van de wijziging, de mogelijkheid van de wijziging, de invloed van de wijziging op de prijs en de leveringstermijn, enz., en of de wijziging zal worden doorgevoerd.<br><\/p>\n<\/blockquote>\n\n\n\n<p>Dit is bedoeld om te voorkomen dat men plotseling de andere partij verraadt met een formeel juridisch argument, zoals &#8220;Of men instemt met een contractwijziging of niet, is geheel aan de discretie van de partij die het verzoek ontvangt, en er is geen verplichting om te voldoen aan dwang&#8221;, in onderhandelingen die tot nu toe zijn gebaseerd op een vertrouwensrelatie. Dit weerspiegelt ook de principes van het recht dat van toepassing is op transacties tussen particulieren, niet alleen op systeemontwikkeling.<br><\/p>\n\n\n\n<blockquote class=\"wp-block-quote\">\n<p>Artikel 1, lid 2 van het Burgerlijk Wetboek (Japanse Burgerlijk Wetboek)<\/p>\n\n\n\n<p>De uitoefening van rechten en de nakoming van verplichtingen moeten te goeder trouw en oprecht worden uitgevoerd.<br><\/p>\n<\/blockquote>\n\n\n\n<p>De wet respecteert niet alleen de formele &#8216;inhoud van het contract&#8217; of &#8216;de bewoordingen van de clausules&#8217;. Vooral in transacties waarbij de andere partij betrokken is, moet het flexibel worden gebruikt, rekening houdend met de substanti\u00eble &#8216;goede trouw&#8217; en &#8216;oprechtheid&#8217;. Overigens, het feit dat de &#8216;verplichting&#8217; die wettelijk wordt opgelegd, niet noodzakelijkerwijs gebaseerd is op de procedure van het &#8216;contract&#8217;, wordt in detail uitgelegd in het volgende artikel.<\/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=\"Samenvatting\"><\/span>Samenvatting<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p>In systeemontwikkelingsprojecten gebaseerd op het Agile ontwikkelingsmodel is het uiteraard belangrijk om de risico&#8217;s te begrijpen die gepaard gaan met een geleidelijke verslapping van administratieve procedures en managementstructuren. Echter, het is niet alleen dat. Het is ook belangrijk om de flexibele kenmerken van de wet, die geworteld zijn in principes zoals de &#8216;goede trouw&#8217;, te begrijpen en deze in de praktijk te brengen. <\/p>\n","protected":false},"excerpt":{"rendered":"<p>Er zijn methodologie\u00ebn voor het voortzetten van systeemontwikkeling. De meest klassieke en algemene is het watervalmodel, en veel juridische boeken die systeemontwikkeling behandelen, worden besproken [&hellip;]<\/p>\n","protected":false},"author":32,"featured_media":62938,"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\/nl\/wp-json\/wp\/v2\/posts\/61456"}],"collection":[{"href":"https:\/\/monolith.law\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/monolith.law\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/monolith.law\/nl\/wp-json\/wp\/v2\/users\/32"}],"replies":[{"embeddable":true,"href":"https:\/\/monolith.law\/nl\/wp-json\/wp\/v2\/comments?post=61456"}],"version-history":[{"count":2,"href":"https:\/\/monolith.law\/nl\/wp-json\/wp\/v2\/posts\/61456\/revisions"}],"predecessor-version":[{"id":62937,"href":"https:\/\/monolith.law\/nl\/wp-json\/wp\/v2\/posts\/61456\/revisions\/62937"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/monolith.law\/nl\/wp-json\/wp\/v2\/media\/62938"}],"wp:attachment":[{"href":"https:\/\/monolith.law\/nl\/wp-json\/wp\/v2\/media?parent=61456"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/monolith.law\/nl\/wp-json\/wp\/v2\/categories?post=61456"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/monolith.law\/nl\/wp-json\/wp\/v2\/tags?post=61456"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}