Aktuální rozsudek k agilnímu vývoji softwaru

Autor: Mgr. Petr Otevřel | Vloženo: 7. 11. 2021 21:24 | Přečteno: 2575X

Agilní vývoj softwaru se stává stále častěji preferovanou metodou. Dodavatelé propagující tuto metodu ji pro její flexibilitu považují z principu za lepší než tzv. vodopádový model. V tomto článku si rozebereme jeden docela nový rozsudek soudu prvního stupně, který zatím dopadl pro dodavatele velice špatně a dobře poukazuje na právní úskalí agilního vývoje softwaru.

Co je agilní vývoj softwaru?

Základ metodiky agilního vývoje vychází ze čtyřbodového agilního manifestu, který upřednostňuje interakci osob před procesy, fungující software před vyčerpávající dokumentací, flexibilní reagování na změny před dodržováním plánu. Jedním ze čtyř bodů je také to, že spolupráce se zákazníkem má přednost před vyjednáváním o smlouvě.

Není v možnostech tohoto článku popsat podrobně metodiku agilního vývoje, která má řadu modifikací, více např. zde. Stručně řečeno jde o proces, v němž na začátku mají obě strany jen hrubou představu o finální podobě softwaru, zpravidla také o ceně, a proto je nezbytný velice flexibilní přístup a průběžná oboustranná komunikace obou stran. Základní vizi včetně vlastností, funkcionalit a priorit uvedou strany v dokumentu „Product Backlog“, a v rámci jednotlivých krátkých etap, tzv. sprintů pak dodavatel vyvíjí vybrané části softwaru, na nichž se dohodnul s objednatelem (obvykle na tzv. Sprint Meetingu, jehož výstupem by měl být tzv. Sprint Backlog, tedy jakási specifikace daného sprintu, orientovaná na požadované cíle a funkcionalitu, nejde o technickou specifikaci). Výsledky sprintů dodavatel prezentuje (Sprint-Review) a výsledkem může být akceptace/odmítnutí, ale také dohoda o tom, že se flexibilně změní či rozšíří Product Backlog. Tento postup musí být flexibilní, s maximálním zapojením objednatele, důležité jsou jednotlivé role projektového týmu (Product Owner, Scrum tým).

Agilní vývoj má umožnit vznik finálního produktu, který plně odpovídá představám a potřebám objednatele. To je zásadní rozdíl oproti tzv. vodopádovému modelu, kde dodavatel postupuje v rámci jednotlivých fází k dosažení předem daného a specifikovaného řešení.

Spor ze smlouvy o agilním vývoji

Žalobce se domáhal úhrady částky celkem 742.424,73 Kč spolu s úrokem z prodlení, a to na základě rámcové smlouvy o poskytování služeb (dále „smlouva“ nebo „rámcová smlouva“), jejímž předmětem byl závazek žalobce (dále „zhotovitel“) provést dílo představující projekt počítačového programu, a to s využitím agilních metod vývoje softwaru.

Hned na začátku uvedu, že soud žalobu v plném rozsahu zamítnul a přiznal žalovanému objednateli náklady řízení ve výši přesahující 143 tis. Kč.

Z odůvodnění rozsudku vyplývá, že smlouva obsahovala definici agilní metody, základní pojmy jako Backlog, sprint atd. Cena byla sjednána jako součin hodinových sazeb a odvedené práce a měla být účtována průběžně. Objednatel zadával v souladu se smlouvou pokyny k provedení vybraných činností uvedených v Backlogu, tj. zadával jednotlivé sprinty a na základě těchto objednávek vznikaly dílčí smlouvy o dílo.

Objednatel po třech těchto sprintech odstoupil od celé smlouvy, což odůvodnil soustavným a hrubým porušováním smluvních povinností ze strany zhotovitele, mimo jiné nedodržením agilní metodiky, prodlením se splněním harmonogramu, absencí prezentace uceleného řešení a nesplněním povinností stanovených v jednotlivých dílčích smlouvách o dílo. Objednatel tak uhradil pouze část ceny za první sprint, další část si jednostranně započetl a odmítnul uhradit cenu vyfakturovanou ze strany zhotovitele za druhý a třetí sprint.

Dodavatel v žalobě tvrdil, že řádně provedl a vyúčtoval dílo, které předával online v rámci cloudového uložiště, kdy nově provedené části propojil s kódem provedeným již dříve. Žalovaný objednatel odmítnul uhradit cenu, ačkoliv byl k tomu vyzván.

Argumentace účastníků sporu

Objednatel během soudního sporu poukázal na skutečnost, že vytýkal zhotoviteli vady „u veškerých děl zhotovených během prvního sprintu“ a následně poukazoval na nedostatky vyúčtování druhého i třetího sprintu, během nichž mu zhotovitel vyúčtoval čas strávený na odstraňování vad, jako by šlo o provádění díla. Z výkazů za druhý a třetí sprint objednatel dovodil, že šlo o „práce na totožných úkolech,“ které měly být vykonány během prvního sprintu a šlo tedy ve skutečnosti o odstraňování vad. Objednatel proto odmítnul podepsat předávací protokoly, které potvrzovaly převzetí jednotlivých děl, resp. děl prováděných v jednotlivých sprintech. Z tohoto důvodu zhotovitel dle názoru objednatele vůbec nebyl oprávněn vystavit předmětné faktury.

Zhotovitel měl samozřejmě pohled opačný. Jednak poukázal na údajně nedostatečnou součinnost objednatele, která vedla k vyššímu počtu odvedených hodin, než by jinak bylo nutné. Zhotovitel v rámci svého vyjádření začal poukazovat na specifika agilního vývoje softwaru, dokonce tvrdil, že na základě pokynů objednatele nevznikaly žádné dílčí smlouvy o dílo, „neboť to odporuje podstatě agilního vývoje.“ Zhotovitel tak neprováděl samostatná dílčí plnění, ale „pro žalovanou (objednatele) na základě jejích pokynů a požadavků prováděla dílo jakožto celek.“ Zhotovitel dále popíral tvrzení o vadném plnění v rámci prvního sprintu, kdy mj. poukazoval na to, že objednatel nedokládá svá tvrzení reklamacemi nebo jinými záznamy a tvrdil, že „pokud žalovaná (objednatel) vznášela další požadavky na provádění díla a udílela pokyny (což je při agilní metodě provádění díla zcela v pořádku a je to esenciálním základem této formy provádění díla), nelze toto považovat za jakékoliv odstraňování vad, avšak jedná se o samostatné provádění díla.“

Znalecký posudek

Soud ustanovil soudního znalce, jehož posudek hrál v rozhodnutí soudu prvního stupně zásadní roli. Neznáme bohužel konkrétní zadání formulované soudem, nicméně lze říct, že znalec posoudil celý případ velice široce a zabýval se mj. také obecně metodikou agilního vývoje a tím, zda byla v daném případě vůbec vhodná. Ve svých závěrech znalec posuzoval přiměřenost ceny vyúčtované zhotovitelem s průběhem projektu, který by probíhal klasickým „vodopádovým“ způsobem.

Znalec především konstatoval, že celý projekt měl nedostatečné zadání a chyběla technická a datová analýza, což vedlo k většímu objemu práce, než by bylo potřeba v případě systematicky zadaného projektu. Podle znalce „rozsah žalobkyní účtovaných konzultací a meetingů odpovídá nepřesnému zadání a agilnímu způsobu vývoje programu.“ Čas vykázaný dodavatelem je dle znalce „přiměřený způsobu zadání a agilní (nesystematické) metodě vývoje programu.“

Podle znalce zhotovitel nepředal objednateli dokumentaci, popis datového modelu a celkovou specifikaci vyvíjeného programu, což má za následek, že „pro třetí stranu je využitelnost naprogramovaného zdrojového kódu prakticky nulová“, efektivnější by bylo vytvořit tyto zdrojové kódy znovu.

Ještě podstatnější byl závěr, že zhotovitel nevytvořil navzdory objednávky objednatele „ucelený program, který by mohl být uplatněn na trhu“. Znalec odhadl obvyklou tržní cenu funkčních modulů, které měly být vytvořeny na základě objednávky objednatele, na 100 – 200 tis. Kč. Avšak vzhledem k tomu, že plnění dodané zhotovitelem „netvoří ucelený program ani jeho části“, konstatoval znalec, že tržní hodnota těchto plnění včetně výhradní licence ke zhotoveným částem díla má nulovou tržní cenu. Tržní cena přitom nezávisí na množství práce, ale na ceně programu na trhu nebo pro zadavatele.

Na druhou stranu znalec zmínil také špatný postup na straně objednatele, který na neuspokojivý směr vývoje upozornil až během 4. etapy (sprintu), kdy už bylo vykázáno přes 100 pracovních dnů. Správně by měl Product Owner (na straně objednatele) reálně řídit celý projekt, dbát na řádný obsah Product Backlogu (tzn. na řádném a úplném zadání) a na konci každého sprintu ověřit jeho splnění. Nutno říct, že tato část odůvodnění nekoresponduje s tvrzením objednatele o tom, že plnění jednotlivých sprintů odmítnul převzít.  

Argumentace soudu

Soud přisvědčil výkladu objednatele, že na základě rámcové smlouvy vznikaly jednotlivé dílčí smlouvy, a to na základě objednávek objednatele. Šlo tedy o model „Sprint = dílčí smlouva o dílo“.

Soud poukázal na ujednání v rámcové smlouvě ohledně fakturace, která opravňovala zhotovitele fakturovat jednotlivé sprinty až po jejich převzetí a odsouhlasení objednatelem.

Dále soud poukázal na závěry znalce o tom, že žádné ucelené části programu nebyly zhotovitelem předány a nulové tržní hodnotě plnění zhotovitele a žalobu v plném rozsahu zamítnul, jak bylo uvedeno výše.

Co ze shora uvedeného vyplývá

Mé dále uvedené závěry vychází pouze ze studia odůvodnění rozsudku, bez znalostí konkrétních dokumentů nebo jiných okolností.

Právní povaha smlouvy o agilním vývoji

Přes zásadu agilního manifestu „spolupráce se zákazníkem má přednost před vyjednáváním o smlouvě“ by si měli zhotovitelé uvědomit, že právníci včetně soudců budou zpravidla na sprint nahlížet jako na samostatné dílčí plnění vytvořené v režimu smlouvy o dílo. Takové plnění musí být řádně provedeno, tj. vytvořeno v rozsahu sjednaném v objednávce (Sprint Backlogu) a předáno objednateli. Teprve pak vzniká zhotoviteli nárok na cenu příslušného díla. Pozdější argumentace typu „ale objednatel pořád přicházel s novými požadavky a my jsme mu chtěli vyjít vstříc“ není právně relevantní.

Pokud chce zhotovitel argumentovat tím, že jednotlivé sprinty nepředstavují žádná samostatná plnění (viz shora v části „Argumentace účastníků sporu“), měl by to jasně do smlouvy uvést a nepodmiňovat fakturaci sprintů na jejich převzetí a odsouhlasení objednatelem, viz níže.

Na druhou stranu, pokud objednatel dílčí plnění akceptuje a převezme, nemá později možnost odstoupit od smlouvy ve vztahu k těmto plněním, ledaže by si to ve smlouvě výslovně vymínil.

Předání a převzetí dílčích plnění (sprintů)

Z citovaného rozsudku vyplývá, že zhotovitel si nezajistil potvrzení předávacích protokolů k jednotlivým sprintům. Z povahy předávání jednotlivých sprintů jako relativně malých dílčích plnění přitom vyplývá, že ne vždy musí být předávané plnění tvořit „ucelenou část“ schopnou samostatného užití. Zhotovitel by si měl ve smlouvě upravit kritéria, podle kterých bude posuzována způsobilost plnění k předání a případně zdůraznit, že může jít pouze izolované ověření funkcionalit stanovených ve Sprint Backlogu.

Je v podstatě pravidlem, že zejména v raných fázích projektu nelze přezkoumat plnou funkcionalitu dílčího plnění, jeho propojení s ostatními částmi systému nebo informačními systémy třetích stran, které je možné až v rámci finálního předání celého díla. To by mělo ze smlouvy jasně vyplývat. Citovaný rozsudek a argumentace zhotovitele, že se u sprintů vůbec nejednalo o dílčí smlouvy, nám napovídá, že možná ani v této klíčové problematice neměly strany jasno.

Součinnost objednatele

Z praxe je mi známo, že řada objednatelů si neuvědomuje, že cenou za flexibilitu agilního vývoje jsou mnohem vyšší nároky na součinnost z jejich strany. Roli Product Ownera nelze omezit pouze na přebírání plnění, měl by naopak být osobou, která se aktivně podílí na tvorbě a úpravám Backlogu, tj. aktivně ovlivňuje zadání včetně zadávání jednotlivých sprintů ve smyslu „čeho má být dosaženo“, prioritizaci plnění a spolurozhodování o tom, co má zhotovitel dělat v následujícím sprintu. Je zřejmé, že ne každý objednatel má ve svých řadách osobu odborně způsobilou vykonávat roli Product Owner, viz shora citované výtky soudního znalce.

Cena

V rámci agilního vývoje nezřídka zhotovitelé zapomínají na skutečnost, že objednatelé po určité době a úhradě nemalých peněžitých částek za jednotlivé sprinty začínají ve svém mentálním nastavení vracet k jim důvěrně známému vodopádovému modelu, který jim dává minimálně pocit, že ví, za co platí, kdy to bude hotovo a kolik to bude nakonec stát.

Cenová ujednání by proto neměla být smlouvou ledabyle postavena na principu součinu hodinové sazby a odvedených hodin. Řešením mohou být cenové stropy, tj. rozsah hodin předem stanovený odhadem, s možností překročit jej maximálně o např. 10%. Existují i další způsoby stanovení ceny takovým způsobem, aby nedocházelo k omezení flexibilitu celého agilního vývoje. Např. tzv. agilní pevná cena nebo metoda „Money for nothing, change for free“, ale to už přesahuje rozsah tohoto článku.

Závěr

Bude zajímavé sledovat, jak v této věci rozhodne odvolací soud, nicméně příliš velký prostor pro zamítnutí rozsudku soudu prvního stupně nevidím, alespoň tedy z hlediska hmotněprávního. Zhotovitel, který poskytuje služby agilního vývoje softwaru, by si měl být vědom toho, že kvalitní smlouva je jedním z předpokladů dobré spolupráce se zákazníkem, nikoliv něčím nepodstatným, co během projektu spoluprací se zákazníkem „dožene“. Objednatel by zase měl zvážit, zda je skutečně dobře připraven na plnění své role v rámci agilního vývoje softwaru, která na něj klade mnohem větší nároky, než klasický „vodopádový“ model.

 

Autor: Mgr. Petr Otevřel, otevrel@lawyer.cz | LinkedIn

Autor působí v advokátní kanceláři Jansa, Mokrý, Otevřel & partneři s.r.o., kde se zabývá zejména smluvní úpravou v oblasti informačních technologií, autorským a obchodním právem a problematikou ochrany osobních údajů.