Ačkoliv způsobů vývoje softwaru je víc, tradičně se využívá pouze jedna metoda, označovaná díky postupným navazujícím krokům za waterfall metodu Tato metoda staví na základním předpokladu, kterým je zdokumentování všech požadavků objednatele ještě před zahájením vývoje. V praxi se počítá s přesným zadáním, do něhož se v průběhu vývoje příliš nezasahuje.
Využíváte už ve firmě autonomní agenty postavené na bázi umělé inteligence?
Zhotovitel dostává zadání a jeho úkolem je odevzdat řešení, které tomuto zadání odpovídá. Z pohledu zhotovitele po převzetí zadání následuje obvykle analýza, návrh řešení, samotný vývoj a fáze testování. V případě nedostatků po ukončení testování následuje pouze řešení vad, k předchozím fázím se však již nevrací.
Metoda má v právním řádu oporu v ustanoveních zákona č. 89/2012 Sb., občanský zákoník, v sekci věnované smlouvě o dílo. Zhotovitel provádí dle § 2586 uvedeného zákona vývoj samostatně, na svůj náklad a nebezpečí. Nepočítá se s ingerencí objednatele, není-li tak ve smlouvě o dílo výslovně ujednáno.
Ve smlouvě je zcela nezbytné precizně specifikovat pouze předmět díla, specifikace ostatních práv a povinností může být i velice stručná, neboť se mohou využít defaultní, podpůrná zákonná ustanovení.
Tato metoda tak nachází své uplatnění, pokud objednatel ví, jaké vlastnosti má daný software mít, a nepotřebuje zadání následně upravovat. Výhodou postupu jsou zejména nižší nároky na objednatele, který po předání zadání již nemá jiné povinnosti než zaplatit zhotoviteli a převzít dílo, a dále lepší možnost rozvržení práce zhotovitele.
Úskalí metody waterfall se často projeví až v konečné fázi při předání hotového produktu. Teprve v této fázi může objednatel zjistit, že výsledek neodpovídá jeho představám. Často je na vině právě nedostatečné zadání a absence jeho následného vyspecifikování.
Oproti metodě waterfall se lze setkat s agilními metodami vývoje software, které mohou být považovány za protipól metody waterfall. Předmětem agilní smlouvy není zhotovení díla, ale nastavení samotného procesu, pravidel agilního procesu vývoje software, jehož přesnou specifikaci před zahájením vývoje nemají strany k dispozici.
Agilní metody se často využívají také v případech, kdy si zhotovitel není jistý tím, zda požadovaný výsledek je objektivně realizovatelný. Při využití klasických metod by zodpovídal za výsledek, v rámci agilních metod vývoje odpovídá jen za řádný průběh provádění vývoje.
Základní pravidla agility shrnuje dvanáct principů uvedených v Manifestu Agilního vývoje software, který byl vytvořen samotnými zástupci společností zabývajícími se vývojem softwaru. Agilní vývoj je postaven především na malých týmech, krátkodobých cílech, průběžném přezkumu plánu, flexibilitě, rozdělení vývoje do kratších časových úseků, průběžném testování, a zejména na spolupráci, která musí fungovat po celou dobu vývoje.
S jistou nadsázkou lze říci, že agilní vývoj stojí a padá právě se spoluprací mezi obchodními partnery, což klade určité nároky i na objednatele. Na rozdíl od smlouvy o dílo totiž podpisem agilní smlouvy spolupráce stran teprve začíná.
Základem pro zahájení agilního vývoje a stěžejní přílohou agilní smlouvy je vize objednatele, která obsahuje hrubé zadání pro výsledný software. Vize by měla být objednatelem vyjádřena co možná nejpodrobněji a není vyloučeno, aby při jejím sestavení objednateli asistoval i zhotovitel. Vize je významným dokumentem i proto, že se zohledňuje v případě sporů nebo při existenci více různých cest pokračování vývoje.
Na základě vize objednatele je na úvod spolupráce sestaven produktový backlog, který řadí jednotlivé požadavky objednatele dle priority společně s uvedením časové dotace potřebné k jejich vývoji.
V průběhu realizace projektu se představa zákazníka dotváří a zpřesňuje s každým dílčím výstupem. Aby bylo možné včas reagovat na změny a nedocházelo ke zbytečným nákladů, je třeba, aby objednatel se zhotovitelem na vývoji aktivně spolupracoval, a to na úrovni vývojového týmu a v pravidelných intervalech.
Objednatel by proto měl vyčlenit osobu, která za něj bude jednat, účastnit se pravidelných schůzek a činit rozhodnutí týkající se vývoje. Stejně tak zhotovitel bude mít za úkol vyčlenit tým z osob, které se na vývoji budou po celou dobu podílet.
Samotný vývoj probíhá v časových úsecích, nazývaných sprinty, o předem stanovené délce, nejčastěji okolo dvou týdnů. V jednotlivých sprintech dochází k vývoji částí řešení identifikovaných v produktovém backlogu, které pro daný sprint agilní tým určí. Sprinty mají pevný začátek i konec a nemělo by docházet k jejich prodlužování ani v případě, že vývoj určený pro daný sprint nebyl ukončen.
Agilní metoda také nemá jednu konkrétní podobu. Naopak, praxe vymezila hned několik způsobů, jak agilní vývoj pojmout. Uvést optimální nastavení procesů je proto v podstatě nemožné a strany by měly určit takové, které vyhovuje jejich představám i zadanému projektu.
Mezi nejvyužívanější patří metoda Scrum, eXtreme Programming, Kanban nebo DSDM, v praxi se však setkáváme i s různými modifikacemi a hybridními formami. Všechny však spojují stejné priority a cíle.
Při sestavování smlouvy o agilním vývoji se v prvé řadě musíme zabývat tím, kterou z metod hodlají strany při agilním vývoji využít. Doporučujeme přímo ve smlouvě detailně specifikovat, jak se má daná metoda při vývoji projevovat, a to i přes to, že strany budou povětšinou tato pravidla dobře znát. Vyhnou se tím však zbytečným sporům a zajistí, že i třetí osoba lehce pochopí, k jakým povinnostem se strany zavázaly.
Získejte pro svůj produkt či službu ocenění IT produkt roku! Soutěž „IT produkt roku“ vyhlašuje redakce Computerworldu s cílem vyzdvihnout výrobky disponující vlastnostmi, které je významně odlišují od konkurenčních produktů stejné kategorie. Může přitom jít jak o celkově inovativní pojetí produktu, tak o jednotlivé funkční zdokonalení, výrazně zjednodušené ovládání nebo třeba o výjimečně příznivou cenu.
Soutěž probíhá ve třech samostatných kolech v kalendářním roce a každý postupující produkt či služba do jednoho ze tří finálových kol získává právo na titul IT produkt roku.
Máte-li zájem účastnit se soutěže IT produkt roku, neváhejte. Kontaktujte nás prosím na itprodukt@iinfo.cz.
O přihlášku a více informací si můžete napsat nebo zavolat na telefonech 776 204 420 nebo 604 266 707 či 725 326 893, případně na také na adrese itprodukt@iinfo.cz.
To může hrát významnou roli, pokud by spory stran eskalovaly až k řešení soudem nebo rozhodčím orgánem. Rozhodně nelze očekávat, že soud bude pravidla agilního vývoje znát, a jelikož jednotný, ucelený seznam práv a povinností stran v rámci jednotlivých metod neexistuje, bude mít detailní specifikace uvedená ve smlouvě rozhodující význam pro vítězství v případném sporu.
Dalším bodem smlouvy o agilním vývoji je určení ceny. Zde je třeba mít na paměti, že ve smlouvě nemá místo pevná cena, může být určena pouze cena maximální, kterou je objednatel ochoten zaplatit. Pro platné ujednání o ceně je však třeba dle § 1792 občanského zákoníku ujednat alespoň způsob jejího určení.
Ve smlouvě se proto obvykle uvádějí hodinové sazby vývojářů jako základní předpoklad pro stanovení ceny, ke kterým přistupuje výkaz hodin dodaný v rámci jednotlivých sprintů. Cenu je samozřejmě možné ujednat i jinými způsoby, např. metodami využívanými u smlouvy o dílo – odhadem či rozpočtem, nicméně tento způsob rozhodně nepovažujeme za optimální.
Hlavní pozornost bude v agilní smlouvě směřována na agilní tým a jeho fungování. Strany by měly již při uzavírání smlouvy závazně určit, kdo bude členem týmu a jakou úlohu bude zastávat. Smlouva by měla obsahovat i mechanismy pro zachování týmu. Ve funkčním agilním týmu by nemělo docházet ke změnám pouze pro rozhodnutí jedné ze stran, naopak by smlouva měla jasně stanovit, kdy je možné člena týmu nahradit, aniž by se jednalo o porušení smlouvy.
Nastavení komunikace v rámci agilního týmu i smluvních stran je dalším nezbytným předpokladem funkční agilní smlouvy. Přes častou deklaraci stran, že si sami zajistí, že komunikace stran bude probíhat, vždy doporučujeme nastavit alespoň frekvenci setkávání a pravidelný program. To platí především pro meetingy před zahájením a po skončení sprintů. Bez této úpravy není možné vynucovat si (aktivní) účast druhé strany, což vede ke zbytečným prodlením nebo dokonce k neúspěchu vývoje.
Ve smlouvě by neměly být obsaženy ani sankční ujednání pro případ prodlení s vývojem a doporučuje se i omezit možnou odpovědnost zhotovitele. Také možnosti ukončení smlouvy před dosažením výsledku mají svá specifika. Strany by měly mít především možnost vývoj bez sankcí ukončit, ukáže-li se, že úspěšné dokončení vývoje řešení objektivně není možné.
Objednatel by měl mít ovšem možnost ukončit smlouvu i po ukončení každého úseku vývoje, neboť záleží především na něm, jakým směrem se bude vývoj dále ubírat. V takovém případě však doporučujeme do smlouvy včlenit možnost kompenzací pro zhotovitele, který již alokoval lidské zdroje na vývoj.
Nelze než doporučit, aby strany agilní smlouvy sjednaly práva a povinnosti v rámci spolupráce co možná nejdetailněji. Agilní vývoj totiž nemá žádný zákonný podklad, a proto v případě sporu nebo chybějící úpravy ve smlouvě není téměř nikdy možné využít podpůrná ustanovení právního řádu.
Autor je právníkem v advokátní kanceláři, Šetina, Komendová & Partners
Článek vyšel v magazínu Computerworld 4/2023. Pokud vás zaujal, zde si můžete objednat celé vydání.
Computerworld si můžete objednat i jako klasický časopis. Je jediným odborným měsíčníkem na českém a slovenském trhu zaměreným na profesionály v oblasti informačních a komunikačních technologií (ICT). Díky silnému zázemí přináší aktuální zpravodajství, analýzy, komentáře a přehledy nejnovejších technologií dříve a na vyšší odborné úrovni, než ostatní periodika na tuzemském trhu.
Obsah Computerworldu je určen odborníkům a manažerům z firem a institucí, kteří se podílejí na rozhodovacím procesu při nákupu ICT technologií. Jednotlivá čísla si můžete objednat i v digitální podobě.
Chcete si článek přečíst celý?
Tento článek je součástí exkluzivního obsahu pouze pro odběratele našeho newsletteru.
Přihlaste se k odběru newsletteru a my vám do mailu pošleme odkaz na celý článek.
PŘEDPLATNÉ
ČLÁNKY DO MAILU