A vízesésmodell, agilis fejlesztés esetleg scrum vagy hibrid modell. Az informatikában, a szoftverfejlesztésben, ha projektekről beszélünk, ezek mindennapos fogalmak, hol egyiket, hol másikat alkalmazzuk egy-egy projekt kapcsán.

Egy sikeres projekthez kulcsfontosságú a megfelelő vezetési modell megválasztása, ezért összeszedtük saját tapasztalatainkat, hogy példákkal szemléltetve bemutassuk ezeket.

Ismerjük először meg az agilis és a vízesés modellt, és hogy mikor, melyiket érdemes használni.

Agilis modell

Az agilis szoftverfejlesztés hallatán mindenkinek olyan kifejezések jutnak eszébe, hogy daily (stand-up), planning, Scrum, Kanban, pair-programming, TDD, FDD, és még sorolhatnánk. Joggal merül fel a kérdés, hogy akkor mi is az agilis modell? Mindez, és még több; keretrendszerek (Scrum) és folyamatok (TDD, pair-programming) összessége, amelyek alapja a „The Agile Manifesto”  és az ehhez kapcsolódó 12 elv.

Úgy is összefoglalhatnánk, hogy ez egy olyan módszer, ahol az ügyfelek rövid idő alatt jól működő szoftvert kapnak, és aminek a fejlesztése során a csapat szorosan együtt működik az ügyféllel. Fontos, hogy a fejlesztési folyamat iteratív, kisebb szakaszokból áll, és nagyfokú rugalmasságot enged a változtatásban.

Az agilis módszertanok használatával hatékonyabb munka, a csapattagok bevonásával jobb munkamorál érhető el, amelynek eredményei a legmagasabb elvárásoknak is megfelelő alkalmazások.

A következő táblázatban az agilis szoftverfejlesztés módszertanának előnyeit és hátrányait pontokba szedve mutatjuk be.

Vízesés, azaz Waterfall modell

A projektvezetés klasszikus modellje, amelyben az egyes folyamatok egymásra épülve valósulnak meg: követelmények összegyűjtése, vizsgálata, majd tervezés, megvalósítás és sikeres tesztelés után az alkalmazás telepítése.

A waterfall szoftverfejlesztési modellben az egyes fázisok szorosan egymásra épülnek, így, ha az egyes folyamatok teljesítése nem történik meg időben, az könnyen a projektek nagyobb csúszásához vezet. Ez tehát nagyobb projekteknél kulcsfontosságú és megfontolandó kérdés, míg rövidebb projektek esetén a csúszás kevésbé valószínű, jobban tervezhető.

A következő táblázatban, az agilis modellhez hasonlóan összeszedtünk pár jellemző és fontos érvet/ellenérvet a vízesés modellhez is.

Agilis és Waterfall modell különbségek

És akkor vessük is össze milyen különbségek adódnak a két módszertanban. Az összehasonlításnál a projekt életciklusában az egyes állomásokat vettük alapul (mint például tervezés, ütemezés, megvalósítás, tesztelés), és az ezekben lehetséges lényeges különbségeket mutatjuk meg.

Ha tehát adott egy kisebb (néhány száz órás) fejlesztés, és az alkalmazás funkció is ismertek és még a felhasználói felület tervei is készen állnak, akkor a vízesés modell jól használható.

Minél jobban eltérünk ettől – pl.: a felhasználói felület elkészítése még csak most következik, vagy a funkciók nincsenek egyértelműen meghatározva – annál inkább javasoljuk az agilis módszertanok használatát, hiszen, ha a funkciók még nincsenek meghatározva, akkor a határidők tervezése nem kivitelezhető. Ha esetleg ezekre további funkciók épülnek, akkor pedig ez hatványozottan igaz.  A vízesés modell erőssége a tervezés, és kiszámíthatóság, ami ilyen esetekben nem valósítható meg.

Ha a felhasználó felület tervei – UX és design – nem állnak rendelkezésre, akkor jobb az agilis módszertanok használata, mert a felület tervezése közben tapasztalatink szerint sokat változik funkcionalitásában az alkalmazás. Ezeket a változásokat pedig nagyon nehezen kezeli a vízesés modell.

Hibrid megoldások

A gyakorlat azt mutatja, hogy új projektek esetében ügyfél oldaláról nézve a klasszikus vízesés modell szerint történne a projekt megvalósítása. Adott költségkeret, funkció lista és leggyakrabban már az élesítés időpontja is eldöntött.

Összetetten projektek esetében óhatatlanul felmerül, hogy a fejlesztés során az ügyfél változtatni szeretne a funkciókban, a rendelkezésre álló költségkeret és időkorlátok megtartása mellett.

Nagyobb projektek esetében jól használható megoldást nyújt a hibrid módszertan, ahol agilis és vízesés modellt használjuk. Fontos megjegyeznünk azonban, hogy ez nem azt jelenti, hogy ad-hoc hol egyiket, hol másikat használjuk, hanem már a projekt elején eldöntjük mit, mikor és miért.

Például egy nagyvállalati intranet rendszer elkészítésénél, ha a funkciókat csoportosítjuk, akkor a legfontosabbak készülhetnek el az első mérföldkőben, a közepesen fontosak a következőben, és így tovább.

Így a megrendelőnek a vízesés modell szolgáltat tervezhetőséget, a funkciók egymásra épülést mutatja. A fejlesztői csapatok pedig az egyes mérföldkövekben agilis módszertant követve fejleszthetnek. A mérföldkövek jobban tervezhetőek, és az egyes sprintekben lehetőség nyílhat a funkciók változtatására is.

Mit javaslunk tehát?

A gyakorlatban elég ritka, hogy a projektek tisztán agilis módszertan alapján valósuljanak meg. A költségkeret a legtöbb esetben fix, és túlnyomó részt a megvalósítás határideje is kötött. Ezek a megkötések nagyban leszűkítik az agilis módszertanok használatának mozgásterét. Priorizálással az átadás határideje ugyan sok esetben módosítható, de a fix költségkeret kevés rugalmasságot ad.

Sokszor elhangzik a megrendelő oldaláról, hogy az agilis fejlesztés egyenlő a drágább fejlesztéssel.

De melyik is valójában a drágább projekt? – Amelyik olyan funkciókkal rendelkezik amire szükségünk van, még ha a tervezettnél többet is fordítottunk rá, vagy az, amelyik a tervezett költségkereten belül valósul meg, de végül nagyon keveset használt funkciókkal is rendelkezik?

Hogy ne kelljen kellemetlen kompromisszumokat kötnünk, a hasonló helyzetekben döntsünk a hibrid módszer mellett.

A központi funkciókat jól megtervezve a vízesés modellt használjuk, míg a további funkciók esetén az agilis módszertant alkalmazzuk, hogy hatékonyan és közben rugalmasan valósulhasson meg a projekt.