Vyberte stránku

Porovnání agilních metod s waterfallem II

Kvě 1, 2018O strategiích, plánování nebo vitalitě

Předešlé články

Přečtěte si 1. díl k tomuto tématu – „Porovnání agilních metod s waterfallem I„, kde jsem jsem popsal obě metody a věnoval se výhodám a nevýhodám agilních metod.

V tomto článku se budu pokračovat. Přečtete si něco o výhodách a nevýhodách waterfallu.

Výhody a nevýhody waterfallu

Jak už jsem psal v předchozím článku, waterfall je vlastně sekvenční proces okopírovaný z pásové výroby přenesený a upravený pro vývoj sw. A jaké jsou tedy jeho hlaví výhody a nevýhody?

 

Výhody

  • Jednoduchý na řízení. Teď jsem trochu popíchnul projektové manažery popřípadě manažery řídící vývoj na základě tohoto modelu. Konečně jak jsem napsal v předchozím blogu, víc jak 89% těchto projektů selhává, nebo má potíže. Tak jak jen můžu napsat, že je to“brnkačka“? Je to jednoduché. Navazuje a podporuje tzv. „best practice“. Tedy po léta vyvíjené metody a postupy, které nemají za cíl nic jiného než mitigovat (zmírnit) rizika. Konečně od toho tyto normy a doporučení jsou. No ne? Proč čím dál častěji selhávají se budu věnovat v nějakém z dalších blogů.
  • Snadno navazuje na zaběhlé metody a metodiky řízení kvality.
  • Snadné stanovení a vyhodnocení KPI, SLA a konkrétních výsledků jednotlivých fází. 

A proto je milují všichni „klasičtí“ manažeři, auditoři, lidé odpovědní za kvalitu,… Bodejť ne, vše je pěkně ohraničeno. Časově, zdrojově i obsahově. A tam, kde je vše jasně ohraničeno, tam se dobře měří. A jak známo, kde se měří, tam se řídí (a taky „challenguje“)…

  • Výrazně snadnější řízení závislostí (takzvaný „dependency management“). Toto tvrzení vychází z toho, že díky fázím jako je „business analýza“ a „architektura“ by měla být tato problematika z hlediska vlastního systému vlastně „vyřešena“ a co se případného projektového řízení týká, tak tyto dvě úvodní fáze poskytují většinu potřebných podkladů.
  • Nastavený proces, oddělené role a fáze usnadňují outsourcing a tím částečně mitiguje některá rizika jako je fluktuace členů týmu.  Proč? Nu je to „nativní vlastnost procesního řízení. Jestliže máme jasně popsáno co má být výsledek (výsledek business analýzy) a jak to má vypadat (výstup architektury) snadno zadáme programátorské práce třeba do Indie a otestování nějaké specializované firmě…
  • Usnadňuje řízení dodavatelů, aprocesy spojené s nákupem včetně stanovení rozsahu, výběrových řízení protože to, co se dá snadno zadat, to se také dá snadno smluvně podchytit a případně vymáhat .
  • Velmi dobře a efektivně funguje všude tam, kde jasné a pevné zadání a prostředí. Tedy všude tam, kde je dost času a zajištěna stabilita. Dostatkem času mám na mysli to, že cyklus od vstupu do procesu po nasazení je kratší než dynamika změn nebo trhu.

 Nevýhody

  • Lineární průběh předpokládá umožnění změn až po doběhnutí cyklu. Je tedy nevhodný všude tam, kde dynamika změn je vyšší než doba trvání procesu. Druhá strana mince posledního bodu výhod. Tento bod je často zvládán zavedením procesu řízení změn do procesu vývoje (waterfall). Změny v zadání ještě před ukončením procesu, tedy před doprogramováním, otestováním a akceptováním však zásadním způsobem komplikují proces a  zpochybňují nastavené metriky.
  • Vzhledem k odloženému testování je vysoké riziko nákladných oprav chyb a následného re-testování. Následek překvapení na konci typu „… to je sice pěkné, ale já to chtěl jinak a tady to je napsané (varianta na „houpačku“ popsanou níže). Takže následuje kolečko opravit, znova otestovat a jestli je to OK, tak nasadit…
  • Metoda náchylná k „zbytečnému“ vývoji.  Je to tak lákavé vymazlit apku k dokonalosti. Tuhle ta funkcionalita, onde tohle okénko, vyskakovací „opičárna“, … A v reálu? Jedna studie uvádí, že až 70% všech funkcionalit u waterfall projektů je zbytečných. Buď se nikdy nepoužijí, nebo jen zřídka (nemluvím o těch, které nutí legislativa a tudíž tam musí být a my doufáme, že budou využívány jen zřídka). A to v tom lepším případě. V tom horším komplikují uživateli práci.
  • Extrémně citlivá metoda na kvalitu zadání / analytickou část. Jinými slovy i skvěle udělaná „business analýza“ včetně všech „user story“ ještě nezaručuje, že výsledek procesu nebude nepříjemné překvápko. Konečně znáte ten obrázek s houpačkou? Dalším rozměrem téhož je „tak jsme se snažili a on nám to zákazník zkazil… Je to následek „prodloužení“ cesty mezi zákazníkem, jeho očekáváním a zpětnou vazbou a výsledkem procesu.
  • Metoda je má dlouhý „time to market“. Tedy hodně dlouhý čas od zadání po uvedení do provozu. V prostředí, kdy potřebujeme rychle reagovat na potřeby zákazníka nebo trhu. popřípadě chceme postupovat metodou testování prototypů a rychlé zpětné vazby se stává waterfall metodika prakticky nepoužitelnou.

Mezivýsledek

„Waterfall metodika je jako náklaďák“

Dříč. Sice není žádný fofrník, ale své si odpracuje. Je předvídatelná a snadněji se řídí. Jen si musíte být jisti co a kam vlastně chcete dovézt.

Následovat bude blog o tom, kdy a proč se která metodika hodí lépe.

 

Share This