Advokátní kancelář Jansa, Mokrý, Otevřel & partneři - specialisté na problematiku IT práva

Právní aspekty agilního vývoje a dodání softwaru

Autor: JUDr. Lukáš Jansa | Vloženo: 18. 1. 2017 11:21 | Přečteno: 6962X

Poslední dobou se ve své praxi více setkáváme s požadavkem na úpravu smlouvy pro agilní způsob vývoje a dodání softwaru, lépe řečeno vývoj a implementace některou z forem agilní metodiky. Následující článek si tedy klade za cíl poukázat na vybrané právní aspekty tohoto trendu v oblasti informačních technologií.


Úvod do problematiky

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 funkcionalitu 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ím 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 funkcionalit. 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.
Závěrem tohoto úvodu je třeba poznamenat, že agilní způsob dodání SW není vždy lepší, jako spíš je vhodnější pro určité typy projektů, kdy na počátku nemá zákazník zcela jasnou představu o finální funkcionalitě softwaru nebo kdy má okamžitou potřebu na dodávce softwaru a počítá s jeho postupnými úpravami.
V praxi se 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ů.

Tzv. 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 funkcionalit 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 emailem 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, emailová korespondence atd.). Lze také doporučit definici pravomocí jednotlivých klíčových osob s vazbou na formulaci zásadní funkcionality 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ě.

  • 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.

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.

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 – www.softwarovepravo.cz.

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 více např. na www.sprintmethod.cz

Článek byl publikován v časopise IT Systems 7-8/2016.
JUDr. Lukáš Jansa, jansa@lawyer.cz
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.