Agilis projektmenedzsment vagy klasszikus módszertan?

A hagyományos és az agilis módszertan hívei gyakran vitáznak arról, hogy melyik megközelítés a helyénvaló, de az az igazság, hogy mindkét módszertan alkalmassága gyakorlati példákkal alátámasztható, vagyis mindig az adott projekt és annak paraméterei kell, hogy eldöntsék, melyik úton induljunk el. Igazságot mi sem szeretnénk tenni, de mivel cégünk is sikerrel gyakorolja az agilis módszertant a szoftverbevezetések során, így szeretnénk megmutatni, milyen projektek, milyen vállalati kultúra és hozzáállás mellet lehet sikeres egy rendszerbevezetés agilis megközelítéssel.

Mit nevezünk agilis módszertannak?

Rugalmasság, dinamizmus, gyorsaság, hatékonyság, emberközpontúság. Talán ezekkel a szavakkal lehet leginkább jellemezni az agilis megközelítést. Az agilis módszertan tehát olyan projektmenedzsment megközelítés, amely elősegíti a projektben résztvevő tagok együttműködését, valamint a kész szoftver jó minőségben történő, gyors leszállítását helyezi fókuszba úgy, hogy mindeközben az ügyfél elvárásai is maradéktalanul teljesülnek.

Az agilis módszertan gyökerei az 1990-es évekre nyúlnak vissza, mikor is az alkalmazásfejlesztőkre jellemző laza, rugalmas magatartást szerették volna viszontlátni a projektmenedzsment terén is. Az agilis irányzatok hívei 2001-ben lefektették a legfőbb alapelveket, ez az un. Agile Manifesto, vagyis az Agilis Kiáltvány.  A kiáltvány kimondja, hogy:

• az egyének és a köztük lévő interakciók, vagyis a személyes kommunikáció előnyt kell, hogy élvezzen a folyamatokkal és eszközökkel szemben,
• a működő szoftver fontosabb, mint az azzal kapcsolatos részletes, átfogó dokumentáció,
• az ügyféllel történő együttműködés értékelendőbb a szerződéses tárgyalással szemben,
• a változásokra történő reagálást előnyben részesítjük a tervek követésével szemben.

Fontos, hogy megértsük az ügyféligényeket, ehhez pedig szükséges a tehetséges, motivált személyek együttműködése, vagyis a jó csapatmunka. Tehát nem magától a módszertantól lesz sikeres egy szoftverfejlesztés/bevezetés, hanem a projektben dolgozó tagok kiváló csapatmunkájától. A dokumentáció sem szabad, hogy öncélú legyen: a dokumentációnak mindig a szoftvert, annak működését kell szolgálnia, de sohasem lehet fontosabb, mint a jól működő szoftver. A szerződés mindig a szerződő felek együttműködését szabályozza, de sosem mehet a két fél közötti együttműködés rovására. Az agilis módszertan esetén is tervezünk, de ha változás történik a projektben, nem mehetünk el mellette csak azért, mert az az eredeti tervekben nem szerepelt, hanem módosítanunk kell a terveken a feltárt információknak megfelelően.

Az agilis irányzat követői azt vallják, hogy a fenti alapelvek betartásával sikeresebb szoftverfejlesztési/bevezetési projekteket hajthatunk végre. A kiáltványt olyan emberek fogalmazták, akik egytől-egyig valós projekteken dolgoznak, vagyis a gyakorlatban már megtapasztalták mindazt, amit az agilis módszertan alapelveinek tekintünk. A klasszikus és az agilis módszertanok képviselői egyetértenek abban, hogy a projektek célja a működő termék és nem a dokumentáció, ugyanakkor az is egyértelmű, hogy tervezés és dokumentáció nélkül nem lehet szoftvert fejleszteni. De azt sem vitatják, hogy a megrendelővel személyes kontaktus és együttműködés során kell menedzselni a projekteket és nem a szerződéseken keresztül, na de ki vállal be olyan kockázatot, hogy nem szabályozza szerződéssel az együttműködést? Érezhető tehát, hogy a fenti gondolatmenet mindkét irányzat számára elfogadható, mégis gyakran egymásnak feszülnek a felek. De mi ennek az oka?

Agilis vs. hagyományos

Induljunk ki a klasszikus, mások által csak hagyományosnak nevezett módszertanból, amely közel 40 éves koncepció már. Önmagában az, hogy már 1970 óta alkalmazzák, nem jelenti azt, hogy elavult lenne, a probléma nem ebben gyökerezik.

Dr. Winston W. Royce szerint, aki az un. vízesés modell megálmodója, a szoftverfejlesztési projekteket két nagy etapra kell bontani: elemzésre és megvalósításra. Persze míg a működő szoftverig eljutunk, ezeket a szakaszokat további etapokra kell bontanunk (rendszerkövetelmények, szoftverkövetelmények, programterv, kódolás, tesztelés, pilot és éles üzemeltetés). A hagyományos módszertan alapja, hogy a szoftverrel szemben támasztott elvárásokat a projekt elején meghatározzuk, készítünk egy tervet és e tervet követve implementáljuk a rendszert. Ugyanakkor az egyes etapokat végigjárva kizárólag a folyamat végén, a tesztelési fázisban van arra lehetőségünk, hogy leellenőrizzük, hogy a követelményeknek megfelelő szoftvert sikerült-e összehoznunk. Mondhatnánk, hogy nincs is ezzel baj, hiszen a tervet követtük végig, ugyanakkor egy projekt során egy dolog biztos: a VÁLTOZÁS! Vagyis a projekt elején hiába egyeztetünk le mindent, a munka során szinte mindig el kell térni a megbeszéltektől: a fejlesztés közben derülhetnek ki olyan információk, amik felboríthatják az előzetes terveket és új, megváltozott igényeket eredményezhetnek megrendelői oldalról.

Mi történik ilyenkor? Helyes az, ha nem vesszük ezeket figyelembe és elmegyünk az új információk mellett, mert azok az előzetes tervekben nem szerepeltek és nem a megrendelői igényeket kiszolgáló szoftvert vezetünk be? Nincs olyan projektvezető, aki erre igennel válaszolna. Mi is nap mint nap tapasztaljuk szoftverbevezetéseink során, hogy az előzetes tervektől bizony el kell térnünk, ami hatással van a tervezett költség- és határidőkeretre is.

A projektmenedzsment vasháromszöge

A projektmenedzsment vasháromszögének nevezzük az alábbi ábrán szereplő 3 kritériumot (szkóp, költség, határidő), melyet a minőség mentén határozunk meg:

Mindkét módszertanra ráhúzható a fenti ábra, különbség abban van, hogy mely kritériumok rögzítettek és melyeket tudunk csak megbecsülni. Az agilis módszertannál a vasháromszöget fordított vasháromszögnek szokás hívni, mindjárt elmondjuk azt is, hogy miért.

Míg a klasszikus modell esetében a szkóp (szoftverrel szemben támasztott követelmények) rögzített, mert a projekt elején meghatároztuk őket és e mentén haladunk a fejlesztés és bevezetés során, addig az agilis módszertannál a szkópot nem ismerjük biztosan, az a projekt során alakul, a projekt teljes hosszán egyenletesen oszlik el. Ez nem azt jelenti, hogy tervek nélkül vágunk bele a szoftverfejlesztésbe, hanem csak nyitva hagyjuk a kaput a megoldásra: előre csak azt rögzítjük, hogy milyen üzleti problémát akarunk megoldani és azt, hogy mindezt hogyan tesszük, a projekt során alakítja majd a csapat. Tehát az agilis modellnél a szkóp finomhangolható, a klasszikusnál azonban szigorúan rögzített.

Különbség van a költségek és határidők tekintetében is. Az agilis megközelítésnél a költségek és a határidők rögzítettek, míg a hagyományos modell esetében ezeket csak megbecsülni tudjuk. Mit jelent ez?  Míg az agilis irányzat hívei azt kérdezik, hogy „Ennyi pénzből, ennyi idő alatt mi fér bele?”, addig a tradicionális modell képviselői ezt a kérdést teszik fel: „Mennyi idő alatt és mekkora költségből lehet mindezt megvalósítani?”

Ha tehát ismerjük a szoftverrel szemben támasztott követelményeket, akkor megbecsülhetjük a projekt idő- és költségráfordítását. De mi van akkor, hogy rosszul becsüljük meg azokat? Ha projekt közben derül ki, hogy a követelmények ennyi pénzből nem megvalósíthatók? Két lehetőség van: vagy engedjük kedvezőtlen irányba elmozdulni a költségeket vagy a határidőt, vagy a minőségen próbálunk spórolni, így szoftverünk tele lehet hibákkal.

Az agilis projektmenedzsment lépései

Az agilis szoftverfejlesztési szemlélet a módszertan helyett a működőképes termékre, a motivált és a cél érdekében együttműködő projekttagokra helyezi a hangsúlyt. A csapat feladata tehát az, hogy a megrendelő által felvázolt üzleti problémára hathatós megoldást találjon úgy, hogy az a rögzített költség- és időkeretbe beleférjen.

Az agilis projekt kezdetekor össze kell szedni mindazon feladatokat, amelyeket a projekt során el kell végezni, mindezt megvalósítási sorrendben, a megrendelő számára az „értékesség” megfogalmazásával (backlog). Majd a csapat meghatározza, hogy mennyi feladatot tud elvállalni a következő ciklusra, értelmezi és pontosítja a backlog szakaszban megfogalmazott elvárásokat és elkészíti a feladatspecifikációt. (sprint backlog)

Az agilis szemléletet előnybe részesítő projektvezető több sprintre - egységnyi hosszúságú időszakra- bontja a projektet, egy-egy sprint 2-4 hetes periódust ölel fel. (sprint) Az egyes sprintekben a résztvevők önállóan szervezik a munkájukat, mindenki igyekszik megérteni a problémát és a legjobb tudása szerint részt venni annak megoldásában. Minden ciklus végén megtörténik a visszacsatolás (sprint kiértékelés), melynek következtében jobb minőség érhető el: bemutatjuk az elkészült terméket, kiértékeljük a megoldott feladatokat és megvizsgáljuk, hogy a felhasználói igényeknek megfelel-e a végeredmény. Így nemcsak egyszer, a projekt végén ellenőrzünk, hanem a folyamat során többször is. Az önszerveződő, motivált projektcsapat feladata tehát, hogy minden sprint végén tesztelt, jól működő, a megrendelő igényeinek megfelelő, dokumentált szoftvert szállítson le.

Mi lehet sprint egy szoftverbevezetés során? Például, ha a szoftvert nem teljes funkcionalitásában indítjuk el a megrendelőnél és zúdítjuk rá a felhasználókra, hanem fokozatosan kezdik el használni a rendszer funkcióit. Dmscloud szoftverünk esetében, mely 4 fontos területet ölel fel (dokumentumkezelés, csoportmunka, feladatkezelés, workflow), először érdemes csak a csoportmunka és dokumentumkezelés funkciókat (üzenőfal/hírfolyam használata, topiknyitás, kommentelés, dokumentum-megosztás) használatba venni, majd a következő sprintben jöhetnek a feladatkezelés funkciói, mint a feladatkiosztás és –fogadás, valamint ezek begyakorlása a kulcsfelhasználók által. Majd ha ezek a funkciók már olajozottan működnek, jöhet a munkafolyamat (workflow) tervezés, egyszerűbb és bonyolultabb workflow-k beállításával és használatával. Így dmscloud csoportmunka szoftverünk akár 10 hét alatt is bevezethető!

A fentiek alapján tehát ha egy gyakran változó környezetben dolgozunk, ahol a megrendelő igényei gyakran módosulnak, akkor az agilis modell lehet a célravezető, míg egy szabályokra, parancsokra épülő, változásoktól mentes környezetben a hagyományos projektmenedzsment módszert érdemes alkalmazni. Ha tapasztalt, megbízható, önszerveződő projekttagokkal dolgozunk együtt, akkor az agilis szemléletnek van létjogosultsága, míg az olyan szervezeteknél, ahol nem vállalják fel a döntéseket, problémás a felelősség vállalása és az egyének nem hajlandóak azonosulni a szervezet céljaival, ott a klasszikus megközelítéssel kell próbálkoznunk. A nagyméretű projektek esetén inkább a tradicionális, tervek által működtetett szemlélet működhet sikeresebben, míg kicsi és közepes projektméret esetén az agilis módszertan. Nincs tehát „rossz válasz”, mindig az adott projekt alapján kell eldöntenünk, hogy melyik módszertannal érhetjük el a legjobb eredményeket.

Forrás: http://dmsone-hu.blogspot.hu/

Ajánlott képzések:

Scrum- Agilis fejlesztési módszertan

A Számalk Training saját fejlesztésű képzése, amely során összehasonlítjuk a fejlesztési projekteben alkalmazható hagyományos és agilis módszertanokat.

Tovább