Klasická smlouva o dílo počítá s tím, že na začátku je jasné, co se má postavit: pevný rozsah, pevná cena, na konci předání a akceptace celku. Agilní vývoj stojí na opaku — rozsah se tvoří za pochodu podle priorit v backlogu a software vzniká po inkrementech, které se nasazují průběžně. Kdo natáhne šablonu smlouvy o dílo na sprinty, dostane smlouvu, která neodpovídá ničemu, co strany skutečně dělají — a při prvním sporu se ukáže, že nekryje ani jednu z nich.
Kde se smlouva o dílo se sprinty rozchází
Podle § 536 odst. 1 slovenského obchodního zákoníku se zhotovitel zavazuje provést určité dílo a objednatel zaplatit cenu za jeho provedení. U agilního projektu však na začátku nikdo nedokáže popsat výsledný systém tak, aby popis vydržel do konce; ví se jen, jak se bude pracovat. Druhý rozpor je v řízení:
Při provádění díla postupuje zhotovitel samostatně a při určení způsobu provedení díla není vázán pokyny objednatele, ledaže se výslovně zavázal je plnit. — Český překlad § 537 odst. 3 zákona č. 513/1991 Zb.
Agilní projekt přitom stojí právě na pokynech objednatele — product owner určuje priority každý sprint. Pokud se dodavatel ve smlouvě k plnění pokynů výslovně nezaváže, zákonný základ mluví proti tomu, co si objednatel myslí, že si koupil.
Rámcová smlouva a objednávky
Spolupráci lze upravit na dvou úrovních: rámcová smlouva určí pravidla spolupráce — sazby, role, proces zadávání, akceptaci, práva ke kódu, důvěrnost a ukončení — a jednotlivé objednávky či sprinty se zadávají podle ní, typicky přes projektový systém, ve kterém vzniká i důkazní stopa. Právně jde o kombinaci smlouvy o dílo a nepojmenované smlouvy podle § 269 odst. 2 obchodního zákoníku, která vyžaduje splnění této podmínky:
Účastníci mohou uzavřít i takovou smlouvu, která není upravena jako smluvní typ. Pokud však účastníci dostatečně neurčí předmět svých závazků, smlouva není uzavřena. — Český překlad § 269 odst. 2 zákona č. 513/1991 Zb.
Předmětem rámce proto není hotový systém, ale přesně popsaný proces: kdo zadává, kdo schvaluje odhad, co je výstupem sprintu. Odměna bývá time & material — sazba krát vykázaný čas — což zákon připouští, protože stačí dohodnout způsob určení ceny (§ 536 odst. 3). Bez dohodnuté sazby by hrozila cena obvyklá (§ 546 odst. 1), tedy dokazování místo faktury. Ochranou objednatele je rozpočtový strop na období nebo objednávku, po jehož dosažení práce bez nového schválení nepokračují; ochranou dodavatele pravidlo, že vykázaný a akceptovaný čas je splatný i tehdy, když objednatel projekt předčasně zastaví.
Akceptace po inkrementech a definice hotového
U sprintů nelze čekat s akceptací na konec projektu. Akceptuje se každý inkrement: smlouva určí akceptační kritéria — definici hotového včetně testů a dokumentace — krátkou lhůtu na vyjádření a fikci akceptace, pokud se objednatel ve lhůtě nevyjádří ani nevytkne vady. Jinak se nasazené inkrementy hromadí v právním vzduchoprázdnu. Proč je mlčení při přebírání nebezpečné i bez fikce, ukazuje poradna nepodepsaný předávací protokol a cena díla. Samostatně je třeba upravit vady: akceptace inkrementu se týká funkcí daného sprintu, nesmí však zbavit dodavatele odpovědnosti za integrační vady a regrese, které se projeví až v souhře s pozdějšími inkrementy. Odpovědnost za celek proto běží od nasazení poslední části, nikoli od první akceptace.
Změna rozsahu bez dodatků
Výhodou rámcové smlouvy je, že při změně rozsahu není třeba měnit samotnou smlouvu. Backlog je živý seznam, který product owner bez dodatků doplňuje i přeskupuje — smlouva jen určí, jak se položka stane závaznou: dodavatel předloží odhad, objednatel ho schválí, teprve potom se pracuje. K tomu patří dohodnutá tolerance překročení odhadu; nad ni dodavatel nesmí pokračovat bez nového souhlasu, jinak vícepráce nese sám. Sporné body řeší eskalační postup — nejprve projektové role, potom statutární orgány — aby jeden neschválený ticket nezastavil celý projekt.
Kód, ukončení a předání repozitáře
Práva k softwaru vytvořenému na objednávku upravuje § 91 zákona č. 185/2015 Z. z.; při vývoji přes dodavatelskou firmu nelze bez dalšího předpokládat, že objednatel získává výkon majetkových práv autora. To však nevylučuje nevýhradní licenci vyplývající z dohody stran a účelu smlouvy (§ 65 a § 66). Výslovné ujednání dává jistotu o jejím rozsahu, zejména při úpravách, sublicencích a předání zdrojového kódu. Podrobně to rozebírá poradna autorská práva k softwaru na objednávku. V rámcové smlouvě je klíčový časový rozměr: práva a přístup ke kódu mají přecházet průběžně s akceptací každého inkrementu, nikoli až po zaplacení poslední faktury. Prakticky to znamená vývoj v repozitáři pod kontrolou objednatele nebo povinnost kód a dokumentaci po každém sprintu předat. Na ukončení musí rámec pamatovat předem: výpověď bez udání důvodu s přiměřenou lhůtou, dokončení nebo vypořádání rozběhnutých objednávek, předání repozitáře, dokumentace a přístupů, součinnost při přechodu na nového dodavatele. A pokud má dodavatel po nasazení držet pohotovost, je třeba ji ocenit samostatně — zda se platí i bez zásahu, vysvětluje poradna platí se pohotovost bez zásahu?.
Pro obě strany
Dobře napsaný rámec chrání objednatele před nekonečným rozpočtem a dodavatele před prací, kterou nikdo neschválil. Připravíme nebo zrevidujeme smlouvu na IT dílo a agilní vývoj pro kteroukoli stranu, k nasazení cizího systému implementační smlouvu, práva ke kódu ošetříme v softwarové a licenční smlouvě a u klasických dodávek s pevným rozsahem připravíme smlouvu o dílo.
Článek představuje obecnou právní informaci ke stavu k datu 6. 9. 2026 — nejde o právní službu ani radu k vaší konkrétní věci. Právní předpisy se mění a vaše situace se může v detailech lišit; před rozhodnutím si postup ověřte nebo se nám ozvěte.
