Negatíva metodiky vodopádu

V tomto článku by som sa rád venoval metodike riadenia projektu metodikou vodopád. Originalne sa jednalo o moju reakciu na členov týmu, ktorí sa snažili zrušiť agilné programovanie, kvôli sekundárnym nevýhodam (ktoré rieši vodopád) neuvedomujúc si však nové riziká.

Text nie je vhodné brať ako učebnú pomôcku, lebo sa jedná o subjektívny názor (môj) založený na riadení projektov (skúsenosti) konrétnej firmy – teda nie je vylúčené, že v iných firmách spomínané nedostatky sa nevyskytnú, resp. pri konkrétnom projekte sa nedostatok zmení na výhoduj! Taktiež sa nevenujem pozitívam vodopádu, len jeho negatívnymi dopadom.

1 Metodika vodopád

Vodopád je klasický, elegantný model riadenia projektu, ktorý je orientovaný jedným smerom rozdelený na jednotlivé fázy. Tu je dôležité si uvedomiť, akú prioritu má samotný vývoj, pretože v tomto modeli je zdanlivo podcenená jeho úloha, keďže je iba jedným z krokov (čo môže podceňovať jeho zmysel – narozdiel od agilného modelu, kde sa javí ako „srdce“ projektu):

                Takže máme tu fázy: nápad, plánovanie, vývoj, testovanie, prevádzka. Model je jednoduchý a všetko v prírode inklinuje ku jednoduchosti. Príroda ale rozdeľuje komplexné dynamické systémy na malé celky a tie sú práve riadené jednoduchými princípmi! Podobne to funguje aj pri ekonomických systémoch, kde trh (jednotlivec sledujúci SVOJ zámer) dokáže nájsť najvhodnejšie riešenie (zázrak agregácie kde jednotlivec ovplyvní konečný výsledok).

1.1 Uplatnenie

Z tohto pohľaduje je teda zrejmé, že spomínaný model sa skôr uplatní:

1.       Pri manufaktúrnej výrobe – najprv sa musí auto vyrobiť, aby sa mohlo otestovať. Programovanie je ale vývoj, ktorý aj keď nie je komplikovaný, nejedná sa o triviálnu úlohu, pretože vývoj nie je exaktná veda – niektoré premenné nám MUSIA byť skryté v štádiu návrhu (pozri môj predchádzajúci článok).

 

2.       Pri obrovských skupinách s obrovským finančným zázemím (NASA). Ak máme takmer neobmedzené zdroje, dokážeme sa venovať návrhu tak dlho, pokiaľ nebudú naplánované jednotlivé časti do detailu (aj keď tu vždy hrozí, že sa na niečo zabudne). Tento systém ale vyžaduje niekoľko týmov odborníkov. Keďže je model neefektívny (vysvetlíme neskôr) a musí byť obsiahnutý veľkým počtom odborníkov, značne sa predražuje (no ale vtedy dosahuje celkom slušné výsledky).

 

3.       Vhodné pre malinké projekty. Väčšina neefektivity modelu sa dá zredukovať ak obmedzíme týmovú spoluprácu a zredukujeme úlohu (z toho ináč výchádza agilný systém, ktorý využíva tento model na riadenie podčastí ale nie celku). Ak teda máme malý tým a jednoduchú úlohu, tento model je vhodný, pretože kritické body sú vynulované a v prípade fatálneho zlyhania, začatie od druhej fázy nie je až tak nákladne.

1.2 Negatívne dopady

Povedali sme si, kde sa model hodí, teraz si povedzme samotné negatívne dopady (komparatívne nevýhody), ktoré budú vysvetlené nižšie (pre urýchleného čitateľa nepotrebné informácie a tak začínam „záverom“):

-          Všetky fatálne chyby, spôsobené časom alebo technickými problémami sa budú navonok javiť ako chyby vývojára (pretože nastanú v tejto fáze). To je spôsobené degradáciou samotného vývoja, keďže bez jeho ukončenia nie je výsledok, ale z modelu riadenia to nie je viditeľné. Čo nie je fér, pretože práve tento model berie všetky páky, aby to programátor zvrátil... ak už má byť na vine!

 

-          Je veľmi ťažko nájsť zodpovednú osobu, ktorá má prehľad nad detailmi projektu a je súčasťou celého životného cyklu. Je to preto, že tu bude existovať niekoľko zodpovedných ľudí... ale zodpovedných za jednotlivé fázy, nie projekt! Čo môže byť kontraproduktívne a viesť až ku nevraživosti medzi týmami (pretože nie projekt je cieľom každého týmu, ale len jeho jediná fáza).

 

-          Model nie je flexibilný – je takmer nereálne zmeniť špecifikáciu, čo v prípade robustných projektov (alebo SOA projektov ktoré sa navrhujú v rôznych fázach iného projektu ale sú na sebe závislé). Tento model vychádza z princípu: všetko alebo nič, čo môže byť deštruktívne z hľadiska biznisu.

 

-          V tomto modeli sa veľmi ťažko niečo plánuje – aj keď sa zdá, že pravda je opakom! Problém je v tom, že na jednotlivé problémy sa prichádza v neskorších štádiach, čo spôsobujé častejšie zmeny v termínoch, resp. sa termíny tak nafúknu, že budú v podstate pre plánovanie irelevantné (pretože sa niektoré fázy skončia výrazne skôr, alebo s drobný zdržaním a teda sa nedá naplánovať exaktne každý krok). Tento model považujem za nočnú moru každého projektu s fixným termínom (vládne uznesenie).

1.2.1 Analýza

                Chcel by som sa pokúsiť vysvetliť všetky negatívne dopady (ako som spomínal, pozitívami sa tu nezaoberám):

-          Na nízku efektivitu modelu sa pozriem z pohľadu kontrétnej fázy a to tej, ktorá mi je najbližšie – vývoj. Celý systém je postavený na myšlienke „end-to-end“. Inými slovami nemá zmysel niečo ukončovať, kým nie sú dosiahnuté všetky ciele. Ak sa jedná o mierne rozsiahly projekt, na ktorom sa podieľa okolo 5 ľudí, tak nafázovanie sa bude podobať tvorbe komponentov. Každý komponent je samozrejme rozlične náročny a pri troche štastia autonómny – neovplýva ho vývoj iného komponentu. Tak sa začnú teda práce na jednotlivých častiach, paralelne (efektivita). Ak jednotlivé fázy sa ukončia skôr, ostatní čelenovia tímu musia čakať na tých „najpomalších“ (pomalý členovia v tomto prípade skôr participujú na zložitejších úlohach). To efektivite neprospieva, pretože už v rámci jednej fázy vznikajú „hluché“ miesta. Trocha priestoru na „čarovanie“ tu je, ale väčšinou na úkor rizika, že „ušetrený“ čas sa „vráti“ neskôr vo forme vyšších nákladov – ak napríklad člen týmu zodpovedný za synchronizáciu všetkých časti bude zakomponovaný aj v inej fáze, v prípade testovania bude riešiť proporčne viac problémov ako iní členovia tímu (chyby vyplývajú z architektúry a plus „jeho“ problému). Tu sme si demonštrovali príklad prestojov v rámci jednej fázy – „medzifázové“ prestoje sú oveľa markantnejšie! Ostatné dopady tejto neefektivity:

 

o    Model nevyužíva plné kapacity týmu => ak je vývoj najrozsiahlejšiou fazou, vďaka tomuto modelu musí byť celkový čas omnoho výšší, ako by byť mohol (čo ma samozrejme vplyv na cenu).

 

o    Všetky chyby implementácie budú identifikované (zbytočne) v neskorších štádiách, čo má taktiež vplyv na cenu. Napríklad ak vytváramé nejaké výpočtové jadro, nebude testované a implementované vo finálnom systéme do poslednej chvíle. V jednom našom prípade sa ale ukázalo, že sa zabudlo na to, že výsledný produkt namiesto pamäti používa databázu. Tam sú pravidlá podobné, ale nie totožné! Ak by sa na to dohliadalo už počas vývoja, nestalo by to takmer ani cent. Vo vyššej fáze vývoja to však stálo 5% času s ktorým sa nerátalo. Môže sa to zanedbateľné, ale ďalšie percená sa nasumujú za iné „nečakané“ veci a už v prípade rozpočtu 100.000e aj 5% je zaujímavá čiastka, ktorá mohla byť radšej rozdelená v rámci prémii... Vo všeobecnosti platí, čím sa neskôr chyba objaví, tým je nákladnejšia jej oprava (v živej prevádzke môže mať fatálne následky pre firmu ako strata mena, značky, kľúčového zákazníka):

-          Metodika vytvára veľké riziká (ktoré nie sú rozložené) – už len kvôli nízkej flexibilite v dnešnej „ubehanej“ dobe:

 

o    Každá chyba s ktorou sa nerátalo môže mať fatálne dopady na celý projekt (alebo firmu). Rovnaký efekt môže mať aj obyčajná (neplánovaná samozrejme) choroba dôležitého člena týmu ak su napnuté termíny! Spomeňme si na filozofiu: všetko alebo nič! Jedna takáto chyba nám mohla vylomiť väz, keď sme sa domnievali, že jeden systém bude fungovať on-line, zadávateľ chcel off-line riešenie a domnieval sa, že je to „jasné“. No nebolo. Na otázku typu: bude to chodiť aj na lokálnom počítači sa odpovedalo „samozrejme“ a všetci boli šťastní. Ak by sa riešenie odovzdalo testne pred termínom, nebol by priestor napraviť danú chybu a tak by sme museli riešiť milión vecí len ohľadom inštalácie zbytočne 3 vrstvovej aplikácie s webovým serverom!!! Tu nejde o zlyhanie jednotlivcov, ale celého týmu – a jedná sa o ľudí, teda chyby sú predpokladateľné! V systéme vodopádu takéto zlyhanie však neodporúčam, hlavne ak sa jedná o obmedzený čas alebo zdroje! Ale ono to bez ľudí asi nepôjde...

 

o    Ak by ale vznikol nečakaný problém, programátor je tvor vynaliezavý a určite by dokázal vyriešiť problém nejakou obchádzkou. Zo skúsenosti viem, že každá obchádzka prirodzeného riešenia viedla ku inej obchádzke neskôr a potom obchádzke obchádzky, až sa všetko muselo kompletne preprogramovať. Toto sú prosím pekne skryté náklady... a môžu byť riadne vysoké!

 

-          Stráca sa motivácia – nikto z týmu nie je motivovaný dotiahnúť projekt do úspešného konca. Všetci sa len starajú o „svoju“ fázu.

 

o    Tester je vylúčený z fáze vývoja (nemôže do toho kecať). Toto môže mať neblahé dôsledky pri vyhodnocovaní dôležitosti chýb. Môže sa stať, že tester bude trvať na úprave nejakej somariny (on je pánom poslednej fázy), ale tá môže mať dopad na celý systém. Vyhodnotenie priorít tester nie je schopný pretože mu je v podstate projekt ukradnutý (zohráva tu teda rolu ješitnosť) a nemá vedomosti o tom, akými útrapami sa projekt vyberal počas predchádzajúcich fáz a teda je dosť možné, že tester bude trvať na niečom triviálnom s ohromným rizikovým dopadom!

 

o    Vo fáze testovania v ideálnom svete bude mať programátor na starosti iný projekt s novými termínmi. Priority sa teda z pohľadu programátora presunú niekde inde a tak útrapy testera s „predchádzajúcim“ projektom budú riešené len v rámci „voľného času“ – veď zodpovednosť už prebral niekto iný. Ak však úlohy pre programátora nie sú (už spomínaná neefektivita) – môže sa stať, že v dobe, keď bude požadovaná jeho prítomnosť, sa nebudena pracovisku nachádzať. A pre „hodinový“ job sa mu neoplatí príjsť do kancelárie. V oboch prípadoch je tester bezmocný (závisí na programátorovi), ale práve tester je zodpovedný za túto fázu (čo je fáza kvality) a teda začne strácať motiváciu aj on!!!

2 Agilná metodika v skratke

                Všetky tieto problémy rieší „kombinovaný“ model vodopádu a špirály. Tento model je tiež známy ako agílna metodika (nie technika!!!). V podstate dokáže rozfázovať komplexný problém na menšie časti (ktoré sa testujú) a v prípade problému sa jednoducho novo-vyskytnuté zmeny zahrnúť do plánu, resp. ak sa nestíha, vylúčia sa nepotrebné veci.

V podstate ak sa naplánujú najdôležitejšie veci od ranných štádii (ktoré sa testujú v čase keď sa implemenujú menej dôležité veci), vie sa produkt aj keď obmedzený vydať vo fixnom termíne. Zvyšné veci sa môžu dokončiť neskôr (treba rozlíšiť čo MUSÍ byť v daný termín dokončené, všetko ostatné už len MôŽE byť zahrnuté pre daný termín).

                Tento model samozrejme ma kopec múch (preto sme vo firme začali diskutovať o vodopáde), ale obmedzuje riziká, dokáže sa prispôsobiť novým okolnostiam a tak z mojho pohľadu jednoznačne vedie.

                Model vychádza z filozofie: všetko alebo aspoň niečo. Toto sa mi zdá menej invazívne v dnešnej hektickej dobe. Ďalšou výhodou je, že všetci čelnovia týmu vidia v ako štádiu sa projekt nachádza (denné release) a tak podľa potreby vie vedenie zasiahnúť a povedať: „toto nám teraz stačí, musíme začať trénovať ľudí a napísať manuál – zvyšok urobíme v Second Edition“.