Agilní vývoj vs. waterfall: 7 otázek, které rozhodnou o vašem projektu

01Agile a waterfall: co se při vývoji skutečně liší

Waterfall, česky vodopádový model, organizuje práci do navazujících fází: požadavky, návrh, realizace, ověření a předání. Tým nejprve podrobněji vymezí, co vznikne, a podle toho plánuje další práci. U postupu se schvalovacími milníky se před pokračováním kontrolují dohodnuté výstupy. Vodopádový model a řízení pomocí milníků spolu souvisejí, ale nejsou totožné.

Agilní vývoj pracuje v kratších cyklech. Tým průběžně ověřuje výsledek, získává zpětnou vazbu a upravuje pořadí práce. Agilní manifest upřednostňuje spolupráci, fungující software a schopnost reagovat na změny. Výslovně přitom uznává hodnotu procesů, dokumentace, smluv i plánů. Agilní projekt tedy potřebuje jasný cíl a pravidla rozhodování.

Dvanáct principů agilního vývoje zdůrazňuje průběžné dodávání užitečného softwaru, spolupráci zadavatele s vývojáři a pravidelné zlepšování práce. Pro firmu z toho plyne praktický požadavek: někdo musí mít čas výsledek kontrolovat a pravomoc rozhodnout, co má následovat.

Scrum je konkrétní rámec pro práci na komplexních problémech. Agile je širší pojem. Podle oficiálního Scrum Guide z roku 2020 trvá sprint nejvýše měsíc a má vlastní cíl i plán. Použitelný přírůstek může být uvolněn i před jeho koncem. Konec sprintu sám o sobě neurčuje termín nasazení do ostrého provozu.

02Srovnání agile a waterfallu z pohledu zadavatele

Z tabulky nevyplývá, že agile je vždy rychlejší nebo waterfall vždy levnější. Rozhoduje velikost neznámých, dostupnost lidí, kvalita zadání a způsob kontroly. Průběžné schůzky bez rozhodnutí projekt neposunou. Stejně tak podpis specifikace nezaručí, že všichni její obsah chápou stejně.

03Kdy dává větší smysl agilní vývoj a kdy pevné fáze

Agilní postup pro potřeby, které teprve ověřujete

Vyvíjíte nový zákaznický portál, aplikaci pro obchodníky nebo službu, kterou lidé ještě nepoužívali. Víte, jaký problém chcete vyřešit, ale nemáte jistotu, jak má vypadat ovládání a které funkce budou potřebné nejdřív. Zvolte menší funkční části a pravidelné zkoušení. U nového produktu začněte také ověřením zájmu a výběrem rozsahu MVP, aby první verze nestála na pouhých domněnkách.

Pevné fáze pro známý výstup a pevné návaznosti

Nahrazujete přesně popsaný export, přenášíte dohodnutou datovou sadu nebo napojujete aplikaci na rozhraní s určeným formátem. Výstup lze porovnat s konkrétními pravidly a práce více dodavatelů na sebe navazuje. Podrobnější specifikace, schvalovací milníky a řízení změn zde mohou pomoct. Ani tady nemusíte čekat s technickým ověřením až na hotovou aplikaci.

Princip rozhodovacích bran popisuje například Systems Engineering Handbook NASA: přechod mezi fázemi závisí na posouzení připravenosti. Není to návod, že firemní software má kopírovat kosmický projekt. Použitelná je myšlenka, že před nákladným dalším krokem musíte vědět, co bylo ověřeno a co ještě chybí.

Nedostupný zadavatel nezachrání žádná metodika

Jestli vedení nemá čas na rozhodnutí, nejprve určete zástupce s potřebnou pravomocí. Agilní tým bez odpovědí čeká nebo hádá. U pevného zadání se stejný problém může projevit později při převzetí. Do plánu patří také čas účetní, správce IT, obchodníků a lidí, kteří budou systém zkoušet.

04Sedm otázek před výběrem způsobu vývoje

1. Co víme a co zatím jen předpokládáme?

Oddělte známá pravidla od neověřených potřeb. „Doklad musí obsahovat tato pole“ je jiné zadání než „zákazníci si chtějí objednávat sami“. U druhého potřebujete zkoušení a rozhovory. Každé významné neznámé přiřaďte způsob ověření ještě před odhadem celé aplikace.

2. Co musí být pevné: termín, rozpočet, nebo rozsah?

Pokud máte pevné datum spuštění a rozpočet, určete minimální použitelnou verzi a volitelné funkce. Když je pevný celý rozsah, změny nebo nové poznatky mohou ovlivnit cenu či termín. Zapište, kterou veličinu lze upravit a kdo o tom rozhoduje.

3. Kdo bude rozhodovat za firmu?

Určete člověka, který vyřeší střet požadavků oddělení, schválí priority a zajistí odpověď v dohodnuté lhůtě. Nemusí být programátor. Musí rozumět provozu a vědět, kdy přizvat účetní nebo správce systému. Nevyřešené požadavky pěti vedoucích nejsou plán práce.

4. Kdy se k výsledku dostanou skuteční uživatelé?

Domluvte konkrétní kalendář. Například každé dva týdny obchodník vyzkouší rozpracovanou cestu od poptávky k nabídce. Sledujte, co zvládne, kde potřebuje vysvětlení a co musí dělat mimo systém. Prezentace vedení nenahradí práci člověka u jeho běžné zakázky.

5. Na čem závisí další dodavatelé a systémy?

Zjistěte dostupnost testovacího prostředí, přístupů, rozhraní a lidí na druhé straně. U propojení systémů přes API vymezte formát dat, odpovědnost za jejich správnost a obsluhu chyb. Neznámou dostupnost cizího systému ověřte dřív, než na ní postavíte termín.

6. Podle čeho poznáme, že je část hotová?

Popište běžný případ, výjimku a očekávaný výsledek. Například opakované odeslání objednávky nesmí vytvořit druhý doklad a uživatel bez oprávnění nesmí vidět cizí zakázku. Domluvte, kdo výsledek zkouší, kdo jej přebírá a jak se evidují vady.

7. Kolik stojí pozdní změna nebo chybný přechod?

Úprava textu tlačítka potřebuje jinou přípravu než změna identifikátorů zákazníků po migraci. U dat, oprávnění a provozních návazností věnujte víc práce návrhu a kontrolám předem. U vratných úprav rozhraní si nechte prostor pro pokusy. Závažnost dopadu je důležitější než počet obrazovek.

05Pevná cena a agile: na čem se musíte dohodnout

Způsob vývoje a způsob účtování jsou dvě různá rozhodnutí. I zakázku s pevnou cenou můžete zpracovávat po menších částech a průběžně zkoušet. Musí však být jasné, za jaký výsledek cena platí, co nabídka předpokládá a jak se posoudí změna. Slovo „agile“ samo o sobě neopravňuje dodavatele přidávat náklady.

Rozlišujte pevnou cenu za vymezený rozsah a pevný rozpočet na práci s průběžně volenými prioritami. U druhé možnosti se zavazujete k limitu výdajů, ale seznam všech budoucích funkcí není slíbeným výstupem. Povinné jádro, očekávané výstupy jednotlivých etap a hranice dalších objednávek přesto potřebují konkrétní popis.

• Rozsah první verze: co musí umět, co je volitelné a co je výslovně mimo zakázku.
• Převzetí: ověřitelné podmínky, testovací scénáře, odpovědnost za kontrolu a postup u vad.
• Změny: popis požadavku, dopad na cenu, termín a návaznosti, schválení před zahájením práce.
• Čerpání rozpočtu: pravidelný přehled hotové práce, výdajů a aktualizovaný odhad zbytku.
• Předání a provoz: zdrojový kód, přístupy, dokumentace, data, nasazení a následná podpora.

Chce obchod nové filtrování, zatímco blíží se termín? Můžete odložit jinou volitelnou funkci. Ne každá výměna má stejnou pracnost, proto dopad posoudí tým. Pokud je požadavek navíc a nic jiného neustoupí, potřebujete schválit navýšení nebo další etapu. U pevného termínu naplánujte i rezervu na ověřování a závislosti.

06Hybrid v praxi: pevné propojení, postupně ověřované ovládání

Vezměme modelovou českou firmu, která nahrazuje staré CRM a chce přenášet schválené objednávky do účetnictví. Účetní pravidla, identifikátory a vazby mezi záznamy potřebují přesný popis. Obrazovku pro obchodníka má smysl zkoušet postupně: možná potřebuje vyhledávání podle telefonu, možná seznam zakázek čekajících na reakci.

Pevně navrhněte datové rozhraní, oprávnění a pravidla přenosu. U každé integrace, například s POHODOU, ověřte možnosti konkrétní instalace a dostupnost testovacích dat. Rozhraní pro lidi potom upravujte v kratších cyklech. Obě části musí mít společný plán, jinak se hezká obrazovka odpojí od reálných údajů.

Přenos starých dat připravujte souběžně. Migrace dat z Excelu a starého systému potřebuje kontrolu duplicit, vazeb, obsahu i návratu při neúspěšném přechodu. Odhalení chyb v datech může změnit další práci bez ohledu na metodiku.

Hybrid funguje, když je jasné, které rozhodnutí už ostatní části používají. Změna datového formátu pak projde posouzením dopadu; úprava pořadí polí může vzniknout po zkoušení. Kombinace nesmí znamenat dvojí schvalování stejné věci nebo dva týmy, které si předávají neověřenou práci.

07Jak může vypadat prvních šest týdnů spolupráce

Následující rozvrh je model přípravy a ověření první funkční části. Není to slíbená délka vývoje celé aplikace. Velikost etap upravte podle projektu; například návaznost na jiného dodavatele může vyžadovat delší přípravu.

1. První a druhý týden: cíl a rizika. Projděte skutečné pracovní postupy, vyberte uživatele pro zkoušení a oddělte povinné jádro od volitelných funkcí. Ověřte přístupy a nejrizikovější propojení. Výstupem je hranice první verze a plán s otevřenými otázkami.
2. Třetí a čtvrtý týden: jedna celá cesta. Připravte funkční část, třeba založení a schválení objednávky. Ověřte oprávnění a chybové situace. Uživatel ji vyzkouší na připravených případech; tým zaznamená problémy a firma rozhodne o prioritách.
3. Pátý a šestý týden: úpravy a rozhodnutí. Opravte zjištěné nedostatky, ověřte návaznost na další systém a zopakujte zkoušení. Porovnejte výsledek s cílem, rozpočtem a původními předpoklady. Rozhodněte o dalším rozsahu a podmínkách případného pilotního provozu.

V každém kole chtějte tři odpovědi: co nyní opravdu funguje, co jsme zjistili a co to mění v plánu. Sledujte také nevyřešené vady a závislosti. Počet dokončených úkolů bez informace o použitelnosti systému vám při rozhodování o další investici nepomůže.

08Co kontrolovat bez ohledu na metodiku

Společná kritéria dokončení chrání před situací, kdy vývojář hlásí hotovo, ale chybí testy, oprávnění nebo návod pro správce. Ve Scrumu je popis potřebné kvality označen jako Definition of Done. Technické dokončení a převzetí zadavatelem nejsou automaticky stejný krok. Dohodněte obojí a stanovte podmínky pro nasazení.

U fázového postupu požadujte časné kontroly návrhu, zkušební propojení a testování vznikajících částí. Závěrečný test celku potřebujete stejně, ale nemusí být první příležitostí najít chybu. U agilního postupu hlídejte kvalitu, dokumentaci a chování celku po přidání další funkce. Krátký cyklus není důvod odkládat bezpečnost.

Zpozorněte, když dodavatel nedokáže ukázat použitelný výsledek, nechce pojmenovat předpoklady nabídky nebo nedokáže vysvětlit čerpání rozpočtu. Stejně problematické je zadání, které se denně mění bez odpovědné osoby. Ještě před podpisem si nechte ukázat, jak bude vypadat průběžná kontrola, hlášení problému a schválení změny.

09Časté otázky k agilnímu vývoji a waterfallu