pDIA_KC_
zadávání veřejných zakázek na ICT s využitím agilního vývoje softwaru_
metodické doporučení pro zadavatele
Obsah_
A. Úvod k problematice a doporučení_
Waterfall a Agile jsou nejpoužívanější metodologie pro softwarové vývojové projekty. Obě metodologie mají své jedinečné požadavky, silné stránky a výzvy. V první řadě je tedy nezbytné posoudit, kdy použít jednu z těchto metodologií, případně zda je možné kombinovat oba přístupy a použít je současně.
Waterfall (tzv. vodopádový model) použijte tehdy, pokud je váš projekt natolik striktně vydefinovaný, že jej musíte dokončit v jasně stanoveném termínu, máte omezený rozpočet, funkce projektu jsou předdefinované nebo projekt musí splňovat přísné regulační požadavky. S tímto zadáním můžete jasně definovat projekt a sledovat pevně stanovenou a předvídatelnou cestu k získání požadovaného projektu.
Agilní vývoj softwaru je založen na co nejrychlejším dodání funkční základní verze projektu, přičemž jeho vylepšování a rozšiřování o další funkce probíhá průběžně během zkušebního, případně ale také během ostrého provozu. Vývoj je organizován do tzv. sprintů, které zahrnují fáze analýzy požadavků, vývoje a implementace. Tyto sprinty se opakují a během nich dochází k postupnému zpřesňování a doplňování požadavků na funkčnost projektu. Produkt není vyvíjen najednou, pracuje se na něm postupně v několika cyklech, kde každý cyklus přináší vylepšení a nové funkce.
Můžete také začít s Agile k vytvoření představy o vašem finálním produktu a přejít na Waterfall, když kritéria vašeho projektu budou jasná a zřejmá. Stejnou péči jako výběru metodologie pro softwarový vývojový projekt je třeba věnovat také výběru smlouvy, kterou s dodavatelem softwaru uzavřete. Pečlivost je na místě zejména z toho důvodu, že tradičně používané smluvní nástroje nejsou uzpůsobeny na průběžný vývoj softwaru. Tradiční smlouvy (např. smlouva o dílo) zpravidla vycházejí z výše zmiňovaného vodopádového modelu a přesně upravují jeho jednotlivé fáze, které navazují jedna na druhou: koncepce, analýza, design, konstrukce, testování, implementace atd.
Při vývoji softwaru by se však jednotlivé fáze měly prolínat, aby se včas zjistilo, jestli zvolené řešení je správné, realizovatelné, zda způsob provedení a vynaložené náklady jsou odpovídající. Výsledek projektu se tak rýsuje postupně, v závislosti na výstupech z jednotlivých sprintů (krátkých časově ohraničených fází). Není tedy předem možné vydefinovat odpovídajícím způsobem předmět díla a bez jasně definovaného předmětu díla není možné uzavřít platnou smlouvu o dílo. Jako řešení se nabízí uzavření rámcové smlouvy (v terminologii zákona o zadávání veřejných zakázek “rámcové dohody“) na agilní vývoj softwaru nebo smlouvy nepojmenované, případně smlouvy kombinující prvky smlouvy o dílo a smlouvy na agilní vývoj softwaru (jako vhodné se jeví i užití tzv. dynamického nákupního systému).
Aby byl agilní vývoj a celkově přístup k zadání úspěšný, je též nezbytné, aby znalosti tohoto přístupu nebyly jen na straně dodavatele, ale také na straně samotného zadavatele – produktového vlastníka, ekonomického úseku, IT provozu, vnitřního auditu apod. Více méně musí „agilně“ myslet všichni pracovníci zadavatele, kteří budou mít co do činění s daným projektem. Cíl a účel produktu (projektu) je také třeba dostatečně určitě, byť rámcově, nadefinovat (tj. aniž by se současně podrobně specifikovaly technické vlastnosti konečného softwaru) a celý vývoj by k němu měl směřovat a postupně jej naplňovat (aby byly zachovány zásady 3E – účelnosti, efektivnosti a hospodárnosti).
B. Obecně o agilním vývoji software_
KAPITOLA 1: Základní principy agilního vývoje
Místo dlouhého, jednorázového vývojového cyklu při využití vodopádového modelu využívá agilní vývoj krátké, časově ohraničené cykly zvané iterace nebo sprinty (obvykle trvající 1–4 týdny). Na konci každé iterace je hotová a funkční část softwaru, kterou lze testovat nebo nasadit, což umožňuje rychlé přizpůsobení změnám a zlepšení výsledků.
Členové týmu spolu úzce spolupracují, často sdílejí úkoly a průběžně komunikují s klienty či koncovými uživateli, aby se vývoj přizpůsoboval jejich potřebám a prioritám.
Agilní metodologie je otevřená změnám v požadavcích v průběhu vývoje. Tento přístup tak umožňuje rychle reagovat na nové požadavky nebo přehodnotit dřívější rozhodnutí. Skutečnost, že průběžně jsou k dispozici hotové části produktu, přináší průběžnou hodnotu zadavateli nebo i koncovým uživatelům. Zadavatel díky tomu může sledovat výsledky a poskytovat dodavateli zpětnou vazbu.
Výhody agilního vývoje
Flexibilita. Agilní vývoj umožňuje reagovat na změny požadavků během vývoje. Je zvláště vhodný pro projekty, ve kterých se zadání může vyvíjet v návaznosti na nové legislativní požadavky nebo měnící se potřeby zadavatele či jeho klientů.
Vyšší „spokojenost“ zadavatele. Zadavatel je do celého procesu vývoje průběžně zapojen a má možnost pravidelně nahlížet na pokrok projektu. Díky tomu může snadno přizpůsobit požadavky, aniž by musel čekat na finální dodávku. Zadavatel má průběžnou kontrolu nad tím, jak se projekt vyvíjí, což zajišťuje vyšší transparentnost.
Snížení rizika. Agilní přístup zahrnuje pravidelné dodávání hotového kódu, což umožňuje nasazovat produkt po částech. Zadavatel tak může včas odhalit problémy a předcházet větším komplikacím. Díky tomu může reagovat na možné překážky, čímž se snižuje riziko zpoždění nebo neúspěchu projektu.
Manifest agilního vývoje software (tzv. Agilní manifest)
Agilní manifest je dokument, který definuje principy a hodnoty agilního vývoje softwaru, a který tuto metodu vývoje odlišuje od jiných metod, zejména pak od metody waterfall. Dokument položil základy pro všechny agilní metodologie. Agilní manifest vymezuje čtyři základní hodnoty a dvanáct principů:
Základní hodnoty:
Jednotlivci a interakce před procesy a nástroji
Lidé a jejich vzájemná komunikace jsou důležitější než formální postupy a nástroje. Důraz je kladen na efektivní spolupráci a týmovou práci.
Fungující software před rozsáhlou dokumentací
Cílem je rychle vytvořit a dodávat funkční software, přičemž dokumentace má podporovat vývoj, nikoli jej brzdit.
Spolupráce se zákazníkem před vyjednáváním o smlouvě
Spolupráce se zákazníkem je důležitější než pouze sledování formálních smluvních ujednání. Cílem je rychle reagovat na zpětnou vazbu a měnící se požadavky.
Reakce na změnu před dodržováním plánu
Agilní přístup podporuje flexibilitu a schopnost reagovat na změny místo striktního dodržování předem stanoveného plánu.
Principy:
Naší nejvyšší prioritou je vyhovět zákazníkovi časným a průběžným dodáváním hodnotného softwaru.
Vítáme změny v požadavcích, a to i v pozdějších fázích vývoje. Agilní procesy podporují změny vedoucí ke zvýšení konkurenceschopnosti zákazníka.
Dodáváme fungující software v intervalech týdnů až měsíců, s preferencí kratší periody.
Lidé z byznysu a vývoje musí spolupracovat denně po celou dobu projektu.
Budujeme projekty kolem motivovaných jednotlivců. Vytváříme jim prostředí, podporujeme jejich potřeby a důvěřujeme, že odvedou dobrou práci.
Nejúčinnějším a nejefektnějším způsobem sdělování informací vývojovému týmu z vnějšku i uvnitř něj je osobní konverzace.
Hlavním měřítkem pokroku je fungující software.
Agilní procesy podporují udržitelný rozvoj. Sponzoři, vývojáři i uživatelé by měli být schopni udržet stálé tempo trvale.
Agilitu zvyšuje neustálá pozornost věnovaná technické výjimečnosti a dobrému designu.
Jednoduchost – umění maximalizovat množství nevykonané práce – je klíčová.
Nejlepší architektury, požadavky a návrhy vzejdou ze samoorganizujících se týmů.
Tým se pravidelně zamýšlí nad tím, jak se stát efektivnějším, a následně koriguje a přizpůsobuje své chování a zvyklosti.
Agilní manifest je volně dostupný i v češtině, například na stránce agilemanifesto.org. Manifest je spíše proklamativní bez konkrétních kroků.
Klíčové prvky metodiky Scrum
Hodnoty a principy agilního vývoje jsou rozvedeny v několika metodikách. Velmi používaná je metodika Scrum, což je agilní rámec pro řízení projektů.
Základní stavební bloky Scrumu jsou Sprinty, což jsou časově omezené iterace (fáze), v nichž se tým snaží dokončit předem definovanou část práce.
Role ve Scrum týmu:
Scrum Master – zastupuje stranu dodavatele, zodpovídá za proces, zajišťuje, aby tým dodržoval Scrum1 jakožto nejrozšířenější agilní rámec pro řízení projektů a vývoj softwarových produktů, odstraňuje překážky, které mohou zpomalit práci, a chrání tým před rušivými vlivy.
Product Owner – zastupuje stranu zadavatele, zodpovídá za produktový backlog2, prioritizuje úkoly, aby tým pracoval na věcech, které přinášejí největší hodnotu.
Vývojáři (Development Team) – odborníci, kteří pracují na tvorbě produktu.
Scrumové týmy nemají žádné podskupiny ani hierarchické struktury. Jsou složeny z členů s různými odbornými znalostmi, což zajišťuje, že tým má všechny potřebné dovednosti k dosažení hodnoty v každém Sprintu. Týmy jsou také sebeřídící (self-managing), což znamená, že sami rozhodují o rozdělení úkolů, načasování a způsobu jejich provedení.
Scrumový tým je navržen tak, aby byl dostatečně malý pro agilní práci, ale zároveň dostatečně velký na to, aby mohl v rámci Sprintu dokončit významné úkoly.
Scrumový tým nese odpovědnost za všechny aspekty související s produktem, včetně spolupráce se stakeholdery, ověřování, údržby, provozu, experimentování, výzkumu a vývoje, a dalších potřebných činností.
Události (ceremonie) ve Scrumu
Scrum zahrnuje čtyři formální události pro kontrolu a úpravu, které jsou součástí Sprintu – viz níže bod 3).
Tyto události jsou účinné díky transparentnosti, kontrole a přizpůsobení.
Transparentnost: Procesy a práce musí být viditelné jak pro ty, kteří je vykonávají, tak pro ty, kteří přijímají výsledky. Ve Scrumu jsou klíčová rozhodnutí založena na vnímaném stavu. Nízká transparentnost může vést k rozhodnutím, která snižují hodnotu a zvyšují riziko. Transparentnost umožňuje kontrolu. Kontrola bez transparentnosti je zavádějící a neefektivní.
Kontrola (Inspection): Pokrok směrem k dohodnutým cílům musí být často a svědomitě kontrolován, aby se zjistily potenciální nežádoucí odchylky nebo problémy. Kontrola umožňuje přizpůsobení. Kontrola bez přizpůsobení je zbytečná. Scrumové události jsou navrženy tak, aby vyvolaly změnu.
Přizpůsobení (Adaptation): Pokud se některé aspekty procesu odchylují mimo přijatelné limity nebo je výsledný produkt nepřijatelný, musí být proces nebo výsledky upraveny. Úprava musí být provedena co nejdříve, aby se minimalizovala další odchylka. Přizpůsobení je obtížnější, pokud zúčastnění lidé nejsou zmocněni nebo nejsou sebeřízení. Očekává se, že Scrumový tým se přizpůsobí okamžitě.
Sprint – základní časový úsek (nejčastěji 1-4 týdny), během kterého tým pracuje na splnění stanovených cílů. Na konci každého sprintu by měl být dodán potenciálně použitelný produktový inkrement.3
Sprint Planning – plánovací setkání, na kterém se stanoví cíle a úkoly pro nadcházející sprint.
Daily Scrum – krátká denní schůzka (15 minut), na které členové týmu sdílejí pokrok a překážky.
Sprint Review – setkání na konci sprintu, na kterém se prezentuje dokončená práce.
Sprint Retrospective – po každém sprintu tým reflektuje, co lze zlepšit v dalším sprintu.
Artefakty Scrumu
Product Backlog – seznam všech funkcí, úkolů a požadavků, které je třeba dokončit. Product Owner se stará o aktualizaci a prioritizaci backlogu.
Sprint Backlog – konkrétní úkoly, na kterých bude tým pracovat v aktuálním sprintu.
Inkrement – souhrn všech dokončených položek backlogu, které jsou připravené k použití nebo uvedení na trh.
Oficiální průvodce metodikou Scrum (Scrum Guide) je volně dostupný a pravidelně aktualizovaný. Jeho česká verze je na stránkách scrumguides.org, kde je možné si ho zdarma stáhnout.
Existuje celá řada dalších metodik, nicméně jejich principy jsou vždy obdobné, tedy vývoj na základě takzvaných sprintů či iterací. Některé metodiky zároveň tento vývoj kombinují s dalšími prvky řízení, popřípadě s principy standardního vývoje.
Agilní vývoj ve veřejném sektoru
Digitální transformace veřejných služeb: Pokud veřejný zadavatel plánuje modernizaci nebo digitalizaci služeb, jako je správa portálů či aplikací pro občany, může být agilní vývoj vhodný postup. Požadavky na funkcionalitu se mohou v průběhu projektu měnit na základě zpětné vazby od uživatelů nebo změn legislativy.
Vývoj informačních systémů pro státní správu: Požadavky v této oblasti mohou být silně ovlivněny změnami právních předpisů nebo interních směrnic. Agilní přístup umožňuje flexibilní přizpůsobení systému těmto změnám během vývoje.
Městské a regionální aplikace pro občany: Vývoj webových a mobilních aplikací pro obyvatele měst a obcí mohou vyžadovat reakci na požadavky podle aktuálních trendů a zpětné vazby od veřejnosti. Agilní metoda umožňuje veřejným zadavatelům přizpůsobit aplikaci tak, aby byla uživatelsky přívětivá a aktuální.
Zapojení veřejného zadavatele
Pravidelné schůzky (sprinty): Zadavatel by měl pravidelně komunikovat s dodavatelem a na základě průběžných výsledků upřesňovat zadání. Tento postup napomáhá veřejným zadavatelům sledovat pokrok, přizpůsobovat směr.
Validace jednotlivých kroků a verzí: Každá fáze nebo verze produktu by měla být předmětem schválení zadavatele. Dodané části projektu mohou být průběžně kontrolovány a hodnoceny tak, aby byly v souladu s původním zadáním.
Možnost úprav a změn během vývoje: Agilní metoda umožňuje zadavateli provádět změny během procesu vývoje. Pokud se například změní legislativní požadavky nebo přijdou nové technické standardy, zadavatel je může do projektu implementovat bez zásadního narušení celého vývojového cyklu.
KAPITOLA 2: Agilní vývoj a veřejné zakázky
Agilní vývoj softwaru v kontextu veřejných zakázek představuje specifický způsob plnění, kdy plnění zakázky se uskutečňuje prostřednictvím postupných iterací, které umožňují přizpůsobování výsledného produktu na základě průběžných potřeb zadavatele. V případě veřejných zakázek tak jde o situaci, kdy je nutné, aby smlouva na vývoj software odpovídala principům a charakteristikám agilního přístupu. Zadavatel proto při zadávání zakázky musí vymezit předmět plnění a smluvní podmínky tak, aby umožňovaly flexibilní průběh vývoje. Tento specifický typ plnění v rámci veřejných zakázek s sebou přináší potřebu přizpůsobit formu a podmínky zadávacího řízení. Nastavení smlouvy pro agilní vývoj tedy vyžaduje podrobnou analýzu zadání, vhodné vymezení předmětu a především zohlednění charakteristik, které agilní vývoj přináší, například možnost změn požadavků a vývoj po jednotlivých částech.
Hodnocení nákladové stránky
Agilní přístup zahrnuje průběžné plnění s předběžně neurčenou výslednou podobou softwaru, což znamená, že ve smlouvě není dopředu znám kompletní výstup do detailů a ani konečné náklady nemusí být stanoveny s absolutní přesností. Na začátku vývoje softwaru nelze tedy stanovit pevnou cenu, v průběhu vývoje bude docházet ke změně požadavků. Předmětem hodnocení tak může být například cena vyjádřená formou „člověkodní nebo „člověkohodin“. Není také vyloučeno, a v praxi to bude jistě vhodné, aby zadavatel nehodnotil generální hodnotu člověkodní (člověkohodin), ale aby hodnotil cenové nabídky člověkodní (člověkohodin) na různých pozicích v týmu. Zároveň je připuštěno, aby zadavatel hodnotil náklady životního cyklu, kdy je možné hodnotit obdobná kritéria jako u vývoje, který je prováděn běžnými postupy. V tomto ohledu může být naznačené hodnocení ceny agilního vývoje součástí širšího portfolia hodnotících kritérií směřujících k posouzení výše nákladů celého životního cyklu.
Zohlednění odborné zkušenosti
Specifika agilního vývoje softwaru vyžadují, aby zadavatel stanovil specifické kvalifikační požadavky a kritéria, která zohledňují nejen zkušenosti v oboru vývoje softwaru, ale i schopnost pracovat v rámci agilních metodologií. Zákon umožňuje hodnotit kvalitu realizačního týmu, a zadavatel by proto měl zohlednit, zda dodavatel má zkušenosti nejen s vývojem softwaru, ale také s agilním přístupem. Kromě možných požadavků na odbornou zkušenost dodavatele jako takového (reference) by měla být zohledněna také kvalita konkrétních členů týmu, kteří se budou na vývoji podílet. Toto hodnocení kvality jednotlivců je podloženo zákonem, který umožňuje zohlednit odbornou způsobilost a zkušenosti členů realizačního týmu, což se stává důležitým faktorem při výběru vhodného dodavatele.
Hodnocení nabídky na základě zkušeností a metodiky
Při výběru dodavatele pro agilní vývoj softwaru je žádoucí, aby zadavatel vyžadoval od uchazeče detailní popis metodiky, kterou pro řízení vývoje použije. Tato metodika by měla být buď popsána na základě existujících metodik, nebo by měl dodavatel poskytnout podrobné vysvětlení vlastní metodiky, kterou bude během vývoje používat. Zadavatel může metodiku a způsob řízení vývoje hodnotit. Kromě posouzení metody je možné do hodnotících kritérií zahrnout například i četnost iterací, která určuje frekvenci dodávek, nebo mechanismy komunikace mezi zadavatelem a dodavatelem, což jsou důležité aspekty agilního přístupu.
Vymezení předmětu zakázky
Zadavatel by měl při formulaci předmětu zakázky upřednostnit funkční specifikace před detailním technickým popisem konečného produktu. Tímto způsobem zadavatel postupuje v souladu s § 89 odst. 1 a 3 zákona o zadávání veřejných zakázek, který umožňuje, aby zadavatel definoval cíl a účel produktu, aniž by podrobně specifikoval technické vlastnosti konečného softwaru. Takový přístup je vhodný právě pro agilní vývoj, protože umožňuje průběžné přizpůsobení výsledného softwaru bez nutnosti měnit technické zadání, což je jedním ze základních principů agilního vývoje.
Výběr zadávacího řízení
Při zadávání veřejné zakázky na agilní vývoj softwaru se zadavatel musí důkladně zamyslet nad tím, jaký způsob zadání smlouvy zvolí, protože druh zvoleného zadávacího řízení bude mít vliv na proces uzavření smlouvy i na její podobu, na možnosti řízení projektu a průběžné dodávání výsledků. Agilní vývoj softwaru, na rozdíl od tradičních metod, vyžaduje iterativní přístup, kdy se software vytváří po menších krocích a je průběžně přizpůsobován zpětné vazbě a aktuálním požadavkům zadavatele. Tento přístup vyžaduje, aby byl ve smlouvě nastaven mechanismus, který umožní efektivní komunikaci a spolupráci mezi zadavatelem a dodavatelem.
V každém z možných zadávacích řízení by měl zadavatel klást důraz na:
Zdůraznění agilního přístupu: Zadavatel by měl v zadávací dokumentaci jasně uvést, že zakázka bude realizována formou agilního vývoje, což vyžaduje specifické procesy a postupy, jako jsou iterativní sprinty, pravidelné hodnocení výstupů a průběžná komunikace s cílem co nejrychleji identifikovat problémy a optimalizovat postup prací. Toto zdůraznění má zásadní význam, jelikož dodavatelé musí být předem obeznámeni s požadovaným stylem spolupráce, aby byli schopni předložit adekvátní nabídky.
Stanovení cílů agilního vývoje: Cíl agilního vývoje softwaru by měl být ve smlouvě a v zadávací dokumentaci zřetelně popsán, aby bylo jasné, čeho má projekt dosáhnout a jakou hodnotu má výsledný produkt poskytovat.
Preference pro průběžné plnění a úpravy zadání: Zadavatel by měl v zadávací dokumentaci a následně ve smlouvě specifikovat nejen požadované funkční výsledky, ale i způsob, jakým bude v průběhu vývoje probíhat komunikace týkající se změn (zadavatel by měl stanovit formu komunikace, kdy proběhne písemně a jakým způsobem, a kdy proběhne ústně a jakým způsobem bude zaznamenávána) a jakým způsobem bude docházet k průběžnému vyhodnocování výsledků jednotlivých sprintů či iterací. Je vhodné, aby smlouva obsahovala i konkrétní mechanismy pro provádění změn v zadání.
Zohlednění cíle veřejné zakázky v rámci agilního přístupu
Veřejná zakázka na agilní vývoj softwaru se bude odlišovat od tradiční zakázky nejen způsobem realizace, ale také tím, jakým způsobem je definován cíl a jaké výstupy se očekávají. Zadavatel by měl při tvorbě zadávacích podmínek důsledně dbát na to, aby se v nich odrážel právě cíl agilního přístupu. Tento cíl by měl být definován tak, aby bylo jasné, že cílený produkt bude vznikat průběžně a bude schopen reagovat na změny v požadavcích zadavatele i na vývojové změny v průběhu času.
Druhy zadávacího řízení ve vztahu k agilnímu vývoji
Zadavatel může zakázky na agilní vývoj softwaru zadávat v rámci různých druhů zadávacího řízení, přestože zákon předpokládá u specifických řízení splnění určitých předchozích podmínek. Nicméně v případě agilního vývoje jsou tyto podmínky svou podstatou naplněny. Zadavatel tak může volit mezi jednotlivými řízeními podle toho, které nejlépe odpovídá povaze projektu, aniž by musel striktně dodržovat formální omezení obvyklá pro standardní vývojové projekty.
Například jednací řízení s uveřejněním umožnuje zadavateli jednat o předběžných nabídkách s cílem zlepšit tyto předběžné nabídky ve prospěch zadavatele, což vyhovuje agilnímu vývoji, které je svou povahou postupný, a ne vždy dovoluje dopředu definovat všechny požadavky na výsledný produkt. Podobné je to u soutěžního dialogu, kde se hledá nové, dosud neexistující řešení, což je přístup, který se s agilním vývojem slučuje, neboť zadavatel může v průběhu dialogu formovat a vyjasňovat své potřeby ve spolupráci s dodavatelem.
Agilní vývoj lze řešit i prostřednictvím inovačního partnerství, pokud je předmětem projektu vývoj zcela inovativního produktu, který na trhu dosud není.
Každé řízení má svá specifika a nelze zobecnit, že určitý druh zadávacího řízení je pro agilní vývoj nejvhodnější. Lze porovnávat pouze výhody a nevýhody, jak uvádíme v přehledu níže, a tyto aplikovat na konkrétní projektový záměr.
Otevřené řízení
Otevřené řízení je vhodné pro agilní vývoj, protože zadavatel může definovat principy pro agilní vývoj již v zadávacích podmínkách a nastavit kvalifikaci uchazečů. Flexibilní plnění smlouvy je umožněno, i když není možné jednat o nabídkách po jejich podání. Nabídky tedy musí být posouzeny a hodnoceny v souladu s původním zadáním, což však nevylučuje flexibilní plnění po uzavření smlouvy.
Užší řízení
Užší řízení umožňuje zadavateli předběžně posoudit kvalifikaci uchazečů a následně vyzvat k podání nabídky jen kvalifikované uchazeče, což je vhodné zejména při potenciálně větším počtu uchazečů.
Jednací řízení s uveřejněním
Jednací řízení s uveřejněním nabízí možnost jednání o nabídkách (nad rámec zadavatelem stanovených minimálních technických podmínek), což je pro agilní vývoj přínosné, neboť zadavatel může vést jednání s cílem zlepšit nabídku dodavatele. Například lze jednat o frekvenci jednotlivých iterací, což umožňuje dodavateli přizpůsobit nabídku požadavkům zadavatele a lépe se orientovat na jeho specifické potřeby.
Soutěžní dialog
Soutěžní dialog je vhodný pro případy, kdy zadavatel má stanovený cíl, ale nemá předem jasnou představu o cestě k dosažení tohoto cíle. Tento postup je běžný, pokud zadavatel potřebuje softwarové řešení, ale očekává, že optimální řešení bude vyvinuto v rámci dialogu s kvalifikovanými uchazeči. Výsledkem soutěžního dialogu může být ujednání o použití principů agilního vývoje.
Inovační partnerství
Inovační partnerství se používá, pokud výsledný produkt dosud na trhu neexistuje. Tento postup je vhodný, pokud zadavatel potřebuje vývoj nového softwarového řešení, které má inovativní charakter. Jednotlivé fáze inovačního partnerství mohou částečně odpovídat iteracím v agilním vývoji, i když mají uzavřenější charakter.
Inovační partnerství je ideálním řešením pro projekty, které vyžadují výzkum, vývoj a inovaci. Tento typ řízení podporuje dlouhodobou spolupráci mezi zadavatelem a dodavatelem, což je klíčové pro agilní vývoj. Nicméně je třeba počítat s vyšším rizikem neúspěchu a vyššími náklady spojenými s výzkumem a vývojem, protože výsledný produkt nebo služba neexistuje na začátku projektu, je obtížné přesně předvídat, jak bude konečné řešení vypadat, a zda bude plně splňovat očekávání zadavatele. Vývoj zcela nových řešení rovněž vždy nese riziko, že výzkum či vývoj selže, což může vést k neúspěchu celého projektu. Inovační partnerství může vyžadovat značné investice do výzkumu a vývoje, přičemž konečné náklady mohou být těžko odhadnutelné a mohou překročit původní rozpočet.
C. Právní aspekty agilního vývoje software_
KAPITOLA 1: Rámcová dohoda na agilní vývoj softwaru
Rámcová dohoda je oproti níže komentované smlouvě inominátní (nepojmenované) pro agilní vývoj obecně spíše méně vhodná, protože předpokládá pevně stanovený objem plnění, který může omezit flexibilitu. Navíc v případě rámcové dohody s více účastníky může nastat problém s přiřazením zodpovědnosti za plnění, což není v souladu s principy agilního vývoje, kde je žádoucí, aby odpovědnost za plnění měl jeden dodavatel. Nicméně, pořád jde o jeden z možných právních nástrojů, který se pro účely využití agilních metod nabízí. Aby rámcová dohoda skutečně podpořila agilní vývoj, musí být správně nastavena a reflektovat potřeby flexibilního projektu.
Rámcová dohoda pro agilní vývoj softwaru je flexibilní smluvní nástroj, který se zaměřuje na spolupráci a iterativní vývoj, spíše než na striktní definici výsledku. Vyznačuje se tím, že se zaměřuje na procesy a postupy vývoje, nikoliv na pevně stanovený výsledek, což je typické pro agilní metodiku. Podstatná v rámcové dohodě je tedy úprava samotných procesů, na které by měl být kladen největší důraz, nikoli detailní popis finálního výsledku, protože výsledek (minimálně v jeho detailu) je v okamžiku začátku vývoje ze své podstaty nejasný.
Klíčové oblasti rámcové dohody
Technické a funkční požadavky
Pokud je zvolena agilní metoda, není předem známo, jaká bude konečná podoba softwaru a není tudíž ani možné dopředu předmět dohody jasně popsat (na rozdíl od waterfall metody). Namísto detailního technického popisu konečného produktu na začátku projektu je tedy důležité nastavit rámcové technické požadavky a cíle projektu. Rámcová dohoda by měla definovat hlavní cíle, kterých je potřeba dosáhnout, ale měla by ponechat prostor pro průběžnou úpravu funkcionalit v závislosti na aktuálních potřebách a vývoji projektu při uzavírání jednotlivých dílčích smluv.
VZOROVÉ USTANOVENÍ:
Předmět a cíl rámcové dohody
Předmětem této rámcové dohody je:
obecné vymezení některých postupů a podmínek při vyzývání účastníků k předkládání návrhů řešení do mini tendrů na základě této rámcové dohody,
obecné vymezení některých postupů výběru nejvhodnějšího návrhu řešení dle této rámcové dohody,
zavedení práv k výsledkům řešení vzniklých v rámci plnění rámcové dohody a dílčích smluv z této rámcové dohody uzavřených.
Cílem rámcové dohody je vytvoření softwarového řešení s názvem „[DOPLNIT NÁZEV]“
Podmínky a mechanismy změn
Rámcová dohoda by měla zahrnovat jasné cenové podmínky pro jednotlivé dílčí zakázky, ale zároveň umožňovat úpravy na základě změn ve specifikacích nebo technických požadavcích. Jistá míra cenové flexibility je klíčová, protože jednotlivé části projektu mohou vyžadovat různé úrovně složitosti a zdrojů. Např. hodinová sazba by se mohla lišit v závislosti na druhu prováděných prací a potřebné kvalifikace pracovníků dodavatelů k poskytnutí daného plnění.
V rámci úpravy cenových podmínek musí rámcová dohoda a zadávací dokumentace určit také maximální výši finančních prostředků, které je zadavatel ochoten na plnění vynaložit během celého trvání rámcové smlouvy. Pokud dojde k dosažení této částky, rámcová smlouva pozbyde účinnosti.
VZOROVÉ USTANOVENÍ
„Jednotná nabídková maximální cena za hodinu „[POPIS ČINNOSTI]“
činí ……………. Kč bez DPH tedy……………. Kč včetně DPH
Cenu návrhu řešení tvoří počet hodin odborných činností potřebných k vytvoření návrhu řešení.
Účastník má možnost, pokud to zadavatel umožnil ve výzvě k podání návrhu řešení, do ceny návrhu řešení započíst jako její součást až 10 % paušálních nákladů.
Cena návrhu řešení, kterou bude zadavatel hodnotit, tak bude tvořena součinem počtu hodin, které účastník navrhuje ve svém návrhu řešení jako hodiny potřebné pro řešení, a navrhovanou hodinovou sazbou, a následným možným přičtením 10 % z uvedeného součinu.
Maximální přípustná nabídková cena veřejné zakázky „[DOPLNIT NÁZEV]“ činí _____mil Kč bez DPH.“
Systém kontroly a průběžného hodnocení
Agilní vývoj je založen na pravidelných kontrolních bodech, kdy je hodnocen pokrok a zpětná vazba od uživatelů. Rámcová dohoda by měla zavést mechanismy pro hodnocení jednotlivých fází projektu a kontrolu plnění smluvních závazků, která probíhá zejména při předání výstupů jednotlivých dílčích smluv. Ustanovení rámcové dohody o akceptaci plnění tak musí jasně určit, jakým způsobem budou smluvní strany testovat dodanou část softwaru, za jakých podmínek je zadavatel ochoten plnění přijmout (akceptační kritéria mají zejména určit kategorie a množství vad, s jakými je zadavatel ochoten plnění přijmout a s jakými sankcemi se pojí nedodržení stanovaných podmínek).
Mechanismy pro hodnocení a zadávání dílčích zakázek
Pokud zadavatel zvolí cestu uzavření smlouvy s více dodavateli, měla by jasně definovat proces hodnocení a výběru dodavatelů pro dílčí zakázky (mini-tendry). Měla by obsahovat kritéria, která zajistí, že zadavatel bude moci vybrat toho nejlepšího dodavatele pro danou fázi projektu, a zároveň zachová spravedlivou soutěž.
Otevřenost řešení
Rámcová dohoda může (v případě vícero zadavatelů musí) zahrnovat podmínky, které zajistí otevřenost vyvíjeného řešení. To znamená, že projekt bude navržen tak, aby na něm mohl případně pokračovat jiný dodavatel, přičemž logickou podmínkou je i povinnost dodavatelů vést náležitou dokumentaci.
V rámci rámcové dohody se mohou jednotlivé fáze projektu zadávat formou mini-tendrů, kde může být vybrán nový dodavatel pro každou dílčí objednávku. Otevřené řešení zajišťuje, že nový dodavatel bude schopen bez problémů navázat na práci svého předchůdce a pokračovat v plnění. Otevřené řešení také snižuje riziko tzv. vendor lock-in4, tedy závislosti na jednom dodavateli za situace, kdy zadavatel zaplatí cenu např. za vývoj softwaru, ale nedostane k němu zdrojové kódy. Předání zdrojových kódů by proto mělo být ve smlouvě výslovně sjednáno. Díky otevřenému přístupu může zadavatel přejít k jinému dodavateli, aniž by to vedlo ke komplikacím nebo prodlevám v projektu (i po ukončení rámcové dohody).
Práva duševního vlastnictví
Rámcová dohoda by měla rovněž jasně stanovit podmínky týkající se práv k duševnímu vlastnictví, včetně autorských práv a práv k patentům. Je důležité vyjasnit, kdo bude mít práva k výstupům jednotlivých fází a jaká práva bude mít zadavatel k používání, úpravám a distribuci výsledného řešení. V rámcové dohodě je také vhodné upravit odpovědnost dodavatele za porušení práv duševního vlastnictví třetí osoby.
Service Level Agreement (SLA)
SLA, které stanoví úroveň poskytovaných servisních a podpůrných služeb, jako jsou doba k řešení různých kategorií incidentů, parametry helpdesku atp. může být buď součástí rámcové dohody, nebo samostatnou smlouvou o poskytování podpory uzavřenou na základě samostatného zadávacího řízení (tj. i s jiným dodavatelem, za předpokladu zajištění odpovídajících práv takového jiného dodavatele k danému software). Uzavření SLA s jinou osobou, než s hlavním dodavatelem software snižuje riziko vendor lock-in, tedy stavu uzamčení v obchodním vztahu s hlavním dodavatelem, protože software už je de facto vyvíjen od počátku tak, že jeho servis a další rozvoj bude možný jinou osobu (popř. zadavatelem samotným).
KAPITOLA 2: Inominátní smlouva na agilní vývoj softwaru
Ve smlouvě na agilní vývoj softwaru je vhodné stanovit prvky, které umožňují flexibilitu a průběžnou kontrolu projektu. Tyto principy přispívají k efektivnímu řízení vývoje softwaru, který odráží potřeby veřejného zadavatele a umožňuje přizpůsobit se změnám v průběhu projektu.
Klíčové oblasti inominátní smlouvy
Definice projektu a rozsahu práce
Vize projektu a dlouhodobé cíle: Je vhodné uvést přehledný popis očekávaných výsledků a cílů, aby projekt odpovídal záměrům veřejného zadavatele a aby byl i dostatečně určitý a srozumitelný (a naplňoval tak i základní zásady dle § 6 zákona o zadávání veřejných zakázek včetně zásady transparentnosti) a dodavatelé podle něj mohli sestavit nabídky.
Rozsah prací: Je žádoucí nastavit, že rozsah prací bude během projektu postupně upravován podle aktuálních potřeb, což podporuje iterativní přístup a zajišťuje, že se práce zaměřuje na požadované funkce. Celkový rozsah prací by měl být ovšem stanoven alespoň prostřednictvím základního odhadu, doporučujeme popsat alespoň účel softwarového řešení.
VZOROVÉ USTANOVENÍ
Zadavatel má zájem touto Smlouvou zajistit pro svou činnost vytvoření, implementaci, provoz, správu a kontinuální rozvoj [NÁZEV SOFTWARU] (dále jen „SOFTWARE“). Zadavatel má zájem na realizaci SOFTWARU v režimu agilního vývoje, kdy jednotlivé části a jeho funkce budou vyvíjeny postupně, za průběžného ověřování naplnění potřeb Zadavatele.
Dodavatel je odborníkem v oblasti vývoje SOFTWARU a má zájem poskytnout Zadavateli plnění dle této Smlouvy s využitím procesů agilního vývoje k uspokojení jeho potřeb vyjádřených v předchozím odstavci.
Dodavatel se zavazuje na základě této Smlouvy a objednávek učiněných dle této Smlouvy provést pro Zadavatele díla nebo jiné činnosti, které směřují k vytvoření a rozvoji SOFTWARU.
Iterativní vývoj a dodávky
Harmonogram: Je vhodné stanovit frekvenci iterací, po kterých budou dodávány a kontrolovány dílčí části projektu, čímž se podpoří transparentnost a umožní včasná reakce na aktuální požadavky. To nevylučuje stanovení konečného termínu pro splnění smlouvy. Postupnému předávání softwaru zadavateli (jednotlivé milníky) odpovídá povinnost zaplatit cenu za provedenou část softwaru. Tato povinnost může samozřejmě být sjednána i odlišně.
Průběžné dodávky: Na konci každého sprintu je přínosné dodávat funkční části softwaru s přidanou hodnotou pro zadavatele, což přispívá ke kontrole směřování projektu. Toto postupné předávání softwaru na konci každého sprintu (lze ale stanovit i jiné milníky), by mělo být v harmonogramu zachyceno a ten by měl být součástí smlouvy. Výslovně by ve smlouvě mělo být zakotveno, jestli zadavatel může užívat a upravovat software i tehdy, kdy ještě není celkově dokončený.
VZOROVÉ USTANOVENÍ:
Tvorba a rozvoj SOFTWARU bude probíhat iterativní metodou, tzn. že Dodavatel bude SOFTWARE vyvíjet v průběhu několika kratších časových bloků, tzv. „sprintů“. Sprinty budou probíhat na základě objednávek uskutečněných způsobem níže popsaným v tomto odstavci (dále jen „Objednávky“). V jedné Objednávce může být zahrnuto i více sprintů.
Zadavatel zadá [DOPLNIT DOHODNUTÝ ZPŮSOB KOMUNIKACE] požadavek na provedení díla nebo jiných činností Dodavatele směřujících k vytvoření nebo rozvoji SOFTWARU. V rámci požadavku specifikuje Zadavatel obecně, co má být vytvořeno a čeho má být dosaženo.
Dodavatel na základě požadavku Zadavatele navrhne řešení potřeby Zadavatele specifikované v požadavku. Dodavatel se zavazuje svou reakci na požadavek Zadavatele zaslat Zadavateli nejpozději do 3 pracovních dnů od doručení požadavku. Je-li to s ohledem na složitost požadavku a další relevantní okolnosti potřeba, vyžádá si Dodavatel v rámci své reakce od Zadavatele doplnění, upřesnění či jinou součinnost potřebnou k návrhu řešení.
Strany [DOPLNIT DOHODNUTÝ ZPŮSOB KOMUNIKACE], případně jinou vhodnou formou, vč. osobní schůzky, poskytnou součinnost ke specifikaci díla a vytvoření zadání pro Dodavatele na základě požadavku Zadavatele. Pro vyloučení pochybností se uvádí, že zadání vytvořené v součinnosti Stran se může lišit od původního požadavku Zadavatele, zejm. je-li to účelné s ohledem na vývoj SOFTWARU a naplnění potřeby Zadavatele v přiměřeném čase.
Tímto způsobem dohodnou Strany obsah Objednávky, a tedy zejména:
i) předmět Objednávky, tedy dílo, které má být v rámci sprintu provedeno, nebo jiné činnosti Dodavatele dle této Smlouvy, a to zejména skrze vymezení funkcí a parametru, které má dílo, resp. SOFTWARE jako celek splňovat: je-li do Objednávky zahrnuto více sprintů, bude Objednávka obsahovat rovněž rozdělení, do kterého sprintu spadá provedení příslušného díla nebo dalších činností;
ii) časový rozsah sprintu/sprintů, tedy maximální množství člověkohodin potřebných ze strany Dodavatele k vytvoření, poskytnutí či jinému splnění předmětu sprintu: člověkohodinou se rozumí výkon práce kompetentního pracovníka, tj. programátora nebo jiného odborného pracovníka, který se podílí na poskytování plnění ze strany Dodavatele dle této Smlouvy v délce jedné hodiny;
iii) termín sprintu, tedy termín, do kdy má být sprint dokončen a předmět sprintu předán Objednateli v souladu s touto Smlouvou, případně rovněž počátek běhu sprintu.
Okamžikem odsouhlasení obsahu Objednávky oběma Stranami prostřednictvím Projektového software nebo jinou vhodnou formou vzniká mezi nimi dílčí smlouva, jejímž předmětem je provedení díla a poskytnutí jiných činností ze strany Dodavatele dle Objednávky (dále jen „Dílčí smlouva“).
JINÝ PŘÍKLAD ZAKOTVENÍ SPRINTŮ
„S ohledem na agilní vývoj webové aplikace bude webová aplikace dodávána po částech, a to v rámci jednotlivých sprintů.
Sprint bude smluvními stranami definován alespoň těmito náležitostmi:
Obsahovat definici sprintu, tedy požadavky objednatele na novou funkcionalitu či na změnu předcházející funkcionality webové aplikace, opravu chyb a podobně;
Odhadem časové náročnosti na realizaci sprintu, tedy hodinová doba práce potřebná k tomu, aby došlo k dokončení sprintu;
Termínem realizace, respektive datem dokončení a předání sprintu;
Zda bude sprint obsahovat dokumentaci k webové aplikaci a v jakém rozsahu.
Strany budou každý sprint definovat prostřednictvím projektové aplikace XXX. Dodavatel zahájí sprint vždy do 3 pracovních dnů poté, co dojde ke shodě ohledně výše uvedených náležitostí.“5
Mechanismus řízení změn
Flexibilita rozsahu: Doporučuje se, aby smlouva umožňovala průběžné úpravy priorit a změny v rozsahu projektu na základě aktuálních potřeb veřejného zadavatele.
Odhady nákladů a času: Je žádoucí nastavit pravidelné aktualizace odhadů nákladů a časového harmonogramu s možností úpravy (předem vysoutěžené) ceny podle skutečného rozsahu prací.
Průběžné hodnocení a zpětná vazba
Pravidelné hodnocení: Doporučuje se stanovit frekvenci schůzek pro kontrolu průběhu projektu, čímž se zajistí průběžná kontrola výsledků a možnost poskytovat zpětnou vazbu.
Role a odpovědnosti: Je vhodné, aby veřejný zadavatel jmenoval zástupce (tzv. product owner), který bude zodpovědný za komunikaci s dodavatelem a hodnocení každého sprintu, což podporuje efektivní spolupráci.
Platební podmínky
Platby podle milníků nebo iterací: Doporučuje se nastavit platby na základě dokončených milníků nebo sprintů, což zajistí, že veřejné prostředky budou využívány na konkrétní, průběžně dodávané výsledky.
VZOROVÉ USTANOVENÍ
Objednatel je povinen zaplatit Poskytovateli za řádně provedené Dílo částku [DOPLNÍ OBJEDNATEL PŘED PODPISEM SMLOUVY] Kč (slovy: [DOPLNÍ OBJEDNATEL PŘED PODPISEM SMLOUVY] korun českých) bez DPH („Cena díla“). Cena díla bude placena po částech po provedení jednotlivých Dílčích částí díla.
Možnosti ukončení smlouvy: Je užitečné umožnit veřejnému zadavateli smlouvu ukončit na konci každého sprintu s výpovědní dobou, pokud projekt nesplňuje očekávání.
Předání, akceptační testy, záruky a odpovědnost za vady
Předání: Jako v případě předání každého díla i u softwaru je třeba sjednat způsob a termín jeho řádného předání. Domluvit se na okamžiku předání patrně nebude tak komplikované jako určení způsobu předání softwaru. Software může být instalován přímo v provozním prostředí zadavatele, může být zaslán e-mailem, předán odkazem s možností stažení nebo zpřístupněn na konkrétním serveru. Způsob předání by měl být ve smlouvě zcela jasně vymezen. Stejně tak by měla být ve smlouvě ošetřena situace, kdy dodavatel neposkytne při předání softwaru nutnou součinnost. O předání softwaru doporučujeme sepsat předávací (akceptační) protokol.
Akceptační testy: vlastnosti softwaru nelze zjistit a ověřit pouhým zhlédnutím předávaného díla. Vady softwaru, chyby a vůbec to, jestli software splňuje požadované vlastnosti lze ověřit pouze provedením tzv. akceptačních testů. Při agilním vývoji bude patrně nemožné stanovit akceptační postup nebo kritéria pro testování již při uzavírání smlouvy na vývoj softwaru. V takovém případě je třeba ve smlouvě zakotvit následný proces určení kritérií (tedy kdo, kdy a jakým způsobem je stanoví). Akceptační testy lze např. provádět na konci každého sprintu (akceptačním testům bude podléhat každý jeden výsledek sprintu).
VZOROVÉ USTANOVENÍ
"Objednatel může nejpozději 7 dnů před termínem dokončení softwaru podle harmonogramu sdělit dodavateli, že dokončení softwaru bude požadovat prokázat provedením zkoušek. V takovém případě je software dokončen až úspěšným provedením zkoušek. Strany se dohodnou nejpozději 3 dny před termínem dokončení softwaru podle harmonogramu na termínu, způsobu provedení akceptačních testů a na akceptačních kritériích. V případě, že se strany podle předchozí věty nedohodnou, určí termín, způsob provedení akceptačních testů a akceptační kritéria objednatel.“6
Záruky na dodaný kód: Doporučuje se sjednat dostatečně dlouhou dobu, po kterou bude dodavatel poskytovat podporu nebo opravy chyb po nasazení softwaru. Otázkou zůstává, co je to podpora a co je dostatečně dlouhá doba. Z hlediska zadavatele by zjevně bylo nejvýhodnější, kdyby bylo možné vrátit software dodavateli k úpravám, pokud software nebude vyhovovat představám zadavatele. Postup pro řešení vad by bylo žádoucí opakovat do té doby, dokud nebudou vady odstraněny.
Kvalita a technické standardy: Stanovení minimálních požadavků na kvalitu kódu a technologie může přispět k udržitelnosti softwaru a dlouhodobému plnění stanovených cílů.
Duševní vlastnictví
Práva ke zdrojovému kódu: Doporučuje se stanovit podmínky, za kterých zdrojový kód, resp. práva k němu, přechází na veřejného zadavatele (anebo i jím určenou třetí osobu – nového potenciálního dodavatele), obvykle po zaplacení příslušné části projektu. Případně uzavřít aspoň smlouvu o úschově zdrojového kódu u třetí osoby (viz i níže – tzv. escrow).
VZOROVÉ USTANOVENÍ
Dodavatel se zavazuje předat společně se SOFTWAREM nebo jiným výstupem své činnosti dle této Smlouvy Zadavateli zdrojový kód (je-li výstupem plnění činnosti Dodavatele počítačový program), dokumentaci ke svému výstupu včetně dokumentace ke zdrojovému kódu a veškeré externí komponenty nezbytné nebo vhodné pro úplný a řádný provoz SOFTWARU, které souvisejí s předávaným dílem nebo jiným výstupem činnosti Dodavatele, a to nejpozději dne XX. Zadavatel je oprávněn zdrojový kód SOFTWARU modifikovat dle své úvahy, případně tím pověřit třetí osobu, a to za účelem úplného a řádného provozu SOFTWARU a jeho rozvoje.
Dokumentace: Je vhodné ve smlouvě uvést, že dodavatel dodá dokumentaci k softwaru v předepsané formě a rozsahu, což usnadní případné další rozšíření nebo údržbu systému.
VZOROVÉ USTANOVENÍ
Forma předání: Zdrojový kód, dokumentace a externí komponenty budou Zadavateli předány ve formátu běžně dostupném a čitelném prostřednictvím repozitáře nebo datového uložiště zvoleného Zadavatelem, nedohodnou-li se Strany jinak.
Požadavky na kvalitu zdrojového kódu a dokumentace: Zdrojový kód a dokumentace budou mít kvalitu a rozsah dle nejvyšších standardů akceptovaných (tzv. state-of-the-art) v oblasti vývoje a tvorby SOFTWARU. Zdrojový kód bude řádně komentovaný tak, aby jakýkoliv jiný odborník v oblasti vývoje SOFTWARU byl schopen s vynaložením přiměřeného úsilí na něj navázat, zejm. za účelem úprav a rozvoje SOFTWARU, a dále bude zdrojový kód čitelný a kompilovatelný za použití běžně dostupného a používaného softwarového vybavení.
Obecná ustanovení a ukončení smlouvy
Úhrada víceprací: ve smlouvě je vhodné zakotvit, jak se budou platit případné vícepráce.
Řešení sporů a rozhodné právo pro smlouvu: rovněž by ve smlouvě nemělo být opominuto.
Povinnost mlčenlivosti – dodavatel by měl být smluvně zavázán k povinnosti mlčenlivosti ohledně důvěrných informací zadavatele.
Nedokončení softwaru – jaká jsou práva zadavatele v případě, že software nebude dokončen? Může jej zadavatel upravovat, dokončit a užívat?
Ochrana proti vendor-lock-inu – je více než žádoucí připravit se na situaci, kdy se softwarem v budoucnu bude pracovat jiný dodavatel (vrácení veškeré dokumentace k softwaru i materiálů poskytnutých zadavatelem, zaškolení pracovníků nového dodavatele, předání přístupů do administrátorských rozhraní, úschova kódů u třetí osoby – tzv. escrow)7.
Pojištění dodavatele proti odpovědnosti za škodu – je vhodné toto pojištění požadovat, a to po celou dobu účinnosti smlouvy a doložit například kopií pojistné smlouvy nebo certifikátem o uzavřeném pojištění.
Konkurenční doložka – v některých případech je vhodné zamyslet se nad zákazem činnosti soutěžní povahy dodavateli.
Smluvní pokuty – plnění veškerých povinností lze zajistit přiměřenou smluvní pokutou.
KAPITOLA 3: Změny inominátní smlouvy
Otázka změn smlouvy ve vztahu k agilnímu vývoji softwaru je zásadní, neboť samotná povaha agilního vývoje staví na flexibilitě a průběžných úpravách, které se postupně definují na základě jednotlivých iterací či sprintů. Právě iterativní povaha agilního vývoje umožňuje, aby se projekt průběžně vyvíjel a reagoval na aktuální potřeby zadavatele. Proto je klíčové zohlednit, jakým způsobem se změny smlouvy v souvislosti s agilním vývojem promítají do právního rámce smlouvy a jaká jsou zákonná omezení pro případné změny v rámci veřejných zakázek.
Zákon o zadávání veřejných zakázek stanovuje konkrétní podmínky, za kterých může k jakékoliv změně smlouvy dojít, a tyto podmínky je třeba dodržovat i při agilním vývoji. Přestože se agilní vývoj vyznačuje vysokou mírou flexibility, není to důvod, proč by tento proces měl být mimo právní rámec smlouvy. Smlouva na agilní vývoj by tak měla obsahovat jasně nastavený mechanismus, který definuje, jak se bude iterativní vývoj realizovat a jakým způsobem budou prováděny případné změny plnění. Tím se zajišťuje, že se smlouva nemusí měnit pokaždé, když dojde k úpravám ve vývojovém procesu, protože mechanismus těchto změn je již přímo součástí smlouvy.
Mechanismus změn jako součást smlouvy
V rámci agilního vývoje se nastavení dalšího postupu určuje v reakci na aktuální stav projektu, který vyplývá z předešlého sprintu. Předpokládá se, že smlouva obsahuje podmínky a parametry, podle nichž budou jednotlivé úpravy realizovány, což znamená, že k těmto změnám není potřeba přistupovat jako ke změně smlouvy, pokud se tím nenarušuje cíl projektu („změny“ jsou součástí už původního závazku). Jinými slovy, pokud smlouva výslovně zahrnuje mechanismus změn, který určuje, jak budou konkrétní úpravy probíhat, není každou změnu nutné považovat za změnu smlouvy (závazku) ve smyslu zákona o zadávání veřejných zakázek.
Lze zde uvažovat o analogii s tzv. výhradou změny závazku dle § 100 zákona o zadávání veřejných zakázek, která předpokládá, že zadavatel předem jednoznačně stanoví podmínky a způsoby, za kterých se může plnění měnit. Pokud tedy zadavatel v původní smlouvě na agilní vývoj jednoznačně definoval podmínky pro úpravy v návaznosti na iterace (a nemění se ani celková povaha veřejné zakázky – cíl projektu), je naplněna podstata výhrady změny smlouvy, která umožňuje, aby úpravy vzniklé v důsledku agilního procesu nebyly vnímány jako nepřípustná podstatná změna smlouvy dle § 222 zákona o zadávání veřejných zakázek (resp. ani jako jakákoliv jiná – i „nepodstatná“ změna). Tento mechanismus tak splňuje podmínky pro řádné plnění veřejné zakázky bez nutnosti využití ustanovení o změnách smlouvy dle § 222 zákona o zadávání veřejných zakázek.
Pokud se tedy dodržuje smluvní mechanismus a cíl projektu zůstává zachován, jde o naplnění smluvních podmínek bez nutnosti řešit změny jako zásah do původní smlouvy. Ve smlouvě by tedy mělo být stanoveno, že dodavateli se platí podle předem definovaných jednotek práce, například formou tzv. „člověkodnů“ nebo „člověkohodin“. Tento způsob platby zajišťuje, že nedochází ke změně ve výsledném cíli projektu, ale umožňuje reagovat na změny v rozsahu prací.
Možnosti změny závazku ze smlouvy na veřejnou zakázku
I přes flexibilitu agilního přístupu, a i když mechanismus změn je dobře nastaven ve smlouvě, mohou nastat případy, kdy bude právně sporné, zda úprava vychází ze smlouvy, nebo zda se jedná o změnu závazku ze smlouvy na veřejnou zakázku.
V takovém případě je třeba posoudit, zdali se jedná o změnu podstatnou, či nepodstatnou. V případě podstatných změn je zadavatel povinen provést nové zadávací řízení, neboť se jedná o tak zásadní změnu, že je měněna povaha původní veřejné zakázky a je nutné umožnit účast i jiným dodavatelům (výjimku představují smlouvy, které byly uzavřeny na základě veřejné zakázky, na níž se aplikuje zákonná výjimka z povinnosti zadat veřejnou zakázku v zadávacím řízení). V případě podstatných změn tak v plnění veřejné zakázky nelze pokračovat a pro tyto účely poskytuje zákon v § 223 zadavateli zákonnou možnost smlouvu na veřejnou zakázku vypovědět nebo od ní odstoupit. Ustanovení § 222 daného zákona však upravuje i řadu situací – změn, které se nepovažují za podstatné a jako takové jsou tedy povoleny. Těmito změnami jsou mj. i situace tzv. nepředvídatelných okolností dle § 222 odst. 6 zákona o zadávání veřejných zakázek. Blíže se této problematice věnujeme v naší metodice k problematice vendor-lock in.
Naplnění smluvního mechanismu
Jednotlivé iterace, tedy sprinty, nejsou změnou smlouvy, ale představují naplnění smluvního mechanismu agilního vývoje, který je ve smlouvě předem definován. Smlouva by měla být nastavena tak, že upravuje způsob, jakým budou jednotlivé sprinty vedeny, jak se bude hodnotit jejich výstup, a kdo bude odpovědný za jejich kontrolu. Průběžné dodávky produktů (či jeho částí) po jednotlivých sprintových iteracích umožňují zadavateli mít průběžný přehled o vývoji softwaru a včas reagovat na případné nesrovnalosti či odchylky od původního zadání, aniž by docházelo ke změnám smlouvy. Tento přístup zároveň odpovídá požadavku na efektivní a účelné nakládání s veřejnými prostředky, protože průběžná kontrola zajišťuje včasné odhalení a nápravu nedostatků, což může zabránit pozdějším problémům (při současném naplňování cílů projektu skrze jednotlivé sprinty, aby naopak zadavatel nebyl napadán ze „zmařené investice” apod.).
V rámci jednotlivých sprintů tedy probíhá flexibilní úprava produktu tak, aby vyhovoval aktuálním požadavkům, přičemž se celý proces řídí předem stanovenými pravidly, která jsou součástí smlouvy. Proto jednotlivé iterace podle nás nenaplňují definici změny smlouvy ve smyslu § 222 zákona o zadávání veřejných zakázek, neboť jde pouze o naplňování stanoveného mechanismu vývoje, jehož cílem je dosáhnout výsledného plnění v souladu s původním zadáním veřejné zakázky.
Agilní vývoj softwaru, pokud je ve smlouvě odpovídajícím způsobem upraven, nevyžaduje nutně zásahy do samotné smlouvy, neboť pružný mechanismus změn je již její součástí. Dodavatel je odměňován na základě jednotek práce (člověkodny, člověkohodiny), přičemž základní cíl projektu zůstává stejný a postupné úpravy a přizpůsobení nevedou k podstatné (a podle nás ani nepodstatné) změně smlouvy. Přesto mohou nastat situace, kdy se změna smlouvy stává nezbytnou, zejména kvůli nepředvídatelným okolnostem – v případě takových okolností se aplikuje § 222 odst. 6 zákona o zadávání veřejných zakázek, jak výše uvádíme.
D. Výhrady zpracování_
DIA KC jsou konzultačním a podpůrným útvarem Digitální a informační agentury a jeho stanoviska, metodiky, závěry z konzultací či jiná doporučení nelze zaměňovat se stanovisky a doporučeními Digitální a informační agentury publikovanými v rámci úřední činnosti ani nelze na jejich základě předjímat rozhodnutí Digitální a informační agentury jako správního orgánu.
PRAHA, XX. XX. 2026