Význam a uplatnění agilních smluv při vývoji softwaru

Nevyhovující nastavení práv a povinností stran, ale též nedostatečná flexibilita při reagování na mnohdy nevyhnutelné změny mají za následek, že úspěšné dokončení projektů zaměřených na vývoj softwaru je spíše vzácností. Při užití tradičních metod končí úspěšně pouze 1 ze 6 projektů.[1]

Důvod je zřejmý, tradiční smluvní nástroje nejsou na vývoj softwaru uzpůsobeny. Proces vývoje, který upravují, je obvykle založený na tzv. vodopádovém modelu_,_ kdy jedna fáze následuje druhou – koncepce, analýza, design, konstrukce, testování, implementace atd.[2] Při vývoji softwaru by však měly být jednotlivé fáze prostupné, aby bylo zjištěno včas, nakolik je řešení užitečné, proveditelné, jakým způsobem a s jakými náklady.

Problém je ještě zjevnější v případě softwarových projektů, při jejichž zadání zákazník disponuje pouze vizí nebo základní charakteristikou výsledného softwaru, která je však nedostatečná pro specifikaci softwaru jako díla a může zapříčinit různé představy smluvních stran o požadovaném výsledku. Pro předejití nedorozumění nebo sporů smluvních stran o požadovaný výsledek je proto třeba smluvně upravit možnost – či spíše povinnost – zákazníka operativně reagovat na dosažené výsledky již v průběhu vývoje. Praxe proto v posledních letech stále častěji užívá metody agilního vývoje softwaru, které mají zajistit u obou stran větší zapojení a mnohem užší kooperaci.

V čem agilita spočívá

Předmětem agilní smlouvy je nastavení pravidel agilního procesu vývoje softwaru, jehož detailní specifikaci před zahájením vývoje nemají strany k dispozici. V čem agilita spočívá se pokusil vymezit Manifest Agilního vývoje software, který byl vytvořen zástupci společností zabývajícími se vývojem softwaru. Předmětem manifestu jsou základní principy a hodnoty, na nichž se agilní vývoj zakládá:

• Jednotlivci a interakce mají přednost před procesy a nástroji;
• Fungující software má přednost před vyčerpávající dokumentací;
• Spolupráce se zákazníkem má přednost před vyjednáváním o smlouvě;
• Reagování na změny má přednost před dodržováním plánu.[3]

Ptáme-li se tedy, na čem je agilní vývoj postaven, jsou to malé týmy, krátkodobé dílčí cíle, průběžný přezkum plánu, rozdělení do kratších časových úseků, průběžné testování a především spolupráce. Agilní vývoj totiž stojí a padá spolu se spoluprací mezi obchodními partnery.

Ačkoli je dodavatel na počátku seznámen s představou zákazníka, stává se tak pouze v hrubých rysech. V průběhu realizace projektu se však představa zákazníka dotváří a zpřesňuje s každým dílčím výstupem. Aby však bylo včas reagováno na změny a nedocházelo ke zbytečnému vynakládání nákladů, je třeba, aby zákazník s dodavatelem na vývoji aktivně spolupracoval, a to povětšinou i na denní bázi, což ovšem klade značné nároky také na zákazníka.

Uvést optimální nastavení procesů je v podstatě nemožné s ohledem na to, že existuje větší množství postupů, které reflektují principy agilního vývoje, avšak liší se mimo jiné právě rozsahem zapojení zákazníka do procesu vývoje. Mezi nejvyužívanější patří metoda Scrum, eXtreme Programming, Kanban nebo DSDM. Každá z těchto metod má své výhody a záleží na posouzení obchodních partnerů, která bude pro jejich vztah nejvhodnější.

Nezbytnost užití agilního vývoje v praxi

Agilní vývoj se užívá převážně při vývoji softwaru, avšak je na místě vždy, když není možné předem vydefinovat odpovídajícím způsobem předmět díla nebo když zákazník ani neví, co přesně má výsledkem projektu být. Že se nejedná o výjimečný jev dokumentuje skutečnost, že ideologie agility není žádnou novinkou poslední doby. Naopak, agilní metodika se stává hlavním proudem při vývoji softwaru. Uvádí se, že při vývoji softwaru využívá agilní způsob vývoje více než 1/3 softwarových společností v USA a Evropě,[4] přičemž tento trend stále roste.

Důvodem je, že agilní způsob vývoje v podstatě není možné nahradit konvenčními smluvními typy. Jakkoli se stále jedná o vývoj a je tedy možné uvažovat o smlouvě o dílo, bez definovaného předmětu díla není možné platnou smlouvu uzavřít. Přistoupí-li strany pouze k vágnímu popisu díla, zavdávají prostor pro nesoulad představ objednatele s dílem provedeným zhotovitelem. Filosofie agility má daleko blíže ke smlouvě o společnosti, avšak účel, odpovědnostní vztahy nebo rozdělení práv a povinností jsou zcela jiného charakteru.

Závěrem

Orientace ve smlouvách o agilním vývoji se při přípravě smlouvy o vývoji softwaru, jak se zdá, stává nezbytností. Pro specifika vývoje softwaru je užití jiných smluvních typů problematické, ačkoli zejména jednodušší projekty mohou i při jejich využití skončit úspěchem. Ze zahraniční zkušenosti je však zřejmé, že zájem o tento typ smluv stoupá a tento trend lze v současné době pozorovat i v prostředí České republiky. [5]

---

[1] The Chaos Report [online]. The Standish Group International, Inc, 1995. Dostupné z: www.csus.edu/indiv/v/velianitis/161/ChaosReport.pdf

[2] ROYCE, W.W. Managing the devolopment of large software systems_, Proceedings of IEEE Wescon_. 1970, s. 328-338.

[3] Manifest Agilního vývoje software [online]. Dostupné z: www.agilemanifesto.org/iso/cs/manifesto.html

[4] WEST, D.; GRANT, T. et al. Agile development: Main-stream adoption has changed agility [online]. Forrester Research, 2010. Dostupné z: www.forrester.com/report/Agile+Development+Mainstream+Adoption+Has+Changed+Agility/-/E-RES56100

[5] Viz např. STANÍČEK, Z.; HORÁKOVÁ, V. Agilita a projekty [online]. SHINE Group. Dostupné z: www.shine.cz/blog/agilita-projekty