Egy korábbi, a Scrum alapjairól szóló bejegyzésünkben már szóba került a waterfall típusú projektmenedzsment. Amolyan elrettentő példaként említettük, de ez nem jelenti azt, hogy aki szoftverfejlesztésre adja a fejét, annak ne lenne érdemes megismerkednie a waterfall metódussal. Abból is lehet tanulni, ami nem működik tökéletesen, és ha az ember meg akar valamit haladni, akkor legalábbis nem árt tudnia, hogy pontosan minél is gondolja magát okosabbnak.
Mi a waterfall lényege?
Bár nem nevezték mindig így, volt idő, amikor a waterfall (vízesés) magától értetődően kedvelt technikának számított a szoftverfejlesztésben. Ez ma már sokkal kevésbé jellemző – olyannyira, hogy a menőbbnek számító módszertanok szeretik éppen a waterfall ellenében meghatározni magukat, és nem véletlenül. Ez egy egyszerű, könnyen emészthető és működtethető eljárásrend, mely rendezettségével és látszólagos evidenciájával könnyen megtévesztheti a felületes wannabe-fejlesztők széles tömegeit.
A waterfall legfőbb jellegzetessége, hogy kiszámíthatóan lineáris, akár egy realista regény. Julien Sorel nem kezdhet hozzá az implementációhoz, amíg Madame de Renal nem végzett a rendszertervezéssel. A fejlesztés egyes szakaszai egymásra épülnek, a lezárásuk után nem lehet újrakezdeni, visszatérni valamelyikhez, nincs köztük átfedés. Az is elég jól körülírható, hogy mik ezek a szakaszok: elemzés, tervezés, felépítés, tesztelés, illetve a lista kiegészíthető még a telepítéssel és a karbantartással.
Hogyan épülnek egymásra a waterfall szakaszai?
A kiindulási pont a követelmények nagyon alapos, teljes körű feltérképezése a projekt kezdetekor. Itt egyrészt az a cél, hogy ettől fogva egészen a befejezésig ne kelljen többé kommunikálni az ügyféllel az elvárásokról. Másrészt az, hogy az esetleges problémás, ellentmondásos kívánságok már ekkor kiszűrhetők legyenek, ily módon elkerülve a későbbi károkat. Kétszer mérj, egyszer vágj, ugyebár. Az igényfelmérés alapvetően a termékmenedzser dolga.
A tervezést általában kettébontják, egy, a lehetséges megoldásokat számba vevő brainstormingos és az ötleteket, elképzeléseket konkrét formába öntő specifikációs alfázisra. Utána következik az implementáció, amikor a programozók a specifikációk alapján előállítják a kódot. A tesztelés/verifikáció során pedig ellenőrzik a működést, valamint azt, hogy valóban a felállított követelményeknek megfelelő termék született-e.
Mindennek kétségkívül vannak előnyei. Mindenekelőtt az, hogy a módszer nagyon könnyen és gyorsan elsajátítható, így bárki által szinte azonnal alkalmazható. Merevsége miatt menedzselni sem nehéz – a fázisoknak előre meghatározható eredményt kell szállítaniuk, majd felülvizsgálat következik. A fázisok világosan definiáltak, a mérföldkövek minden résztvevő számára egyértelműek. Ideális esetben a gondos dokumentáltság is ide sorolható.
Mikor jó a waterfall?
Léteznek helyzetek, ahol ez a strukturált felfogás kitűnően működik. Tipikusan ilyen ágazat, például, az építőipar, ahol a dolgok természetéből fakadóan tényleg fontos, hogy a műveletek sorrendje még annak érdekében se legyen felcserélhető, hogy nyerjünk egy kis időt vagy megspóroljunk némi pénzt. Még azt sem mondhatjuk, hogy a szoftverfejlesztésben mindenkor okvetlenül alulmarad a waterfall a riválisaival szemben. Vannak esetek, amikor igenis megállja a helyét. Lássuk, mi kell ehhez: jól dokumentált, világos és végleges követelmények; szilárd termékdefiníció; kipróbált, statikus technológia; elegendő erőforrás és szakértelem; és egy viszonylag rövid projekt.
Vannak ilyen projektek? Természetesen akadnak. A tapasztalat azonban az, hogy egyre több a fenti feltételek többségének meg nem felelő, tehát bonyolult, hosszadalmas és a folyamat során változó követelményű fejlesztés. Ha ilyenre próbáljuk a waterfall módszert ráhúzni, előbb-utóbb kiütköznek a gyengeségei.
Mik a waterfall hátrányai?
A rendszerszintű probléma, hogy egészen a ciklus végéig nincs működő szoftver, ami komoly kockázatot, illetve bizonytalanságot hordoz magában. Elég gyakran előfordul, hogy egy ügyfél az induláskor nem képes pontosan megfogalmazni a funkcionális specifikáció nyelvén, hogy mire lenne szüksége, ezért aztán bármilyen lelkiismeretesen igyekszünk kipuhatolni a vágyait, később sok pénzbe kerülő meglepetések érnek.
A waterfall megközelítéssel nem lehet alkalmazkodni az időközben bekövetkező esetleges változásokhoz, a scope módosulása pedig véget is vethet a projektnek. Ha tehát minden erőfeszítésünk ellenére valamilyen hiba adódik, annak a kijavítása borítékolhatóan drága lesz. Ami annál is kínosabb, mivel a kezdés környékén oly aktív termékmenedzser a kódolás megindulásától a befejezésig lényegében munka nélkül lebzsel, de beavatkozni nem tud.
A fejlődési lehetőségek szempontjából sem ideális a waterfall alkalmazása. Nehéz mérni az egyes fázisokon belüli előrehaladást, és szinte lehetetlen időben azonosítani a fejlesztést lassító technológiai vagy üzleti szűk keresztmetszeteket (bottleneck), vagy más kritikus nehézségeket. Ezáltal nem sok mozgástér marad a hatékonyság növelésére.
