Az agilis módszertan nagyon elterjedt az IT világában, és számos munkakör alkalmazza ezt a megközelítést a hatékonyabb és rugalmasabb munkavégzés érdekében. Az agilis módszertan lényege a folyamatos fejlesztés, iteráció, és a gyorsan változó környezetekhez való alkalmazkodás. Az agilis csapatok többnyire kisebb, önálló egységekként működnek, ahol minden szerepkör aktívan hozzájárul a projekt sikeréhez. Nézzük meg a leggyakoribb agilis munkaköröket az IT-ben:

1. Scrum Master (SM)

• Feladatok: A Scrum módszertan betartásának biztosítása, a csapat támogatása, az akadályok elhárítása (impedimentek), facilitálás a csapat és az érintettek között. Felelős azért, hogy a csapat hatékonyan és agilis elvek szerint működjön.
• Készségek: Erős kommunikációs készség, facilitálás, konfliktuskezelés, Scrum és más agilis keretrendszerek alapos ismerete.
• Agilis kapcsolódás: A Scrum Master szerepe kulcsfontosságú a csapat agilis folyamatainak irányításában és fejlesztésében. Feladata, hogy a csapat akadálymentesen dolgozhasson és folyamatosan fejlődjön.

2. Product Owner (PO)

• Feladatok: A termék víziójának és céljainak meghatározása, a felhasználói igények megértése, a termék backlog karbantartása és priorizálása. A PO felelős azért, hogy a fejlesztőcsapat a legnagyobb értéket képviselő feladatokon dolgozzon.
• Készségek: Erős üzleti érzék, stratégiai gondolkodás, stakeholder management, kommunikációs készségek.
• Agilis kapcsolódás: A PO biztosítja, hogy a csapat az üzleti céloknak megfelelően dolgozzon, és az ügyfélértéket maximalizálják. Folyamatosan egyeztet a csapattal és a felhasználókkal a prioritásokról.

3. Agilis coach

• Feladatok: Az agilis módszertan bevezetése és fejlesztése a csapatokban, mentorálás és tréningek nyújtása a csapatok számára. Segít az agilis elvek mélyebb megértésében és gyakorlati alkalmazásában.
• Készségek: Tanácsadás, facilitálás, csapatfejlesztés, kiváló kommunikációs és problémamegoldó készségek.
• Agilis kapcsolódás: Az agilis coachok feladata, hogy segítsék a csapatokat az agilis módszertanok adaptálásában, és biztosítsák, hogy azok hatékonyan alkalmazzák az agilis elveket a mindennapi munkában.

4. Fejlesztő (Developer)

• Feladatok: Szoftverek, alkalmazások és új funkciók fejlesztése. Egy agilis csapatban a fejlesztők önállóan dolgoznak, szoros együttműködésben a Product Ownerrel és a Scrum Masterrel. Folyamatosan iterálják a megoldásokat és gyakran dolgoznak kisebb, gyorsan elkészülő feladatokon (sprint).
• Készségek: Programozási nyelvek ismerete, kódolás, verziókezelés (Git), problémamegoldás.
• Agilis kapcsolódás: Az agilis módszertanban a fejlesztők rugalmasan dolgoznak, gyakori visszajelzések alapján folyamatosan fejlesztve a szoftvereket.

5. Tesztelő / QA mérnök (Quality Assurance)

• Feladatok: A szoftverek minőségének biztosítása, automatizált és manuális tesztelések végzése, a hibák felderítése és dokumentálása. Az agilis módszertanban a tesztelők is szerves részét képezik a csapatnak, folyamatos visszajelzést adnak a fejlesztések minőségéről.
• Készségek: Automatizált tesztelési eszközök ismerete, hibakeresés, kommunikáció a fejlesztőkkel, minőségbiztosítási elvek.
• Agilis kapcsolódás: Az agilis folyamatban a tesztelés nem az utolsó fázis, hanem folyamatosan történik, hogy azonnal javíthatók legyenek a hibák, és gyorsan iterálható legyen a termék.

6. UX/UI designer

• Feladatok: A felhasználói élmény és az interfész tervezése, tesztelése, iterálása az agilis csapatokban. A tervezők szorosan együttműködnek a fejlesztőkkel és a Product Ownerrel, hogy a végfelhasználói igényeket figyelembe véve készüljenek el a funkciók.
• Készségek: UX kutatás, wireframing, prototípus készítés, felhasználói tesztek levezetése.
• Agilis kapcsolódás: Az agilis módszertanban a tervezők gyakran iteratív módon dolgoznak, folyamatosan finomítva a dizájnt a felhasználói visszajelzések és a fejlesztési ciklusok alapján.

7. Rendszerintegrátor (DevOps Engineer)

• Feladatok: Az agilis fejlesztésben a DevOps mérnökök feladata az automatizálás, a folyamatos integráció (CI) és folyamatos szállítás (CD) folyamatok bevezetése és fenntartása. Ők biztosítják, hogy a fejlesztések gyorsan és megbízhatóan kerüljenek éles környezetbe.
• Készségek: Konténerizáció (Docker, Kubernetes), felhőszolgáltatások (AWS, Azure), automatizálás eszközök (Jenkins, GitLab).
• Agilis kapcsolódás: A DevOps mérnökök gyorsítják a fejlesztés és a kiadás folyamatát, így lehetővé teszik az agilis csapatok számára a gyakori, gyors szállítást.

8. Agilis Projektmenedzser

• Feladatok: Bár az agilis módszertanban nincs hagyományos projektmenedzser, sok szervezetben mégis van ilyen szerep, ami a projektek stratégiai irányítását végzi. Az agilis projektmenedzser feladata az érintettek koordinálása, az időkeretek és költségvetés kezelése, miközben az agilis elveket figyelembe veszi.
• Készségek: Projektmenedzsment, stakeholder management, agilis módszertanok ismerete (pl. Scrum, Kanban).
• Agilis kapcsolódás: Segít abban, hogy a projektcélok összhangban legyenek az agilis csapat működésével, és mind az üzleti, mind a fejlesztési célokat elérjék.

9. Business Analyst (Agilis elemző)

• Feladatok: A vállalkozás igényeinek elemzése, dokumentálása, és azok agilis csapatokkal történő megosztása. Az elemző szerepe az, hogy a fejlesztési folyamatok során biztosítsa, hogy az üzleti igények és a technikai megoldások találkozzanak.
• Készségek: Elemzés, kommunikáció, specifikációk írása, stakeholder menedzsment.
• Agilis kapcsolódás: Segít a csapatoknak abban, hogy a fejlesztési folyamat során az üzleti céloknak megfelelően dolgozzanak, és az ügyfélközpontú szemlélet megmaradjon.

10. Service Manager

• Feladatok: A Service Manager az IT-szolgáltatások általános működéséért és minőségéért felelős, közvetlen kapcsolatban áll az üzleti vezetőkkel és ügyfelekkel. Ő biztosítja, hogy az IT-szolgáltatások megfeleljenek az üzleti elvárásoknak. Az Service Level Agreement (SLA) kidolgozásáért és nyomon követéséért felel, hogy az IT-szolgáltatások teljesüljenek. Ezenfelül a pénzügyek és a pénzügyi felelősség és ebből adódó döntések is a Service Manager feladatai közé tartoznak.
• Készségek: Service management / Service projektmenedzsment, stakeholder management, agilis módszertanok ismerete (pl. Scrum, Kanban).
• Agilis kapcsolódás: Amennyiben egy adott projekt egy nagyobb szolgáltatásban van benne, így akkor ő a felelős a projektért. Övé a pénzügyi felelősség, ő viszi az eszkalációs eseteket és a stratégiai egyeztetéseket a stakeholderrel

11. IT Support

Az IT support feladatai közé tartozik a technikai segítségnyújtás és támogatás biztosítása a felhasználók számára informatikai problémák esetén. Az IT support biztosítja, hogy az informatikai rendszerek és eszközök zökkenőmentesen működjenek, minimalizálva az üzletmenetet érintő technikai problémákat.

A pontos feladatkörök a következők lehetnek:

• Hibaelhárítás: A felhasználók által jelentett hardveres vagy szoftveres problémák elemzése és megoldása (pl. lassú számítógépek, nem működő programok).
• Felhasználói támogatás: Segítségnyújtás a felhasználóknak a különböző eszközök, szoftverek és rendszerek használatában (pl. e-mail beállítások, jelszó visszaállítás).
• Telepítés és frissítés: Szoftverek, operációs rendszerek telepítése, frissítése, illetve biztonsági javítások végrehajtása.
• Eszközkezelés: Új hardverek beállítása (pl. számítógépek, nyomtatók), valamint ezek karbantartása.
• Hálózati támogatás: Hálózati kapcsolódási problémák diagnosztizálása és javítása, illetve az internetelérés biztosítása.
• Biztonsági támogatás: Segítségnyújtás a vírusirtók és tűzfalak beállításában, valamint adatvédelmi kérdések kezelése.
• Dokumentáció: A megoldott problémák dokumentálása és a tudásbázis karbantartása, amely segíti a jövőbeli problémák gyorsabb megoldását.
• Szükség esetén eszkalálás: Ha a probléma meghaladja a kompetenciájukat, továbbítják azt a megfelelő szintű technikai támogatáshoz vagy szakértőkhöz.

Az IT Support azért egy kicsit kakukktojás az egész agilis menedzsmentben, mert ezt egyszerűen nem lehet egyik agilis módszertannal sem keverni. Feladatuk elég komplex, még ha az ember ezt nem is gondolná. Egy tapasztalt IT Supporter bizonyos esetben jobban kereshet mint egy fejlesztő vagy menedzser kolléga. Az IT Support folyamatait és a munkakör részletesebb bemutatásával az ITIL fogalalkozik, amiről természetesen még szó lesz. 🙂

Körül vagy véve projektekkel? Fogadni mernénk, hogy igen! Legyen szó akár munkáról, akár a magánéletről, a kisebb és nagyobb projektek mindenhol jelen vannak. Egy vasárnapi kirándulást meg kell tervezni, egy kéthetes nyaralást vagy akár egy világkörüli utazást? Mi van a felújításokkal, új építkezésekkel, átalakításokkal vagy költözésekkel? Nem is beszélve az ügynökségek ügyfélprojektjeiről, a gyártóvállalatok új berendezéseinek telepítéséről, a hivatalokban új folyamatok bevezetéséről, vagy új szoftverek és innovatív fitnesz-trackerek fejlesztéséről.

Ha az idő és a pénz nem számítana, ezeknek a projekteknek a kezelése sokkal könnyebb lenne: Az épület ferde, mert kimaradt egy gerenda? Semmi gond – akkor kezdjük elölről. Az olyan idegesítő dolgok, mint a be nem tartott törvényi szabályok vagy a hiányzó szabadalmak sem okoznának gondot, ha korlátlan erőforrások állnának rendelkezésre, és senki sem foglalkozna a határidőkkel.

De a valóság másképp néz ki: A való életben a költségvetések korlátozottak, a határidők szorítanak, és senki sem engedheti meg magának, hogy felesleges hibákat kövessen el. Képzelj el egy közepes méretű vállalatot, amely a versenyéles piacon azért bukik meg, mert termékeit túl lassan fejleszti, vagy ügyfélprojektjeit nem megfelelő minőségben teljesíti.

Itt lép be a képbe a projektmenedzsment. Az alapötlet: Komplex feladatokat a megfelelő módszerekkel és technikákkal úgy kezelni, hogy azok a lehető leghatékonyabban, erőforráspazarlás nélkül valósuljanak meg.

A projektmenedzsment definíciója

Kezdjük egy általános definícióval: Mi is tulajdonképpen a projektmenedzsment? Röviden: A projektmenedzsment egy vezetési diszciplína, amely magában foglalja a komplex feladatok (projektek) tervezését, végrehajtását, irányítását, ellenőrzését és kommunikálását.

Vagy másképp kifejezve, a PMI® (Project Management Institute) szerint: A projektmenedzsment a tudás, képességek, eszközök és technikák alkalmazása a projektek tevékenységein, hogy teljesítsék a projekt követelményeit.

Mi a klasszikus projektmenedzsment?

Ha egyszerűen szeretnénk megfogalmazni, így hangzana a válasz: A hagyományos vagy klasszikus projektmenedzsment minden, ami nem agilis. Valójában az agilis projektmenedzsmentet általában „újként” érzékelik, míg minden „régi” módszert a klasszikus projektmenedzsmenthez sorolnak. Az agilis és a klasszikus megközelítés megkülönböztetése valóban hasznos lehet, de ez nem jelenti azt, hogy a klasszikus projektmenedzsment „elavult” vagy „nem modern”.

A klasszikus projektmenedzsment különböző módszereket alkalmazhat. Ettől függetlenül a klasszikus módszerekkel végzett projektek általában a következő jellemzőkkel bírnak:

• Világosan körülhatárolt fázisokban zajlanak, előre meghatározott eredményekkel.
• Az elvárásokat részletesen meghatározzák a projekt elején.
• Nagy hangsúlyt fektetnek az intenzív tervezési szakaszra.
• Kevesebb változtatás várható, és a változások zavaró tényezőként jelennek meg.
• A projektterv betartására helyezik a hangsúlyt.

A klasszikus projektmenedzsment elterjedt módszerei közé tartoznak a Gantt-diagramok, a mérföldkövekkel ellátott fázistervek vagy a projektstruktúratervek.

Meghalt a klasszikus projektmenedzsment?

Az agilitás divatos, a klasszikus megközelítés pedig kiment a divatból? A helyzet ennél bonyolultabb! Míg a termékfejlesztések vagy szoftverprojektek dinamikus piacokon profitálnak az agilis megközelítésekből, a fix keretek között zajló projekteket nagyszerűen lehet kezelni hagyományos módszerekkel, például az alábbi esetekben:

• Olyan projektek, ahol az eredményt „egy darabban” kell a végén átadni és jóváhagyni, különösen fizikai tárgyaknál.
• Olyan projektek, ahol a követelmények részletezve vannak, és minden érintett jóváhagyta őket.
• Stabil környezetek, ahol kevés új technológiát alkalmaznak.
• Erősen szabályozott projektek, például az orvostechnikában vagy a tőzsdén jegyzett vállalatok pénzügyi menedzsmentjében.
• Olyan projektek, ahol specifikus és szigorú dokumentáció szükséges.

A klasszikus projektmenedzsment előnyei és hátrányai

Kevés fekete és fehér, sok szürke árnyalat: Tartsd ezt szem előtt, amikor az előnyöket és hátrányokat látod. A projekt csak akkor profitálhat az előnyökből, ha jól vezetik. Fordítva, egy jó projektmenedzsment segítségével elkerülhetők a tipikus hátrányok.

Előnyök:

• Könnyen átlátható: A lineáris megközelítés, beleértve a felügyeletet és az irányítást, minden résztvevő számára könnyen érthető.
• A komplexitás csökkentése: A fázisok és mérföldkövek meghatározásával a projekt kezelhető darabokra bomlik.
• Jól előre jelezhető: Egy világos ütemterv biztosítja a tervezhetőséget minden résztvevő számára.
• Nem szükséges folyamatos kommunikáció: Az ügyfél vagy megbízó a kezdeti és záró szakaszban aktívan jelen van, de a megvalósítás során nem feltétlenül kell bevonni.
• Jó dokumentáció: A klasszikusan végzett projektek általában nagy hangsúlyt fektetnek az átfogó dokumentációra.

Hátrányok:

• Hiányzó áttekintés: A komplex projektek ritkán láthatók át teljes részletességgel a kezdetektől.
• Rugalmatlanság: A terv betartása a fókusz, nem pedig a projekt környezetének változásaira való folyamatos reagálás.

Fázisok a klasszikus projektmenedzsmentben
A klasszikus projektmenedzsment megközelítéseit általában egyértelműen elkülönített projektfázisok jellemzik. A tipikus projektmenedzsment-fázisok a következők:

• Projektindítás
• Projekttervezés
• Projektvégrehajtás, -felügyelet és -irányítás
• Projektlezárás

A projekt típusától, a szabványoktól és a módszertantól függően több vagy kevesebb fázis is lehetséges. Az alábbi cikkben további áttekintést nyújtunk erről.

Tipikus megközelítési modellek
A „klasszikus projektmenedzsment” kifejezés nem egy konkrét módszert ír le, hanem egy gyűjtőfogalom különféle módszertanok számára, amelyek általában lineáris és szekvenciális megközelítést követnek. Két tipikus megközelítési modell a vízesésmodell és a V-modell.

Vizesésmodell
A vízesésmodell egy lineáris megközelítési modell a projektmenedzsmentben. Jellemzője, hogy a projektfázisok szigorúan meghatározottak, és mindegyik fázis egyszer megy végbe, grafikus ábrázolása pedig gyakran egy vízeséshez hasonlít. A vízesésmodell olyan projektekre alkalmas, ahol az elvárások már az elején tisztázottak és teljesek, és ahol kevés változás várható.

V-modell
A V-modell szintén egy lineáris megközelítési modell a projektmenedzsmentben, amely a szoftverfejlesztési folyamatot meghatározott fázisokra bontja. A vízesésmodellhez képest a V-modell kiegészíti a fejlesztési fázisokat azok tesztelési fázisaival, amelyek az adott fejlesztési szakaszokhoz kapcsolódnak. A V-modell a szoftverfejlesztésen kívül is alkalmazható, például akkor, ha rendszereket vagy termékeket fejlesztenek, amelyeket hierarchikusan alá lehet bontani egységekre és komponensekre.

Klasszikus vagy agilis projektmenedzsment? Melyiket válasszam?
Az agilis és klasszikus projektmenedzsment több területen is teljesen eltérő megközelítéseket alkalmaz. Szeretnél többet tudni erről? A következő cikkekben részletesen bemutatjuk az agilis projektmenedzsment alapjait, módszertanait.

Összegzés
A hagyományos projektmenedzsment sem elavult, sem korszerűtlen. Ahogy sokszor, itt is igaz: ha a megfelelő eszközt választjuk, nő a projekt sikeres befejezésének valószínűsége. A klasszikus projektmenedzsment megközelítések különösen akkor alkalmasak, ha a követelmények egyértelműek, kevés változtatás várható, nagy hangsúlyt fektetnek a dokumentációra, és minden résztvevő egy fix keretet szeretne az időzítést és a költségvetést illetően.

Az IT Agilist az a személy, aki az agilis módszertanok elveit és értékeit a szoftverfejlesztésben és más IT munkaterületeken gyakorolja és képviseli.

Az agilis módszertanok a rugalmasságot, az együttműködést és a folyamatos fejlesztést helyezik előtérbe a magas minőségű eredmények gyors és hatékony elérése érdekében.

Az IT agilisták lehetnek fejlesztők, projektmenedzserek, csoportvezetők vagy bárki, aki részt vesz a szoftverfejlesztési folyamatban és magáévá teszi az agilis gondolkodásmódot és elveket.

Gyakran olyan szervezetekben dolgoznak, amelyek értékelik az innováció és a folyamatos tanulás kultúráját, és olyan keretrendszereket használhatnak munkájuk irányításához, mint a Scrum vagy a Kanban.

Mit csinálnak az agilisok?

Az agilisok az agilis módszertanok elveit és értékeit gyakorolják és képviselik a szoftverfejlesztésben és más munkaterületeken.

Konkrét szerepük és felelősségi körük a kontextustól függően változhat, de az agilisok néhány kulcsfontosságú feladata a következő lehet:

Együttműködnek a csapattagokkal, hogy az összetett feladatokat kisebb, kezelhető munkaegységekre bontják.
A folyamatos fejlesztés és tanulás kultúrájának elősegítése a csapataikban és a szervezetükben.

Agilis keretrendszereket, például Scrumot vagy Kanbant használnak a munkafolyamatok irányítására és annak biztosítására, hogy a feladatok időben és a költségvetésen belül elkészüljenek.
Segítenek a csapattagok, az érdekelt felek és az ügyfelek közötti kommunikáció és együttműködés elősegítésében.
A magas minőségű eredmények gyors és hatékony szállítására összpontosítanak, különös hangsúlyt fektetve az ügyfelek elégedettségére.
A teljesítmény optimalizálása és a jobb eredmények elérése érdekében folyamatosan nyomon követik és a visszajelzések és adatok alapján módosítják a megközelítésüket.
Összességében az agilisok kritikus szerepet játszanak abban, hogy a csapatok és szervezetek hatékonyabban tudjanak dolgozni, gyorsan reagáljanak a változó körülményekre, és jobb eredményeket érjenek el az ügyfelek és az érdekeltek számára.

A téma elég hosszú, mivel több best practice is létezik. Ezek bővebb bemutatására is kitérek, de kezdjük először a sietősökkel:

Téma 30 másodpercben:

Az agilis projektmenedzsment nem egy konkrét módszertan, hanem a különböző projektmenedzsment-módszerek, például a Scrum vagy a Kanban gyűjtőfogalma. A Scrum, Kanban, hibrid modellek, mint például a Scrum/Extreme Programming vagy a Scrumban: az agilis projektek mintegy 80-90%-át e megközelítések valamelyikével valósítják meg. Ezek olyan iteratív megközelítést követnek, amelyben rövid időközönként (rész)eredményeket adnak át, és gyors visszajelzést kapnak az érdekelt felektől. Ezek a kezelhető szakaszok lehetővé teszik a változó követelményekre való gyors reagálást. Ez a cikk áttekintést nyújt az agilis projektmenedzsment legnépszerűbb folyamatmodelljeiről és keretrendszereiről.

Tehát aki mélyebben meg akar ismerkedni az elmélettel, annak most jött el az ideje:

Szerinted az agilis projektmenedzsment ugyanaz, mint a Scrum? Ez nem egészen így van. Az agilis projektmenedzsment nem kevesebb, mint 50 különböző agilis módszer, keretrendszer vagy megközelítés gyűjtőfogalma, amelyeket agilis környezetben használnak. Nem csoda: az „agilis projektmenedzsment” kifejezés nem egy konkrét módszertant ír le, hanem inkább egy filozófiát vagy a termékfejlesztés meghatározott értékeken és elveken alapuló megközelítését.

Az agilis projektmenedzsmentet az önszerveződő csapatok, a folyamatos fejlesztésre való törekvés, a magas minőségű termékekre való összpontosítás és az intenzív kommunikáció jellemzi. Ami jól hangzik, a gyakorlatban mégsem könnyű megvalósítani: Tényleg tudja, hogy pontosan mit jelentenek ezek a szép szavak? Pontosan hogyan kell megszervezni a munkát?

Ez a világos folyamatok és szabályok iránti vágy vezetett az agilis irányelveken alapuló különféle keretrendszerek és módszertanok kialakulásához. Az alapgondolat az, hogy olyan szabályokat és folyamat- és szerepleírásokat hozzanak létre, amelyek segítségével az agilis elképzelések a gyakorlatba ültethetők.

Melyek a legnépszerűbb agilis módszerek a projektmenedzsmentben?
Az elmúlt évek statisztikái önmagukért beszélnek: a Scrum messze a legnépszerűbb agilis módszer a projektmenedzsmentben. A legfrissebb, 2021-es „State of Agile” jelentés szerint az agilis projektek 81%-át a Scrum vagy a Scrum hibridek, a Scrumban és a Scrum/Extreme Programming (XP) segítségével hajtják végre.

Három alapvető agilis módszer: Scrum, Kanban és Extrém programozás
A Scrum és a Kanban egyértelműen a két legnépszerűbb agilis módszer. Az extrém programozást (XP) is itt tárgyaljuk. Bár ezt tiszta formában csak az agilis projektek körülbelül 1%-ában alkalmazzák, a Scrum/XP hibridként a projektek 6-10%-ában alkalmazzák, a statisztikáktól függően.

Scrum
Ha azt gondolja, hogy az agilis megközelítések egyet jelentenek a „keret nélküli, szabad munkavégzéssel”, akkor valószínűleg még sosem foglalkozott a Scrummal. A Scrum keretrendszer minden, csak nem anarchia; épp ellenkezőleg, egy kompromisszumok nélküli, szigorú szabályrendszer. A Scrum hivatalos útmutatója a Scrumot keretrendszerként írja le, amely lehetővé teszi az emberek számára, hogy komplex, adaptív feladatokkal foglalkozzanak, és a legmagasabb minőségű termékeket produktívan és kreatívan szállítsák le.

Igen, „komplex, adaptív, produktív, kreatív, legmagasabb minőségű” – ez a Scrum világának nyelve. Melléknevek, határozószók és nagy információs sűrűség. Ezeket a megfogalmazásokat azonban a kezdők gyakran nehezen értik meg. Nem lesz sokkal jobb, ha két mondatban összefoglaljuk a Scrum keretrendszerét:

A Scrum keretrendszer Scrum-csapatokból és szerepeikből (Roles), eseményekből (Events), artefaktumokból (Artefacts) és szabályokból (Rules) áll. Egy Scrum projekt meghatározott időperiódusokban, az úgynevezett sprintekben fut.

Nézzük tehát az egészet egy kicsit gyakorlatiasabban:

A Scrumban a projekteket iteratív módon, például 4 hetes sprintekben hajtjuk végre.
Minden egyes sprintben elkészül egy (részleges) termék, amelyet a megrendelő vagy az ügyfél átnézhet.
Ezt a visszajelzést beépítik a következő sprintbe.
A Scrum-csapat tagjai különböző szerepeket töltenek be, és önszerveződő módon dolgoznak.
Ha még soha nem került kapcsolatba a Scrummal, a keretrendszerben használt számos kifejezés elsőre zavaró lehet. Anélkül, hogy elmélyülnénk, itt adunk egy áttekintést.

A Scrum-ban három fontos szerepkör van:

• A terméktulajdonos: A projekt tartalmáért felelős személy, aki az ügyfelet vagy más érdekelt feleket képviseli. Mit kell létrehozni és milyen sorrendben? A terméktulajdonos rendelkezik a termék víziójával és az üzleti áttekintéssel.
• A Scrum Master: A Scrum folyamat betartásáért felelős személy. Coachként, mentorként, moderátorként és az akadályok elhárítójaként tevékenykedik.
• A fejlesztőcsapat: A projekt tartalmának megvalósításáért felelős személyek. A csapatoknak több funkciót betöltő (cross-funkcionális) személyzettel kell rendelkezniük (pl. tervezők, Java programozók, tesztelők), hogy képesek legyenek önállóan megoldani a teljes feladatokat.

A Scrum keretrendszerben nem létezik a projektmenedzser szerepe. Ennek ellenére projektmenedzsment feladatokat természetesen el kell végezni – de ezek megoszlanak a különböző szerepkörök között.

Egy Scrum projektben rendszeresen különböző események zajlanak:

• Sprint: A Scrum központi eleme és egyfajta miniprojekt. Minden Scrum-projekt több, egyenként legfeljebb egy hónapos sprintből áll, amelyek során egy meghatározott célt kell elérni. Minden sprintben a következő négy eseményre kerül sor.
• Sprintplanning (Sprinttervezés) : Minden sprint a sprinttervezéssel kezdődik. Itt kerülnek kidolgozásra a sprint során elérendő célok.
• Daily Scrum: A név mindent elmond: a Daily Scrum megbeszélést naponta tartják, és áttekintést nyújt a munka aktuális előrehaladásáról.
• Sprint review (Sprint felülvizsgálat): A sprint végén az eredményeket bemutatják az érdekelteknek, és megvitatják a következő lépéseket.
• Sprint Retrospective (Sprint visszatekintés) : Míg a sprint áttekintés a projekt tartalmára összpontosít, a sprint visszatekintés a folyamatokról és az együttműködésről szól. Mi megy jól – és mit lehet javítani?

A szerepek és események mellett a következő artefaktumok játszanak fontos szerepet:

Produkt Backlog : Az összes olyan funkció tárolója, amelyet a jövőbeli terméknek tartalmaznia kell, vagy az összes olyan feladat, amelyet a projekt során el kell végezni. A terméktulajdonos karbantartja és rangsorolja a tartalmat.
Sprint backlog: A product backlog részhalmaza és azok a funkciók, amelyeket a sprinttervezés során az aktuális sprint céljaként választanak ki.
Inkrement: Egy sprint eredménye és egy potenciálisan szállítható termék vagy termékrészlet. Az inkrementumnak meghatározott kritériumoknak kell megfelelnie (Definition of Done).

Sok agilis megközelítéshez hasonlóan a Scrum is a szoftveriparban a legelterjedtebb, de korántsem korlátozódik rá: Mivel a Scrum nem egy szoftverfejlesztési modell, hanem egy általános keretrendszer az agilis megközelítéshez, egyre gyakrabban alkalmazzák más iparágakban is.

Kanban
Ha a Kanban szót nem az agilis módszertanokkal kapcsolod össze a projektmenedzsmentben, hanem a termelési környezetekből ismered, akkor igazad van: a Kanban eredetileg nem egy agilis projektmenedzsment-módszertan, hanem a Toyota termelésirányításából származik. A kihívás ott: túl sok pazarlás a magas készletek, rugalmatlan folyamatok és alacsony termelékenység miatt. A Kanban célja az volt, hogy optimalizálja a termékek áramlását a gyártásban. A következetes pull-elv (keresletorientált termelésirányítás) révén a Toyota és más gyártó cégek elérték a just-in-time gyártást – mindig pontosan annyit, amennyire kereslet volt.

Ez a kitérő a termelésirányításba visszavezet bennünket a projektmenedzsmenthez: Az iparból származó módszert nem lehetett egyszerűen átültetni az IT-projektekbe. Ehelyett egy újfajta Kanban jött létre, amelyben a Lean Production, a Lean Development és a korlátozások elmélete (Theory of Constraints) elveit kombinálták. Az alapvető kérdés minden gondolat mögött: „Hogyan lehet (szoftver)termékeket sokkal rövidebb idő alatt fejleszteni?”

Ennek eléréséhez a Kanbanban 4 alapelv szerint dolgoznak:

1. „Start where you are”: Kezdd ott, ahol jelenleg állsz, és építs a meglévőkre.
2. Tegyél fokozatos, evolúciós változtatásokat.
3. Tiszteld a meglévő folyamatokat, szerepeket és felelősségeket.
4. Bátoríts minden szinten a vezetői képességek megmutatására.

Ezek az alapelvek természetesen rendkívül absztraktak. Ne aggódj: nem várjuk el tőled, hogy ezen alapelvek elolvasása után pontos képed legyen arról, mi is a Kanban és hogyan működik. De szerencsére itt nem állunk meg: az alapelvek mellett léteznek a Kanban úgynevezett 6 alapvető gyakorlata is – konkrétabb ajánlások az alkalmazásra és megvalósításra:

1. Visualize Work: Vizualizáld a munkádat és a folyamatlépéseket az értékláncban. A legtöbb projektben ehhez egy Kanban-táblát használnak.
2. Limit work-in-progress: Korlátozd a párhuzamos feladatok számát egy folyamatban lévő munka limit (WIP-limit) segítségével.
3. Manage Flow: Irányítsd a feladatok áramlását az olyan tipikus mutatók elemzésével, mint az átfutási idők.
4. Make process policies explicit: Fogalmazd meg konkrétan, milyen szabályokat kell betartani a folyamatban. Minden csapattagnak ismernie kell ezeket.
5. Implement feedback loops: A retrospektívákban vagy értékelésekben a csapat rendszeres időközönként kap és ad visszajelzést.
6. Improve collaboratively: Az egész folyamatot az állandó fejlesztés iránti törekvés jellemzi – nemcsak a végtermék minőségére vonatkozóan, hanem a munka és a folyamat minőségére is.

Nincs Kanban Kanban-tábla nélkül: A vizuális aspektusnak nagy szerepe van a Kanbanban. Valószínűleg már láttál ilyet. Az elrendezés változhat, de az alapötletek mindig ugyanazok: Minden feladatot az állapot vagy a folyamatlépések szerint oszlopokba rendeznek, és balról jobbra vezetik végig a folyamaton. A WIP-limit (work-in-progress) biztosítja, hogy ne kezdjünk túl sok feladatot párhuzamosan.

Példa:
A legegyszerűbb formájú Kanban-tábla három oszlopból áll: „Nyitott”, „Folyamatban” és „Elkészült”. Egy 2-es WIP-limit azt jelenti, hogy legfeljebb 2 feladat lehet párhuzamosan a „Folyamatban” oszlopban. Csak akkor lehet a következő feladatot „behúzni” balról, ha az egyik feladat jobbra, az „Elkészült” oszlopba került (pull-elv).

A Kanban, akárcsak a Scrum, nem korlátozódik a szoftverfejlesztésre, és más iparágakban is sikeresen alkalmazzák.

Extreme Programming (XP)
Mielőtt a Scrum megszerezte volna az első helyet, mint a legnépszerűbb agilis módszer a projektmenedzsmentben, az Extreme Programming (XP) volt rendkívül népszerű a szoftveriparban. Az 1990-es évek végén, főként Kent Beck által a Daimler Chryslernél kifejlesztett XP célja a jobb szoftverminőség és a gyorsabb alkalmazkodás volt az új ügyféligényekhez. Ahelyett, hogy minden lehetséges jövőbeni szoftverfunkciót implementálnának, az XP világosan a jelenleg legfontosabb funkciókra összpontosít. Ennek megvalósításához elengedhetetlen: a szoros együttműködés az ügyfelek és fejlesztők között:

• Az ügyfelek és érintettek prioritást adnak a termék legfontosabb funkcióinak.
• A fejlesztők rövid időközönként új frissítéseket adnak ki az ezen visszajelzések alapján.

Az Extreme Programming hasonlóan a Scrumhoz és a Kanbanhoz alapvető értékeket, elveket és szabályokat hirdet. Azonban a többiektől eltérően konkrét gyakorlatokat és módszereket kínál a szoftverfejlesztéshez, amelyek elsősorban a minőségbiztosítást és a minőség növelését szolgálják, mint például a Tesztvezérelt Fejlesztés (Test Driven Development), a Refaktorálás, a Páros Programozás, a Folyamatos Integráció (Continuous Integration) vagy a Kódolási Szabványok.

Hibrid megközelítések
Egy módszer tiszta formájában nem működik a saját cégedben? Vagy szeretnéd kombinálni a különböző megközelítések legjobbjait? Nem gond: Az agilis kiáltvány egy olyan keretet ad, amelyet minden agilis módszer vagy azok kombinációja tartalommal tölthet meg. Ahhoz, hogy a különböző megközelítésekből a legtöbbet profitálhass, egyes módszereket együtt alkalmaznak, például a hibrid megközelítéseket, mint a Scrum/XP, Scrumban vagy egyéni módszertanok.

Scrum XP Hybrid
A Scrum és az Extreme Programming tökéletesen kiegészítik egymást: Míg a Scrum egy keretrendszert biztosít a munkaszervezéshez szerepekkel és eseményekkel, addig az XP a szoftverfejlesztés konkrét módszereit biztosítja, mint például a Páros Programozás vagy a Folyamatos Integráció. Mivel az Extreme Programming a szoftverfejlesztésre specializálódott, a Scrum XP Hybrid kizárólag szoftverprojektekhez alkalmazható.

Scrumban
A Scrumban a Scrum és a Kanban népszerű hibridje. Az ötlet: A Scrum rögzített struktúráját kombinálják a Kanban rugalmasságával. A Scrumbannak nincs szigorú definíciója – minden csapat kialakíthatja a saját folyamatait. Egy lehetséges megvalósítás a következőképpen néz ki:

• A Scrum szerepek megmaradnak: Product Owner, Scrum Master és Fejlesztőcsapat.
• A munka vizualizálásához egy Kanban- vagy Scrumban-táblát használnak.
• Rögzített WIP-limitekkel dolgoznak.
• Meghatározott sprintek helyett folyamatosan biztosít

Összefoglalás:
A Scrum és a Scrum-hibridek uralják az agilis világot. Ha agilis környezetben dolgozol, ismerned kell az agilis értékeket és elveket, rendelkezned kell a Scrum keretrendszer alapvető ismereteivel, és legalább hallanod kell más agilis módszerekről, például a Kanbanról és az extrém programozásról.

Az érzelmi intelligencia (EI) és a hatékony kommunikáció kulcsfontosságú az agilis projektmenedzsmentben és klasszikus projektmenedzsmentben is, de alapjaiban minden projekt sikerében, legyen szó például egy it service felépítéséről és működtetéséről, ahol a módszertan alapja a csapatmunka, az együttműködés, a gyors alkalmazkodás és a folyamatos visszajelzés. Az agilis projektekben például a csapatok gyakran szoros határidőkkel dolgoznak, és gyorsan kell reagálniuk a változásokra, ezért az érzelmi intelligencia és a kommunikáció képessége kritikus szerepet játszik a hatékony munkavégzésben.

1. Az érzelmi intelligencia (EQ) jelentősége

Az érzelmi intelligencia az egyén képessége arra, hogy felismerje, megértse és kezelje saját érzelmeit, valamint empátiával viszonyuljon mások érzelmeihez. Az EI különösen fontos az agilis környezetben a következők miatt:

• Önmenedzsment és stresszkezelés: Az projektek gyakran intenzív ritmusúak, és a csapatoknak gyorsan kell alkalmazkodniuk a változó igényekhez. Az érzelmi intelligenciával rendelkező csapattagok jobban tudják kezelni a stresszt, és higgadtabban reagálnak a nehéz helyzetekre, ami javítja a teljesítményt és a munkamorált.
• Empátia és csapatkohézió: Alapvetően a projektekben a tagok, (legyen szó agilis vagy klasszikus projektről is) szoros együttműködésben dolgoznak. Az empátia lehetővé teszi a jobb megértést és együttérzést a csapattagok között, ami elősegíti az erős csapatszellem kialakulását. A különböző érzelmek felismerése és megértése segít a konfliktusok kezelésében és elkerülésében.
• Pozitív visszajelzéskultúra: Az agilis módszertanban például folyamatos visszajelzések történnek (pl. sprint retrospektívák során), és az érzelmileg intelligens emberek képesek építő jelleggel adni és fogadni ezeket a visszajelzéseket. Az EI segít abban, hogy a kritikai megjegyzések ne vezessenek feszültségekhez, hanem inkább fejlődési lehetőségekké váljanak.
• Rugalmasság és adaptivitás: Az agilis környezet gyorsan változik, ami gyakran kihívásokat okozhat a csapatok számára. Az érzelmileg intelligens emberek könnyebben alkalmazkodnak a változó helyzetekhez, mert képesek megfelelően kezelni a saját és mások érzelmeit a változások során.

2. A kommunikáció szerepe

Az agilis módszertanokban, mint például a Scrum és a Kanban, a kommunikáció a sikeres projektmenedzsment alapja. Az agilis projektek jellemzői, mint a gyors iterációk, gyakori megbeszélések és közös problémamegoldás, mind folyamatos és nyílt kommunikációt igényelnek.

• Átláthatóság és bizalom: Az agilis csapatokban az átlátható kommunikáció megteremti a bizalom alapját. A csapattagoknak tisztán és őszintén kell beszélniük a haladásukról, a problémáikról és az esetleges akadályokról. A megfelelő kommunikáció segít abban, hogy a csapatok időben felismerjék a problémákat és megoldásokat találjanak rájuk.
• Gyakori és strukturált visszajelzés: Az agilis módszertan fontos eleme a visszajelzések folyamatos áramlása. A napi stand-up meetingek, a sprint tervezések és a retrospektívák olyan fórumok, ahol a csapattagok visszajelzést adhatnak egymásnak. Ha a kommunikáció nyílt és konstruktív, ezek a visszajelzések elősegítik a csapat folyamatos fejlődését.
• Tudásmegosztás: Az agilis környezetben mindenki tudásának megosztása kritikus a csapat sikeréhez. A hatékony kommunikáció biztosítja, hogy az információ ne szoruljon néhány kulcsemberre, hanem elérhető legyen mindenki számára. Ez különösen fontos, amikor a csapatnak gyorsan kell új tudást felvennie és alkalmaznia.
• Stakeholderekkel való kapcsolattartás: Az agilis csapatok nem csak egymással kommunikálnak, hanem folyamatosan egyeztetnek az üzleti érintettekkel is (pl. Product Owner, megrendelők, ügyfelek). Az egyértelmű és rendszeres kommunikáció biztosítja, hogy az érintettek tájékozottak legyenek a projekt előrehaladásáról és arról, hogy az üzleti célok teljesülnek-e.
• Konfliktuskezelés: Az agilis csapatokban, ahol gyors döntéshozatalra és intenzív együttműködésre van szükség, elkerülhetetlenek a nézeteltérések. A jó kommunikáció lehetővé teszi a nyílt, tiszteletteljes párbeszédet, ami segít a konfliktusok gyors és hatékony kezelésében.

3. Érzelmi intelligencia és kommunikáció a sprint retrospektívek során az agilis projektekben

Az érzelmi intelligencia és a kommunikációs készség különösen fontos szerepet játszik a sprint retrospektívákban, ahol a csapatok megbeszélik, mi ment jól, és min lehetne javítani. Az érzelmileg intelligens csapattagok képesek konstruktív visszajelzést adni úgy, hogy az ne sértő legyen, hanem ösztönözze a fejlődést. Az empatikus megközelítés segíthet abban is, hogy a visszajelzések jobban befogadhatók legyenek.

4. Kultúraépítés és motiváció fenntartása

Az agilis csapatokban a pszichológiai biztonság megteremtése, ahol a csapattagok szabadon kifejezhetik ötleteiket, kérdéseiket vagy aggályaikat, közvetlenül kapcsolódik az érzelmi intelligenciához. Azok a vezetők és csapattagok, akik odafigyelnek egymásra, erősítik a bizalmat, motivációt és elköteleződést, ami végső soron növeli a csapat teljesítményét.

Összegzés

Az érzelmi intelligencia és a kommunikáció alapvető szerepet játszik az agilis és klasszikus projektekben, hiszen ezek teszik lehetővé a hatékony csapatmunkát, a gyors problémamegoldást és a folyamatos alkalmazkodást a változó környezethez. Az érzelmileg intelligens csapattagok és vezetők elősegítik a nyílt, bizalomra épülő kultúrát, ami az agilis módszertan egyik legfontosabb eleme.

Az IT-szakemberek fizetései Magyarországon nagyban függenek a szakmai tapasztalattól, a szakiránytól, a technológiai ismeretektől, és a lokációtól (pl. Budapesten jellemzően magasabbak a bérek). Az alábbiakban bemutatom a jellemző IT-fizetéseket különböző tapasztalati szinteken, az országos átlagokat figyelembe véve.

1. Junior szint (0-2 év tapasztalat)

Az IT-karrier kezdetén a fizetések széles skálán mozognak, attól függően, hogy milyen technológiákkal foglalkozik az adott szakember.

• Szoftverfejlesztő: 500 000 – 700 000 Ft/hó
• Rendszergazda: 400 000 – 600 000 Ft/hó
• Tesztelő (QA): 400 000 – 600 000 Ft/hó
• Helpdesk, IT-support: 350 000 – 500 000 Ft/hó
• Adatbázis adminisztrátor: 450 000 – 650 000 Ft/hó
• Frontend fejlesztő: 500 000 – 700 000 Ft/hó
• Scrum Master: 600 000 – 800 000 Ft/hó
• IT Projekt Manager: 700 000 – 900 000 Ft/hó

2. Medior szint (2-5 év tapasztalat)

Ahogy a tapasztalat nő, az IT szakemberek számára egyre nagyobb fizetések válnak elérhetővé, különösen, ha specifikus technológiai területeken szereznek mélyebb tudást.

• Szoftverfejlesztő: 700 000 – 1 200 000 Ft/hó
• Rendszergazda: 600 000 – 850 000 Ft/hó
• Tesztelő (QA): 600 000 – 850 000 Ft/hó
• Helpdesk, IT-support: 450 000 – 650 000 Ft/hó
• Adatbázis adminisztrátor: 700 000 – 1 000 000 Ft/hó
• Frontend fejlesztő: 700 000 – 1 100 000 Ft/hó
• DevOps mérnök: 900 000 – 1 500 000 Ft/hó
• IT projektmenedzser: 900 000 – 1 500 000 Ft/hó
• Scrum Master: 800 000 – 1 200 000 Ft/hó

3. Senior szint (5+ év tapasztalat)

A tapasztalt IT-szakemberek fizetései kiemelkedően magasak lehetnek, különösen, ha kritikus technológiai területeken, például felhőalapú rendszerekben, kiberbiztonságban vagy big data-elemzésben dolgoznak.

• Szoftverfejlesztő: 1 200 000 – 2 000 000 Ft/hó
• Rendszergazda: 850 000 – 1 300 000 Ft/hó
• Tesztelő (QA): 850 000 – 1 300 000 Ft/hó
• Adatbázis adminisztrátor: 1 000 000 – 1 500 000 Ft/hó
• Frontend fejlesztő: 1 100 000 – 1 800 000 Ft/hó
• DevOps mérnök: 1 500 000 – 2 500 000 Ft/hó
• Felhőarchitekt: 1 800 000 – 3 000 000 Ft/hó
• Kiberbiztonsági szakértő: 1 500 000 – 3 000 000 Ft/hó
• IT projektmenedzser:: 1 500 000 – 2 000 000 Ft/hó *
  • Különleges esetek azért vannak, de nagyobb cégeknél, nehezebb projektekben, de Budapesten). Ilyenkor a fizetés akár elérheti ezt a bérsávot is: 2 000 000 – 2 800 000 Ft/hó
• Scrum Master: 1 200 000 – 1 800 000 Ft/hó
  • Különleges esetek azért vannak, de nagyobb cégeknél, nehezebb projektekben, de Budapesten). Ilyenkor a fizetés akár elérheti ezt a bérsávot is: 2 000 000 – 2 800 000 Ft/hó

4. Magasabb vezetői szintek

Az IT-szakma csúcsán a vezetői és stratégiai pozíciókban még magasabbak lehetnek a fizetések.

• CTO (Chief Technology Officer): 2 500 000 – 4 500 000 Ft/hó
• CIO (Chief Information Officer): 2 500 000 – 4 000 000 Ft/hó
• IT igazgató: 2 000 000 – 4 000 000 Ft/hó

Technológiai specializációk, amelyek magasabb fizetéseket eredményezhetnek:

• Felhőtechnológiák (pl. AWS, Azure)
• Kiberbiztonság
• Adattudomány, Big Data
• DevOps és konténerizáció (Docker, Kubernetes)
• Mesterséges intelligencia (AI) és gépi tanulás (ML)

Lokációs különbségek

• Budapesten magasabbak az átlagfizetések, mivel több multinacionális vállalat és startup is jelen van a fővárosban, amelyek nemzetközi szinten is versenyképes fizetéseket kínálnak.
• Vidéken alacsonyabbak lehetnek a fizetések, de az elmúlt években itt is megfigyelhető volt a növekedés, különösen az olyan városokban, mint Debrecen, Szeged vagy Győr, ahol szintén egyre több IT-cég van jelen.

Összegzés

Az IT-ban a fizetések Magyarországon folyamatosan növekednek a technológiai szektor iránti magas kereslet és a tehetségek hiánya miatt. A tapasztalat, a speciális tudás és a technológiai trendekhez való alkalmazkodás kulcsfontosságú abban, hogy valaki versenyképes fizetést érjen el ezen a területen.

Fontos viszont, hogy ezek a fizetések csak irányadóak. Minden attól függ, hogy mit sikerül kialkudni, megbeszélni a felvételi beszélgetésnél. Sok múlik a projekt fontosságától, komplexitásától.

Ha érdekel ez ez a téma és naprakész akarsz lenni, mindenképp kövesd a No Fluff Jobs oldalát, ahol fizetési sávval ellátott hirdetéseket találhatsz vagy a Hays oldalát, ami minden évben monitorozza és szállítja az adott munkakörhöz tartozó átlag havi bruttó fizetéseket. 😉

Bár már egy másik cikkben már igyekeztünk a Scrum Master és IT Projektmenedzser munkaköröket összehasonlítani, most gondoltuk egy nagyot és bevesszük még a Produkt Owner szerepkört is az összehasonlításba. A Product Owner, Scrum Master, és az IT Projektmenedzser különböző szerepeket töltenek be az agilis fejlesztési folyamatban és a projektmenedzsmentben. Bár néha van átfedés a feladataik között, mindegyikük sajátos felelősségi körrel rendelkezik. Íme a fő különbségek:

1. Product Owner

A Product Owner (PO) az agilis csapatban az ügyfél igényeit képviseli, és felelős a termékfejlesztés üzleti értékeiért. Az ő feladata, hogy biztosítsa, hogy a fejlesztett termék megfeleljen az üzleti céloknak.

• Fő feladatai:
  • A termék víziójának meghatározása és képviselete a csapat számára.
  • A product backlog kezeléséért és priorizálásáért felelős (azaz a feladatok listájáért, amit a csapat elvégez a projekt során).
  • A felhasználói igények és a stakeholderek elvárásainak közvetítése a fejlesztőcsapat felé.
  • Döntéseket hoz arról, hogy mely funkciók élvezzenek elsőbbséget a fejlesztési ciklusok során.
  • Ügyel arra, hogy a fejlesztési folyamat során az ügyféligények megfelelően legyenek kezelve.
• Fókuszterületek: Üzleti értékek, ügyféligények, prioritások, termékstratégia.

2. Scrum Master

A Scrum Master a Scrum módszertan betartásáért és a csapat hatékonyságának optimalizálásáért felelős. Ő az agilis csapat facilitátora, segítve a csapatot abban, hogy a Scrum szabályai és elvei szerint dolgozzon.

• Fő feladatai:
  • Támogatja és oktatja a csapatot az agilis elvekről, valamint a Scrum keretrendszer használatáról.
  • Eltávolítja azokat az akadályokat, amelyek a csapat munkáját hátráltatják.
  • Segít a kommunikációban és a koordinációban a csapattagok, a Product Owner és a szervezet többi része között.
  • Sprintek és egyéb agilis események (pl. sprint tervezés, retrospektív) szervezése és moderálása.
  • Coachingot nyújt a csapatnak a folyamatos fejlődés érdekében, és segít az önszerveződésben.
• Fókuszterületek: Csapatmunka, hatékonyság, akadálymentesítés, Scrum folyamatok betartása.

3. IT Projektmenedzser

Az IT Projektmenedzser (PM) hagyományos projektmenedzsment módszertant (pl. vízesés modell) alkalmazhat, de egyes esetekben agilis projekteket is vezet. Ő a projekt teljes végrehajtásáért, időkeretéért, költségvetéséért és az összes résztvevő koordinációjáért felelős.

• Fő feladatai:
  • Projekttervezés és projektstratégiák kidolgozása a projekt céljainak elérése érdekében.
  • Projekt ütemezése, költségvetés kezelése, erőforrások allokálása, és a projekt státuszának nyomon követése.
  • Az összes stakeholder kezelése és kommunikációs csatornák fenntartása, beleértve az ügyfeleket és a belső érintetteket.
  • Rizikókezelés és problémamegoldás.
  • Felelős a projekt befejezéséért a megállapodott időben, költségvetésen belül és a minőségi követelmények betartásával.
• Fókuszterületek: Időmenedzsment, költségvetés, projekt hatókör, kockázatkezelés, általános projektkoordináció.

Összefoglalás

• Product Owner: A termék üzleti oldalát képviseli, meghatározza a prioritásokat és a termék vízióját a felhasználói érték maximalizálása érdekében.
• Scrum Master: Támogatja a csapatot, hogy hatékonyan dolgozzon a Scrum szabályai szerint, biztosítva a csapat folyamatos fejlesztését és a gördülékeny munkafolyamatokat.
• IT Projektmenedzser: A projekt általános lebonyolításáért felelős, gondoskodik az ütemterv, a költségvetés és a célok betartásáról, gyakran hagyományos projektmenedzsment eszközöket használva.

Mindhárom szerep fontos a projekt sikeréhez, de különböző fókuszpontokkal és felelősségekkel dolgoznak. Az agilis módszertanban gyakran a Product Owner és a Scrum Master működnek együtt a projektek hatékony irányításában, míg a hagyományos projektmenedzsment környezetben az IT Projektmenedzser vezető szerepet tölt be.

Még ha a scrum master és az IT projektmenedzser szerepe első ránézésre azonosnak is tűnik, végső soron alapvetően különböznek egymástól. Míg a projektmenedzser vezető szerepet vállal és felelős a projekt sikeréért, addig a scrum master támogató szerepet tölt be a csapat számára.

Mivel a scrum master és a projektmenedzser feladatai látszólag nagyon hasonlóak, a kettőt gyakran összekeverik. Gyakran felmerül például a kérdés, hogy a scrum master nem egyszerűen valami olyasmi-e, mint a projektmenedzser – azzal a különbséggel, hogy az utóbbi agilis módszereket használ, és valamivel szélesebb a feladatkörük.

Itt elmagyarázzuk, hogy pontosan mi a különbség a két szakma között, és hogy miért egyáltalán nem ugyanaz a scrum master, mint a projektmenedzser.

A Scrum Master feladatai
Ha még nem hallottál a Scrum keretrendszerről, az első kérdés, amit valószínűleg felteszel magadnak, az a következő: Mi az a Scrum Master? Dióhéjban összefoglalva: A terméktulajdonos és a fejlesztő mellett a scrum master a keretrendszer három alappillérének egyike. Ők biztosítják a folyamatok zökkenőmentes működését az akadályok elhárításával.

Akadályok lehetnek például: a kudarctól való félelem az új projektekkel kapcsolatban, kommunikációs nehézségek vagy konfliktusok a csapaton belül, vagy a munkavállalók rossz időbeosztása. Az ilyen akadályok elhárítására a teljes repertoárját beveti:

• coaching
• moderálás
• felügyelet
• segítségnyújtás
• kommunikáció
• motiváció
• stb.

Fontos, hogy a Scrum Master ne vezető, hanem inkább támogató szerepet vállaljon a csapat számára. Emiatt nem az egyes munkatársakra, hanem magára a csapatra helyezi a hangsúlyt. A Scrum Master a terméktulajdonost is támogatja a jelentéskészítéssel, a coachinggal, valamint a rendszeres Scrum-értekezletek és a sprinttervezés megszervezésével.

Hogyan lehet Scrum Masterré válni?
A Scrum Master kommunikációs készségekkel biztosítja a csapatban a sikeres, motivált és tehermentes munkavégzést. Ennek érdekében eltávolít mindent, ami ezt akadályozza, és erősíti a motivációs tényezőket. Ahhoz, hogy szemmel tartsa és lehetővé tegye a zökkenőmentes folyamatokat, a Scrum mesternek természetesen ismernie kell azt a területet, amelyen dolgozik. A legtöbb esetben ezek a fejlesztő cégek.

A legjobb módja annak, hogy Scrum Masterré váljon, ha van a repertoárjában egy üzleti adminisztráció vagy gazdasági informatika szakirányú végzettség. Sajnos nincs közvetlen képzés a Scrum Masterré váláshoz, de egy nem államilag ellenőrzött továbbképzési programon keresztül szerezhetsz tanúsítványt a Scrum Masterré váláshoz.

A keresett iparágban szerzett tapasztalattal vagy vezetői tapasztalattal a Scrum Management képzéssel és a Scrum Master tanúsítvánnyal kombinálva jó esélyei vannak a munkaerőpiacon.

A projektmenedzser feladatai
A támogató és kommunikáló Scrum Masterrel ellentétben a projektmenedzser vezető szerepet vállal. Fontos döntéseket hoz, feladatokat tervez a csapat számára, és összességében felelős azért, hogy a csapattagok teljesítsék a projektcél elérése érdekében rájuk háruló feladatokat.

Annak érdekében, hogy a projektek egészen a végéig a lehető leggördülékenyebben haladjanak, figyelemmel kell kísérniük a napi projektcélokat, és projektjelentéseket is kell készíteniük. Ők irányítják a beszállítókat, a feladatokat, a folyamatokat és az erőforrásokat, és mindig áttekintést tartanak fenn. Emellett irányítják az egyes csapattagok napi feladatait és teljesítményét is, ezért fontos kapcsolattartó pontként működnek. Összességében a projektmenedzser a következő feladatokért felelős:

• A találkozók ütemezés
• Folyamatok tervezése
• Az egyes projektfázisok tervezése és a célok meghatározása
• Az erőforrások, a költségek és az idő becslése
• A projekthez szükséges csapatok összeállítása
• Az alkalmazottak koordinálása és a feladatok elosztása
• Projektjelentések készítése a résztvevők és a szponzorok számára

Ezekhez a feladatokhoz a projektmenedzsernek jól kell ismernie az üzleti folyamatokat. Képesnek kell lennie arra is, hogy saját maga mellett másokat is szervezzen és motiváljon. Az erőforrás- és költségvetési megbeszélésekhez természetesen jó kommunikációs és tárgyalási készségekre is szükségük lesz.

Hogyan leszel projektmenedzser?
Mivel számos különböző vállalat, például az IT-szektorban, igényel projektmenedzsereket, képességeidtől függően többféleképpen is beléphetsz ebbe a szakmába. Sok esetben például elegendő a gazdasági vagy kereskedelmi irányultságú iskolai végzettség, de a műszaki és adminisztratív tapasztalat is számít. Klasszikus útvonal a projektmenedzseri képzés vagy a műszaki főiskolák vagy egyetemek bizonyos szakirányú képzései is.

Legnagyobb különbségek
Az már most világossá vált, hogy egyes felelősségi területek némileg átfedik egymást. Ugyanakkor a Scrum keretrendszerben a projektmenedzser munkájának nagy része a vállalatnál a terméktulajdonos felelőssége, nem pedig a Scrum Masteré. A következő táblázatban a két szakma közötti valódi különbségeket mutatjuk be:

A scrum master és a projektmenedzser különböző feladatai
Bár bizonyos esetekben mindketten tanácsadói szerepet vállalnak és motiválják a csapatot, a két szakma nagyrészt jelentősen különbözik egymástól. Míg a projektmenedzser magasabb szinten koordinál, addig a Scrum Master belülről nyújt támogatást.

Összefoglalva, az egyik legnagyobb különbség a felelősségi körökben van: Míg a projektmenedzser a projektekért, azok kiosztásáért és végrehajtásáért felel, addig a scrum master feladata a csapattagok támogatása abban, hogy maguk osszák ki a projekteket (sprinteket) és értékeljék a munkaterhelést. Ugyanakkor a terméktulajdonos felelősséget vállal.

Végső soron azonban mind a projektvezető, mind a scrum master a csapattal együtt biztosítja a projektek sikeres befejezését.

Az agilis gondolkodásmód nem csak egy üres frázis vagy divatos kifejezés, hanem egy fontos sikertényező, amely lehetővé teszi, hogy sikeresen dolgozzunk a változó időkben. Miért is? Mert segít mindannyiunknak rugalmasan és megoldás orientáltan reagálni a változásokra, és alkalmazkodni az új kihívásokhoz. Ebben a cikkben közelebbről megvizsgáljuk, mit jelent pontosan az agilis gondolkodásmód.

Mi is az a gondolkodásmód?

A „gondolkodásmód” általában „szellemi hozzáállásként” fordítható. Az egyén meggyőződésein és belső hozzáállásán alapul, amelyek gondolati és viselkedési mintákhoz vezetnek.

Példa: Flóra abban hisz, hogy folyamatosan fejlődhet, és a problémákat kihívásként kezeli. Ezzel a gondolkodásmóddal inkább nyitott lesz új dolgokra, mint Szabina, aki úgy gondolja, hogy a változások rosszak.

Mi az az agilis gondolkodásmód?

Először is: Nincs egyértelmű meghatározás az „agilis gondolkodásmód” kifejezésre. Azonban számos gondolkodásmód és tulajdonság létezik, amelyek szükségesek ahhoz, hogy az agilis projektek sikeresek legyenek:

• Fejlődési és növekedési vágy
• Együttműködési és társas kapcsolatok iránti igény
• Az eredmények elérésére való fókuszálás
• Az új helyzetekhez való alkalmazkodás képessége
• A bizonytalanság elfogadása
• Kölcsönös tisztelet
• Változási hajlandóság
• A folyamatos javulásra való törekvés

Az agilis gondolkodásmód tehát egy olyan alapvető hozzáállás, amely lehetővé teszi, hogy előre nem látható helyzetekben is megoldásokat találjunk. Az agilis gondolkodásmódhoz gyakran kapcsolódnak a „Fix gondolkodásmód” és „Növekedési gondolkodásmód” kifejezések is.

Nézzük meg a következő példákat:

Példa 1: Zoli szívesen próbál ki új dolgokat, és tudja, hogy a bizonytalanság az élet része. Bármi is történjen, biztos abban, hogy találni fog megoldást – akár a csapat többi tagjával együtt. Szeret folyamatosan megkérdőjelezni a meglévő dolgokat, hiszen mindig van lehetőség a fejlődésre. Új technológiák vagy folyamatok? Csak jöjjenek!

Példa 2: Peti szereti, ha minden ugyanúgy van, mint korábban. Nehezen birkózik meg az új dolgokkal – végül is nemrég definiálták a folyamatokat, és ezek viszonylag jól működnek. Megint pletykák keringenek arról, hogy több önállóságot kellene vállalni az osztályukban. De miért? Elégedett azzal, ha feladatokat osztanak rá, amelyeket sorra elvégezhet.

Nyilvánvaló, hogy kinek van agilis gondolkodásmódja, igaz? Az ilyen példákat olvasva több kérdés is felmerülhet benned:

• Csak az agilis gondolkodásmód pozitív?
• Mindannyiunknak agilis gondolkodásmóddal kell rendelkeznie?
• Most akkor én egy „régi vágású” unalmas ember vagyok?

Talán azonosulsz Zolival, és örülsz, hogy agilis gondolkodásmóddal rendelkezel. Mindenesetre érdemes megkérdezni, hogy valóban mindenkinek agilis gondolkodásmóddal kell-e rendelkeznie ahhoz, hogy sikeresen dolgozzon a változó időkben és agilis környezetben.

Mindenkinek szüksége van agilis gondolkodásmódra?

Legyünk őszinték: Mindannyian ismerünk embereket, akik képtelenek lennének boldogulni egy teljesen agilis környezetben. Van oka annak, hogy egyes emberek inkább könyvelők lesznek egy hagyományos középvállalatnál, míg mások kreatív marketingkampányokat fejlesztenek egy start-up cégnél.

A tény az, hogy sikeres projektekhez és vállalatokhoz különböző személyiségtípusokra és munkamódszerekre van szükség – és ez rendben is van. A csapatok sokféle személyiségtípusból profitálnak, feltéve, hogy alapvető értékeik nem különböznek túlságosan.

Fejleszthető az agilis gondolkodásmód?

Igen és nem – de inkább „igen”. Bizonyos személyiségjegyek nehezen változtathatók meg, így egy erősen hierarchikus gondolkodású és magas biztonságigényű személy soha nem fogja teljesen jól érezni magát egy agilis környezetben. De persze semmi sem lehetetlen. Még a végén IT Agilist válhat belőle. 🙂