Agilis Szoftverfejlesztök Egyesülete

"Agilizálás" - Dr. Haraszti Miklós

Az agilis megközelítést nem csak közvetlenül az agilis szoftverfejlesztésre, hanem az egész hozzá tartozó informatikai projektre kiterjesztve számos ellentmondásba, vagy kulturális, hagyományokon alapuló ellentétbe ütközünk. Ilyenek lehetnek a hierarchikus szervezeti környezet, a belső minőségbiztosítás követelményei, a hagyományosan "dokumentáljunk mindent" megközelítés, vagy a túlzott tervszerű működés. Lássuk be, hogy ezek a tényezők nem ritkák egy nagyvállalati környezetben, így nem véletlen, hogy a szakma kisebb-közepes projektek esetén javasolja az agilis módszertanokat.

Véleményen szerint - és ezzel inkább szakmai beszélgetést, együtt gondolkodást szeretnék indikálni - a mai magyarországi környezetre, a jelen valós helyzetekre értelmezve, komoly jelentősége lehet, egy speciális, a projektet "agilizáló" módszertan átvételének. Az alábbiakban az ide vezető utat világítanám meg.

Bizonyára mindenki megtapasztalta, amikor egy-egy fejlesztési, vagy bevezetési projekt kapcsán a kezdeti lelkesedés lankadásával, a munkafolyamatok beállásával mechanikussá váló középszakasz (általában 1-3 hónap között) a projektek belassulásához vezet. Ilyenkor még nincs nagy krach, nincs vezetői ejnyebejnye, de a projekttagok már-már érzik, hogy a csúszásnak következményei lesznek. Ilyenkor a legnagyobb a táptalaja a kollektív elhallgatásnak, amikor mindenki az időre játszik, és abban bízik, hogy a majd a másik szól, hogy "fiúk, most már gáz van!"

Rosszabb esetben egy ilyen állapotú projekt a szakasza kétharmadában belső kontroll alá esik, és felszínre kerül a belassulás következménye: nem ott tartunk, ahol terveztük. Most nem térnék ki a lehetséges alternatívákra, ki, milyen módon "mozdítja el" a projektet az ilyen, vagy ehhez hasonló "gödörből", a példában az a lényeges, hogy megrekedt állapotba, időleges felfüggesztésbe, leállásba kerülhet a fejlesztési projekt. (Jöhet a fejvakarás, hogyan tovább, más szereplőknél pedig a bűnbakok, felelősök keresése, hogy ez ne fordulhasson elő legközelebb - persze fog...)

Ezt a projektállapotot, pillanatot tekintem az "agilizálás" kiinduló pontjának. Az agilis módszertanok bevezethetőségének, alkalmazhatóságának nehézségei vezettek arra a gondolatra, hogy ezek a "korlátok", akadályok, nehézségek fellazulhatnak, ha eleve egy vesztett helyzetbe kerül az informatikai projekt. Márpedig szokott, így jó eséllyel játszhatunk erre. Vagyis ezen elvi módszer alapján, hagyományosan engedjük a projekt és a fejlesztés menetét mindaddig, amíg érzékelhetővé nem válik a fent leírt szituáció, amikor szinte minden projekttagra vonatkozóan elmarasztalás, kellemetlen helyzet, korrigálás, és ezek hatásai várhatóak. Akkor célszerű beavatkozni. Tudom, hogy sokkal nehezebb egy már folyamatban lévő projekt esetében alkalmazni az agilis módszertanok adta lehetőségeket, de tisztán agilis projektet sem könnyű indítani, ezért helyből nem célszerű a javaslatot elutasítani.

Hogyan agilizáljunk egy folyamatban lévő projektet? A képlet egyszerű, vegyük sorba a módszertani lehetőségeket, csoportosítsuk az érintett projekttagok szerint, hiszen lehetnek olyan módszertani változtatások, amelyek csak bizonyos személyeket érintenek. Lehetnek a folyamatban lévő projektben olyan tényezők, amelyek gyökeresen ellentétesek az agilis megközelítéssel, gondolok itt a megrendelő szervezetébe teljes mértékben beintegrált projekt tervezésre, vagy annak dokumentálására, ezek biztosan merev keretek ahhoz, hogy egy projektet agilizáljunk. A klasszikus "projekt" definíciók mentén haladva kapaszkodhatunk abba, hogy egy projekt, mint egy önálló egység akár teljesen önálló szervezettel, beosztással, módszertannal, metodikával, stb. rendelkezhet. Ha a projekt indításáig nem volt lehetőség agilis módszertanokat "erőltetni" a megrendelőre, integrálni a projektbe, itt a megrekedés pillanatában talán könnyebb ezt újból megpróbálni. Kifejezetten az informatikai projektekre jellemző a tanácstalanság, a kilátástalanság, amikor "technológiai" problémának álcázott, általában szervezetlenségen, vagy hanyagságon alapuló probléma gyökeresen elakasztja a projekt haladását. Nagyvállalati környezetben ezt nehezebb indikálni, mivel a sok szereplő, az ügyviteli mellékfolyamatok, vagy a folyamatban lévő szervezeti szintű jóváhagyások, vélemény ütköztetések, a sok megbeszélés elkeni a lényegi probléma felbukkanását, és annak hatásainak objektív belátását. Tehát az agilizálás arra épít, hogy gyenge pontot keres a már folyamatban lévő projektben, némi előre látással néhány projekttag felfedezheti a "vesztünkbe rohanást", és megkongathatja a vészharangot: "Állj, fiúk innentől agilisan csináljuk!" Tudom, hogy számos hátránya van ennek a megközelítésnek, például az agilis szinergiákat nem tudja visszaforgatni: mivel már megkötöttük a szerződést, közvetlenül nem fogunk jól járni a menet közbeni agilizálással. De ne feledjük, hogy erre eleve nem volt lehetőségünk, mivel a projekt már elindult agilis additívum nélkül. És gondoljunk a veszteségre amit a projekt csúszása, vagy a projekttagok fásulása okozhat. Ha kivágjuk a rezet, és egy-egy hagyományos projektet "megmentünk" az agilizálással, az agilis módszertan projekt-folyamatok közbeni adagolásával, akkor későbbi munkák során ennek pozitív hatásaira építve mi magunk is magabiztosabbá válunk, a referenciák meggyőzőbbé válnak, és talán hamarabb jön el az az idő, amikor a megrendelőt sikerül meggyőzni már a kezdetektől, az agilis megközelítés elvitathatatlan előnyeiről.

dr. Haraszti Miklós - DMSLabor