Az agilis szoftverfejlesztés és a projektmenedzsment együttműködése egy új és érdekes téma, amelyről egyre többet hallani. A kor kihívásaira válaszolva 2011 második felétől megjelenik a PMI Agile minősítés. Vajon milyen viszonyban áll a projektvezető és a szoftverfejlesztő, hogyan lehet összeilleszteni az agilitást a jól bevált projektvezetési módszerekkel?

Az agilis szoftverfejlesztés és a projektmenedzsment együttműködése egy új és érdekes téma, amelyről egyre többet hallani. A kor kihívásaira válaszolva 2011 második felétől megjelenik a PMI Agile minősítés. Vajon milyen viszonyban áll a projektvezető és a szoftverfejlesztő, hogyan lehet összeilleszteni az agilitást a jól bevált projektvezetési módszerekkel?

Eredeti forrás: http://www.hiradastechnika.hu/data/upload/file/2011/HT2011_4_10.pdf

Írta: Csutorás Zoltán CSM CSP, Agilis projektvezetési tanácsadó, Adaptive Consulting Kft., és Kocsis Árpád, Section Manager, Nissan Europe Information Systems

1. Bevezetés

Mind az agilis szoftverfejlesztés, mind a projektvezetés olyan terület, ahol temérdek könyv, tanfolyam és cikk áll rendelkezésre. Mind a két terület rendelkezik szervezett képzési és minősítési rendszerrel. Azt szeretnénk megvizsgálni, hogyan fog e két terület a valós életben, a gyakorlatban találkozni, amikor a szoftvert agilisan fejlesztik projektszerű keretek között.

Arra a kérdésre keressük a választ, milyen egy igazi, „éles” agilis szoftverfejlesztés üzleti környezetben, azaz olyan vállalatok kontextusában, ahol az IT üzleti célokat szolgál ki, tehát a kiszolgáló folyamatok része. A szoftverfejlesztést a vállalat szemszögéből vizsgáljuk.

A szoftverfejlesztés az ICT és IT területen működő cégek esetén (pl. Nokia, Microsoft, Apple) – tehát ahol a szoftver maga a termék – kicsit más, bár sok megállapítás ebben a környezetben is megállja a helyét. Ugyanígy félretesszük a kutatás-fejlesztési (R&D) területet. Elsősorban arra az esetre koncentrálunk, ami tipikus lehet egy informatikai cég, egy kkv számára: vállalati környezetben történő üzleti célú szoftverfejlesztés. Nem teszünk különbséget belső, külső vagy kiszervezett fejlesztés között – a cikk megállapításai érvényesek mindhárom esetben.

A célunk az, hogy a rámutassunk az összefüggésekre, ok-okozati viszonyokra, és azokra a kényszerekre, amelyek mentén az agilis szoftverfejlesztésnek a projektvezetéssel együtt kell mozognia.

2. A vállalati környezet

A környezet leírására a MOST piramist használjuk némi módosítással, lásd 1. ábra.

A vállalatot a Tulajdonos érdekei mozgatják – a Tulajdonos profitot szeretne termelni. A Menedzsment  határozza meg a célokat és a stratégiákat. A stratégia megvalósítása taktikai szinten projekteken keresztül történik, amelyeket a PM vezet a megfelelő projektvezetési módszertan alkalmazásával. A munkát az informatikusok végzik, azaz ők fejlesztik ki a szoftvert. (Természetesen létezik projekt informatikus nélkül is, de az most számunkra nem érdekes.)

Konkrét példa autóipari környezetből:

A hatalom gyakorlása, az érdekek érvényesítése felülről lefelé történik, azaz a tulajdonos céljai adják a menedzsment feladatait, a menedzsment által szabott célok szerint dolgozik a projektvezető, és a projektvezető ad feladatokat az informatikusoknak. A fejlesztői csapatok feladata a felülről meghatározott célok elérése, a feladatok végrehajtása.

A tulajdonos, a menedzsment és a projektvezető elvárása a projektekkel szemben a kiszámíthatóság, tervezhetőség és a keretek között maradás (time-budget-scope-quality).

A fejlesztő áll a piramis alján, és jól látható, hogy alkalmazkodni kényszerül a felette meghatározott célokhoz és tervekhez. Illetve ha nem akar, akkor majd keresnek másik fejlesztőt.

Az IT projektnek ebben a közegben kell léteznie, és az informatikusnak alkalmazkodnia kell a vállalati környezethez. Más út nincs.

3. Projektmenedzsment

Vállalati környezetben a változás eszköze a projekt – legyen szó bármilyen változásról és bármilyen iparágról. Minden nagyobb fejlesztési feladat projektszerűen zajlik. A projekt környezetet a 2. ábra szemlélteti.

A projektek vezetése módszertanok alkalmazásával történik. A nagyvállalatok kialakították maguk módszertanát, amely a nemzetközi szabványok, pl. PMI ajánlás vagy PRINCE2 adaptációját jelenti.

Az informatikai feladatok szükségszerűen egy üzleti projekt részeként valósulnak meg, annak keretein belül. Azonban a projekt és a szoftverfejlesztés nem azonos! A projekt jóval azelőtt elkezdődik, mielőtt a fejlesztők nekiállnának dolgozni, és nem fejeződik be ott, amikor a szoftver elkészül, lásd 3. ábra.

Jól látható, hogy még mielőtt a fejlesztőktől megrendelnénk a szoftvert, a projektet fel kell építeni. Illetve látható, hogy a kész szoftver még nem elég, azt át kall adni az üzemeltetésnek, illetve stabilizálni kell az üzemeltetést.

Az előző szakaszban említett példához visszatérve: a projekt nem akkor van kész, amikor a szoftvert átadták, hanem amikor az új autómodell értékesítése gond nélkül zajlik.

A munka a szigorúan vett fejlesztési feladatoknál jóval szélesebb, a keretek a szoftverfejlesztés megkezdésekor adottak. A rendszerfejlesztéshez kapcsolódó tradicionális szabványok és módszertanok (pl. ISO 12207) figyelembe veszik a rendszerfejlesztésnek ezt a tágabb értelmezését.

4. Módszertanok és szemléletmódok

Az üzleti környezet meghatározása és a projektmenedzsment után most essék szó a szoftverfejlesztésről. Amikor vízesésről vagy agilis fejlesztésről beszélünk, akkor tulajdonképpen nem egy-egy módszertanról van szó, hanem szemléletmódról.

A vízesés vagy PPP szemlélet lényege a munkafolyamatok fázisokra bontása (ezért is használják rá a PPP – phased product planning – elnevezést), és a tervezés fontossága. A vízesés kifejezést ennek a szemléletmódnak az elnevezésére használjuk a továbbiakban, és beleértjük mindazon módszertanokat, amelyek megfelelnek a definíciónak.

Az agilis modellt ezzel szemben arra szemléletmódra használjuk, amely az egyénekbe és a csapatba vetett bizalomra épül, elfogadja a fejlesztési folyamatokban lévő bizonytalanságot és ezért ciklikus fejlesztési megközelítést javasol.

A vízesés modell kora és kialakulása miatt jól összekapcsolható a projektmenedzsment módszerekkel. Ugyanakkor a projektmenedzsment módszertanok és ajánlások nem mondják azt, hogy csakis vízesés modell szerint lehet szoftvert fejleszteni.

Már csak azért sem, mert a projektvezetés és a szoftverfejlesztés a projekt különböző szintjeit jelentik (lásd 1. ábra).

5. Az agilis szoftverfejlesztés

Az agilis szoftverfejlesztésre elsősorban mint értékrendszerre érdemes tekinteni. Az agilis kiáltvány és a 12 agilis alapelv is röviden és világosan megfogalmazott értékrendszert rögzít. Ennek az értékrendszernek a lényege a gyorsaság, a változásra való reagálási képesség, az egyének és a csapat képességeibe és motivációjába vetett bizalom, a működő terméknek, mint a siker egyetlen mércéjének a elismerése. Az agilis szemlélet nem más, mint a értékrendbeli hangsúlyok erős megváltoztatása a vízesés szemlélethez képest. Amíg vízesés szemlélet kiindulási pontja, hogy az a team, amelyik jól kidolgozott eljárásokat, szabályokat és szervezeti felépítést követ hatékony lesz, addig az agilis szemlélet abból indul ki, hogy ha a megfelelő emberekből összeállított team elé világos célokat tűzünk ki, és világos kereteket jelölünk ki számukra, akkor azok hatékony eljárásokat, szabályokat és szervezeti felépítést fognak kialakítani. A különbség tehát a kultúra és a team kialakításának sorrendjében van, nem pedig abban, hogy szükség van-e szabályokra. Az agilis szemlélethez igazodó modellek egy olyan keretrendszert definiálnak, amelyek azt írják elő a megvalósító csapatok számára, hogy tudatosan, és megállás nélkül vizsgálják felül saját működésüket, és a termékkel párhuzamosan saját szabályaikat és eljárásaikat is folyamatosan fejlesszék. Ezek a keretrendszerek nem a termék megvalósítására vonatkozó módszertanok, hanem olyan szabályok és szervezeti keretek, melyek az egyedi problémákra testre szabott eljárások kialakítására késztetik a megvalósító teamet.

Az agilis szoftverfejlesztési alapelvek mentén számos módszertani keretrendszer alakult ki. Ezek közül a legismertebb a Scrum, de vannak más érdekes irányzatok is pl. az eXtreme Programming, a DSDM, vagy a Kanban System for Lean Software Development. Az agilis keretrendszerek sosem lesznek módszertanok, mivel az alapelvük az igényekre történő adaptáció és a folyamatos javítás érdekében történő állandó változtatás.

Az agilis módszerek hatékonysága akkor mutatkozik meg igazán, ha a projekt célja egy új (még nem létező) termék fejlesztése. Ebben az esetben nincs hová visszanyúlni, alig állnak rendelkezésre tapasztalati alapok, tehát nincs okunk azt hinni, hogy létezik olyan módszer, ami az új problémára megoldást tud kínálni. Ezekre a projektekre az a jellemző, hogy csak homályosan ismerjük az elkészítendő termék körvonalait, nem rendelkezünk kellő információval a pontos specifikációhoz, nincsenek tervezési mintáink a tervek elkészítéséhez és nem tudjuk előre azonosítani azokat a tevékenységeket, amelyek az új termék előállításához fognak vezetni.

A Scrum egyik ihletőjeként számon tartott „The New New Product Development Game” c. cikkében pont olyan projekteket és csapatokat vizsgált, amelyek ilyen, instabil elvárások mellett értek el kiemelkedő eredményeket. A feladatok, amelyekre ezeket a teameket létre hozták például ilyenek voltak: „Ki kell fejleszteni egy olyan nyomtatót, ami a cég jelenlegi csúcskategóriás nyomtatóinak paramétereivel rendelkezik, de a gyártási költsége annak maximum a fele. A termék kifejlesztésére a team 24 hónapot kap, pont fele annyit, mint a termék elődjének kifejlesztésére felhasznált idő.” /Fuji-Xerox, FX-3500 projekt/ Az ő általuk „rugby módszernek” nevezett alapelvek szolgáltak kiindulási pontként a Scrum keretrendszer kialakításához.

Fontos tehát kiemelni két olyan tényt, ami meglátásunk szerint általában nem kap kellő hangsúlyt az agilis módszerek tárgyalásakor. Az első, hogy a Scrum elvei szerint szervezett teamekkel szemben eredetileg igen kemény, kőbe vésett határidő, költség, minőség és cél (nem követelmények/scope) elvárásokat támasztottak. A szabadsági fokuk a cél elérésének módjában volt. A másik, hogy ezeket a teameket olyan termékfejlesztési feladatok megvalósítására alakították, melyek jelentős mértékű innovációt igényeltek. Ezekre a projektekre az volt a jellemző, hogy ismeretlenek voltak a módszerek, amelyekkel a cél elérhető lett volna és nem volt világos koncepció a célt kielégítő termék jellemzőire vonatkozóan.

Ha az agilitást úgy értelmezzük, hogy az a teamek felhatalmazása a termék jellemzőinek megfogalmazására és a saját munkamódszereik kialakítására, akkor az agilitás kívánatos szintje az innováció mértékétől, azaz a megvalósítandó termékkel szemben támasztott elvárások előre történő megismerhetőségétől függ. Minél inkább biztosak vagyunk abban, hogy pontosan mit szeretnénk előállítani és ezt hogyan kell megtennünk, annál kevésbé szükséges az agilitás. Ekkor az energiánkat nem arra kell fordítani, hogy teljesen új munkaszervezési módszereket dolgozunk ki. (A módszerek javítása ugyanakkor továbbra is fontos kell, hogy legyen!) Ezzel ellentétben, ha jelentős az innováció a projektben, nincsenek tapasztalatok és minták a termék koncepciójának részletes meghatározásához, akkor majdnem biztosak lehetünk benne, hogy a szigorúan fázisolt PPP módszerek kudarchoz vezetnek. Ekkor az agilis szemlélet eszköztárához kell nyúlnunk.

6. A látszólagos ellentmondás

Mi fog történni akkor, amikor a Scrum Master (tegyük fel, hogy a fejlesztés Scrum szerint történik) összeül megbeszélni a projektmenedzserrel a munka indítását?

Bábeli zűrzavar lesz. A Scrum Mastert felkészítették arra, hogy hatékonyan irányítson egy agilis szoftverfejlesztést, de arra nem, hogy egy klasszikus projekt keretein belül dolgozzon. A Scrum Master képzések jellemzően nem szólnak a projektek tágabb környezetéről.

A másik oldalról nézve, a projektvezetőnek nem mondták el, hogy léteznek agilis módszertanok, ezek mit jelentenek, és mi az ő szerepe egy Scrum fejlesztésben. Az agilitás szemléletidegen lesz.

Az ellentéteket tovább fokozzák a terminológiai eltérések. Például a tervezés (planning) kifejezést mind a két oldal használja, és mind a két oldalon mást jelent. Szoftverfejlesztés során a tervezés alatt a szoftver műszaki és ütemtervének kialakítását értjük. Ez a munka azonban projektvezetési szempontból már a végrehajtás (execution) része, nem pedig a tervezési fázisé.

A félreértések oka az, hogy a Scrum Master és a projektvezető különböző szemléletet képvisel, ennek megfelelően más terminológiát, más eszközöket és más folyamatokat.

A 4. ábra mutatja be a különböző módszertanok helyét és szerepét. A fejlesztő és vezető fejlesztő szintjén szoftverfejlesztési modellről beszélhetünk, miközben a projektvezető az ő szintjén projektvezetési módszereket használ. Az egészet pedig csokorba fogja a Portfólió Menedzsment.

Továbbmenve: ahogyan az agilis fejlesztésről általában beszélnek, az ellentmondásban van a projektvezetési módszertanokkal.

Ilyen például a tervezés fontossága: minőségbiztosítási szempontból kulcsfontosságú a projekt terv megléte, miközben az Agile Manifesto szerint ez másodlagos. Ugyanilyen nézőpontbeli eltéréseket találunk, ha a szerződés kidolgozottságáról, a dokumentáció szükségességéről vagy az igények előzetes megismeréséről beszélünk, csak hogy néhányat említsünk.

Az eltérések oda vezetnek, hogy barikád emelkedik az informatikusok és a projektvezetők között, és mindkét oldal próbálja meggyőzni igazáról a másikat.

Harcolni nem érdemes, hiszen a projektszerű működés adottság, amit el kell fogadni. Az üzleti célokat el kell érni – és az informatikus lecserélhető.

7. A vízesés modell

Ha az agilis szemlélet konfliktusokat teremt, akkor nem lenne-e jobb vízesés modell szerint fejleszteni? Elvégre ez a szemlélet kiszolgálja a vezetőség igényét a kiszámíthatóság és tervezhetőség iránt.

Ha ma, a 21. században megnézzük a „hagyományos” módszerekkel dolgozó fejlesztő csapatokat, akkor kiderül, hogy amit a 20. században gondoltunk vízesés módszer alatt, az már nem állja meg a helyét.

Ennek egyik oka a változás: nincs projekt változás nélkül, nincs szoftverfejlesztés változáskérelem nélkül. Az üzleti élet felgyorsult, az igényeket követni kell. A projektvezetési módszertan szerves része a változás kezelés. Tehát pontosan a projektvezetés lesz az, ami rugalmasságra kényszeríti a kötött módszertant. Következmény: a specifikáció nincs kőbe vésve.

A másik ok pedig a hatékonyság: a nagyvállalatok felismerték, hogy a kis csapatok rugalmasabban és nagyobb hatékonysággal képesek szoftvert fejleszteni, mint a nagyok. Manapság már nincs olyan, hogy 100 fejlesztő egy nagy irodában ülve dolgozik egy 1000 oldalas specifikáció alapján. A kiszervezés megváltoztatta a munkamódszereket és a működési környezetet. Ez a vízesés már nem az a vízesés.

Végeredményben azt láthatjuk, hogy a merevnek tartott, folyamat alapú fejlesztési módszertanokat is rugalmasabban kezeljük, azaz tetten érhető az agilizálódás. Az agilizálódás pedig pontosan felülről lefelé, a vezetőség irányából jön, akik a változó üzleti igényeknek megfelelő, jól működő szoftvert szeretnének – és mindezt holnapra.

8. A két modell találkozása

A szoftverfejlesztési keretrendszerek és modellek csak eszközök, amelyek a jó projektvezető eszköztárának a részei. Nem szembeállítani kell őket, hanem alkalmazni az adott helyzetnek megfelelően, megtalálva az arany középutat.

Bármelyik módszerrel is indul el, egy sikeres vezető nagyon hasonló gyakorlati alkalmazásra fog jutni. A vízesés is lehetőséget ad a változáskezelési eljárásokra. Ha ezek gyakoriak, ha a tervezés a valós tudásra és nem erőltetett feltételezésekre épül, akkor működni fog és meglehetősen sok „agilis” elem köszön majd vissza belőle.

Az agilis szemléletben induló teamek pedig minden iteráció után alakítanak a szabályaikon, egyre szervezettebbek és szabályozottabbak lesznek. Az igazán jó agilis teamek egy idő után legalább annyi szabályt és normát vezetnek be, amennyit egy vízesés modellre alapuló módszertan is megirigyelne.

Az 5. számú ábra mutatja be a két modell találkozását. A vízesés módszertanok a bürokratikus szakaszból indulnak, de az üzleti elvárásoknak engedve az idő előrehaladtával a projektvezető és csapata kénytelen lesz rugalmasnak lenni.

A másik oldalról indulva, az agilis keretrendszerek kaotikusnak tűnhetnek eredeti formájukban, de ahogyan a csapat egyre több szabályt alakit ki, lesz egyre bürokratikusabb.

A kétféle szemlélet közelíteni fog egymáshoz.

Ez elsőre meglepő, de másodjára már teljesen logikus, a következő okok miatt:

-          A cél azonos: működő szoftver, elégedett ügyfél

-          A 2. szakaszban leírt vállalati környezet azonos, tehát gyakorlatban a megvalósításnak is hasonlónak kell lennie függetlenül attól, hogy agilis vagy nem agilis

-          A 3. szakaszban ismertetett projektmenedzsment környezet is adottságnak tekinthető, ami a kivitelezéstől függetlenül (agilis vagy nem agilis) létezik

-          A 4. szakaszból kiderült, hogy a különféle módszertanokat és szemléletmódokat azonos céllal hozták létre, az eltérés csak a megközelítésben és az eszközökben van

-          Kiderült, hogy a 6. szakaszban ismertetett, módszertanok közötti ellentmondás a projektmenedzsment alatti szinten jelentkezik csak, egyik sem ellentétes, vagy támogató a projektvezetési területtel (lásd 6. ábra)

Mindezek miatt a módszertanok gyakorlati alkalmazása nem lehet túlságosan eltérő.

Mivel a módszertanok egymás felé közelítenek, feltesszük, hogy létezik a kettő között egyfajta optimum: az „ideális” szoftverfejlesztési modell. A „működő szoftver” címszóval jelölt terület az, ahol a projekt csapat magabiztosan, tervezetten, vezetetten fejleszti a szoftvert, és a fejlesztés sikeres lesz. Mivel a fejlesztés folyamat-optimalizálás útján jutott ide, párhuzam érezhető a CMMI 5-ös szintjével.

A projektmenedzser feladata az, hogy a módszertani elemeket és az eszközöket felhasználva - szükség szerint variálva - megtalálja ezt a középutat. Tulajdonképpen semmilyen újdonság nincs ebben, hiszen a PMI is eleve csak ajánlást fogalmaz meg – építőkockákat (folyamatokat) ad, amelyekből felépíthető a projekt.

9. Összegzés

Elindultunk a vállalati környezetből, megvizsgáltuk a szoftverfejlesztést a projektmenedzsment szemüvegén át, majd szemügyre vettük fejlesztési módszertanokat, különös tekintettel az agilis szoftverfejlesztésre.

Kiderült, hogy az agilis modell eltér ugyan a hagyományos megközelítéstől, de ez nem gond, hiszen egyik modellt sem alkalmazzuk vakon, és a cél mindenhol azonos lesz. Bármilyen megközelítésből is indulunk, a projektvezetési eszközök alkalmazása és a gyakorlat azonos lesz.

Mindegyik modell mellé kell egy projektmenedzser, aki látja az elvárásokat és ezek alapján felépíti a projektjét a módszertani elemek (gyakorlatok és folyamatok) alkalmazásával.