Nové moderní metodiky vývoje se často vymezují vůči vodopádovému vývoji. Člověk snadno nabyde dojmu, že nic horšího než vodopádový model vývoje být snad ani nemůže. Bohužel žádná z nových, ale ani starých metodik není dokonalá, vždy a na vše použitelná. Rád bych ve svém článku ukázal, že vodopádový přístup je přinejmenší dobrou inspirací.

Je zvláštní, že při hledání vhodného obrázku „s vodopádem“ jsem našel obrázků spousty, ale každému něco chybělo. Rozhodl jsem se tedy nakreslit svoji variantu. Právě jí se týkají moje úvahy.

Proč oceňuji vodopádový vývoj

Snad nejkrásnější na výše uvedeném obrázku je to, že pojmům na něm uvedeným rozumí většina lidí, která se kdy zajímala o vývoj software. Lidé, kteří ve vývoji pracují, intuitivně podle názvu své role tuší, co vlastně mají dělat a jakou mají odpovědnost.

Výhodou (ale i nevýhodou) této metodiky je důraz na zadání. Odpovídá to realitě většiny SW projektů při vývoji na zakázku – zákazník nerad platí vývojáře hodinovou sazbou, ale podle dodaných funkcionalit (tedy podle zadání).

Další výhodou je (když už se podaří vytvořit zadání), že je možné odhadout i časovou náročnost a termíny, zkrátka vytvořit relativně podrobný projektový plán.

S jistou mírou nadsázky se dá říct, že vývojový proces je samodokumentující se – architekt potřebuje (písemné) zadání, programátor nakreslenou architekturu, tester zadání ověřuje, podpora potřebuje dokumentaci k podporování…

Kritika

Vodopádový vývoj je závislý na přesném a úplném zadání. Bohužel se často v průběhu projektu požadavky na změny objevují, s tím ovšem vodopádový vývoj nepočítá.

Další nevýhodou je, že z programátora dělá kodera – když už má programátor vhodné zadání a návrh architektury, tak vlastně „nemusí být tak schopný“ – je degradován na kodera.

Vodopádový vývoj se nehodí na malé projekty, kdy jsou všechny role v projektu, od analytika k podpoře, soustředěné v jedné nebo dvou osobách programátorů. Sice tito jednotlivci určitě také budou postupovat od analýzy k nasazení, ale protože vlastní program velmi dobře znají, nebude pro ně takový problém změna zadání.

Nezvládnutá míra podrobnosti předávaných materiálů může vést k přehnanému „papírování“.

Korekce

Vodopádový vývoj není žádné dogma, lze ho upravit k obrazu svému. Například nejasnost zadání lze vyřešit prototypem (a vývoj tak rozdělit na dvě vodopádem řízené části – prototypovou a obyčejnou). Je možné sloučit roli analytika a architekta (a přiblížit tím zadání „realitě“) nebo architekta a programátora (a tím „zatraktivnit“ kódování).

Často bývá kritizován vodopádový vývoj také proto, že zákazník vidí reálnou aplikaci až během testování, a to už je na připomínky pozdě. Nicméně ani to není dogma, zákazník může vidět aplikaci již dříve, otázkou je, jestli tím nebude zneklidněn – z pohledu vnějšího pozorovatele se při vývoji SW často na začátku „dlouhou dobu nic neděje“.

Určitě není problém zpestřit vodopádový vývoj kontinuální integrací nebo průběžným alfa testováním.

Závěr

Vodopádový vývoj není ani lepší ani horší než jiné metodiky – velmi často ostatní metodiky alespoň částečně jeho přístup používají. Proto považuji za důležité správně chápat „vodopád“ i v případě, že ho při vývoji nepoužíváte…