Egy korábbi blogposztunkban arról írtunk, hogy mik az előnyei a SCRUM módszertannak, azonban nem tértünk ki arra, hogy bizony nem minden esetben alkalmas maradéktalanul arra, hogy a projekt minden szereplője elégedett legyen.
A SCRUM alapvetően a projekt legtöbb érintettjétől erős bevonódást követel meg, hogy a produktum végül megfelelő formában készüljön el. Fontos, hogy a SCRUM első megjelenése és korai adoptálói olyan csapatok voltak, akik saját termékük fejlesztésén dolgoztak, amelynek az ötletgazdája minden esetben a csapat szerves részét tudta képezni. A szoftverfejlesztésben mint iparágban azonban nem csak saját terméken dolgozó csapatok vannak, hanem sok esetben egy megrendelő számára készül egy projekt.
Alapvetően a külső fejlesztőcsapat önmagában nem jelenti azt, hogy a SCRUM módszertan nem lehet sikeres, azonban vannak olyan követelmények a csapattal szemben, hogy eredményesek legyenek, amiknek nem biztos, hogy minden esetben meg lehet felelni.
A legfontosabb elem, amely sokszor nem valósul meg kifogástalanul a megrendelésre készülő projektek esetén, az az, hogy a megrendelő vagy annak képviselője szerves része legyen a SCRUM csapatnak a projekt teljes ideje alatt, vagy legyen kapacitása arra, hogy a dedikált csapattaggal (PO) gyakran és felkészülten egyeztessen.
De miért baj, ha ez elmarad? Tömören azért, mert így az agilis szemlélet mögé bújva, hisz majd “később áttervezzük, ha nem jó”, nem megfelelően átgondolt tervezés miatt indokolatlanul megnőhet a fejlesztési idő, és ezzel könnyen túlléphető a fejlesztési keret is. Sajnos, ha agilis szemlélettel állunk egy projekthez, akkor a megrendelő oldaláról sem működik a “majd a végén megnézem, amikor elkészült” hozzáállás.
Jellemzően a klasszikus iparágakból érkező, régi szervezeti múlttal és az idők alatt változatlan management nézetekkel rendelkező megrendelők azok, akik a mai napig nem minden esetben alkalmasak egy SCRUM típusú együttműködésre. Ezekben az esetekben érdemes egy alapos tervezési szakasszal indítani, amely után a véglegesített és elfogadott terveken csak a fejlesztés lezárultával lehet módosítani. Ez természetesen a fejlesztőcsapat számára nem a legideálisabb működés, azonban van, amikor elkerülhetetlen ez a fázis.
Alapos tervezési fázissal és megfelelő technikai, illetve funkcionális tervekkel elkerülhető a gyakori verem, amelybe sok fejlesztés esett a múltban, és esik ma is, hogy nem megfelelő specifikáció miatt olyan software készül el a folyamat végén, amely alkalmatlan a megrendelő igényeinek kielégítésére. Ennek a fontosságát meg kell értetni az ügyféllel, és enélkül nem szabad belekezdeni egy vízesés modellbe felépített projektbe, mert így a negatív sztereotípiákat erősíthetjük tovább a módszertan kapcsán.
Az ügyfélen múlik?
Egyszerű lenne azt mondani, hogy “ne vállaljuk el azokat a projekteket, ahol az ügyfél nem megfelelő az agilis módszertanok alkalmazására”, de az élet nem fekete-fehér. Egy jó kiindulási alap lehet, ha az ügyfél számára a projekt kezdetekor biztosítunk lehetőséget agilis trainingen való részvételre, de ez sem garantált megoldás minden esetben. Ezek alapján van, amikor érdemes az ügyféllel való munkavégzést klasszikus, bár adminisztratív szempontból sokkal időigényesebb vízesés modell keretei közé szorítani, aminek ugyan később lesz kézzelfogható eredménye az ügyfél számára, de a projekt a megrendelő nézőpontjából konkrétabb, az ő kultúrájuk szerint kezelhetőbb mederben zajlik.
Hogyan lehet megvalósítani a vízesés modellt?
Amire kiemelten fel kell hívni a figyelmet a vízesés modell kapcsán, azaz, hogy mivel a modell feltételez egy elég alapos dokumentációt, és annak elfogadását továbbá betartását, így a fejlesztés jellemzően nehezen tud alkalmazkodni, ha menet közben esetleg megváltozik a megrendelői igény. Ez lehet előnyös fejlesztési oldalról, hiszen a vízesés ugyanúgy keretet ad a megrendelői oldalnak is, amiket annak be kell tartania. Természetesen túlságosan idealista hozzáállás lenne azt mondani, hogy a lefektetett szabályokat mindenki mindig követi, de erősen kézben tartott ügyféllel ez teljes mértékig lehetséges.
Tömören összefoglalva, a vízesés modell akkor jó, ha mind a kiindulási ponttal, mind a céllal tökéletesen tisztában vagyunk, illetve a cél eléréséhez szükséges utat közösen, kétséget kizáróan meg tudjuk tervezni, viszont a legnagyobb kockázat az, ha le kell térni a tervezett útról.
Szerző:
Kujbusz Péter – Product owner
Stylers