Az agilis irányzatok futótűzként terjednek. Van, aki kedveli, van aki elutasítja, ám bármely csoportba is tartozunk, az egyértelmű, hogy legalább ismerni célszerű ezt a gondolkodásmódot. Igen, gondolkodásmódot és nem módszertant, erre a későbbiekben kitérünk.
Azok számára, akik még nem találkoztak az agilis projektmenedzsment gondolkodásmódjával, összefoglaltuk a leglényegesebb tudnivalókat, hogy az általunk tapasztalt tévhiteket és ellentmondásokat tisztázzuk.
A bejegyzésben az alábbi témákról olvashat:
Tartalom
Projektmenedzsment alapok és annak 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.
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), idő (mikorra szállítsunk) és 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.
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.
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.
Agilis projektmenedzsment: gondolkodásmód, irányzatok, módszertanok és eszközök
Sok esetben azt látjuk, hogy az agilitás, illetve az agilis projektmenedzsment értelmezése is eltérő, sok esetben téves. 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 egy, számos más agilis módszertan mellett. 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.
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 módszerek. A káosz ennek totális ellentéte, melyet sok szervezetnél látunk akár tanácsadóként, coachként, vagy trénerként is. Ehhez a korántsem előnyös állapothoz a teljesség igénye nélkül az alábbi tévhitek vezethetnek:
- 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:
Másik komoly eltérés a szerepekben keresendő. A hagyományos projektmenedzsment irányzatokban egy fő felelőst, a projektvezetőt tesszük a középpontba, ő felel a munka megtervezéséért, levezényléséért és nyomon követéséért is. Bár legtöbb esetben érdemes bevonni a projekttagokat a tervezési feladatokba is, mégis ő a munka végső felelőse, tehát ez a szereplő magas hatáskörrel működik, feladatokat oszthat ki, projekttagokat utasíthat adott feladatok elvégzésre.
Az agilis irányzatok esetén teljesen más a helyzet. A felelősséget nem egy fő viseli, hanem megoszlik több szereplő között. A megvalósításért és annak módjának kiválasztásáért is a csapat a felelős, tehát az agilis módszertanok önszerveződő, keresztfunkcionális csapatokkal operálnak. A csapat határozza meg egy adott prioritás mentén, hogy mit képesek egy adott iteráción, sprinten belül szállítani, ők határozzák meg saját munkamódszerüket és folyamatukat, ők becsülnek feladat méretet és ők is vállalják a felelősséget a szállításért is. Itt nincs tehát egy olyan vezető, aki megmondja a csapatnak hogy hogyan dolgozzanak.
A csapat mellett kell egy szereplő, aki a megrendelői érdekeket képviseli, azaz definiálja hogy mik az elvárások felhasználói, vagy megrendelői szinten és képviseli is azokat. Ez a szerep a scrumban a Product Owner (PO), aki priorizálja a “követelményeket”, azokat dokumentálja és a csapat által szállított inkrementumok elfogadásáról döntést hoz. A PO feladata, hogy maximalizálja a ROI-t, tehát a megrendelő számára valós értékkel bíró funkciókat, inkrementumokat definiáljon.
Minden csapatmunka tartogat kihívásokat, amikor emberek dolgoznak együtt, számos nehézség merülhet fel. Ezeket a nehézségeket hivatott csökkenteni, megoldani az agilis coach, (scrumban Scrum Master). Az ő feladata igen összetett, hiszen ez a személy egyfajta szolgáló vezető megközelítéssel működik, azaz támogatja a csapatot az együttműködésben, segít nekik a hatékony munkához szükséges feltételek megteremtésében. Egy erős Scrum Master facilitál, tanít, mentorál, “tükröt tart” és védi is a csapatot a káros külső tényezőktől. Ő az a szereplő, aki elhárítja az akadályokat, betartatja a ceremóniák kereteit, támogatja a csapat és a PO együttműködését, fejleszti a csapat együttműködését és betartatja a kereteket is.
A szerepkörök tehát az agilis értékek mentén hálózatokban működnek igazán a korábbi túlzott hierarchikus struktúrák helyett.
Ceremóniák
A hagyományos projektekben mindenki találkozott már “meetingekkel”, projektértekezletekkel, amik legtöbb esetben a projektvezető irányításával valósulnak meg. Ezek lehetnek rendszeres, vagy ad-hoc találkozók is projekttől és helyzettől függően.
Az agilis irányzatok nem értekezletekkel (erről ugye mindenkinek a formális, unalmas, komoly és hosszadalmas találkozók jutnak eszébe), hanem úgynevezett ceremóniákkal operálnak. A ceremóniák agilis irányzatokon belüli módszertanonként eltérőek lehetnek.
Scrum módszertanok 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.
- Nap 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
Ahhoz, hogy a hagyományos megközelítésekkel sikert tudjunk elérni feltétlenül szükséges az elvégzendő munka, leszállítandó termék megfelelő specifikálása. Erre a hagyományos projektek a követelményspecifikációkat alkalmazzák, melyek célja hogy minden kétséget kizáróan fixálja a projekt terjedelmét. Aki részt vett már nagy projektekben gyakran találkozott akár több száz oldalas specifikációval is. Saját tapasztalatunk, hogy igen nehéz úgy követelményeket leírni, hogy mind a szállító, mind a megrendelő oldal ugyanazt értse alatta és egységesen értelmezze.
Erre a problémára az agilis irányzatok az egyszerűség elvét alkalmazzák, azaz ezek nem preferálják a mindenre kiterjedő, hosszadalmas specifikációkat. Helyette lényegre törő, egyszerűbb formát alkalmaznak, amit product backlognak hívnak. A backlog egy pereferenciák mentén sorrendbe rendezett követelménylista, mely a megrendelő adott termékkel kapcsolatos elvárásait tartalmazza. Ennek elemei eltérőek lehetnek, leggyakrabban mi a user storykkal , epicekkel és spike-okkal találkozunk, de találkoztunk már a témák, feature-ök kifejezésekkel is.
User story, epic, spike:
A user story-k rövid “történetek”, amiket a megrendelők, felhasználók szeretnének viszontlátni a termékben. Ezek jó esetben egymástól független követelmények, amik több formában is leírhatóak. Formáktól függetlenül ezek a leírások tesztelhetővé is teszik az adott elemet, illetve célt is meghatároznak neki (pl. én mint – azt szeretném, hogy – annak érdekében).
Az epicek nagyobb “csomagok”, melyek általában több, ritkábban egy user story-ra bonthatóak. Ezek szerepe az iterációt megelőző tervezéseken igazán hangsúlyos, melyek többek közt segítenek a minimálisan elvárt funkcionalitás (MVP) meghatározásában elindulni.
Természetesen előfordulhat, hogy a megrendelői elvárások megvalósításához belső feladatokat kell ellátni, esetleg körül kell járni egy-egy témát, hogy azt milyen módszerrel, technológiával lehet megvalósítani. A csapat ezekre spike-okat definiálhat, melyek megvalósítása természetesen energiát igényel.
A csapat általi becslés szinte bármilyen dimenzióban történhet, story pontokban, időben, kavicsokban. A lényeg, hogy a csapat egymáshoz képest viszonyítani tudja a feladatok méretét és azokról döntést tudjon hozni, hogy mi férhet bele egy adott iterációba.
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 programunkat.
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 kihelyezett program keretén belül tudunk támogatást nyújtani, melyet a közeljövőben tervezünk nyílt programként is meghirdetni.
Amennyiben kérdése van, nem tudja hogyan lépjen tovább e témában, keressen minket bizalommal!
Designabc