Az agilis módszertanokat alapvetően szoftverfejlesztésre dolgozták ki, a komplexebb feladatoknál viszont jobb hibrid megoldásokkal tervezni. A megrendelői oldal felé érdemes a waterfall szerint kommunikálni, hogy mikor, mit és mennyiért tudunk szállítani, míg a fejlesztői csapatok az agilis módszerekkel működnek hatékonyabban. A témáról bővebben Tild Attilával, a Projektmenedzsment az IT területén című kurzus előadójával beszélgettünk.
Milyen típusú projekteknél alkalmazható a hibrid módszertan?
Minden projektben, ahol nem egy darab szoftvert vagy alkalmazást kell fejleszteni, vannak nagyobb döntési pontok, mérföldkövek, résztermékek. Általában a magasabb szintű tervezést, a fázisokra bontást és az egyéb mérföldköveket a waterfall szerint rakjuk össze. Ezeken a nagyobb tömbökön belül tudjuk alkalmazni az agilis módszertan valamelyik verzióját, amikor is a fejlesztő csapatok már önállóan tudnak dolgozni. Projektvezetői szempontból ez azért jó forgatókönyv, mert így nem szükséges mikromenedzselni a technikai fejlesztési részeket. Ha van egy összeszokott fejlesztői csapat, egy product owner és egy scrum master, akkor a projektvezetőnek elég csak magasabb szinten kontrollálnia a munkát, nem kell az időtervezéssel és egyéb részletekkel foglalkoznia.
Tudna egy konkrét példát mondani?
Ez a módszer akkor alkalmazható, ha egy nagy szoftverrendszerről beszélünk, mint például az SAP, aminek számos modulja van. Ezek bevezetése, bár nem igényel részletes szoftverfejlesztést, de valamilyen szintű testreszabást igen. Ez a feladat végezhető valamilyen agilis módszertan szerint, viszont az egyes modulok egymásra épülését, vagy épp a párhuzamosságát már waterfall szerint szoktuk megtervezni.
Hogy egy másik példát is említsek: dolgoztam Telco számlázási rendszerek bevezetésén is, ami szintén egy nagy moduláris rendszer, rengeteg adattal dolgozik, a modulok egymásra épülnek és egymás adatait használják. A folyamatok egymásutánisága tehát adott, a rendszer felépítéséből adódóan vannak folyamatok, amiket előre meg lehet tervezni waterfall szerint. Gondolok itt arra például, hogy egy elemnek mikorra kell készen lennie, hogy tovább tudjunk lépni. Viszont ezen belül a fejlesztői csapatok kvázi önállóan dolgoztak, nem szóltam bele, hogyan programozzák le az egyes részeket. Hozzáteszem, hogy egy, ezen a területen rutinos, összeszokott csapattal dolgoztam, ami szerencsés felállás volt. Nagyjából tehát ezek azok a pontok, ahol az agilis és waterfall módszertanok keveredni tudnak.
Ezek szerint a legtöbb projekt igazából hibrid módszertan szerint épül fel?
Ez akkor igaz, ha elég komplex szoftverfejlesztésről beszélünk. Mindig hangsúlyozom, hogy az agilis módszertanokat alapvetően szoftverfejlesztésre találták ki. Hardverrendszerek telepítését, adatközpontok költöztetését, távközlési vonalak kiépítését – amik ugyanúgy a Telco-szektor feladatai – nem lehet agilis módszertan szerint kivitelezni.
Alapvetően akkor érdemes hibrid módszertanban gondolkodni, ha a szoftverfejlesztés elég nagy hangsúlyt képvisel a projekten belül. Ekkor lehet ezt a területet kicsit önállósítani, és engedni, hogy agilis módszertan szerint dolgozzanak – ellenőrizve persze, hogy megfelelő tempóban haladjanak. A projekt egészét viszont nem így fogjuk kidolgozni, hiszen a megrendelő felé más ütemben kell beszámolnunk, és más elszámolási pontok szerint dolgozunk.
Ez a fajta keveredés a projekt minden szereplőjét érinti, vagy csak a projektvezetői szinten jelenik meg?
A hibrid módszertan alkalmazása leginkább a projektvezetőnek és a fejlesztőcsapat vezetőjének a munkáját érinti. Ugyanakkor, mikor összeállítjuk a projektcsapatot, akkor az agilis alapon szerveződő egységeknél kicsit más lesz a felépítés, mint a klasszikus modulokon dolgozóknál (megjelenik például a scrum master). A fejlesztői csapat szempontjából nem fontos, hogy felettük épp agilis vagy waterfall módszertan szerint zajlik a munka, viszont náluk a határidők betartására oda kell figyelni.
Az agilis módszertan egyik veszélye, hogy a fejlesztési projektek a végtelenségig elnyújthatók. Az alaphelyzet az, hogy egy projektnek van egy végső, illetve az egyes mérföldköveknek is van egy-egy belső határideje. Ha egy agilis módszertan szerint dolgozó csapat ehhez képest másféle tempóval kezd el dolgozni, akkor a projektvezető feladata, hogy erre időben odafigyeljen. Nem lehet teljesen felügyelet nélkül hagyni a fejlesztői csapatokat még agilis működés esetén sem.
Meg lehet húzni a határokat, hogy mi az, amit waterfall szerint, és mi az, amit agilis módszertan szerint valósítunk meg egy projektben? Van a hibrid megoldásban valamiféle kockázat?
Kockázat mindig van, de ebben az esetben ez kezelhető mértékű. Az egyik tényező, ami meghatározza, mennyire alkalmazhatunk hibrid módszertant az az, hogy az átvevői, megrendelői oldal mennyire támogatja az agilitást. A felsővezetők azért még ma is azt szeretik látni, hogy mi a feladat, annak ki a felelőse, mi a határideje és mennyibe fog kerülni. Ha azt mondjuk a megrendelőnek, hogy itt a product owner, ő tudja, mi kell neked, és itt a fejlesztői csapat, akik elkezdenek ezen dolgozni, aztán készen lesz, amikor készen lesz, vagy amikor el nem fogy a pénz – nos, nem hinném, hogy ezzel bármilyen vezető szívesen megbarátkozna.
A megrendelői oldalon tehát inkább a waterfall szerint nézik a projektet, így ezen a szinten érdemes így tervezni, és feléjük így kommunikálni a mérföldkövekre, a részteljesítésekre, az ellenőrzési pontokra koncentrálva felépíteni a projektet. Nem utolsósorban ezekhez a mérföldkövekhez általában valamiféle fizetési kötelezettség is társul, amivel a megrendelő tervez, de hogy azon belül a fejlesztői csapat pontosan hogyan dolgozik, az már kevésbé érdekli őket.
Van az agilis módszertannal kapcsolatban egy elég rossz megközelítés, amikor a felsővezetői szinten vagy a megrendelői oldalon csak annyit tudnak, hogy ez az a módszertan, amivel fele annyi ember kétszer annyi munkát tud elvégezni, fele annyi pénzért. Ez okozhat kínos perceket, amikor ezeket a félreértéseket tisztázni kell, de mégis jobb az elején elmondani, mit is jelent az agilitás, és mit nem. Az sosem vezet jóra, ha megpróbálunk megfelelni az irreális elvárásoknak.
Volt ilyen jellegű tapasztalata, amikor a megrendelő valami teljesen kivitelezhetetlen ötlettel állt elő?
Volt egy eset, ahol leginkább a határidőre vonatkozóan voltak lehetetlen elvárások. Egy komplex rendszerről volt szó, szerencsétlenségünkre az egyébként nem informatikával foglalkozó megrendelő valahonnan kapott egy tippet, ötletet, így minket már azzal kerestek meg, hogy egy konkrét megoldást kérnek. Hosszas párbeszéd és egyeztetés kellett ahhoz, hogy kiderítsük, pontosan miért is ezt kérik, hiszen láttuk, hogy nem kivitelezhető. Bárki, aki elvállalná, belebukna. Az esetnek azért pozitív vége lett, mert végül sikerült kideríteni, hogy mi volt az alapproblémájuk, így tudtunk ajánlani egy működő megoldást.
Kanyarodjunk vissza a hibrid projektekhez. A klasszikus módszertan lényege, hogy egyértelmű keretek, célok, eredmények vannak lefektetve, míg az agilitás sajátossága a rugalmasság. Adódnak ebből az ellentmondásból konfliktusok egy hibrid projekt esetében?
A feszültségek általában a határidők vagy a büdzsé csúszásából adódnak. Ezért kell a projektvezetőnek egy hibrid projekt esetében is odafigyelni, hogy az egyes sprintek megfelelően haladnak-e. Egyébként erre a waterfallban is van egy hasonló technika, amikor egy hosszú, nagyobb volumenű feladatról van szó, akkor azt szétdaraboljuk úgynevezett work package-ekre, és ezek eredményeit külön-külön ellenőrizzük. Hogy egy egyszerű példával éljek, ha építenünk kell 100 km autópályát, azt sem úgy csináljuk, hogy elkezdjük holnap, és hat hónap múlva megnézzük, hogy megvan-e a századik kilométer. Ehelyett elkezdjük hétfőn, és megnézzük pénteken, elkészült-e az első 3 km. Ugyanez igaz az agilis módszertan szerint működő csapatokra is, vagyis sprintenként kell ellenőrizni, hogy a megfelelő tempóban dolgoznak-e a fejlesztők.
Amikor egy agilis alapú fejlesztés összeáll, akkor nagyjából tudjuk, hogy mekkora feladatról van szó, és mennyi időnk van rá. Ez alapján megállapítjuk a csomagok nehézségét, és ezt beáraztatjuk. Nagyjából pár hét után már látni fogjuk, hogy a tervezett ütemezéssel nagyságrendileg rendben haladunk-e, vagy sem. Ha nem, akkor közbe kell avatkozni, és a megfelelő változtatási kérelmet benyújtani.
Sok oka lehet annak, hogy nem haladunk a kellő tempóban, ez lehet tervezési hiba, valamilyen hiányzó információ – a lényeg, hogy a projektvezető jelezze ezt időben. Amit a kurzuson is hangsúlyozok, hogy minden projektet az elején megtervezünk, és ezeket a terveket aztán mindkét oldal elfogadja. A szállítói oldalon a saját embereimmel is validáltatom, hogy az adott feladatot adott idő alatt el tudjuk végezni, az ügyféllel pedig hogy ezt átveszi és kifizeti. Ha ehhez képest eltérés van, de megfelelően indokolni tudjuk, az mindkét fél számára elfogadható.
Sok forrás említi, hogy a legnagyobb hiba, amit véthetünk, ha egy projekten belül ugrálunk a módszertanok között. Ez mennyire életszerű?
Ha ilyen történik, akkor az egy vezetői és tervezési hiba. A projektek elején el kell dönteni, mit hogyan fogunk csinálni. Ha működik, amit elterveztünk, akkor semmi gond, ha nem, akkor változtatni kell. Ad hoc jelleggel váltogatni a módszertanok között már csak azért is nagyon rossz, mert a projektekben általában ideiglenesen összeállított csapatok által leszállított egyedi termékről szólnak. Ettől projekt a projekt, hogy ideiglenes, van eleje, van vége, és van egy termék, ami elkészül, ehhez pedig egyedi teamek alakulnak.
Idő kell, mire ebből a csapatból összeszokott egység válik: Forming – Storming – Performing. A módszertanok közötti ugrálás ezt az egyenes folyamatot egy zegzugos útvesztővé alakítja, és a csapat sohasem fogja tudni, hogy éppen mit kell csinálnia, vagy ha mégis, nem lesz elég idejük, hogy megfelelően teljesítsenek. A projekttervezés része, hogy a módszertant is meghatározzuk. Ha mégis azt látjuk, hogy valamiért nem működik, akkor sem az a megoldás, hogy ide-oda ugrálunk.
A hibrid módszertanoknál szeretik a mutatót mindig egy kicsit az agilis módszertanok irányába tolni. Magát az agilitást sokszor válságkezelő csodafegyverként akarják alkalmazni, pedig ez nagyon távol áll a valóságtól. Az agilitás nem egy ún. „silver bullet”, nem lehet megölni vele a vámpírokat. Azaz ne próbáljuk meg válságkezelésre alkalmazni, ha van egy problémánk, nem az a megoldás, hogy indítunk rá egy agilis projektet. Sőt sokszor még csak nem is a projektindítás jelenti a megoldást. Azt látom, hogy a vállalati kultúrában a projekt és a projektvezető fogalma nagyon sokszor még összekeveredik a kríziskezeléssel, az agilis módszertan pedig sok helyen úgy épült be a köztudatba, hogy a projektvezetésnek ez az a speciális ága, amivel mindent meg lehet oldani tíz perc alatt. Az agilitás nem erről szól, és a hibrid projektek tervezésekor sem szabad így gondolni rá.
Kapcsolódó kurzusok:
