Amióta az agilis projektmenedzsment módszertanok számos területen és szektorban teret hódítottak – kiváltképp az IT-ban -, rendszeresen kérdésként merül fel, hogy az előre specifikált igényeken, erőforrásokon és határidőn alapuló hagyományos (waterfall vagy vízesés), vagy a változásokra könnyebben reagáló iteratív és inkrementális, tehát agilis modellek (pl.: Kanban vagy Scrum keretrendszer) képesek inkább hozzájárulni egy projekt sikeréhez. Ezeken felül persze számos irányzat és módszertan is elterjedt, de mi ebben a blogbejegyzésben elsősorban ezekkel foglalkozunk.
Az agilis projektmenedzsment hívei általában azzal érvelnek, hogy a folyamatosan változó piaci környezetben egy változásokat könnyen kezelő módszertanra van szükség, a hagyományos modell pedig ezt nem képes kezelni. Akik pedig a hagyományos projektmenedzsmentre esküdnek, sok esetben azért teszik, mert kevesebb kockázatot látnak benne, hiszen a projekt elején definiálva vannak az igények és a szükséges erőforrások.
Mindenki jogosan a saját jó vagy rossz tapasztalatára hagyatkozik, és az alapján formál véleményt. A negatív tapasztalatok adódhatnak abból, ha egy módszertan rá van erőltetve egy olyan projektre, amelyhez scope-ját és célját tekintve nem, vagy nem egy az egyben passzol a módszertan, de az is előfordulhat, hogy a sikertelenséget tévesen kapcsolják a módszertanhoz.
Tehát felvetődik a kérdés, hogy hogyan és milyen szempontok mérlegelése mentén érdemes eldöntenünk, hogy mely módszertan támogatja leginkább egy adott projekt sikerét. Bonyodalmakat, konfliktusokat és rengeteg felesleges energia és erőforrás pazarlást okozhat a módszertan rossz megválasztása, kiváltképp, ha a keretek nincsenek megfelelően kommunikálva az egyes szereplők számára.
Módszertani háttér
Mielőtt a mérlegelendő szempontokat végigvennénk, fontos, hogy néhány alapvető tudnivalóra rávilágítsunk, melyek segítenek megérteni a hagyományos és az agilis modell közötti különbségekeket.
Mindkét típus a szoftverfejlesztés területéről indult. A vízesés modell egészen a hetvenes évekre vezethető vissza, mikor is Winston W. Royce amerikai informatikus kidolgozta ezt a módszertant nagy szoftverek fejlesztésére. A Royce által kidolgozott módszertan lényege, hogy a fejlesztést részfolyamatokra bontják, melyek lineárisan követik egymást, azaz minden fázis csak akkor kezdődhet meg, ha az előzőt már befejezték és jóváhagyták. A fejlesztés folyamata az igények meghatározásával indul, ezt követően kerül sor a tervezési szakaszra, majd a fejlesztési szakasz után következik a tesztelés és az éles működés. Ez a modell annyira időtállónak bizonyult, hogy évtizedekig vezető szerepet töltött be a szoftverfejlesztésben olyannyira, hogy napjainkban is használjuk.
A különböző agilis módszertanok alkalmazása legalább annyi idős, mint a Royce-féle vízesés modell. Ezek hosszú evolúción mentek keresztül és sokáig nem voltak annyira elterjedtek, mint a hagyományos módszertan. Egészen a 90-es évekig, mikor is egyre intenzívebb lett a technológiai fejlődés, egyre erősödött a verseny, így a gyorsabb piacra lépés, az adaptív szoftverfejlesztés egyre fontosabb szemponttá vált.
A szoftverfejlesztésben széles körben használt Scrum keretrendszer is a 90-es évekből indult, ám az agilis módszerek elterjedésében a 2001-ben megjelent Agilis kiáltvány számított mérföldkőnek. A Scrum keretrendszer általánosan 2-4-hetes fejlesztési ciklusokat ún. sprinteket különít el, melyek során a csapat minden sprint végén működő funkciókat szállít le. A sprintek végén a csapat demót tart az érintetteknek, így gyors visszajelzést kapnak a funkciókról, és ezek alapján finomhangolható a szoftver. A Scrum másik fontos eleme, hogy a funkciók priorizálásra kerülnek és ebben a sorrendben zajlik a fejlesztés, mely a szakaszolt piacra jutást, az iteratív és inkrementális, tapasztalatokon alapuló szoftverfejlesztés megvalósítását teszi lehetővé.
Azt gondoljuk, bár a szívünkhöz közelebb áll az agilis megközelítés, hogy mindkét módszertannak vannak előnyei, így nem tennénk le a voksunkat egyik mellett sem, hiszen úgy véljük, hogy a projekthez kell módszertant választani. Lényeges kérdés ennek kapcsán, hogy mi alapján hozzuk meg döntésünket és emellett hogyan biztosítjuk a belső folyamatok stabilitását és állandóságát, mely a fejlesztő csapat számára is kiemelten fontos.
Mi alapján mérlegelünk?
A tervezés
Az egyik alapvető feltétele a vízesés modell alkalmazásának, hogy a fejlesztés kezdetére minden igény pontosan definiált és specifikált legyen a fejlesztés számára elegendő módon, hiszen ezt követően kezdődhet meg a design és a fejlesztési szakasz. Ez sok esetben egy hosszabb és átfogóbb tervezési szakaszt jelent. Ha az igények nem ismertek teljes mértékben a projekt elején, akkor viszont a Scrum alkalmazását érdemes mérlegelni. Ez a módszertan ugyanis megengedi a tervezési és a fejlesztési szakasz elcsúsztatott megvalósítását is. A gyakorlatban a design-sprint(ek)et követően már elkezdődhet a fejlesztés, párhuzamosan pedig folytatódhat a tervezés.
Erőforrások
Sokszor előfordul, hogy egy fejlesztés kapcsán jelentősen korlátozottak az erőforrások, a leggyakrabban a szűken szabott költségvetés vagy a rövid határidő jelenthetnek kihívást, melyekhez igazodni kell. Erősen korlátozott erőforrások esetén a tervezési szakasz optimalizálása mellett inkább a vízesés modell javasolt, hiszen az a tervek hatékony megvalósítását biztosítja viszonylag kevés változtatást engedélyezve. A változtatások nagy száma ugyanis veszélybe sodorhatja a határidő teljesítését, emellett a szűk költségvetés szigorú tartását is megnehezíti. Ahogy már a fentiekben is kitértünk rá, a vízesés modell alapvetően hosszabb tervezési szakasszal jár, hiszen a fejlesztés kezdetére annak már szükséges befejeződnie. Ennek ellensúlyozására lehet egy megoldás, ha a kulcs-funkcionalitást tartalmazó prototípus (MVP) kerül elsődlegesen megvalósításra, mely a tervezési szakasz optimalizálásában, a gyorsabb piacra jutásban, és a piaci tapasztalatokon alapuló további fejlesztési körökben tud segíteni.
Egy agilis, Scrum szerinti fejlesztés esetén egy megfelelő szervezeti kultúrában azonban optimálisabb lehet az erőforrásgazdálkodás. Ennek oka egyrészről, hogy inkrementális és iteratív folyamat mentén halad a fejlesztés prioritási sorrendben, emellett a folyamatok felülvizsgálata és javítása a módszertan része, ami folyamatos hatékonyság-javulást eredményez. Másrészről a fejlesztési folyamatban résztvevőket is közelebb hozza egymáshoz, transzparensebb kommunikációt biztosít, így az információáramlás is gördülékenyebb és a félreértésekből adódó problémáknak is kisebb a kockázata.
Változtatások
A hagyományos modell esetén a megrendelő általában a tesztelési fázisban, vagy ahhoz közeledve látja először a működő funkciókat. Emiatt ez az a szakasz, a szoftver fejlesztésének vége, ahol a legtöbb változtatási igény fogalmazódik meg a megrendelő részéről, hiszen a tapasztalás sokszor felülírhatja a terveket. A teljesen elkészült funkcionalitásban eszközölt változtatások azonban kockázatosabbak lehetnek, hiszen a felépített mögöttes logikában is komoly változást okozhatnak. Az agilis modell nem hagy ennyi időt a funkciók demózását illetően, így a folyamat közben tett változtatások kisebb erőfeszítést igényelhetnek.
A projekt mérete és komplexitása
Bizonyos projektméret felett már nem javasolt a hagyományos projektmenedzsment módszertan, hiszen nagyobb projektek esetén általában nincs annyi idő a fejlesztés megkezdése előtt, ami lehetővé tenné, hogy minden igény előre legyen specifikálva, emellett nagy lenne a kockázata annak, ha a folyamat közben nem fejlesztenénk működő funkciókat és arról nem kapnánk visszajelzést időben. A komplexitás és a méret pedig növeli azoknak a körülményeknek az előfordulását, melyek a projektben változást okozhatnak. Kis projektek esetében, amikor az igények tisztázottak, a hagyományos módszertan továbbra is egy jó opció lehet.
Miben mérjük a projekt sikerét?
A vízesés modellben a megfelelő szállítás kulcsa, hogy az előre definiált üzleti igényeket tartalmazó specifikáció szerinti szoftver került-e megvalósításra a tervezett erőforrásoknak megfelelően. Ezzel szemben egy agilis projekt esetén nagyobb hangsúlyt kap a szoftver üzleti értéke, hiszen a folyamat része alapvetően, hogy az elkészült funkciókat bizonyos időközönként megmutatjuk a megrendelő részére és a visszajelzéseket beépítjük mind a szakmai tartalomba, mind a folyamatba. Míg a vízesés modellben a mérés alapját a specifikáció jelenti, az annak való megfelelést követjük nyomon, az agilis modell az üzleti érték szerinti mérést biztosítja. Ez tulajdonképpen azt jelenti, hogy terv helyett a hozzáadott érték a mérés alapja, hiszen a megrendelő aktívan része a fejlesztési folyamatnak és az elkészült működő funkciókra ad visszajelzést. Emellett előfordulhat, hogy menet közben változnak az üzleti igények – módosulhatnak, kikerülhetnek korábbiak és kerülhetnek be újak -, melyeket egy agilis modell sokkal rugalmasabban tud kezelni. Habár itt az erőforrások bizonyos keretek közötti változása elképzelhető, egyúttal kisebb annak a kockázata, hogy a fejlesztés a leendő felhasználókat, egyúttal az üzleti célokat nem fogja megfelelően kiszolgálni.
Kommunikáció
A kommunikáció módja több aspektusból is különbözik a hagyományos és az agilis modell esetében. A hagyományos projektmenedzsmentben a tervezési folyamat és a tesztelési folyamat során a legintenzívebb a kommunikáció a megrendelővel, míg az agilis modell során egy folyamatos aktív kapcsolat, közös munka áll fenn. Minderre időt kell allokálni, amit már a projekt legelején érdemes tisztázni. Ám ezáltal az agilis modellben a megrendelő folyamatosan látja az előrehaladást a funkciók fejlesztése kapcsán, ami egy nagyon transzparens fejlesztést eredményez. Az agilis modellben a hierarchia és a hierarchikus döntéshozás kisebb szerepet játszik, hiszen a szereplők sokkal szorosabban dolgoznak együtt.
Érthetőség
Egy olyan szervezet számára, amely nem agilisan működik, első pillantásra riasztó lehet például a Scrum keretrendszer alkalmazása, hiszen sok újdonságot jelentő folyamatelemmel és fogalommal találkozhat. A hagyományos módszertan melletti érv, hogy sokak számára ez jelenti a biztonságot, hiszen egy könnyen érthető, széles körben elterjedt és ismert gyakorlatról van szó. Tudjuk, hogy az újdonság gyakran ijesztő is egyben, mégsem tanácsos kizárólag ez alapján a hagyományos módszertan mellett dönteni, érdemes megfontolni, hogy edukációval alkalmassá tegyük az ügyfelet és a projektpartnert a közös munkára.
Merjünk-e kombinálni?
Szinte kivétel nélkül minden szervezet a folyamataihoz igazítja az alkalmazott módszertanokat. Azt szükséges szem előtt tartani, hogy a projekt elején meghatározott célok mindenki számára világosak és egyértelműek legyenek és ne kövessünk olyan folyamatot, ami nem a célok megvalósítását támogatja. Bármilyen folyamatot is választunk, az elején biztosítsuk a megfelelő kommunikációt a közös munka kereteiről, és bizonyosodjunk meg róla, hogy a feltételek mindenki számára elfogadhatóak.
Veszélyben a folyamatok stabilitása?
Felmerülhet a kérdés, hogy egy fejlesztő csapat hogyan reagál arra, hogy bizonyos projekteket a hagyományos, bizonyos projekteket az agilis modell szerint valósít meg, hiszen mindez a belső folyamatokban is teljesen különböző működést feltételez. Mi, a Greenformatics-nál úgy biztosítjuk a folyamatok stabilitását, hogy projekttípustól függetlenül az agilis modell szerinti szerepeket és ceremóniákat tartjuk, az ügyféllel közös folyamatot pedig az adott projekt szerint megválasztott módszertan szerint visszük végig. Így a csapat számára biztosított a folyamatok stabilitása, a projekteket illetően pedig a megfelelő módszertan alkalmazása.