Waterfall vs. Agile: Klíčové rozdíly a vhodnost použití

Co je Waterfall model?

Waterfall byl první formální metodou vývoje softwaru, která byla představena v roce 1970. Myšlenka předvídatelného a sekvenčního vývoje pochází z inženýrství a stavebnictví. Model Waterfall se stal velmi populárním zejména ve vojenských a leteckých projektech, protože byl považován za předvídatelný, kontrolovatelný a dobře zdokumentovaný. Jeho největší nevýhodou je však nízká flexibilita.

Podle Sommervilla (2015) jde o sekvenční proces, ve kterém projekt postupuje přes jednotlivé fáze – analýzu požadavků, návrh, implementaci, testování a údržbu. Každá fáze musí být dokončena, než může začít ta následující.Tento přístup umožňuje detailní plánování a kontrolu, ale zároveň omezuje flexibilitu při změnách požadavků.

Model Waterfall je proto považován za základní rámec pro pozdější vývojové metodologie.

Naše zkušenosti s metodologií Waterfall ve vývoji Softwaru

Ve společnosti Moravio jsme dříve používali metodologii Waterfall pro řízení našich projektů. Tento přístup nám připadal přirozený, protože je snadno pochopitelný a široce používaný v různých odvětvích.
Na začátku projektu jsme shromáždili všechny vstupy od klienta, které sloužily jako základ pro celý vývoj. Jakékoliv změny nebo odchylky jsme nejprve řešili jako dodatky ke smlouvám, než byly implementovány do kódu.
Na základě dohodnutých požadavků jsme stanovili pevnou cenu projektu. Abychom zajistili efektivní řízení, rozdělili jsme projekt do několika fází, přičemž klient platil po dokončení každé z nich.

1. Fáze: Sběr a analýza požadavků

Na začátku jsme provedli důkladnou analýzu vstupů od zákazníka, jeho obchodních cílů, procesů a marketingové strategie. Dále jsme určili funkční a nefunkční požadavky a podporovaná zařízení.
Tato analýza nám umožnila vytvořit detailní projektovou dokumentaci, která popisovala navrhované řešení, a někdy zahrnovala i wireframy. Na dokumentaci navazuje technická analýza, která popisuje navrhovanou architekturu, použité technologie a databázovou strukturu. Jakmile byly požadavky schváleny, naplánujeme technické úkoly, připravíme rozpočet a stanovíme očekávané náklady na implementaci.

2. Fáze návrhu

Jde o tvorbu grafického návrhu řešení. Zákazníkovi jsme poskytli dvě až tři kola na zpětnou vazbu a úpravy, než jsme se shodli na finální verzi designu.

3. Fáze implementace

Jakmile byl design schválen, začala implementace naplánovaných úkolů. Během této fáze klient pravidelně dostával informace o postupu projektu a na konci obdržel finální produkt. Jakékoliv nové požadavky vznesené v průběhu vývoje byly považovány za dodatečné práce, které musí být odhadnuty a schváleny zákazníkem před realizací.

4. Fáze testování

Finální funkční produkt byl nasazen do testovacího prostředí a předán zákazníkovi k důkladnému otestování. Klient měl obvykle předem dohodnuté období, během kterého testování probíhá. Po jeho ukončení poskytl zpětnou vazbu a podepsal předávací protokol.

5. Fáze Nasazení

Jakmile byl produkt schválen, byl “nasazen” do produkčního prostředí v souladu s dohodou uzavřenou se zákazníkem.

6. Fáze Údržba

Po předání hotového produktu zákazníkovi jsme obvykle uzavřeli “servisní smlouvu” (SLA) a zajišťovali dlouhodobou podporu software po stanovené období. Pokud by zákazník chtěl spolupráci ukončit v jakékoliv fázi projektu, bylo nutné se vzájemně dohodnout na podmínkách zrušení objednávky a vypovězení smlouvy.

Náš pohled na Waterfall

Neříkáme, že tento přístup je zcela špatný — může být vhodný pro menší projekty nebo pro případy, kdy se vytváří typově stejný software pro více zákazníků. To ale není to, co obvykle děláme.
V Moravio vyvíjíme na míru šitý software pro naše klienty. Na základě předchozích zkušeností dokážeme poskytnout orientační odhady, avšak čím je projekt složitější nebo rozsáhlejší, tím obtížnější je přesně specifikovat všechny detaily již na začátku – a to jak z naší strany, tak i ze strany zákazníka.

Během vývoje se někdy stane, že se na straně klienta změní odpovědná osoba nebo vnitrofiremní procesy. Nebo že když zákazník poprvé uvidí vyvinutou funkci nebo grafiku, zjistí, že potřebuje fungovat jinak – nebo že se musí upravit kvůli změnám v chování uživatelů či na trhu.

Všechny tyto faktory vedou ke změnám požadavků u již vyvíjeného produktu. Výsledkem často býválo, že zákazník nebyl plně spokojen, protože původní požadavky neodrážely skutečné potřeby, a my jsme také nebyli spokojeni, protože rostly náklady projektu a bylo nutné složitě vyjednávat o dodatečných zdrojích.

Omezení, která ve Waterfall přístupu vnímáme:

• Problémy s požadavky se často objevují až v pozdějších fázích – během návrhu, implementace nebo testování.
• Během vývoje se často objevují nové informace, které musí být zapracovány do dokumentace i implementace.
• Další fáze nemůže začít, dokud není dokončena ta předchozí, což způsobuje prodlevy a prodloužení projektu.
• Každá změna musí být schválena oběma stranami a přidána do smlouvy před implementací.
• Testování uživateli probíhá až po dokončení celého systému – chyby a nedostatky se tak odhalí pozdě a jejich oprava je velmi nákladná.
• Nové funkce často vznikají až po testování, což vyžaduje další vývoj.
• Vyšší riziko neúspěchu u složitějších či dynamických projektů.
• Nízká úroveň zapojení zákazníka během vývoje.
• Požadavky se mohou měnit v důsledku změn na trhu nebo v chování koncových uživatelů.
• Původní zadání nemusí odpovídat skutečným potřebám.
• Rostoucí náklady mohou způsobit problémy jak klientovi, tak dodavateli.

Výhody modelu Waterfall, které vnímáme:

• Náklady, čas a zdroje jsou předem jasně definované.
• Každá fáze má konkrétní cíle, výstupy a schvalovací kritéria.
• Všechny požadavky jsou zdokumentovány a schváleny oběma stranami.
• Snadnější sledování průběhu projektu, čerpání rozpočtu a dodržování harmonogramu.
• Jasně rozdělené odpovědnosti mezi všechny zúčastněné strany.

Kde je Waterfall vhodný?

• Systémy s jasně definovanými požadavky, které se v průběhu času nemění (např. ERP moduly, účetní systémy, bankovní software).
• Systémy podléhající legislativním nebo regulatorním omezením (např. systémy pro sledování léčiv nebo účetní software splňující zákonné požadavky).
• Projekty s pevně stanoveným rozsahem, časem a rozpočtem – často vládní zakázky.
• Projekty vyžadující detailní dokumentaci a formální schvalovací procesy (např. letecký, farmaceutický nebo vojenský průmysl).
• Systémy využívající známé technologie (např. migrace databází nebo přepis starších aplikací na novou platformu bez změny funkcionality).
• Situace, kdy zainteresované strany vyžadují jasný plán, reportování a přísnou kontrolu průběhu projektu.

Co je Agile vývoj softwaru?

Agile je iterativní a inkrementální přístup k vývoji softwaru, který klade důraz na flexibilitu, spolupráci a zpětnou vazbu zákazníka. Vznikl na počátku 90. let 20. století.
Nejpoužívanějším rámcem, který implementuje principy Agile Manifestu, je Scrum.

Na rozdíl od Waterfall přístupu, který postupuje sekvenčně, Agile rozděluje práci do krátkých, snadno řízených iterací nazývaných sprinty.
Každý sprint přináší funkční část produktu, což umožňuje týmům rychle reagovat na změny požadavků a průběžně zlepšovat kvalitu prostřednictvím pravidelného hodnocení a zpětné vazby.

Agile staví na těchto hodnotách:

• Jednotlivci a interakce před procesy a nástroji,
• Funkční software před rozsáhlou dokumentací,
• Spolupráce se zákazníkem před smluvním vyjednáváním,
• Reakce na změnu před striktním dodržováním plánu.

(Beck et al., 2001; Sommerville, 2015)

Další známé Agile frameworky

• Kanban 
• Lean Development
• Extreme programing
• Dynamic Systems Development Method
• Feature Driven Development
• Crystal

Jak jsme začali s agilním vývojem?

Hybridní přístup mezi Waterfall a Agile

Na začátku jsme používali kombinaci přístupů Agile a Waterfall – tedy hybridní metodologii.

Zákazníci tehdy nebyli s Agile přístupem příliš obeznámeni a často mu zpočátku nedůvěřovali, proto jsme zvolili kompromisní model.

Dohodli jsme se na pevně stanoveném harmonogramu a orientačním rozpočtu založeném na specifikovaných požadavcích.

Hlavní rozdíl oproti předchozímu Waterfall přístupu spočíval v úzké spolupráci s klienty, která je klíčovým principem Agile.

Rozdělili jsme dodávky do sprintů, každé dva týdny jsme klientovi prezentovali výsledky a současně jsme pracovali na upřesňování požadavků alespoň o jeden sprint dopředu.
Spolupráce i spokojenost klientů s finálním produktem se výrazně zlepšily. Nicméně během projektu backlog často narůstal, což vedlo k prodloužení harmonogramu.
Nevýhodou tohoto modelu byla i značná časová náročnost na reportování a obhajování každé dodatečně odpracované hodiny.
Stále to nebylo win-win partnerství, kterého jsme chtěli dosáhnout.

Postupem času jsme si uvědomili, že naše další projekty musí být plně agilní.Upravili jsme smlouvy a s rostoucí popularitou metodologie Agile mezi klienty se její přínosy staly všeobecně známé a akceptované

Proč Agile?

Ve společnosti Moravio klademe důraz na otevřenost a transparentnost při zahájení každého projektu. Místo slibování pevných termínů a cen poskytujeme orientační odhady založené na počátečních nápadech nebo specifikacích.

Následně úzce spolupracujeme s klientem, abychom upřesnili požadavky koncových uživatelů a přizpůsobili rozsah projektu tak, aby odpovídal dostupnému rozpočtu.

• Věříme, že jasná komunikace a spolupráce s klientem jsou klíčové pro úspěšné projekty.
• Naším cílem je vždy dosáhnout nejlepšího možného výsledku pro klienta.
• Chápeme, že požadavky se v průběhu času mohou měnit, a proto jsme připraveni se těmto změnám přizpůsobit.
  Díky průběžnému zpřesňování požadavků a úpravám rozsahu projektu dokážeme dodat kvalitní řešení, které naplňuje potřeby klienta i uživatelů a zároveň zůstává v rozumném rozpočtu.

Naším hlavním záměrem je

Usilujeme o to, abychom našim klientům poskytovali špičkovou kvalitu ve všem, co děláme.Opíráme se o naše zkušenosti, odborné znalosti a neochvějný závazek ke kvalitě v každém sprintu.

Věříme, že díky úzké spolupráci s klienty a neustálému zdokonalování požadavků dokážeme dodat výsledky, které odpovídají jejich očekáváním.

Zároveň dbáme na to, aby naši klienti měli plnou kontrolu nad svými projekty a byli svobodní ve své volbě — pokud by kdykoliv nebyli spokojeni s našimi službami, mohou dle dohodnuté výpovědní lhůty zvolit jiného poskytovatele.
Náš úspěch jako softwarové společnosti totiž závisí především na spokojenosti klientů, a proto se snažíme, aby každý projekt skončil úspěchem pro obě strany.

Agile metodologie v naší praxi

Z agilních frameworků používáme především Scrum, i když u některých projektů aplikujeme i Kanban.Nejčastěji pracujeme v krátkých dvoutýdenních iteracích (sprintech), na jejichž konci prezentujeme výsledky zákazníkovi, diskutujeme o nich a podle zpětné vazby je dále upravujeme.Shromážděné podněty převádíme do konkrétních úkolů a následně je společně s klientem prioritizujeme.

Pokud klient potřebuje náhle změnit směr, není to problém — v Agile přístupu nejsme svázáni pevnými smlouvami ani rigidními procesy.
Stačí s klientem vyjasnit nové požadavky a změny naplánovat do následujícího sprintu.

Výhody agilního vývoje

• Flexibilita a rychlá schopnost reagovat na měnící se požadavky.
• Rychlá zpětná vazba od stakeholderů po každém sprintu.
• Jasný přehled o postupu pro tým i zákazníka.
• Vyšší zapojení celého týmu.
• Vyšší kvalita výsledného produktu díky častému testování implementovaných částí.

Možné úskalí Agile

• Riziko rozšiřování rozsahu projektu (scope creep) — priority se mohou měnit s každým sprintem.
• Vyžaduje zkušené, samoorganizované a mezioborové týmy.
• Méně efektivní u projektů s pevně stanoveným rozsahem nebo při koordinaci více týmů současně.
• Méně předvídatelné náklady a harmonogram — flexibilita může ztížit přesný odhad ceny a termínu dodání na začátku projektu.

Souhrn rozdílu mezi Waterfall a Agile Metodologií

Proč preferujeme právě Agilní řešení?

• Protože nám záleží na tom, co vyvíjíme, záleží nám i na kvalitě výsledného produktu.
• Upřednostňujeme úzkou spolupráci s klienty a společné vytváření funkčních a smysluplných řešení před nekonečným vyjednáváním o každé minutě práce.
• Ceníme si agility a flexibility více než slepého následování původních plánů.

Nástroje, které používáme

• Jira - snadno použitelný nástroj s přehlednými tabulemi vhodný pro všechny typy projektů. 
• Product Discovery od Atlassianu - intuitivní a snadno propojitelný s vývojovými tabulemi.
• Trello – používali jsme pro menší projekty.‍
• Gitlab - v některých případech jsme použili jako nástroj poskytovaný zákazníkem pro správu konkrétního projektu.

Obecně dáváme přednost nástrojům, které dobře známe, ale dokážeme se přizpůsobit i těm, které preferuje zákazník

Jiné metodologie používané pro vývoj software 

Podle 17. vydání zprávy o stavu Agile od Digital AI (2023) používá 71 % dotázaných firem metodologii Agile v rámci životního cyklu vývoje softwaru.

Nicméně stále existují i jiné metodologie, které se v praxi využívají:

• V-model
• Rapid Application Development (RAD)
• Spiral model
• Incremental model

Jak AI mění vývojové metodologie?

Umělá inteligence (AI) výrazně ovlivňuje, oba metodologické přístupy. AI proměňuje způsob, jakým týmy shromažďují a spravují projektové požadavky. Umožňuje snadnější shrnutí a analýzu dat a také automatické generování dokumentace
(vývoj řízený specifikacemi).

AI zároveň hraje stále větší roli v návrhu aplikací — například umí automaticky generovat wireframy z textových zadání, čímž zpřístupňuje návrhové procesy i lidem bez zkušeností s designem. Dokáže dokonce vytvořit jednoduché funkční aplikace přímo z dokumentace.

V různých rolích pomáhá AI týmům být konzistentnější, efektivnější a produktivnější. Umí generovat vývojové úkoly z dokumentace, navrhovat konkrétní implementace kódu a asistovat při automatizovaném testování a validaci reálných aplikací.

Z metodologického pohledu pomáhá AI odstranit některá tradiční omezení Waterfall přístupu — zejména v oblasti sběru požadavků a tvorby dokumentace. Tyto procesy se díky ní stávají rychlejši a flexibilnější. Ačkoli smluvní a procesní omezení stále existují, jejich dopad dnes výrazně závisí na kvalitní komunikaci a spolupráci s klienty.

Stejně jako každý nástroj může být ale i AI nesprávně používána. Roste riziko, že lidé se začnou na technologie příliš spoléhat a přestanou kriticky přemýšlet o tom, co dělají. Například mohou automaticky generovat velké objemy požadavků či kódu, které jsou zbytečné, nejasné nebo neodpovídají skutečným potřebám projektu – jen proto, aby měli zadání, které vypadá dobře a dle metodologie.

Podobně, pokud nejsou AI-generované návrhy správně zkontrolovány, mohou vést k nedorozuměním mezi designéry, vývojáři a klienty. To pak způsobuje komunikační šumy, nesrovnalosti a dodatečnou práci později v procesu. Totéž platí i pro automaticky generovaný kód – pokud je zbytečně složitý nebo nepřehledný, může vytvářet úzká hrdla a komplikace při vývoji. To, že něco lze snadno automaticky vytvořit, ještě neznamená, že by se to mělo dělat.

AI by měla podporovat kreativitu, efektivitu a porozumění, nikoliv je nahrazovat. Je nezbytné zachovat lidský dohled, kritické myšlení a spolupráci, aby AI zůstala užitečným pomocníkem – ne nekontrolovaným rozhodovacím nástrojem.

Jakou vidíme budoucnost v softwarovém vývoji?

Ve společnosti Moravio netrváme nutně na Agile nebo Waterfallu. Volba metodologie vždy závisí na typu projektu, potřebách a očekávání klienta. Oba přístupy mohou vést k vynikajícím výsledkům — nebo k problémům — podle okolností.

To, na čem skutečně záleží, je spolupráce a jasná komunikace. Když má klient jasnou představu o tom, co chce vytvořit, nebo je otevřený tuto představu s námi společně rozvíjet, celý proces probíhá plynule bez ohledu na zvolenou metodologii.

Na konci dne — stejně jako ve většině věcí v životě — úspěch závisí na lidech: na otevřené komunikaci, vzájemné důvěře a kvalitě partnerství.

Zdroje: 

Somerville (2015), Software Engineering, 10th GLO https://dn790001.ca.archive.org/0/items/bme-vik-konyvek/Software%20Engineering%20-%20Ian%20Sommerville.pdf 

Agile frameworks: https://www.wrike.com/agile-guide/faq/what-is-fdd-in-agile/

Metodologie softwarového vývoje: https://www.itransition.com/software-development/methodologies