Tradiční (vodopádový) způsob dodání softwaru v podobě předem stanoveného detailního rozsahu dodávky SW, který rozsáhle definuje přesnou funkčnost SW, akceptační kritéria a samozřejmě cenu, naráží v praxi na problémy v podobě častého změnového řízení, prodlužování termínů, navyšování ceny atd. Příčiny těchto komplikací lze pozorovat jednak v nedostatečně formulovaných požadavcích zákazníka, jednak v podcenění prvotní analýzy a také v měnících se počátečních podmínkách, pokud vývoj a dodání složitějšího systému vyžaduje delší dobu. Řešení těchto situací pak je pro obě strany časově náročné a ne vždy ideální uprostřed rozběhnutého projektu. Právě tomu mají agilní metodiky při dodání SW zabránit, resp. alespoň částečně negativní projevy omezit.

Agilní metodiky rovněž reflektují potřebu zákazníka na co nejrychlejší dodání softwaru alespoň se základními funkcemi s tím, že za ostrého provozu bude docházet ke customizaci a dalšímu vývoji požadovaných funkčností. Dalším pozitivním projevem tohoto způsobu vývoje SW je intenzivnější komunikace objednatele a dodavatele a s tím související kontrola postupu vývoje a implementace softwaru a také i možnost kdykoliv vývoj ukončit s tím, že není nutné vracet uhrazenou cenu nebo se složitě dohadovat o finančním vyrovnání za provedenou práci.

Současně je ovšem třeba poznamenat, že agilní způsob dodání SW není vždy lepší. Je spíš vhodnější pro určité typy projektů, kdy na počátku nemá zákazník zcela jasnou představu o finální funkčnosti softwaru nebo kdy má okamžitou potřebu na dodávku softwaru a počítá s jeho postupnými úpravami. V praxi se také lze setkat s celou řadou kombinací i tradičních způsobů dodání s agilními, kdy na počátku je provedena analýza, stanoven finanční rámec na x let a v návaznosti na to jsou na větší celky uzavřeny dílčí smlouvy a ty pak jsou realizovány formou sprintů.

Sprinty

Jednotlivé fáze projektu vývoje a implementace softwaru a jejich konkrétní obsah nejsou tedy u agilního vývoje předem známy, ale jsou tvořeny tzv. sprinty. Jde kratší časové úseky, zahrnující analýzu, vývoj a implementace. Během sprintů dochází k postupnému upřesňování požadavků zákazníka a funkčností SW, a to ve vztahu k jednotlivým částem a modulům SW. Tyto sprinty jsou zakončeny předáním a uvedením do provozu. Je pochopitelné, že právní konstrukce sjednávání a předávání jednotlivých sprintů jakožto menších vývojových celků SW nebude tak složitá jako sjednávání a předání komplikovaného SW u tradičního vývoje. Sprinty se při využití agilních metod opakují (tzv. iterace) až do finálního testování a dokončení projektu jeho předáním jako celku (není vždy nutné). Samozřejmě agilních metodik je celá řada (např. scrum, sprintmethod, extrémní programování, Lean Software Development apod.) a od toho se odvíjí i podoba smluvní úpravy sprintů.

Právní definice předmětu smlouvy

Předmět smlouvy lze stručně shrnout jako závazek na straně dodavatele postupně vyvíjet a implementovat software v tzv. sprintech a na straně objednatele závazek platit za jednotlivé dohodnuté sprinty hodinovou či jinak sjednanou odměnu. Z právního pohledu je možné zakotvit jednotlivé sprinty jako tzv. dílčí smlouvy navazující na základní rámcovou smlouvu s tím, že obsah dílčích smluv bude dán dohodou smluvních stran v průběhu realizace projektu vývoje SW. Dílčí smlouva pak bude obvykle obsahovat definici sprintu, tj. co se bude vyvíjet, kolik hodin připadne odhadem na vývoj a implementaci v daném sprintu (je možné stanovit fixně, či rámcově), termín implementace a předání sprintu (není podmínkou stanovení termínu). Forma uzavírání dílčích smluv by měla být co nejjednodušší, tzn. objednávkovým e-mailem a jeho potvrzením, formou zápisů z projektových schůzek apod., tak aby se předešlo prodlením. Vzhledem k tomu, že agilním metodikám jsou vlastní změny během sprintu, pak je potřeba právně upravit i co nejjednodušší způsob sjednávání těchto změn.

Pro správný průběh sprintů je naprosto klíčovou otázkou forma komunikace smluvních stran, tzn. definice oprávněných osob a způsobu komunikace (pravidelné osobní schůzky, využití softwaru pro správu požadavků – ServiceDesku, e-mailová korespondence atd.). Lze také doporučit definici pravomocí jednotlivých klíčových osob s vazbou na formulaci zásadní funkčnosti SW, maximální ceny sprintu, určování priorit jednotlivých sprintů atd. (tj. funkci Scrum Master, Unblockera, Developer atd.)

Specifika ukončení smlouvy

Pro objednatele je významnou skutečností i ukončení smlouvy v průběhu vývoje softwaru a další pokračování projektu. Rozhodujícím faktorem je, zda jde o software, jehož jediným výrobcem je dodavatel, nebo se jedná o software, který je u nás dodáván a případně customizován více subjekty. Z právního pohledu je nutné v tomto řešit následující témata:

Autorská práva

Mám tím na mysli majetková autorská práva k dosud předaným částem softwaru a současně i možnost upravovat software, spojovat s jiným SW atd. Úprava majetkových práv zahrnuje poskytnutí výhradní licence nebo převod výkonu majetkových práv (u softwaru „na míru“) nebo poskytnutí nevýhradní licence u hromadně distribuovaného softwaru. Není vyloučena ani kombinace výhradní licence ve vztahu k nově vyvinutým modulům SW a nevýhradní licence k jádru SW, u něhož je výrobcem třetí osoba (např. globální výrobce). U na míru vyvíjeného softwaru lze doporučit vedle předání zdrojových kódů právní úpravu i možnosti zásahu do těchto kódů a možnosti měnit SW, spojovat s jiným atd. Dodavatel by tak měl mít závazek předat podklady (programovou dokumentaci) a zdrojové kódy (pokud nejde o nevýhradní licenci) objednateli, a to pod sankcí ve formě smluvní pokuty. Tato úprava by mohla zahrnovat i součinnost s novým dodavatelem. Absence této úpravy by pak mohla dostat objednatele do nevýhodné pozice v situaci, kdy dojde k ukončení spolupráce a bude nutné další rozvoj softwaru svěřit třetí osobě.

Uvedená autorská práva a případné předání zdrojových kódů je samozřejmě nutné řešit i v případě úspěšného ukončení projektu. Úprava odpovědnosti za vady pak bude souviset se servisní činností, pokud dodavatel bude k tomu zavázán.

Odpovědnost za vady

Pokud dojde k ukončení smlouvy a jsou již ukončeny sprinty představující funkční části, pak lze samozřejmě uvažovat o odpovědnosti za vady původního dodavatele ve vztahu k těmto předaným částem. Lze předpokládat, že původní dodavatel bude mít snahu se vyvázat z odpovědnosti v případě, že již dál nebude mít možnost se na agilním vývoji podílet. Bude totiž obvyklé, že části SW budou dál ovlivněny dalšími změnami provedenými novým dodavatelem, a tím pádem je nutné zavázat k odpovědnosti za vady spíše nového dodavatele. Případně veškeré vady lze právně podřídit režimu servisní smlouvy bez ohledu na to, že dodavatelem vadných částí SW byl původní dodavatel.

Finanční vyrovnání

Obrovskou výhodu dodání SW formou sprintů představuje pak při ukončení projektu během vývoje softwaru již v podstatě provedené finanční vyrovnání. Tím, že je projekt profinancováván průběžně, pak jakékoliv ukončení smlouvy v průběhu projektu neznamená žádnou povinnost vrátit uhrazenou cenu nebo potřebu se komplikovaně dohadovat o finančním vyrovnání dosud vyvinutého, ale ještě nepředaného softwaru, jako je tomu u standardního způsobu dodání SW.

Servisní činnost a maintenance

I software, který je výsledkem agilní formy programování, vyžaduje po svém dokončení servis a údržbu. Na údržbu (maintenance, další rozvoj softwaru či jeho změny) se použije stejná forma objednávání změn, tak jako tomu bylo u sprintů. Co se týká servisní činnosti, pak se předpokládá režim standardní servisní smlouvy či tzv. SLA (Service Level Agreement). K servisní smlouvě a SLA lze odkázat na podrobný výklad v naší knize Softwarové právo.

Závěr

Agilní vývoj a implementace softwaru na rozdíl od standardního tedy klade na smluvní úpravu větší nároky zejména v oblasti komunikace a úpravy tzv. sprintů. Právní úprava sprintů vyžaduje dostatečně kvalitní definici způsobu jejich sjednávání a oprávnění jednotlivých členů projektových týmů. V žádném případě nelze také podcenit autorská práva objednatele nezbytná pro další rozvoj softwaru a odpovědnost za vady. Pouze odpovídajícím způsobem právně zakotvená úprava uvedených oblastí může vést k očekávaným přínosům uplatnění agilních metod vývoje a implementace softwaru. Více k tomuto tématu najdete na specializovaném webu www.sprintmethod.cz.

JUDr. Lukáš Jansa Autor působí jako advokát v advokátní kanceláři Jansa, Mokrý, Otevřel & partneři. Je spoluautorem odborné publikace Softwarové právo a Internetové právo (www.softwarovepravo.cz).