Agilní vývoj v praxi

Aktualizováno: srpen 2026

Od sepsání agilního manifestu uplynulo přes dvacet let a v IT se za tu dobu změnilo skoro všechno. Agilní vývoj přesto zůstává standardem, jen dnes vypadá jinak, než jak si ho lidé představují z učebnic Scrumu. Ukazujeme, jak agilní vývoj reálně funguje v agenturní praxi, kdy se vyplatí a jaké smlouvy k němu patří.

📋 TL;DR

• Agilní vývoj rozděluje projekt na krátké sprinty (typicky 2–3 týdny), na jejichž konci vzniká funkční, prezentovatelná verze aplikace.
• Podle Digital.ai State of Agile Report (2025) dnes 74 % týmů používá hybridní nebo vlastní upravenou verzi agilu, ne čistý učebnicový Scrum.
• Klíčovou roli hraje Product Owner – bez rozhodného člověka v této roli se agilní tým snadno zasekne v prioritizaci.
• Agilní vývoj přirozeně sedí ke smlouvě typu Time & Material, zatímco Fixed Time Fixed Price předpokládá předem daný rozsah.
• Agile není univerzální řešení: hodí se tam, kde zákazník nemá od začátku jasno ve všech detailech. Jasně zadaný projekt může klidně proběhnout klasickým waterfallem.

🕰️ Proč je agilní vývoj po 20 letech pořád relevantní

Když vyšel agilní manifest, byl rokem GTA III, prvního macOS X a Windows XP. Dvacet let je v IT nekonečno, a přesto se agilní přístup k vývoji softwaru nejenže neopustil, ale stal se převažujícím standardem. Podle poslední State of Agile zprávy od Digital.ai (18. edice, říjen 2025) dnes ale 74 % týmů nepoužívá agile v čisté, učebnicové podobě Scrumu, ale hybridní nebo vlastní upravenou variantu. Zpráva zároveň ukazuje, že roste tlak měřit agilní vývoj byznysovými výsledky, ne jen rychlostí dodávek: 76 % respondentů hlásí zvýšenou kontrolu nad tím, jaký má agilní přístup skutečný dopad na byznys.

To odpovídá i naší zkušenosti z agenturního vývoje: agile dnes není ideologie, kterou je potřeba dodržovat do písmene, ale sada principů, které se přizpůsobují konkrétnímu projektu a zákazníkovi.

Marek Elznic, autor tohoto článku, to v rozhovoru pro Ackee blog shrnul takto:

🔄 Jak funguje agilní vývoj v praxi

V Ackee používáme metodiku Scrum, kterou jsme přizpůsobili agenturnímu vývoji aplikací. Projekt se rozdělí do kratších časových úseků, kterým se říká sprinty nebo iterace – typicky na dva až tři týdny dopředu.

Před začátkem každého sprintu se tým sejde se zákazníkem na sprint planningu a společně se domluví, co bude jeho náplní. Tahle náplň by se už během sprintu neměla měnit; všechny nové požadavky a změny, které se do aktuálního sprintu nevejdou, míří do backlogu, kam se průběžně sbírají všechny budoucí úkoly.

V rámci jednoho sprintu proběhne krátká technická analýza, návrh UI/UX, samotný vývoj a testování. Výstupem je funkční verze aplikace, kterou lze rovnou prezentovat – v tomhle se agilní vývoj zásadně liší od klasického waterfall modelu, kde na sebe fáze navazují postupně napříč celým projektem: nejdřív kompletní analýza, pak kompletní design, pak teprve vývoj.

Základem celého přístupu je úzká spolupráce se zákazníkem a pravidelná komunikace. Zákazník se stává součástí procesu vývoje a průběžně dostává produkt, na kterém se sám podílí rozhodováním. Díky tomu je možné rychleji reagovat na změny a šetřit čas i peníze, místo aby se nesrovnalosti odhalily až na konci dlouhého vývojového cyklu.

Scrum se sprinty není jediná agilní metodika. Tam, kde práce přichází průběžně a nedává smysl ji násilně cpát do dvoutýdenních bloků (typicky údržba, podpora nebo menší kontinuální vylepšování), se často víc hodí Kanban: místo pevných sprintů pracuje s průběžným tokem úkolů a limitem na to, kolik věcí může být rozpracovaných najednou.

Chcete probrat, jestli se pro váš projekt hodí agilní vývoj, nebo waterfall? Domluvte si konzultaci a projdeme si ho spolu.

⚖️ Agile, nebo waterfall?

Ani jeden přístup není univerzálně lepší, jde spíš o to, kdy se který vyplatí. Agile dává smysl tam, kde zákazník nemá od začátku jasno v každém detailu, počítá s tím, že se zadání bude v průběhu projektu upřesňovat, a hlavně je ochotný se do vývoje pravidelně zapojovat. Waterfall naopak funguje dobře tam, kde je zadání od začátku pevně dané a nemění se, kde má zákazník spíš omezenou kapacitu na průběžnou komunikaci, nebo kde regulatorní či smluvní podmínky vyžadují přesně daný rozsah předem. V praxi jde často i o kombinaci: úvodní analýza a návrh proběhnou waterfallem, samotný vývoj pak agilně po sprintech.

👤 Product Owner: role, bez které se agile rozpadá

Nejdůležitější osobou na straně zákazníka je Product Owner, tedy člověk, který dělá produktová rozhodnutí. Jeho úkolem je komunikovat s týmem na denní bázi, účastnit se sprint planningů, mít o vývoji přehled a hlavně rozhodovat, co je pro produkt aktuálně důležité a co může počkat v backlogu.

Jeden z principů agilního manifestu říká, že změny v požadavcích jsou vždycky vítány – a to je v pořádku, svět i produkt se přece jen vyvíjí. Jenže právě tady hraje Product Owner klíčovou roli: musí umět rychle rozhodnout, co je skutečně důležitá funkcionalita a co jen drobné vylepšení. Bez rozhodného Product Ownera hrozí, že se tým bude sprint po sprintu posouvat bez jasného cíle, a na konci nezbyde ani hotový produkt, ani rozpočet. Roli Product Ownera v kontrolování rozpočtu jsme podrobněji rozebrali v článku o tom, jak ušetřit na vývoji aplikace.

📜 Trochu právničiny: FTFP, nebo Time & Material

V Ackee pro vývoj softwaru využíváme dva typy smluv: Fixed Time Fixed Price (FTFP) a Time & Material (T&M).

U FTFP smlouva definuje konkrétní dílo, které má vzniknout, dodané za pevně stanovenou cenu a v pevně stanoveném čase. Z právního pohledu jde o Smlouvu o dílo, kterou podle § 2586 odst. 1 zákona č. 89/2012 Sb. (občanský zákoník) „se zhotovitel zavazuje provést na svůj náklad a nebezpečí pro objednatele dílo a objednatel se zavazuje dílo převzít a zaplatit cenu.“

Time & Material naopak vyžaduje rámcovou smlouvu o poskytování služeb. Taková smlouva nedefinuje žádné konkrétní dílo, ale pouze služby, které bude dodavatel zákazníkovi poskytovat – například design, programování nebo testování. Jednotlivé služby se objednávají průběžně, typicky po každém sprint planningu.

Kombinace Time & Material a agilního vývoje proto dává smysl: obojí počítá s tím, že se rozsah práce upřesňuje za pochodu, ne že je fixovaný na začátku.

🤔 Kdy zvolit agile, a kdy ne

Agilní metodiky jsou skvělé pro rychlý vývoj softwaru, který se v čase mění. Nejsou ale univerzálně aplikovatelné na všechny projekty a všechny zákazníky. Klasická odpověď zní: pokud přesně nevíte, co chcete, volte agile. Pokud jste zákazník, vyberte si agenturu, která má zkušenosti s oběma přístupy a poradí vám, který je pro váš projekt vhodnější.

Pokud na agilní projekt nemáte čas ani zápal, promyslete si zadání společně předem: zanalyzujte požadavky, navrhněte řešení a otestujte ho. Jakmile máte v ruce takhle připravené zadání, není nic špatného na tom postupovat klidně waterfallem – ani přes dvacet let po vydání agilního manifestu.

❓ FAQ

Co přesně je sprint?

Sprint je časově ohraničený úsek vývoje, typicky dva až tři týdny, na jehož konci vznikne funkční a prezentovatelná verze aplikace. Náplň sprintu se domlouvá předem na sprint planningu a v jeho průběhu by se neměla měnit.

Čím se agilní vývoj liší od waterfallu?

Waterfall postupuje fázemi napříč celým projektem najednou (nejdřív kompletní analýza, pak design, pak vývoj), zatímco agile prochází celým cyklem analýza-design-vývoj-test v každém krátkém sprintu zvlášť.

Proč je Product Owner tak důležitý?

Protože je to jediná osoba, která má mandát rychle rozhodovat, co se do produktu dostane a co ne. Bez ní se tým buď zasekne na čekání, nebo naopak přijímá každý nápad, což vede k rozmělnění rozsahu i rozpočtu.

Jaký je rozdíl mezi FTFP a Time & Material?

FTFP definuje předem přesné dílo za pevnou cenu a v pevném čase (právně Smlouva o dílo). Time & Material naopak platí za odvedené služby průběžně, bez předem fixovaného rozsahu (právně rámcová smlouva o poskytování služeb). Agilní vývoj přirozeněji sedí k Time & Material.

Můžu kombinovat agile s pevným rozpočtem?

Částečně ano – lze si stanovit orientační rozpočet nebo strop, ale čistý FTFP model s pevně daným rozsahem se s podstatou agilu, tedy průběžně se měnícím zadáním, kříží. Kompromisem bývá fixní rozpočet na omezený počet sprintů s tím, že přesný rozsah se dolaďuje za pochodu. Základní přehled, kolik vývoj aplikace obvykle stojí, najdete v samostatném článku.

Je Scrum jediná agilní metodika?

Ne, je jen nejrozšířenější. Kanban je další běžně používaná metodika, která na rozdíl od Scrumu nepracuje s pevnými sprinty, ale s průběžným tokem úkolů. Podle Digital.ai dnes navíc většina týmů (74 %) používá spíš hybridní kombinaci přístupů než jednu metodiku v čisté podobě.

Co když na straně zákazníka není nikdo, kdo by mohl dělat Product Ownera?

Pak je otázka, jestli je agile pro daný projekt vůbec vhodná volba – bez zapojeného zástupce zákazníka agilní proces ztrácí smysl. V takovém případě může být lepší volbou dobře připravený waterfall projekt s detailním zadáním předem.

Vyplatí se agile i pro malé projekty?

Ano, pokud i malý projekt počítá se změnami zadání v průběhu. U jednoduchých, jasně definovaných projektů bez očekávaných změn ale agilní režie (sprint planningy, průběžná komunikace) nemusí přinášet dostatečnou hodnotu navíc oproti klasickému postupu.

🎯 Co si odnést

Agilní vývoj po dvaceti letech neztrácí na relevanci, jen se proměnil: dnes ho většina týmů používá v hybridní, na míru upravené podobě, ne podle učebnice. Funguje nejlépe tam, kde zákazník nemá od začátku jasno v každém detailu a je ochotný se pravidelně zapojovat přes Product Ownera. Pokud tahle podmínka splněná není, není nic špatného na tom zvolit dobře připravený waterfall. A ať zvolíte kterýkoli přístup, typ smlouvy by měl odpovídat tomu, jak se bude rozsah projektu v čase měnit.

Podobné postřehy z agenturního vývoje najdete v newsletteru Ackee – přihlaste se a příští obsah vám přijde přímo do schránky.