Vyberte stránku

Porovnání agilních metod s waterfallem I

Dub 10, 2018O strategiích, plánování nebo vitalitě

První pád – vodopád

Není to tak dáno, kdy jsem byl požádán o toto srovnání. Tak nějak „rukolapně“, pro „excom“ (Executive commitie tedy řídící výbor složený z vrcholového managementu). Určitě to máš někde po ruce, nebo víš kde to vzít…

Jak správně tušíte – tak po ruce jsem to neměl. Ani mě nenapadlo udělat si „nezaujaté“ srovnání těchto metodik v rukolapném provedení, v zjednodušení a rétorických termínech srozumitelných vrcholovému managementu jen tak do šuplíku.

Proč je „nezaujaté“ v uvozovkách? Nu proto, že být nezaujatým je nadlidský úkol. Hezky to vyjádřil G. Christoph:

Všecka nestrannost je neskutečná. Člověk je vždycky na něčí straně, a dobře že tak.

A tak i články a srovnání dostupné na webu některé metodice nadržovaly. Některé okatě, jiné méně.

Je libo koktejl?

Vzal jsem tedy co jsem našel, srovnal to s tím, co o obou metodikách vím, včetně toho, kde mají slabá a silná místa přidal nějaké znalosti a zkušenosti z navazujících oblastí, okořenil o ty zdánlivě nesouvisející, protřepal (nemíchal) a ochutnávka je nyní na stole (nebo lépe na webu). A ano, ani já nebudu nestranný, i když jsem se o to poctivě snažil. Holt do buddhistického mnicha mám dost daleko?

Něco málo o metodikách

Já vím, tisíckrát to samé umořilo … Ale myslím, že je dobré to zde alespoň v krátkosti zmínit. Tak pro celkový obrázek.

Waterfall

Vodopádový model (waterfall) je vlastně sekvenční vývojový proces, ve kterém je vývoj pohlíženo jako na tok navazujících fází analýzy požadavků, návrhu, implementace, testování, integrace a údržby s tím, že každá fáze je jasně ohraničena a definována. Poměrně hezky je to popsáno třeba na Wikipedii (ať už české nebo té anglické).

Vodopádový model paradoxně představil Winston W. Royce ve svém článku jako nevhodný způsob vývoje. Přesněji řečeno načrtl tento model, aby jej vzápětí argumentačně rozcupoval (Vím, také žádná novinka. Jako perlička je to uváděno snad u každého popisu metodiky). Zrovna tak mnohé zdroje, např. „The chaos manifesto“ od The Standish Group, dokládají neefektivitu a rizikovost tohoto modelu vývoje (komu asi straní? ?). O tom, že to nutně nemusí být jen metodikou ještě napíšu.

Tak proč je tak oblíbený a široce nasazovaný? Odpověď je nasnadě. Snadno zapadá do manažerských postupů a metodik řízení. Snadno se měří, snadno se nastavují KPI a tedy řídí kvalita, snadno se definují předávací body a tedy začleňují techniky a postupy jako je outsourcing, nebo části procesu jako servis. Ale o tom níže.

Agile

Agilní metodiky jsou metody založené na iterativním a inkrementálním vývoji. Umožňují rychlý vývoj a zároveň dokáží reagovat na změnu požadavků. Podle těchto metodik se dodává to, co má v danou chvíli největší hodnotu / prioritu a správnost se ověří pomocí rychlé zpětné vazby. Agilní přístupy a filosofie se dnes neomezují jen na projektové řízení nebo programování, ale nachází uplatnění i v manažerských metodách a marketingu.

Z uvedeného „The chaos manifesto“ se pak dá udělat zkratkovitý závěr, že projekty uskutečněné agilními metodami jsou obecně výrazně úspěšnější. Vidět je to i na přiložené tabulce.

Zde by zřejmě stálo za to, zamyslet se, co tabulka vlastně říká. Rozhodně zajímavé může být zamyšlení proč je většina projektů „problematická“ a to napříč velikostí i zvolené metodice. Ale to by bylo na samotnou úvahu. Třeba na téma kultura „výzev“ a její dopady do projektů.

Ale dost bylo povídání a nyní k vlastnímu srovnání.

  • Facebook
  • LinkedIn

Tabulka pochází z „Standish Group 2015 Chaos Report – Q&A with Jennifer Lynch

Výhody a nevýhody agilních metod

    Výhody

    • Metodika je proklientsky zaměřena. Zadavatel je zapojen v celém procesu vývoje, což na jednu stranu snižuje riziko neporozumění nebo chybné interpretace na straně vývojového týmu, na stranu druhou umožňuje korigovat představy zadavatele. Ruku na srdce kdo z nás co někdy něco zadávaly navrhovali nebo vmýšleli dali vše „na první dobrou?“ Většinou je i návrh určitá forma iterace.
    • Velmi flexibilní na změny. Ono to jednat souvisí s předchozím bodem.  Jednak se velmi rychle mění podmíky, jednak zadavatel na základě iterace s týmem může korigovat zadání.
    • Rychle identifikuje neshody implementuje zpětnou vazbu. Abych trochu ochladil optismus. Rychle neznamená ihned. Metoda je ale podstatně flexibilnější a není tedy potřeba čekat na kompletní doběhnutí procesu. Tato flexibilita mnohdy může znamenat nejen podstatnou časovou, ale i finanční úsporu. Je ns ipředstavte, co všechno se nemusí předělávat a retestovat v případě, že je neshoda identifikována a odstraněna včas.
    • V rámci sprintu se zaměřuje na dodání nejvyšší hodnoty. Ač platný, tak trochu problematický výrok. Často bývá prezentován pouze v manažersko – obchodním smyslu. Tedy vyvineme nějakou funcionalitu, nasadíme jí a pokud se přímo nehrnou peníze, tak alespoň zpětná vazba od zákazníků / uživatelů.  Toto pojetí pak budí nedůvěru v metodiku u části profíků zejména z oblasti architektury nebo business analýzy. Ano, mám na mysli oblast takzvaných „nefunkčních“ a architekturních požadavků. Dodání těchto požadavků má ve správný okamžik nejvyšší hodnotu pro projekt.
    • Je naprosto zřejmé, co je hotové a co ne v každé fázi projektu.

     Nevýhody

    • Metoda je náročná na osobnost zadavatele činícího rozhodnutí
    • Metoda je náchylná na odklonění / nedodání výsledků pokud business vlastník nemá jasno v tom, co má být výsledek.

    Tyto dva body spolu souvisí. Všechny ty skvělé (a teď to nemyslím nikterak ironicky) výhody, na kterých jsou agilní metody založeny vlastně vedou k tomu, že projekt „lepíme“ jako vlaštovčí hnízdo. Tento přístup, ač má obrovský potenciál dodat tu správnou věc v ten správný čas, koncentruje pozornost a aktuálně řešenou část a odvádí pozornost od celku. Je pak velmi snadné sklouznout a vytvořit perfektní věc složenou z perfektních částí která… Myslím, že se tomu říká „piecemeal effect“.

     

    • Metoda náročná na disciplínu a kvalitu kódu. Trochu jsem váhal, zda to je výhoda nebo nevýhoda. Nakonec jsem se přiklonil k nevýhodě. Proč? Jeden z principů vyjádřený v agilním manifestu říká: „Fungující software před vyčerpávající dokumentací“. Důležitý moment. Málokdo se rád prokousává stohy papírů, které se jen špatně udržují aktuální stojí spoustu práce a tak. (Jen aby bylo jasno – tahle věta neříká kašlete na dokumentaci!) Jenže pokud nemáme vyčerpávající dokumentaci a chceme projekt dále rozvíjet a udržovat zejména v podmínkách ve kterých se vše mění včetně složení týmu tak je třeba tuto nevýhodu něčím vyvážit. Neboť nezdokumentovaná cochcárna se velmi rychle mění v noční můru.
    • Měření výkonnosti a KPI musí být postaveny na jiných principech. Je nutná změna paradigmatu. Jan Werich jednou řekl: „Čas si vymysleli lidé, aby věděli, od kdy do kdy a co za to.“  Je to vlastně takové lapidární vyjádření řízení výkonu a kvality. Tedy co, v jaké kvalitě a čase musí být dodáno, aby bylo možno výsledek akceptovat. Tento přístup se snadno aplikuje v sekvenčních modelech s jasnými rozhraními. V agilu je ale tento přístup přinejmenším problematický. Řešením ale není na měření rezignovat. Konečně kdo měří může řídit. Jen je třeba metriky pojmout „jinak“.

    Mezivýsledek

    Přemýšlel jsem o takovém krátkém shrnutí první části. Nějakém vhodném přirovnání.  Něco jako:

    „Agilní metody jsou jako sporťák“

    Silné a rychlé. Chce to ale fakt dobrého řidiče abyste ho udrželi na cestě. Pokud ho máte vítězíte. Pokud ne, no pak je na zvážení, zda  nepoužít starý, dobrý a předvídatelný kombík (ale bacha na přetížení 😉 ).

    Následovat bude blog o výhodách a nevýhodách watefallu a srovnání metodik podle oblastí.

     

    Share This