Projekteket – anélkül, hogy így nevezte volna- és azok eredményeit az emberiség már az ókor óta használja. Elég, ha az egyiptomi piramisokra, vagy a hatalmas római építményekre gondolunk. Már ekkor megjelent a tudatosság, ami az elvárt eredményre, tartalomra, időbeliségre, és az emberi-anyagi erőforrások igénybe vételére vonatkozik. Az azóta eltelt időben nyilván egyre fokozódott a szükséglet a projektek becsülhetőségével kapcsolatban.
A 20. században már megjelentek formalizált konkrét módszerek, technikák, eszközök a feladatok kézben tarthatóságának növelésére. Maga a vízesés modell az első komplett módszertanként jött létre a 60-as, 70-es években, körülbelül egyidejűleg a hadiiparban, az építőiparban, és az informatika megjelenésével a hardver- és szoftverfejlesztésben. A 90-es évektől kezdve, főleg az utóbbi területeken, megmutatkoztak hatékonysági korlátai, ami az agilis irányzatok és módszertanok kialakulásához vezetett.
Ez a világméretű változás visszahatott a prediktív jellegű vízesés modellre is. Alkalmazási területei leszűkültek, manapság általánosságban az iteratív megközelítés vált dominánssá a projektmenedzsmentben.
Mit nevezünk vízesés modellnek?
A vízesés modell alapelve az, hogy a projektben elvégzendő tevékenységeket szakmai és projektmenedzsment szakaszokra, fázisokra osztja, ahol minden fázis végén a projektcsapat felülvizsgálja az adott fázist, majd lezárja azt. Így a vízesés modell fenntartja, hogy a következő fázisra csak akkor lehet továbblépni, ha az előző fázist felülvizsgálják és verifikálják. Idő- és költségigényes volt, ha változtatásra volt szükség, hiszen mindig az előző állapotra kellett visszalépni.
A vízesés metódus formális és dokumentum vezérelt. A projekt során nagyszámú dokumentum előállítása biztosítja a tervezett szoftver működőképességét, és megbízhatóságát. Egy másik sajátossága a modellnek a tervezés hangsúlyossága, gondos kivitelezése. Az előre megtervezett rendszer elvileg minimalizálja a tervezési időigényt a későbbi fázisokban.
A gyakorlatban viszont sok olyan le nem szállított, vagy leszállított, de kevésbé használt szoftverről tudunk, amelyek esetén a fő gond a specifikáció, követelmények menet közbeni változása volt. Ez az egyébként gyakori változás, egy fázis teljes újrakezdése esetén a költségek és a határidők jelentős változását, növekedését vonja maga után. Kifejezetten igaz ez akkor, ha a változtatást a projekt késői szakaszában szükséges eszközölni.
A vízesés modell fázisai rendszer-és szoftverfejlesztés esetén:
- Követelmények elemzése és meghatározása (specifikáció)
- Rendszer- és szoftvertervezés
- Megvalósítás és egységteszt
- Teljes rendszertesztelés, átvételi teszt
- Üzemeltetés, működtetés és karbantartás
A fejlesztési projektek gyakori sikertelensége a modell változását, fejlődését indikálta, és módosított modellekhez vezetett. Ilyen például az átfedő fázisú vízesés, a vízeséses alprojektekkel, vagy az „inkrementális vízesésmodell” is.
A vízesés modell alkalmazásának előnyei és hátrányai
Alkalmazásának előnyei:
- Nemcsak a szoftverfejlesztésnél használható, hanem jól tervezhető, megvalósító jellegű végfelhasználói projekteknél kifejezetten alkalmas megközelítés.
- A jól kezelhető és kevésbé komplex projektek esetén szabályozottan rögzíti a komplexitást, és jól átláthatóvá teszi azt.
- Könnyen átlátható, egyfázisú fejlesztési folyamatoknál egyszerű a használata.
- Strukturáltságot biztosít még a kevésbé képzett fejlesztők számára is.
- Kikényszeríti a követelmények rögzítését, törekszik a nagyobb költség- és határidő módosításokat okozó változások minimalizálására a fejlesztés során.
- Meghatározott sablont biztosít arra vonatkozóan, hogy mely módszereket használjuk az analízis, tervezés, kódolás, tesztelés és üzemeltetés során.
- Jó ellenőrzési lehetőséget biztosít definitív mérföldkövek használatával.
- A hibák korai fázisban való felismerése, amikor javításuk még lehetséges, és kevésbé költségigényes.
- A projektmenedzser számára alapvető fontosságú a tervezés (fontos sikertényező) és a szereplők kiválasztása.
- Az erőforrástervezés és a felhasználás kontrollingja átláthatóan biztosítva van.
Alkalmazásának hátrányai, kihívásai:
- Lineáris lefolyású, így nehézkes a felmerülő problémák megoldása, jelentős költség- és időigény növekedés mellett.
- Nem kezeli a szoftverfejlesztésben elterjedt iterációkat.
- Nincs összhangban a szoftverfejlesztés problémamegoldó természetével.
- Az integráció a teljes folyamat végén, egyben valósul meg. A korábban fel nem fedezett hibák ilyenkor hirtelen, együttesen jelennek meg, így felderítésük és javításuk egyaránt nehezebb feladat.
- A megrendelő csak a folyamat végén láthatja a rendszert, menet közben nincs lehetősége véleményezni azt.
- A minőség szintén csak a folyamat utolsó fázisában mérhető.
- Minden egyes fázis az előző fázis teljes befejezésére épít, ezzel jelentősen megnő a kockázat.
- A fejlesztés során a követelmények nem, vagy körülményesen módosíthatók, hiszen már az életciklus elején befagyasztjuk őket.
- Már a fejlesztés kezdetén ismernünk kell valamennyi követelményt.
- Elképzelhető, hogy bár a végtermék megfelel valamennyi specifikációnak, mégsem működik (pl. mert az elvárásokban vannak ellentmondások), vagy a megrendelő nem lesz elégedett az eredménnyel.
- Dokumentum vezérelt, és túlzott dokumentálási követelményeket állít fel.
- Az egész szoftvertermék egy időben készül, nincs lehetőség kisebb részekre osztására.
A vízesés modell hatékony alkalmazásának lépései
A vízesés modell választása és alkalmazása elsősorban olyan projekteknél lehet hatékony, ahol a teljes körű követelmények feltárhatók és rögzíthetők, maga a terméktartalom, az adott szakma szabályai szerint biztosan megvalósítható, és a szükséges technológia is rendelkezésre áll. Amennyiben ezek a feltételek teljesülnek, maga a módszer alkalmas mind kisebb, mind nagyobb projektek sikeres teljesítésére, bár nyilván szakmánként és esetenként változó, hogy mit tekintünk kisebbnek vagy nagyobbnak.
Az előzőekből adódik, hogy a vízesés módszer alkalmazásánál kiemelt jelentőségű a megvalósíthatóság alapos vizsgálata, a követelmények beazonosítása és a teljes körű tervezés. (Erre vonatkozó régebbi globális felmérések szerint az előkészítés minősége és teljessége 60-80 %-ban meghatározza a projekt sikerét).
Menedzsment szempontból fontos a módszertan alkalmazásának teljes körű ismerete, a működési jellemzők megtapasztaltsága. A megvalósítási fázisban kritikus projektvezetői feladat a változások kezelése, felügyelete és az erre való képesség (pl. a megfelelő döntések elérésére).
A vízesés modell és az agilis módszertan közötti különbségek
Az agilis és a vízeséses módszertanok közötti fő különbség az, hogy hogyan tekintenek a minőség-megrendelői elégedettség és a tesztelés kérdéskörére. A vízesés modell mindig külön-külön tervezési-fejlesztési és tesztelési szakaszt definiál; ezzel szemben az agilis szoftverfejlesztés során a tesztelés rendszerint a tényleges fejlesztési (programozási) munkával egyidejűleg, vagy legalábbis ugyanazon iterációban zajlik. Ezért a jövőbeli felhasználóknak folyamatosan lehetőségük van az új részeket használatba venni, és megismerni azok működését.
Az agilis projektmenedzsment egyes iterációiban egyaránt tartanak visszatekintő (retrospektív) és tervezési megbeszéléseket, így a felhasználónak lehetősége van a számára legjobbnak gondolt megoldás felé orientálni a fejlesztést. Ez az iteratív gyakorlat a vízesés modell scope-határidő-költség szemléletmódjával szemben, a jövőbeli termékhasználatot és annak felhasználói elégedettségét helyezi előtérbe.
Megrendelői oldalon azonban nem mindig van meg az agilis működést megvalósító önjáró csoport döntési felhatalmazása, ragaszkodnak a hagyományos fogalomrendszerhez, szerepekhez és folyamatokhoz, ezért kialakultak un. hibrid módszertanok, amelyekben mindkét módszertan elemei megtalálhatók (lásd pl. projektvezetői szerep, mérföldkövek, stb.).
Összegzés
Az elmúlt két évtizedben a projektmenedzsment módszertanok terén is sok változás történt, ahogy az előző pontokból is kiderülhetett. Manapság már tudatos döntést igényel, hogy egy adott feladathoz, projekthez melyik módszertant választjuk. Van olyan projekttípus, ahol a vízesés megközelítés teljességgel megfelelő, ugyanakkor terjed az iteratív módszertani megoldás, és van ahol egyértelműen az agilis megoldás a célravezető. Ez utóbbi, az agilis megközelítés már nem csak egy fejlesztési metódus, hanem szervezetfejlesztési kérdéssé is vált.
A legkülönfélébb ágazatokban vannak már példák a szervezetek agilissá való alakítására, vagyis agilis transzformációra. Ez a folyamat egyben kultúraváltást is feltételez, illetve jelent. Nem véletlen, hogy elsősorban olyan szervezetek vállalkoznak erre, ahol már az IT fejlesztés is agilis módon történik.
