{"id":60128,"date":"2024-02-06T12:11:18","date_gmt":"2024-02-06T03:11:18","guid":{"rendered":"https:\/\/monolith.law\/pl\/?p=60128"},"modified":"2024-02-19T12:32:33","modified_gmt":"2024-02-19T03:32:33","slug":"legal-and-contract-issues-of-agile-development","status":"publish","type":"post","link":"https:\/\/monolith.law\/pl\/it\/legal-and-contract-issues-of-agile-development","title":{"rendered":"Czym s\u0105 problemy prawne i umowne zwi\u0105zane z rozwojem Agile?"},"content":{"rendered":"\n<p>W podej\u015bciu do rozwoju system\u00f3w istniej\u0105 r\u00f3\u017cne metody. Najbardziej klasycznym i powszechnym jest model Waterfall, a wiele ksi\u0105\u017cek prawniczych dotycz\u0105cych rozwoju system\u00f3w omawia ten model jako punkt wyj\u015bcia. W tym artykule om\u00f3wimy problemy prawne zwi\u0105zane z rozwojem system\u00f3w opartych na modelu Agile, kt\u00f3ry jest trudny do zrozumienia na podstawie ksi\u0105\u017cek i innych \u017ar\u00f3de\u0142 informacji.<\/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\/pl\/it\/legal-and-contract-issues-of-agile-development\/#Model_Agile_w_prawie\" title=\"Model Agile w prawie\">Model Agile w prawie<\/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\/pl\/it\/legal-and-contract-issues-of-agile-development\/#Co_to_jest_model_w_rozwoju_systemow\" title=\"Co to jest model w rozwoju system\u00f3w?\">Co to jest model w rozwoju system\u00f3w?<\/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\/pl\/it\/legal-and-contract-issues-of-agile-development\/#Cechy_modelu_Agile\" title=\"Cechy modelu Agile\">Cechy modelu Agile<\/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\/pl\/it\/legal-and-contract-issues-of-agile-development\/#Zarzadzanie_dokumentacja_i_zmianami_w_rozwoju_Agile\" title=\"Zarz\u0105dzanie dokumentacj\u0105 i zmianami w rozwoju Agile\">Zarz\u0105dzanie dokumentacj\u0105 i zmianami w rozwoju Agile<\/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\/pl\/it\/legal-and-contract-issues-of-agile-development\/#Znaczenie_zarzadzania_dokumentacja\" title=\"Znaczenie zarz\u0105dzania dokumentacj\u0105\">Znaczenie zarz\u0105dzania dokumentacj\u0105<\/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\/pl\/it\/legal-and-contract-issues-of-agile-development\/#Ustanowienie_Rady_Konsultacyjnej_jest_skuteczne_dla_zarzadzania_dokumentacja\" title=\"Ustanowienie Rady Konsultacyjnej jest skuteczne dla zarz\u0105dzania dokumentacj\u0105\">Ustanowienie Rady Konsultacyjnej jest skuteczne dla zarz\u0105dzania dokumentacj\u0105<\/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\/pl\/it\/legal-and-contract-issues-of-agile-development\/#Wykorzystanie_Rady_Konsultacyjnej_do_zarzadzania_zmianami\" title=\"Wykorzystanie Rady Konsultacyjnej do zarz\u0105dzania zmianami\">Wykorzystanie Rady Konsultacyjnej do zarz\u0105dzania zmianami<\/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\/pl\/it\/legal-and-contract-issues-of-agile-development\/#Zrozumienie_obowiazku_uczciwosci_i_zasady_dobrej_wiary_jest_kwestionowane\" title=\"Zrozumienie obowi\u0105zku uczciwo\u015bci i zasady dobrej wiary jest kwestionowane\">Zrozumienie obowi\u0105zku uczciwo\u015bci i zasady dobrej wiary jest kwestionowane<\/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\/pl\/it\/legal-and-contract-issues-of-agile-development\/#Podsumowanie\" title=\"Podsumowanie\">Podsumowanie<\/a><\/li><\/ul><\/nav><\/div>\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Model_Agile_w_prawie\"><\/span>Model Agile w prawie<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\">Opisujemy cechy rozwoju Agile.<\/figcaption><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Co_to_jest_model_w_rozwoju_systemow\"><\/span>Co to jest model w rozwoju system\u00f3w?<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>W projektach rozwoju system\u00f3w istnieje co\u015b takiego jak model rozwoju, kt\u00f3ry s\u0142u\u017cy jako ramy do monitorowania post\u0119p\u00f3w. Najbardziej reprezentatywnym jest tzw. &#8220;model wodospadu&#8221;. To znaczy, podobnie jak woda spada z &#8220;g\u00f3ry&#8221; do &#8220;doliny&#8221; rzeki, przechodzi przez wszystkie etapy, takie jak definiowanie wymaga\u0144, projektowanie, implementacja, testowanie itp. Celem jest zminimalizowanie powrot\u00f3w i dublowania pracy, co jest odpowiednie dla planowego prowadzenia prac.<\/p>\n\n\n\n<p>Z drugiej strony, w modelu Agile, ma\u0142e programy s\u0105 implementowane i testowane na bie\u017c\u0105co. W ten spos\u00f3b, powtarzaj\u0105c cykl implementacji i testowania ma\u0142ych program\u00f3w, stopniowo tworzy si\u0119 wi\u0119kszy system. Szczeg\u00f3\u0142owe wyja\u015bnienie tych modeli rozwoju system\u00f3w, a tak\u017ce por\u00f3wnanie zalet i wad obu modeli, mo\u017cna znale\u017a\u0107 w poni\u017cszym artykule.<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=\"Cechy_modelu_Agile\"><\/span>Cechy modelu Agile<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>G\u0142\u00f3wn\u0105 zalet\u0105 rozwoju za pomoc\u0105 modelu Agile jest mo\u017cliwo\u015b\u0107 szybkiego rozpocz\u0119cia rzeczywistej pracy. Poniewa\u017c zadania &#8220;upstream&#8221;, takie jak definiowanie wymaga\u0144 i tworzenie dokumentacji projektowej, nie s\u0105 oddzielone od implementacji programu, model ten jest odpowiedni do elastycznego prowadzenia projektu, w tym do reagowania na dodawanie i modyfikowanie funkcji oraz zmiany specyfikacji. Z punktu widzenia prawa, kluczowym elementem sukcesu modelu Agile jest to, jak zarz\u0105dza\u0107 dokumentacj\u0105 i zmianami. W modelu Agile, role i odpowiedzialno\u015bci nie s\u0105 tak jasno zdefiniowane jak w modelu wodospadu. Ponadto, ze wzgl\u0119du na nacisk na &#8220;szybko\u015b\u0107&#8221; wdro\u017cenia, a nie zarz\u0105dzanie, istnieje ryzyko, \u017ce dokumentacja projektowa, specyfikacje i protoko\u0142y nie b\u0119d\u0105 w pe\u0142ni realizowane.<\/p>\n\n\n\n<p>Co wi\u0119cej, w odniesieniu do zarz\u0105dzania zmianami, model Agile jest sprawniejszy w reagowaniu na zmiany, co mo\u017ce prowadzi\u0107 do sytuacji, w kt\u00f3rej proces zatwierdzania przez decydent\u00f3w jest pomijany, a projekt staje si\u0119 niekontrolowany, gdy na poziomie operacyjnym odpowiada si\u0119 na \u017c\u0105dania zmiany specyfikacji. W takim przypadku, zaleta modelu rozwoju, kt\u00f3ra polega na &#8220;sprawnym reagowaniu na zmiany po fakcie&#8221;, mo\u017ce sama w sobie sta\u0107 si\u0119 ryzykiem dla projektu.<br><\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Zarzadzanie_dokumentacja_i_zmianami_w_rozwoju_Agile\"><\/span>Zarz\u0105dzanie dokumentacj\u0105 i zmianami w rozwoju Agile<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\">Jak zarz\u0105dza\u0107 dokumentacj\u0105 i zmianami w modelu rozwoju Agile?<\/figcaption><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Znaczenie_zarzadzania_dokumentacja\"><\/span>Znaczenie zarz\u0105dzania dokumentacj\u0105<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>W projektach rozwojowych opartych na modelu Agile, prawne obawy wynikaj\u0105 z faktu, \u017ce komunikacja oparta na ustnych porozumieniach gromadzi si\u0119, prowadz\u0105c do braku dokumentacji. Szczeg\u00f3\u0142owe wyja\u015bnienia na temat tego, dlaczego zarz\u0105dzanie dokumentacj\u0105 jest wa\u017cne w projektach rozwoju system\u00f3w, mo\u017cna znale\u017a\u0107 w poni\u017cszym artykule.<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>W tym artykule wyja\u015bniamy znaczenie zarz\u0105dzania dokumentacj\u0105 w projektach rozwoju system\u00f3w z dw\u00f3ch punkt\u00f3w widzenia: prewencji konflikt\u00f3w (tj. &#8220;prawo prewencyjne&#8221;) i zachowania dowod\u00f3w w przypadku konfliktu (tj. &#8220;zarz\u0105dzanie kryzysowe&#8221;).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Ustanowienie_Rady_Konsultacyjnej_jest_skuteczne_dla_zarzadzania_dokumentacja\"><\/span>Ustanowienie Rady Konsultacyjnej jest skuteczne dla zarz\u0105dzania dokumentacj\u0105<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>W przypadku stosowania modelu Agile, w przeciwie\u0144stwie do modelu Waterfall, nie ma przygotowanego z g\u00f3ry jasnego planu. Dlatego nie wystarczy tylko zarz\u0105dza\u0107 rozbie\u017cno\u015bciami mi\u0119dzy planem a rzeczywisto\u015bci\u0105, istnieje obawa, \u017ce koszty, zar\u00f3wno finansowe, jak i czasowe, mog\u0105 gwa\u0142townie wzrosn\u0105\u0107, je\u015bli zostawi si\u0119 to na miejscu.<\/p>\n\n\n\n<p>W zwi\u0105zku z tym, skutecznym rozwi\u0105zaniem jest regularne organizowanie spotka\u0144 konsultacyjnych przez osoby odpowiedzialne za p\u0142ynny przebieg projektu. W przypadku ma\u0142ych projekt\u00f3w rozwojowych, rzeczywi\u015bcie, zamiast regularnie organizowa\u0107 spotkania konsultacyjne, preferowane jest spotykanie si\u0119, gdy osoby odpowiedzialne mog\u0105 si\u0119 spotka\u0107. Jednak w przypadku modelu Agile, ryzyko pomini\u0119cia aktualnych problem\u00f3w na spotkaniach jest wi\u0119ksze. Dlatego bezpieczne jest uwzgl\u0119dnienie regularnych spotka\u0144 konsultacyjnych w umowach itp. Spos\u00f3b regulacji jest pokazany w poni\u017cszym przyk\u0142adzie z modelu umowy Ministerstwa Gospodarki, Handlu i Przemys\u0142u.<br><\/p>\n\n\n\n<blockquote class=\"wp-block-quote\">\n<p>(Ustanowienie Rady Konsultacyjnej)<\/p>\n\n\n\n<p>Artyku\u0142 12. Strony A i B zobowi\u0105zuj\u0105 si\u0119 do organizowania Rady Konsultacyjnej w celu om\u00f3wienia post\u0119p\u00f3w prac, zarz\u0105dzania ryzykiem i raportowania, wsp\u00f3lnych prac i realizacji zada\u0144 przez obie strony, potwierdzenia tre\u015bci, kt\u00f3re powinny by\u0107 zawarte w specyfikacji systemu, om\u00f3wienia i rozwi\u0105zania problem\u00f3w oraz innych kwestii niezb\u0119dnych do p\u0142ynnego wykonania prac. Jednak\u017ce, (pomini\u0119cie).<br><\/p>\n\n\n\n<p>2. Rada Konsultacyjna jest zasadniczo organizowana regularnie z cz\u0119stotliwo\u015bci\u0105 okre\u015blon\u0105 w umowie indywidualnej, a dodatkowo, jest organizowana w dowolnym momencie, gdy strona A lub B uwa\u017ca to za konieczne.<br><\/p>\n\n\n\n<p>3. Na Radzie Konsultacyjnej obecni s\u0105 odpowiedzialni z obu stron, g\u0142\u00f3wni wykonawcy i osoby uznane za odpowiednie przez osoby odpowiedzialne. Ponadto, strony A i B mog\u0105 \u017c\u0105da\u0107 od drugiej strony obecno\u015bci os\u00f3b niezb\u0119dnych do om\u00f3wienia na Radzie Konsultacyjnej, a druga strona zobowi\u0105zuje si\u0119 do spe\u0142nienia tego \u017c\u0105dania, chyba \u017ce istniej\u0105 uzasadnione powody.<br><\/p>\n\n\n\n<p>4. Strona B tworzy i sk\u0142ada raport o zarz\u0105dzaniu post\u0119pami w formacie uzgodnionym oddzielnie mi\u0119dzy stronami A i B na Radzie Konsultacyjnej, potwierdza post\u0119py na podstawie tego raportu, omawia i decyduje o kwestiach takich jak istnienie op\u00f3\u017anie\u0144, przyczyny i \u015brodki zaradcze w przypadku op\u00f3\u017anie\u0144, konieczno\u015b\u0107 zmiany struktury promuj\u0105cej okre\u015blonej w tym rozdziale (zmiana personelu, zwi\u0119kszenie lub zmniejszenie liczby os\u00f3b, zmiana podwykonawcy itp.), stan realizacji \u015brodk\u00f3w bezpiecze\u0144stwa, istnienie przyczyn wymagaj\u0105cych zmiany umowy indywidualnej, tre\u015b\u0107 przyczyn wymagaj\u0105cych zmiany umowy indywidualnej, je\u015bli takie istniej\u0105, i potwierdza kwestie, kt\u00f3re zosta\u0142y zdecydowane, kwestie, kt\u00f3re wymagaj\u0105 dalszego rozwa\u017cenia, i harmonogram i strony odpowiedzialne za rozwa\u017canie, je\u015bli istniej\u0105 kwestie wymagaj\u0105ce dalszego rozwa\u017cenia. <br><\/p>\n\n\n\n<p>(Pomini\u0119cie punkt\u00f3w 5, 6 i 7.)<br><\/p>\n<\/blockquote>\n\n\n\n<p>Kluczowym punktem jest nadanie pewnej legalno\u015bci istnieniu Rady Konsultacyjnej w klauzulach umowy i nadanie jej innego znaczenia ni\u017c spotkania organizowane ad hoc.<br><\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Wykorzystanie_Rady_Konsultacyjnej_do_zarzadzania_zmianami\"><\/span>Wykorzystanie Rady Konsultacyjnej do zarz\u0105dzania zmianami<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>Ponadto, w rozwoju Agile, zmiana tego, co obie strony pocz\u0105tkowo zgodzi\u0142y si\u0119, jest za\u0142o\u017ceniem. Dlatego bardzo wa\u017cne jest, jak zarz\u0105dza\u0107 sytuacj\u0105, gdy specyfikacje s\u0105 zmieniane po fakcie.<\/p>\n\n\n\n<p>Je\u015bli Rada Konsultacyjna jest regularnie organizowana, zarz\u0105dzanie zmianami staje si\u0119 bardzo p\u0142ynne. Na przyk\u0142ad, dyskusje o zmianach s\u0105 prowadzone na Radzie Konsultacyjnej, a je\u015bli jedna strona wnosi o dyskusj\u0119 o zmianach, druga strona ma obowi\u0105zek odpowiedzie\u0107 na t\u0119 dyskusj\u0119 w umowie. (Poni\u017cej znajduje si\u0119 fragment z modelu umowy Ministerstwa Gospodarki, Handlu i Przemys\u0142u.)<br><\/p>\n\n\n\n<blockquote class=\"wp-block-quote\">\n<p>(Procedura zarz\u0105dzania zmianami)<\/p>\n\n\n\n<p>Artyku\u0142 37. Strona A lub B, po otrzymaniu propozycji zmiany od drugiej strony (pomini\u0119cie), zobowi\u0105zuje si\u0119 do przekazania drugiej stronie dokumentu zawieraj\u0105cego nast\u0119puj\u0105ce informacje (zwane dalej &#8220;Dokumentem Zarz\u0105dzania Zmianami&#8221;) w ci\u0105gu \u25cb dni od daty otrzymania, a strony A i B zobowi\u0105zuj\u0105 si\u0119 do om\u00f3wienia mo\u017cliwo\u015bci takiej zmiany na Radzie Konsultacyjnej okre\u015blonej w artykule 12. (Pomini\u0119cie szczeg\u00f3\u0142\u00f3w dotycz\u0105cych zawarto\u015bci)<br><\/p>\n<\/blockquote>\n\n\n\n<p>Kluczowe punkty powy\u017cszego przepisu mo\u017cna podsumowa\u0107 nast\u0119puj\u0105co:<br><\/p>\n\n\n\n<ul>\n<li>Standardyzacja metody akceptacji wniosk\u00f3w o zmian\u0119 za pomoc\u0105 formatu &#8220;Propozycji Zmiany&#8221;<br><\/li>\n\n\n\n<li>Ustalenie terminu na dyskusj\u0119 na temat wniosku od momentu jego otrzymania \u2192 Mo\u017cna to zast\u0105pi\u0107 innymi sformu\u0142owaniami, takimi jak &#8220;jak najszybciej&#8221;.<br><\/li>\n\n\n\n<li>Standardyzacja miejsca dyskusji o mo\u017cliwo\u015bci zmiany na &#8220;Radzie Konsultacyjnej&#8221;<br><\/li>\n<\/ul>\n\n\n\n<p>W ten spos\u00f3b, aby unikn\u0105\u0107 nieporozumie\u0144, takich jak &#8220;wnioskowa\u0142em o zmian\u0119, nie wnioskowa\u0142em&#8221;, &#8220;odpowiedzia\u0142em na mo\u017cliwo\u015b\u0107 zmiany, nie odpowiedzia\u0142em&#8221;, spos\u00f3b post\u0119powania jest jasno okre\u015blony.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Zrozumienie_obowiazku_uczciwosci_i_zasady_dobrej_wiary_jest_kwestionowane\"><\/span>Zrozumienie obowi\u0105zku uczciwo\u015bci i zasady dobrej wiary jest kwestionowane<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p>Dotychczas przedstawili\u015bmy modele klauzul umownych dotycz\u0105cych &#8220;Rady Konsultacyjnej&#8221;, &#8220;Negocjacji Zmian&#8221; itp. Jednak\u017ce, kluczowe dla zrozumienia ich istoty s\u0105 takie kwestie jak &#8220;obowi\u0105zek uczciwo\u015bci&#8221; i &#8220;zasada dobrej wiary&#8221;. Sam model rozwoju Agile jest trudny do przeprowadzenia bez relacji zaufania mi\u0119dzy zamawiaj\u0105cym a wykonawc\u0105. Dlatego, \u017ce priorytetem jest szybko\u015b\u0107 rozpocz\u0119cia prac, a procedury prowadz\u0105ce do rozpocz\u0119cia s\u0105 zazwyczaj minimalizowane. Dlatego te\u017c, w praktyce cz\u0119sto wprowadza si\u0119 klauzule nak\u0142adaj\u0105ce na drug\u0105 stron\u0119 &#8220;obowi\u0105zek uczciwo\u015bci&#8221;.<\/p>\n\n\n\n<blockquote class=\"wp-block-quote\">\n<p>Artyku\u0142 4, ust\u0119p 3: W negocjacjach zmian, obie strony powinny uczciwie dyskutowa\u0107 o kwestiach takich jak cel zmian, mo\u017cliwo\u015b\u0107 ich wprowadzenia, wp\u0142yw zmian na cen\u0119 i termin dostawy.<\/p>\n<\/blockquote>\n\n\n\n<p>Ma to na celu zapobieganie sytuacjom, w kt\u00f3rych, w negocjacjach, kt\u00f3re pocz\u0105tkowo opiera\u0142y si\u0119 na relacji zaufania, nagle pojawia si\u0119 argument, \u017ce &#8220;decyzja o zmianie umowy jest wy\u0142\u0105cznie w gestii strony otrzymuj\u0105cej propozycj\u0119, a nie ma obowi\u0105zku zgodzi\u0107 si\u0119 na przymus&#8221;, co zdradza drug\u0105 stron\u0119 poprzez formalistyczn\u0105 argumentacj\u0119 prawn\u0105. Jest to r\u00f3wnie\u017c odzwierciedlenie zasad prawa dotycz\u0105cych transakcji mi\u0119dzy osobami prywatnymi, nie tylko w przypadku rozwoju system\u00f3w.<\/p>\n\n\n\n<blockquote class=\"wp-block-quote\">\n<p>Artyku\u0142 1, ust\u0119p 2 Kodeksu Cywilnego<\/p>\n\n\n\n<p>Wykonywanie praw i spe\u0142nianie obowi\u0105zk\u00f3w musi odbywa\u0107 si\u0119 zgodnie z zasad\u0105 <u>dobrej wiary<\/u> i <u>uczciwo\u015bci<\/u>.<\/p>\n<\/blockquote>\n\n\n\n<p>Prawo nie zawsze k\u0142adzie nacisk wy\u0142\u0105cznie na &#8220;zapisy umowy&#8221; lub &#8220;sformu\u0142owania artyku\u0142\u00f3w&#8221;. Szczeg\u00f3lnie w transakcjach z udzia\u0142em drugiej strony, powinno by\u0107 stosowane elastycznie, uwzgl\u0119dniaj\u0105c rzeczywiste &#8220;dobrej wiary&#8221; i &#8220;uczciwo\u015b\u0107&#8221;. Co wi\u0119cej, szczeg\u00f3\u0142owe wyja\u015bnienia na temat tego, \u017ce &#8220;obowi\u0105zki&#8221; na\u0142o\u017cone prawnie nie zawsze opieraj\u0105 si\u0119 na procedurze &#8220;umowy&#8221;, mo\u017cna znale\u017a\u0107 w poni\u017cszym artykule.<\/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=\"Podsumowanie\"><\/span>Podsumowanie<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p>W projektach rozwoju system\u00f3w opartych na modelu Agile, oczywi\u015bcie wa\u017cne jest zrozumienie ryzyka, \u017ce procedury biurowe i struktura zarz\u0105dzania mog\u0105 stopniowo stawa\u0107 si\u0119 niedba\u0142e. Jednak\u017ce, nie tylko to jest wa\u017cne. Uwa\u017camy, \u017ce r\u00f3wnie wa\u017cne jest zrozumienie elastycznych cech prawa, takich jak &#8220;zasada dobrej wiary&#8221;, i stosowanie ich w praktyce.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>W podej\u015bciu do rozwoju system\u00f3w istniej\u0105 r\u00f3\u017cne metody. Najbardziej klasycznym i powszechnym jest model Waterfall, a wiele ksi\u0105\u017cek prawniczych dotycz\u0105cych rozwoju system\u00f3w omawia ten model jako punkt w [&hellip;]<\/p>\n","protected":false},"author":32,"featured_media":61312,"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\/pl\/wp-json\/wp\/v2\/posts\/60128"}],"collection":[{"href":"https:\/\/monolith.law\/pl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/monolith.law\/pl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/monolith.law\/pl\/wp-json\/wp\/v2\/users\/32"}],"replies":[{"embeddable":true,"href":"https:\/\/monolith.law\/pl\/wp-json\/wp\/v2\/comments?post=60128"}],"version-history":[{"count":2,"href":"https:\/\/monolith.law\/pl\/wp-json\/wp\/v2\/posts\/60128\/revisions"}],"predecessor-version":[{"id":61313,"href":"https:\/\/monolith.law\/pl\/wp-json\/wp\/v2\/posts\/60128\/revisions\/61313"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/monolith.law\/pl\/wp-json\/wp\/v2\/media\/61312"}],"wp:attachment":[{"href":"https:\/\/monolith.law\/pl\/wp-json\/wp\/v2\/media?parent=60128"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/monolith.law\/pl\/wp-json\/wp\/v2\/categories?post=60128"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/monolith.law\/pl\/wp-json\/wp\/v2\/tags?post=60128"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}