Vállalati agilis transzformáció
01
Klasszikus projektmenedzsment vagy Agilis projektmenedzsment
Az agilis projektmenedzsment lényege abban rejlik, hogy olyan eszközökkel és módszerekkel dolgozik, melyek elsődleges célja az erőforráspazarlás csökkentése és a résztvevők motivációjának növelése olyan projektekben, ahol jellemzően aránylag kevés szereplő dolgozik 1-1 folyamaton, szoros együttműködésben.
Míg egy klasszikus projektmenedzsment módszertan (pl. vízesés módszertan) szigorú specifikációkon és jól elkülönülő, diszkrét projektszakaszokon alapul, addig az agilis módszertanok (pl. Scrum) sokkal szabadabb és rugalmasabb. Agilis módszertanokra jellemző, hogy nem követelmény a tűpontos specifikáció készítése, hiszen a tervezés és a megvalósítás szakaszos és inkrementális formában, egymással átfedésben, iteratív módon valósul meg, azonban kötelező a módszertan szerinti folyamatos dokumentáció és a projekt megrendelőjével való folyamatos egyeztetés és jóváhagyás.
Bár a klasszikus és az agilis projektmenedzsment alapvető logikája különbözik, elképzelhető, hogy egy szervezetben mindkét módszertan jelen van, ugyanis különböző üzleti helyzetekben hol az egyik, hol a másik irány alkalmazható hatékonyabban. Szakértőink célja, hogy segítsék ügyfeleinket annak felismerésében, hogy mely folyamatok esetében melyik lehet hatékonyabb, illetve, hogy megtanítsák ügyfeleink projektvezetőit a megfelelő módszertanok kiválasztására és alkalmazására.
02
Agilis módszertan meghatározása
Szakértőink segítenek meghatározni, hogy az adott projekt problémáit melyik agilis módszertan (pl. Scrum, Kanban) alkalmazásával érdemes kezelni. Az általunk preferált egyik legáltalánosabb és leghatékonyabb agilis módszertan a Scrum.
03
Kollégák oktatása, próbaidőszak
A módszertan kiválasztása után következik ügyfeleink munkatársainak oktatási fázisa. Ennek keretében a kollégák megtanulják a kiválasztott agilis módszertan működését, valamint próbaidőszak keretében annak alkalmazását is.
04
Vállalati agilis transzformáció
Amennyiben az agilis tesztidőszak és tesztprojekt sikerrel zárult és a bevezetett módszertan elnyerte ügyfeleink tetszését, a vállalat számára átfogó agilis transzformációs szolgáltatást biztosítunk, melynek keretében a vállalat akár összes meglévő folyamatát feltérképezzük és javaslatot teszünk az agilis projektvezetésre való átállás lépéseire és megvalósítására.
Agilis transzformáció
Agilis módszertani alapok:
Scrum módszertan
A tudomány jelenlegi állása, valamint szakértőink prefereciára szerint az egyik legáltalánosabban használható, legelterjedtebb és leghatékonyabb agilis módszertan a Scrum. Ügyfeleinknek elsősorban a Scrum bevezetését javasoljuk a vállalat agilis transzformációja során.
Agilis szerepkörök
Scrum Master és Product Owner
A Scrum módszertan alapvetően kis csoportos projektekre készült, a projekt érintettjei két nagy csoportra oszthatók: (1) Scrum Team (“Scrum csapat”) és (2) Egyéb érdekeltek (vezetők, felhasználók, stb).
A Scrum csapat tagjai a csapattagok, akik egymással egyenrangú szereplők a módszertan szerint. Van köztük azonban két különleges szereplő, a Scrum Master (“Scrum Mester”) és a Product Owner (“Terméktulajdonos”).
A Product Owner az a szereplő, aki a klasszikus módszertanokban a projektvezetőnek feleltethető meg, azonban ő nem egy klasszikus vezető, sokkal inkább egy “szolgáló-vezető” (servant-leader), hiszen a Scrum csapat egyenrangú tagokból áll. A Product Owner a projekt megrendelőjének (menedzsment vagy külső megrendelő) képviselője és a feladata az üzleti szempontból megteremtett érték maximalizálásának biztosítása, a munkaelemek priorizálása, a csapattagok támogatása, valamint a Product Backlog nevű dokumentum kezelése.
A Scrum Master felelőssége a Scrum folyamatos szervezése, egyértelműsítése és támogatása a Scrum csapaton belüli és azon kívüli érintettek között egyaránt. A Scrum Master szerepe a Product Owner szerepköréhez hasonlóan rendkívül összetett, egyszerre szervező és támogató, facilitátor és akadálymentesítő, valamint támogató és tanító szerepkör az övé.
A csapattagok adják a harmadik csoportot a Scrum csapaton belül. Ők azok a szereplők, akik a projekt megvalósításának különböző részfeladatait megoldják, ők állítják elő a projekt eredménytermékeit. A csapattagok kvázi önszerveződő módon szervezik saját munkáikat, egymással együttműködve vagy külön-külön.
Agilis munkakörnyezet és ceremóniák
Sprintek, Daily Standup, Retrospektív
A Scrum módszertan alapvetően 2-4 hetes időszakokban, ún. sprintekben gondolkozik, így kerülnek az egyes szakaszok kialakításra. Ezen belül, a módszertan definiál speciális eseményeket, ezek az úgynevezett Scrum ceremóniák. Scrum ceremóniának a következő események minősülnek: Sprint Planning (“Sprint Tervezés”), a Daily Scrum (“Napi Scrum Megbeszélés”), a Sprint Review (“Sprint Áttekintés”) és a Sprint Retrospective (“Sprint Visszatekintés” vagy “Retrospektív”).
A Sprint Planning minden sprint előtt elvégzendő, néhány óra hosszúságú ceremónia. Ennek során kijelölésre kerül, hogy milyen feladatoknak kell elvégzésre kerülni a sprint során, valamint hogy milyen egyéb teendők várhatók ez idő alatt.
A Daily Scrum egy olyan esemény, amelyet minden nap megtartanak a csapattagok. Ennek időtartama korlátozott (15 perc), és egy-egy sprint során jellemzően minden nap ugyanakkor és ugyanott tartják meg a csapattagok. A Daily Scrum tulajdonképpen egy megbeszélés, melynek során a csapattagok tipikusan körben állva osztják meg egymással, hogy (1) mi az amit az előző Daily Scrum óta csinált és tanult, (2) mi az amit aznap fog csinálni, (3) milyen akadályokat lát, illetve mire lesz szüksége a saját céljai és a sprint céljainak eléréséhez. Az akadályok elhárításában a Scrum Master segíti a csapattagokat elsősorban, így ez az információ rendkívül fontos a számára.
A Sprint Review egy olyan, néhány óra hosszúságú esemény, amit – nevéből fakadóan – csak a sprintek végén tartanak meg a csapattagok. Ennek a ceremóniának a lényege, hogy értékeljék a sprintet az előre meghatározott végcél (Product Goal) szempontjából, és hogy áttekintsék, hogy mely munkákat sikerült elkészíteni és melyeket nem. Amennyiben van bemutatható munkaelem, a Sprint Review-nak része egy Demó esemény is, melynek keretében a kész munka “demózásra”, azaz bemutatásra kerül a Product Owner számára.
A Sprint Retrospective – a negyedik ceremónia – a másik olyan, néhány óra hosszúságú esemény, melyet a csapattagok csak a sprint végén tartanak meg. A Sprint Retrospective lényege, hogy értékeljék a sprintet a csapat szempontjából. Ekkor a csapattagok megosztják a gondolataikat, véleményeiket a befejezett sprintről, valamint javaslatokat tesznek a további fejlődésre. Két kérdés vezérli az eseményt, (1) “Mi az, ami jól ment a sprint alatt?” , (2) “Mi az, amit a következő sprint során jobban lehetne csinálni?”. Ezekre a kérdésekre minden csapattag válaszolt, ezek azonban nem kell, hogy rendkívül kidolgozott és megalapozott válaszok legyenek, a cél, hogy a csapattagok beszámolhassanak az élményeikről.
Agilis dokumentumok és eredménytermékek
Backlog-ok, Definition of Done (DoD)
A Scrum módszertan – mint minden agilis módszertan – meghatározza azon általános dokumentumok körét, amit szigorúan el kell készíteni, minden projektben, ezeket nevezzük Scrum Artifacts-nek. Ezek a munkaanyagok a következők: (1) Product Backlog (“Termék követelménylistája”), (2) Sprint Backlog (“Sprint Teendőlistája”) és (3) Increment (“Növekmény”).
A Product Backlog tartalmazza az előállítandó eredménytermékek magas szintű követelménylistáját, valamint a követelmények prioritásait. Ez a dokumentum definiálja a Product Goal-t is, azaz a projekt előre meghatározott végcélját. A követelménylista szabadon szerkeszthető a csapattagok által, azonban a mindenkori felelőse és kezelője a Product Owner, neki kell biztosítani, hogy a projekt megrendelője által kitűzött üzleti cél megvalósulhasson.
A Sprint Backlog az a dokumentum, amely tartalmazza a sprint során elvégzendő teendőket, azaz, hogy a csapat miként fogja megvalósítani a feladatokat. A feladatok részfeladatokra bontódnak, melyek úgy kerülnek kialakításra, hogy 1-1 feladat maximum 1-2 nap alatt elvégezhető legyen. A feladatok és részfeladatok nincsenek konkrét személyhez rendelve, a dokumentum célja épp az, hogy ezáltal a csapattagok átláthatják, hogy az egyes feladatok és részfeladatok milyen állapotban vannak és az elvégzendő feladatokat szétoszthatják egymás között.
Az Increment lényege, hogy tartalmazza azokat az eredménytermékeket (“növekményeket”), amelyek elkészültek. Rögzítésre kerül benne a Definition of Done (DoD), azaz annak a leírása, hogy mi tekinthető elkészült eredménynek. Az eredménytermékek elkészültnek nyilvánításához alapvető követelmény a használható állapot.
Kapcsolat
Kérdése van?
Vegye fel a kapcsolatot velünk! Küldje el kérdését, üzenetét az alábbi űrlap segítségével. Munkatársaink örömmel válaszolnak a felmerülő kérdésekre és adnak ajánlatot a további együttműködést illetően.
Apex Advisory
Hisszük, hogy alaposan kidolgozott, magas szakmai színvonalú módszertanjaink segítségével hatékonyan tudjuk támogatni a hazai vállalatokat céljaik elérésében, legyen szó akár a projektjeik finanszírozásáról és megvalósításáról, innovációmenedzsmentről vagy a generációváltás sikerre viteléről.