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.

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