Telefon: +36 70 6363 538

Agilis projektmenedzsment

Agilis-projektmenedzsment 2020Az ügyfeleim egy része fejlesztőmérnök, akik agilis projektmenedzsmentet alkalmaznak, elsősorban Scrumot. Sokat tanultam tőlük arról, miként alkalmazható az agilis módszertan.

Cikkemmel olyan vezetőknek szeretnék segíteni, akik agilis megközelítésmódokat keresnek, de nem feltétlenül a szoftverfejlesztésben szeretnék alkalmazni, hanem esetleg más területeken.

Mire való az agilis projektmenedzsment?

Az agilis projektmenedzsment bármilyen olyan összetett probléma megoldására alkalmas, amikor

  • a megoldás részletei előre nem ismertek,
  • az eredményekkel kapcsolatos elvárások várhatóan változnak,
  • a munkát részekre lehet bontani, és az egymásra épülő részeredmények értéket képviselnek,
  • lehetőségünk van szorosan együttműködni a végfelhasználóval, akinek a visszajelzései alapján haladunk és hasznosítjuk a tanulságokat.

Néhány területen jól alkalmazható az agilis projektmenedzsment, ezek például a termékfejlesztés, forráselosztás, felforgató innovációk, marketingprojektek, stratégiai tervezés, szervezeti együttműködés javítása.

A rutintevékenységet igénylő feladatok esetén kevésbé van értelme, ezek pl. a könyvelés, karbantartási munkák, értékesítés, beszerzés, teljesítményértékelés.

Az iparágakat tekintve, a szoftverfejlesztésen kívül leginkább a pénzügyi és professzionális szolgáltatások, biztosítás, kormányzat, egészségügy, ipar és telekommunikációs területeken terjedt el.

Az agilis projektmenedzsment egy szemlélet

Vannak, akik nem egy szigorúan meghatározott módszertanról beszélnek, hanem sokkal inkább egyfajta hozzáállásról, kultúráról. Lényege, hogy alaposan megértsük az ügyfeleink igényét, amelyre megoldást dolgozunk ki. A megközelítés azért agilis, vagy más szóval adaptív, vagy rugalmas, mert az ügyfél visszajelzései alapján gyors változtatást tesz lehetővé a fejlesztés alatt álló termékben vagy szolgáltatásban.

Többféle agilis módszertan létezik, amelyek keretrendszert biztosítanak a csapatoknak, amin belül azok szabadon kialakíthatják saját gyakorlatukat (pl. Scrum, Kanban, Lean startup, Design thinking).

A legelterjedtebb keretrendszer a Scrum, amit 1995-ben publikáltak először (az alkotói már 1993 óta használják). Ebben az írásban elsősorban ennek a keretrendszernek a bemutatására helyezem a hangsúlyt.

Mi tanulhatunk a Scrumból?

Nézzük meg, hogyan tudjuk alkalmazni a Scrum-elveket a saját projektjeinkben, amelyeknek – mint azt korábban is hangsúlyoztam – nem kell feltétlenül szoftverfejlesztéshez kapcsolódniuk.

Sprint

A Scrumban sprinteknek nevezték el azokat az egységnyi időtartamokat, amelyekben gondolkodunk. A sprintek 5, 10 napos, de egy hónapnál nem hosszabb időszakok, amelyeknek a végére működő terméket, prototípust kell előállítanunk. Ennek passzolnia kell a korábbi sprintek alatt létrehozott termékbe, szolgáltatásba, azaz egyfajta termék-, szolgáltatásbővítményt hozunk létre.

Agilis szerepkörök

Elméletben három szerepkört ismerünk, de a gyakorlatban számos példát látok arra, hogy két szerepkörrel is jól működnek a sprintek.

Csapat – szoftverfejlesztésben a fejlesztők alkotják a csapatot, de bármilyen szaktudású ember részt vehet. Az ideális létszám 5 fő körül van. Tapasztalatok szerint 9 fő felett a munka már nem szervezhető meg hatékonyan. A lényeg, hogy a tagok teljes munkaidős, belső munkatársak legyenek, akik olyan kompetenciákkal rendelkeznek, ami képessé teszi őket rendszeres időközönként, működő terméket szállítani.

A csapat önszerveződő, és a szállítási képessége nem függ semmilyen külső szakértelemtől. A kompetencia-összetétel nyilván projektenként más és más. Az is előfordulhat, hogy egy csapattag több kompetenciával is rendelkezik. A tagok a feladataikat nem egymástól függetlenül, hanem szoros együttműködésben végzik.

Product owner – magyarul termékgazda, de mivel a kifejezés angolul terjedt el, ezért én is így használom. A product owner felel azért, hogy megfogalmazza a célokat, amelyeknek az eléréséért a csapat dolgozik.

Egy ún. product backlogban, teendőlistában vezeti a csapat összes feladatát. A listát folyamatosan rendezi oly módon, hogy mindig a legfontosabb feladat kerüljön a lista élére. A listában szereplő feladatokat mindenki számára érthetővé és elérhetővé teszi.

A feladatok kis méretűek. Ha egy feladat végrehajtásának ideje meghaladja a 6-8-12 órát, akkor kisebb feladatokra bontják szét. Így a feladatok egy munkanapon belül elvégezhetők és könnyebben kezelhetők. Ha túl sok az 1-2 óránál rövidebb feladat, akkor azokat csoportosítani szokták.

Scrum master – facilitátornak, csapatot szolgáló vezetőnek, vagy agilis coachnak, moderátornak is nevezik. Azért felel, hogy mindenki megértse, elfogadja és betartsa a Scrum szabályait. Feladata a megfelelő légkör, szellemiség biztosítása és a csapat önszerveződésének segítése.

Az ügyfeleimnél láttam példát arra, hogy a product owner és a scrum master szerepét egy fő látja el. Így is működik a projekt, mégis azt javasolom, hogy válasszuk szét a két szerepet, ha egy mód van rá. Különösen kezdő vezetők esetén.

Válasszunk product ownernek olyan vezetőt, aki céltudatos, erős a tervezésben és szívesen bíbelődik a részletekkel. Míg scrum masternek olyat, aki könnyen épít kapcsolatokat, képes másokat lelkesíteni és a csapatot összetartani.

Más-más karaktert és kompetenciákat igényelnek ezek a szerepek. Kezdő vezetők jobban teljesítenek, ha a személyiségükkel rezonáló szerepbe kerülnek, legalábbis vezetői karrierjük legelején.

Sprinttervezés

A legegyszerűbb, ha a sprinteket miniprojekteknek tekintjük. A sprinttervezés közös munka, minden csapattag részt vesz benne. A lényeg, hogy mindenki legyen képben azzal kapcsolatban, hogy milyen célokat szeretnének elérni és azt hogyan teszik.

Sprinttervezésre max. 8 órát javasolnak a szakemberek, ha egy hónapos időtávokban gondolkodunk, és arányosan kevesebbet rövidebb ciklusok esetén. Az ügyfeleim számára, akik kétheti ciklusokban dolgoznak, a 4 óra gyakran kevés. Nyilván projektje is válogatja, minek mennyi a valós időigénye. Ilyenkor érdemes megvizsgálni, hogy hatékonyan gazdálkodunk-e a rendelkezésünkre álló idővel.

Arra is látok példákat, hogy a csapat a „hivatalos sprinttervezést” megelőzően már elkezd tervezni. Mivel a Scrum egy rugalmas keretrendszer, ezzel semmi gond sincs. Egy másik elem, amiben, úgy látom, a csapatok hajlamosak eltérni a nagykönyvben leírtaktól, az erőforrásráfordítás-igény becslése.

A ráfordításigényt a gyakorlatban szívesebben becsülik meg időalapon, mint a feladat komplexitása alapján, amire a Scrum egyébként részletes útmutatást ad planning poker néven. A planning poker lényege, hogy a csapattagok a korábbi sprintek tapasztalatai alapján pontszámokat rendelnek az egyes feladatokhoz azok összetettségét figyelembe véve.

Napi Scrum

Más néven daily stand-up, ami egy 15-20 perces megbeszélés naponta, vagy hetente néhány alkalommal. Célja, hogy a csapattagok összehangolják a munkájukat annak érdekében, hogy a sprint végére elérjék a kitűzött célokat.

Szakemberek azt javasolják, hogy a napi Scrumot mindig ugyanabban a napszakban tartsuk, mindegy, mikor. E mögött az a praktikus megfontolás áll, hogy nem kell napi szinten egyeztetni a találkozókat. Ez az ügyfeleimnél is bevált.

A napi Scrum során a következő három sztenderdnek számító kérdés hangzik el, amit a csapattagok egyenként válaszolnak meg:

1. Mit csináltam az előző napi Scrum-megbeszélés óta, ami hozzájárult ahhoz, hogy a csapat elérje a sprint céljait?
2. Mit fogok tenni a következő megbeszélésig, ami előreviszi a projektet?
3. Látok-e bármilyen akadályt, ami veszélyezteti vagy megakadályozza azt, hogy a csapat elérje a sprint célját?

Ezeken kívül másról nem esik szó. Ha a csapat úgy dönt, hogy több időre van szükség egy téma megbeszélésére, akkor a scrum master kiír egy másik találkozót.

Sprintvisszatekintés

A sprint felülvizsgálatát minden sprint végén megtartják. Célja, hogy megvizsgálják, elérték-e a sprint céljait, és értékelik a sprint során szerzett tanulságokat.

Nem egy formális prezentációt kell elképzelni, hanem egy kötetlen beszélgetést, amit a scrum master facilitál. Részt vehetnek rajta a projekt érintettjei is, őket a product owner dolga meghívni.

A csapat együtt végignézi a product backlogot, és ellenőrzi, hogy mi az, ami elkészült a listából. Végül aktualizálják a listát, ami kiindulópontját képezi a következő sprintnek.

Általában 4 órásra tervezik a visszatekintést (egy hónapos sprint esetén).

Úgy látom az ügyfeleimnél, hogy a visszatekintések alkalmával több figyelmet szentelnek a terméklistának. Kevésbé élnek azonban a csapatmorált és -hangulatot javító lehetőségek kiaknázásával.

Leszámítva azt az esetet, amikor a scrum master szerepét betöltő vezető ügyes a facilitálásban, és szívesen vállalja fel „puhább témák” megbeszélésének ösztönzését.

Agilis eszköztár

Az átláthatóság megteremtésének eszközei a vizuális táblák, grafikonok. Ezek közül az egyik legjelentősebb a burn-down chart, vagy munkahátralék- grafikon, ami azt mutatja meg, hogy a feladatokból mennyit végeztek el, és még mennyi ráfordításra van szükség a sprint végéig.

Az egyik ügyfelem (András) felettese, a vezetői coachingot megelőzően azzal a kéréssel fordult hozzám, hogy találjunk ki valamit, amivel a felső vezetők számára is átláthatóvá válik, mivel foglalkozik András csapata. Nem érti, mitől annyira leterheltek, és miért nem tudják az ügyfelek kéréseit azonnal kielégíteni.

A szoftverfejlesztőknél előfordul (a gyors technológiai fejlődésnek köszönhetően egyre gyakrabban), hogy a fejlesztők feletti, néhány szinttel magasabban lévő vezetői réteg már alig látja át, hogy mit csinálnak az embereik. Következésképpen becsülni sem tudják, hogy mi mennyi ráfordítást igényel.

András csapata nem ismerte az agilis módszertant, de nyitott volt arra, hogy megvizsgálják a burn-down chart elkészítésének a lehetőségét. Sok munkával Excelben elkészítették, és óriási sikert arattak vele. Lehet, hogy a felső vezetők nem értették a részleteket, de vizuálisan átlátták a csapat tevékenységét, és ez megnyugtatta őket. A burn-down chart a projekt láthatóvá tételének egy kiváló, modern eszköze (is).

Az agilis projektmenedzsment Scrum keretrendszere, amelyet a fentiekben bemutattam, a szoftverfejlesztésben terjedt el, de érdemes átvenni belőle elemeket, vagy a teljes megközelítésmódot más projekt esetén is.

Amennyiben érdekli, hogy az agilis projektmenedzsment mennyire terjedt el, ajánlom a VersionOne 2018-as felmérését.

Köszönöm, hogy elolvasta írásomat. Ha tetszett, kövesse szakmai tevékenységemet, és ossza meg cikkeimet másokkal is, ha úgy érzi, hogy számukra is hasznos lehet.
Írásaim saját szellemi termékeim, ezért kérem, ha felhasználja, azt a szerzői jog tiszteletben tartásával tegye. Az eredeti tartalommal, a szerző és a forrás megjelölésével idézze, ahogy én is teszem.

Válasszon engem vezetői coachának, és segítek önnek olyan vezetői kompetenciákra szert tenni, amellyel magabiztosan állhat az agilis átalakulás élére, bármilyen vezetői szerepkörben is van.

Írjon a kranitz.eva@vezetofejlesztes.hu-ra, vagy hívjon a 70 6363 538-as telefonszámon.

Kránitz Éva, MBA

„Olyan vezetői kultúra kialakításához szeretnék hozzájárulni, ahol a vezetők tudatosak abban, amit teremtenek és támogatják munkatársaikat abban, hogy célt, értelmet és megelégedettséget találjanak a munkájukban. ”