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.