Az agilis projektmenedzsment nem módszertan, hanem gondolkodásmód, amely a változások kezelésére, a gyakori visszajelzésekre és az értékteremtésre fókuszál. Különösen bizonytalan, gyorsan változó környezetben hatékony, de nem minden projektre alkalmazható. Az agilis működés önszerveződő csapatokra, világos szerepekre és strukturált ceremóniákra épül, miközben a hagyományos projektmenedzsment megközelítéseknek is megmarad a létjogosultsága.
A bejegyzésben az alábbi témákról olvashat:
Tartalom
Projektmenedzsment alapjai és fejlődése
A projektmenedzsment nem újkeletű dolog. Már az 1960-as években felismerték annak igényét, hogy a nagyobb, jellemzően egyedi termék, vagy szolgáltatás létrehozását, fejlesztését irányított folyamat szerint érdemes kézben tartani.
A nemzetközileg elfogadott definíció szerint a projektmenedzsment a projektkövetelmények teljesítése érdekében végzett tevékenységek során tudás, képességek, eszközök és technikák alkalmazása. Ettől függetlenül mi jobban szeretjük az egyszerűbb, a “dolgok megvalósíttatásának művészete” megfogalmazást.
A projektmenedzsment is, mint oly sok szakma az évek során hol organikusan, hol tudatosan fejlődött. Kezdetben a projektmenedzsment még nem önálló szakmaként jelent meg, ez sok esetben csupán egy „sapka” volt, amit a projektben (még ha nem is így nevezték) dolgozó egy-egy szereplő kapott meg. Az idő múlásával és a feladatok komplexitásának növekedésével azonban ez is önálló, teljes értékű szereppé alakult.
Projekt háromszög: terjedelem, idő, költség
Bármilyen projektről is beszéljünk, alapjaiban minden ilyen jellegű feladatot három tényező befolyásol leginkább.
Ezek:
- a terjedelem (mit csináljunk)
- az idő (mikorra szállítsunk)
- a költségek (mennyibe kerül)
A mai napig kis túlzással minden projekt e háromszögben mozog és próbálja a megrendelői igényeket (mindent, gyorsan, olcsón) egyensúlyban tartani és kielégíteni.
A vízesés modell megjelenése és korlátai
Az 1970-es években elterjedt vízesés modell alapú megközelítéssel a projektek sikerességi mutatója komoly mértékben nőtt. Ennek oka, hogy tudatos tervezéssel egy viszonylag jól kiszámítható, akkor még a maihoz képest nem túl gyorsan változó környezetben lehetett sikereket elérni.
Ez a ’90-es években azonban már egyre többször kevésnek bizonyult, a technológia hirtelen fejlődésével és a projektek számának növekedésével egyre több utólag fölöslegesnek bizonyult munka és egyre több csúszás, vagy költségtúllépés jelent meg.
Ez a felismerés adott teret a különböző, vízeséstől eltérő módszertanoknak is.
Projektmenedzsment módszertanok, irányzatok
A projektmenedzsment fejlődésével különböző irányzatok alakultak ki, melyek eltérő módszertanokban öltöttek testet. Projektmenedzsment módszertannak nevezzük a projektekben közreműködők által használt gyakorlatok, technikák, folyamatok és szabályok rendszerét.
Mára elképesztően sok módszertan került kialakításra, vannak „dobozosak”, de vannak szervezeti szinten fejlesztett megoldások is.
Módszertanok csoportosítása változás és szállítás mentén
Amennyiben ezeket csoportosítani szeretnénk, alapvetően mi 4 féle irányzatot szoktunk definiálni. Ez a változások mértéke és a szállítás gyakorisága mentén azonosíthatók be, tehát a megközelítés többek közt attól függ, hogy a szállítást egy-két, vagy több modulon, részterméken, elemen, ún. inkrementumon keresztül szeretnénk-e megvalósítani, valamint, hogy milyen mértékű változásra számítunk az elvárásokkal, vagy akár ezek gyakori kiváltó okával, a környezettel kapcsolatban.
Az agilis irányzatok tapasztalataink szerint ott a legsikeresebbek, ahol nagy mértékű változásra, bizonytalanságra számítunk és ezt többek között nagyfokú kreativitással és gyakori szállítással, azaz visszajelzésekkel szeretnénk kezelni. Az agilis működés ilyenkor lehet a legideálisabb.
Mi az agilis projektmenedzsment valójában?
Sok esetben azt látjuk, hogy az agilitás, illetve az agilis projektmenedzsment értelmezése eltérő, és nem ritkán téves. Gyakori félreértés, hogy az agilitást egy konkrét módszertannal azonosítják, miközben valójában egy ennél tágabb megközelítésről van szó.
Megközelítésünk szerint az eszközök, ceremóniák és szerepek a módszertanok részei, és a példa kedvéért a leggyakrabban alkalmazott Scrum rendszer is csupán egy a számos agilis módszertan közül.
Agilis irányzatok és módszertanok
Agilis módszertanoknak nevezhetőek többek közt például a lean termékfejlesztés, az eXtreme Programming, vagy bármilyen ezekkel megegyező értékek mentén kialakított hibrid megoldás is. Ezekben a módszertanokban eltérnek, eltérhetnek a szerepek, a folyamtok, a ceremóniák, ám egy dolog közös bennük, ez pedig a gondolkodásmód és az értékközpontúság.
Agilitás mint gondolkodásmód
Ezért szoktuk mi azt képviselni, hogy az agilitás egy mindset, egy gondolkodásmód, mely több módon is testet ölthet a szervezetek és egyének életében. Ezeket az értékeket és a mögöttük húzódó alapelveket jól leírja az agilis kiáltvány is, azonban bár ezek végtelenül egyszerűnek tűnnek, ezek alkalmazásának módja nem minden esetben egyértelmű.
A kiáltványt idézve „(…) megtanultuk értékelni:
- Az egyéneket és a személyes kommunikációt a módszertanokkal és eszközökkel szemben
- A működő szoftvert az átfogó dokumentációval szemben
- A megrendelővel történő együttműködést a szerződéses egyeztetéssel szemben
- A változás iránti készséget a tervek szolgai követésével szemben
Azaz, annak ellenére, hogy a jobb oldalon szereplő tételek is értékkel bírnak, mi többre tartjuk a bal oldalon feltüntetetteket.”
A fent leírt értékek sok esetben nem jelennek meg kellő hangsúllyal a projektek során, ezek erősítése többek között agilis projektmódszertanok megfelelő alkalmazásával, vagy a szervezeti agilitás fejlesztésével is megvalósulhat.
Fontosnak tartjuk azonban mindig hangsúlyozni, hogy nem célszerű minden projektet agilis módszertanok mentén kezelni, szerintünk továbbra is van létjogosultsága a tradicionális irányzatoknak, amik szerintünk az agilis értékek mentén testre szabhatóak.
Tévhitek és a káosz birodalma
Az agilis módszertanok strukturált, szervezett működési kereteket biztosítanak. A káosz ennek totális ellentéte, mégis sok szervezetnél találkozunk olyan működéssel, amelyet tévesen az agilitás számlájára írnak. Ez a helyzet gyakran abból fakad, hogy az agilis megközelítést félreértelmezik, vagy csak részben alkalmazzák.
A leggyakrabban előforduló tévhitek az alábbiak:
- Agilis projekteket nem kell tervezni
- Agilis projektet nem kell dokumentálni
- Agilis projektek gyorsabban lezárulnak
- Igénygazdáknak kevesebb munkájuk van agilis projekt során
- Minden projektre megfelelőek az agilis irányzatok
- Agilis projektben nem kell előre célt meghatározni, az menet közben kiderül
- Napi stand-upokat tartunk, ezért agilisan működünk
- Agilis projektmenedzserként kevesebb munkám lesz agilis projektekben
Utóbbi azért is érdekes, mert sok „agilis evangelistától” megkapjuk, hogy „az agilis irányzatokban nincs projektmenedzser”! Ezzel mi szoktunk vitatkozni, hiszen bár valóban ez a szerepkör hivatalosan nincs definiálva és a hagyományos (tradicionális irányzatok szerinti) értelmezésében nem létezik, azonban egy másféle felfogással tapasztalatunk szerint igenis lehet helye, értéke az agilis projektmenedzsereknek az agilis munkavégzés kapcsán.
Hagyományos és agilis projektirányzatok közti különbségek
A hagyományos és az agilis irányzatok alapjaiban térnek el egymástól. A módszertanok mentén természetesen más a folyamat, mások a szerepek és más ceremóniákat is alkalmazunk, azonban a legfontosabb eltérés ezek gyökereiben, a gondolkodásmódban keresendő.
A korábban leírt hármas korlát mentén a háromszög elemei közül nem „mozoghat” minden, kell egy állandó pont.
- A hagyományos projektekben jellemzően a terjedelem (tehát a mit? kérdés) kerül először definiálásra és arra keressük a tervezés során a választ, hogy azt mennyi időn belül és milyen költségek mentén tudjuk szállítani.
- Az agilis irányzatok ettől eltérően a terjedelmet tekintik változónak. Azaz egy meghatározott időkeretet (time-box) vagy költségkeretet tekintenek fixnek és azt próbálják elérni, hogy e keretek tartásával a legnagyobb (de még reális) értéket szállítsák a megrendelő számára és a terjedelmet csupán az adott iterációra rögzítik.
Szerepköri eltérések
Szempont | Hagyományos projektmenedzsment | Agilis megközelítés |
|---|---|---|
Központi szerep | A projektvezető központi szerepet tölt be | A felelősség megoszlik |
Tervezés felelőssége | A projektvezető felel a tervezésért | A csapat dönt a vállalható munkamennyiségről |
Végrehajtás és nyomon követés | A projektvezető felelőssége | A csapat felelősséget vállal a szállításért |
Döntési és utasítási jogkör | Magas döntési és utasítási jogkör | A csapat határozza meg a munkamódszereit |
Csapat működése | Nem önszerveződő | Önszerveződő, keresztfunkcionális csapat |
Megrendelői érdekek képviselete | Nem külön szerepkörként jelenik meg | Product Owner képviseli |
Követelmények kezelése | Nem részletezett | Prioritás, dokumentálás és elfogadás a Product Owner feladata |
Csapat támogatása | Nem külön szerepkör | Agilis coach / Scrum Master |
Scrum Master feladata | Nem értelmezett | Akadályok elhárítása, ceremóniák támogatása, csapat védelme |
Ceremóniák és működés
A hagyományos projektek értekezletekkel dolgoznak, míg az agilis irányzatok strukturált, célorientált ceremóniákat alkalmaznak. Ezek célja a transzparencia, az együttműködés és a folyamatos tanulás biztosítása.
A ceremóniák agilis irányzatokon belüli módszertanonként eltérőek lehetnek.
A Scrum módszertan fő ceremóniái:
- Sprint tervezés – Célja, hogy a csapat a PO-val együttműködésben a megbízói prioritások mentén definiálja az adott iterációra vállalt munkát, elköteleződjön annak szállítására és megtervezze az iterációra vonatkozó munkát.
- Sprint – 2-4 hetes időciklus, ami során a csapat a leszállítandó inkrementumokon dolgozik.
- Napi scrum – A napi standupnak is nevezett 10-15 perces napi ceremónia célja a transzparencia biztosítása, azaz, hogy a csapat lássa hogy ki mivel foglalkozik, mi valósult meg, mi van még hátra, illetve hogy hangot adjanak az esetlegesen felmerülő akadályoknak.
- Refinement/grooming – Annak érdekében, hogy a munka fenntartható legyen, érdemes a jelenlegi sprinten túlmutató feladatokat időközönként rendszerezni, előkészíteni. E ceremónia fő célja, hogy a következő sprint tervezésre megfelelő mennyiségű és minőségű feladat álljon rendelkezésre, tehát visszajelzést adjon a csapat a PO-nak, hogy a backlogban (az egyszerűség kedvéért hívjuk most követelménylistának) szereplő követelmények tiszták, érthetőek-e, azaz a következő tervezésen képes-e a csapat azt megbecsülni, azokkal tervezni.
- Retrospektív – Annak ellenére, hogy ez az egyik legfontosabb ceremónia, a gyakorlatban azt látjuk, hogy ezt hagyják el a csapatok leggyakrabban. A retro célja, a folyamat és az együttműködés javítása, fejlesztése, tehát erős önreflexióra, tanulságok levonására és konkrét, azonnal indítható akciók megfogalmazására van szükség. Ez kényes terület lehet, hiszen általában az emberek kevésbé szeretnek önmagukról, illetve a hibákról beszélni.
- Review/demo – Minden iteráció végén a csapat bemutatja, hogy mit alkottak az iteráció során, a PO pedig e ceremónia keretén belül dönt azok elfogadásáról és visszajelzést ad a csapatnak, hogy jó irányba tartanak-e a termékkel kapcsolatban.
A fentiek tehát a scrum által használ fő ceremóniák, melyek hatékony betartása és megvalósítása közös érdek. A gyakorlatban gyakran azt látjuk, hogy a csapatok „beleugranak” a sprintbe, azaz nincs azok előtt megfelelő tervezési, előkészítési folyamat. Az üzleti életben itt is szükség lehet üzleti tervre, termékszintű tervezésre, illetve release meghatározásra. Ennek folyamata nagyon eltérő lehet, az általunk használt és legtöbb esetben bevált folyamatot agilis szimulációnkon tapasztalhatja meg.
Változások és követelmények kezelése agilis projektekben
Hagyományos megközelítés
- A siker feltétele az elvégzendő munka és a leszállítandó termék részletes specifikálása
- A projekt terjedelmét követelményspecifikációk rögzítik
- Nagyobb projektek esetén ezek a dokumentumok akár több száz oldalasak is lehetnek
- Tapasztalataink szerint nehéz a követelményeket úgy megfogalmazni, hogy azokat a megrendelő és a szállító oldal egységesen értelmezze
Agilis megközelítés
- Az egyszerűség elvét alkalmazza
- Nem preferálja a mindenre kiterjedő, hosszadalmas specifikációkat
- Egy lényegre törő, priorizált követelménylistát használ, a product backlogot
- A backlog a megrendelői elvárásokat tartalmazza
- Jellemző elemei: user storyk, epicek és spike-ok
- Előfordulhatnak más elnevezések is, például témák vagy feature-ök
Követelménytípusok és becslés agilis projektekben
Az agilis projektekben a követelmények különböző formákban jelennek meg, attól függően, hogy milyen szinten és milyen céllal szeretnénk őket kezelni. Ezek az elemek eltérő részletességűek, de közös bennük, hogy a csapat munkáját és a döntéshozatalt támogatják.
User story
- Rövid „történetek”, amelyek a megrendelők vagy felhasználók igényeit írják le
- Jó esetben egymástól független követelmények
- Több formában is megfogalmazhatók
- Tesztelhetőek, és egyértelmű célt határoznak meg
- Gyakori forma: „én mint … azt szeretném, hogy … annak érdekében”
Epic
- Nagyobb „csomagok”, amelyek általában több user story-ra bonthatók
- Szerepük különösen hangsúlyos az iterációkat megelőző tervezés során
- Segítenek a minimálisan elvárt funkcionalitás (MVP) meghatározásában
Spike
- Olyan feladatok, amelyek egy adott téma feltárását szolgálják
- Jellemzően technikai vagy módszertani kérdések tisztázására használják
- Megvalósításuk a csapat részéről energiabefektetést igényel
Becslés az agilis csapatokban
- A becslés történhet különböző dimenziók mentén (pl. story pontokban, időben vagy más egységekben)
- A lényeg nem az abszolút érték, hanem az egymáshoz viszonyítás
- A cél annak eldöntése, hogy mely feladatok férnek bele egy adott iterációba
GYIK: Gyakran ismételt kérdések az agilis projektmenedzsmentről
Zárásként összegyűjtöttük a leggyakrabban felmerülő kérdéseket az agilis projektmenedzsmenttel kapcsolatban.
Mi az agilis jelentése? Mit takar az agile projekt?
Az agilis egy rugalmas, alkalmazkodó megközelítést jelent, amely a változások kezelésére, a gyakori visszajelzésekre és az értékteremtésre fókuszál. Az agile projektek az agilis elveknek megfelelően kerülnek megvalósításra, jellemzően iteratív működéssel, folyamatos tanulással és visszacsatolással.
Milyen szervezeteknek érdemes agilis működésben gondolkodni?
Az agilis megközelítés elsősorban azoknál a szervezeteknél hoz valódi előnyt, ahol a környezet gyorsan változik, az elvárások nem teljesen ismertek előre, és a visszajelzések beépítése kulcsszerepet játszik. Stabil, erősen szabályozott környezetben a hagyományos megközelítések gyakran hatékonyabbak.
Mennyi idő alatt térül meg egy agilis átállás?
Az agilis működés nem egy egyszeri bevezetés, hanem tanulási folyamat. Rövid távon gyakran már érzékelhető javulás tapasztalható az együttműködésben és az átláthatóságban, míg a valódi üzleti eredmények jellemzően közép- vagy hosszabb távon jelentkeznek.
Lehet-e egy szervezeten belül párhuzamosan hagyományos és agilis projekteket futtatni?
Igen. Sok szervezet sikeresen működtet vegyes projektportfóliót, ahol az adott projekt jellege, kockázata és bizonytalansága határozza meg az alkalmazott megközelítést. Az agilis és hagyományos irányzatok nem kizárják, hanem kiegészíthetik egymást.
Mi a leggyakoribb oka annak, hogy egy agilis kezdeményezés nem hozza a várt eredményeket?
Tapasztalataink szerint a kudarcok leggyakoribb oka nem a módszertan, hanem a szemlélet felszínes alkalmazása. Ha az agilis eszközök bevezetése mögött nem jelenik meg a gondolkodásmódbeli változás, a működés könnyen visszacsúszik a korábbi mintákba.
Szükség van-e külső támogatásra egy agilis átállás során?
Nem minden esetben, de komplexebb szervezeti környezetben jelentős előnyt jelenthet. Egy külső szakértő segíthet elkerülni a tipikus buktatókat, gyorsíthatja a tanulási folyamatot, és támogatást nyújthat a csapatok és vezetők közötti összehangolásban.
Az agilis működés inkább vezetői vagy csapatszintű változást igényel?
Mindkettőt. Az agilis működés akkor fenntartható, ha a csapatok napi működése és a vezetői döntéshozatal összhangban van az agilis értékekkel. Egyik szint sem tud tartósan működni a másik támogatása nélkül.
Mi a refinement jelentése az agilis projektekben?
A refinement (más néven backlog refinement vagy grooming) az a rendszeres agilis tevékenység, amelynek során a csapat és a Product Owner közösen áttekintik és pontosítják a product backlog elemeit. A cél az, hogy a követelmények érthetők, kellően részletezettek és becsülhetők legyenek, így a következő sprint tervezése hatékonyan megvalósulhasson.
Miben tudunk mi segíteni?
Az elmúlt években agilis coach, product owner, fejlesztő és tanácsadó/tréner tapasztalattal rendelkező kollégáink több tucat agilis csapatot és szervezeti agilitás fejlesztési folyamatot támogattak.
Nem vagyunk agilis evangelisták, nem hisszük hogy mindenre az agilis irányzatok jelentenek megoldást. Hisszük, hogy ezek az eszközök segíthetnek a mindennapokban, illetve ennek a gondolkodásmódnak a napi munkába való megfelelő mértékű beépítése rövidtávú sikereket hozhat a projektek és a szervezetek számára.
Amennyiben az agilitás alapjairól, a scrum, esetleg kanban irányzatokról szeretne többet megtudni, ajánljuk agilis projektmenedzsment programjainkat.
Amennyiben Ön projektvezetőként, Product Ownerként, esetleg induló Scrum Masterként szeretné a tervezés folyamatát és eszközeit konkrét projekten kipróbálni, agilis szimulációnkat javasoljuk.
Scrum Masterek és agile leaderek számára készült képzési térképünk itt érhető el.
Amennyiben kérdése van, nem tudja hogyan lépjen tovább e témában, keressen minket bizalommal!
