Telefon: +36 70 6363 538

Agilis szemléletAgilis módszertan vezetőknek dióhéjban

Egyre többet hallunk „agilis módszertanról”, „agilis termékfejlesztésről”, „agilis projektmenedzsmentről” és „agilis szervezetről”.  A fogalmak a vezetés-szervezés körébe tartoznak, ezért úgy gondoltam írok bővebben az agilitásról, ezúttal az agilis módszertanról.

 

Az agilis módszertan a szoftverfejlesztésből jön

A szoftverfejlesztés hajnalán úgy vélték, hogy a fejlesztés lineáris folyamat, aminek az első szakaszaiban kell a megfelelő figyelmet és technikákat alkalmazni, és akkor biztos lesz a siker. Számtalan sikertelen szoftverfejlesztési projekt bebizonyította, hogy ez tévedés. Ha ön 40+ éves, talán van olyan élménye, amikor a pályája kezdetén a cégénél szoftverfejlesztésbe kezdtek, ami teljes kudarccal végződött. Mire a szoftver elkészült, kiderült ugyanis, hogy nem is arra volt az ügyfélnek szüksége, amin a fejlesztők hónapokat dolgoztak, de ami ennél még sajnálatosabb, a saját igényeikkel, elvárásaikkal sem voltak tisztában.

Feltételezem, hogy a sok fejlesztési kudarc, nem beszélve a temérdek költségről, kényszerítette ki a megoldást. 2001-ben a szoftveripar nagyjai együttesen előálltak egy „kiáltvánnyal az agilis szoftverfejlesztésért”. A kiáltvány honlapján található 12 „agilis alapelv” a következő:

  1. Legfontosabbnak azt tartjuk, hogy az ügyfél elégedettségét a működő szoftver mielőbbi és folyamatos szállításával vívjuk ki.
  2. Elfogadjuk, hogy a követelmények változhatnak akár a fejlesztés vége felé is. Az agilis eljárások a változásból versenyelőnyt kovácsolnak az ügyfél számára.
  3. Szállíts működő szoftvert gyakran, azaz néhány hetenként vagy havonként, lehetőség szerint a gyakoribb szállítást választva!
  4. Az üzleti szakértők és a szoftverfejlesztők dolgozzanak együtt mindennap, a projekt teljes időtartamában!
  5. Építsd a projektet sikerorientált egyénekre! Biztosítsd számukra a szükséges környezetet és támogatást, és bízz meg bennük, hogy elvégzik a munkát!
  6. Az információátadás fejlesztési csapaton belüli leghatásosabb és leghatékonyabb módszere a személyes beszélgetés.
  7. A működő szoftver az előrehaladás elsődleges mércéje.
  8. Az agilis eljárások a fenntartható fejlesztést pártolják. Fontos, hogy a szponzorok, a fejlesztők és a felhasználók folytonosan képesek legyenek tartani egy állandó ütemet.
  9. A műszaki kiválóság és a jó terv folyamatos szem előtt tartása fokozza az agilitást.
  10. Elengedhetetlen az egyszerűség, azaz az elvégzetlen munkamennyiség maximalizálásának művészete.
  11. A legjobb architektúrák, követelmények és rendszertervek az önszerveződő csapatoktól származnak.
  12. A csapat rendszeresen mérlegeli, hogy miképpen lehet emelni a hatékonyságot, és ehhez hangolja és igazítja a működését.

A hagyományos felfogás szerint az elérendő cél alapján határozták meg az erőforrásigényeket, az agilis módszertan szerint viszont pont fordítva kell eljárni: az idő és a költségkeretek alapján kell meghatározni az elvégezhető feladatot.

Scrum

Az agilis kiáltvány után számos módszertani megközelítés látott napvilágot (Feature Driven Development, Scrum, Test Driven Development, Kanban, Crystal Clear), melyek közül a Scrum tett szert a legnagyobb ismertsége. A „scrum” a rögbijátékban használt alakzat, amely a labda védelmét szolgálja a támadókkal szemben, akik természetesen mozognak. A Scrum agilis módszer köré komoly infrastruktúra épült ki az évek során. A módszer kézikönyve (Scrum Guide, lásd Sutherland–Schwaber, 2011) több nyelven elérhető, illetve a módszertan elsajátítása esetén többféle Scrum minősítés is szerezhető.

A Scrum terminológiájában egy iteratív fejlesztési ciklust sprintnek neveznek. Az adott sprint során a vizsgált időpontban még hátralevő, megvalósítandó szoftverfunkcionalitást “product backlog”-nak, vagy „sprint teendőlistának” hívják. A Scrum feltételezi, hogy nagy vonalakban ismert a sprint során elkészítendő termék terjedelme.

A Scrum kisebb fejlesztőcsapatokat (3–9 fő) tételez fel. Két szerepet különböztet meg, a „product ownert”, vagy magyarul “termékgazdát”, egy olyan felhasználót értve ez alatt, aki lényegében meg tudja fogalmazni a fejlesztendő szoftvertől elvárt funkcionalitást, illetve a „Scrum-mestert”, aki a Scrum szabályainak megértéséért és betartatásáért felelős. A fejlesztőcsapat további tagjait a módszer nem különbözteti meg névvel. Mindenki fejlesztőnek számít függetlenül attól, hogy az adott platformhoz értő szoftverfejlesztő, üzleti elemző, tesztelő, dokumentumíró vagy a felhasználói élmény megtervezéséért felelős UX/UI designer.

A Scrum módszer sajátossága a fejlesztőcsapat önszerveződő volta. A Scrumban ennek megfelelően a csapat tagjai önként (önszerveződően) vállalják fel a sprint feladatait. Egy sprint időtartama legfeljebb egy hónap, egy feladat időigénye pedig a sprint első részeiben legfeljebb egy munkanap. „Napi Scrumnak”, más néven “Daily stand-up”-nak  nevezett értekezleteket tartanak, ami a következő 24 óra tervezését szolgálja. A napi Scrum legfeljebb 15 percig tarthat, minden résztvevőnek három kérdésre kell válaszolnia:

  • Mit sikerült elvégeznie az előző megbeszélés óta?
  • Mit fog csinálni a következő megbeszélésig?
  • Milyen akadályozó tényezőket lát?

A sprint végén kerül sor a „sprintáttekintőre”, más néven ” sprint visszatekintésre”, vagy “retrospektivre”, ahol áttekintik az elkészült és az el nem készült részeket, megvizsgálják ennek okait és lehetséges következményeit. Ezen a ponton lehet átbeszélni azt is, hogy miként áll a teljes termék megvalósítása. Ilyenkor felmérhetik a fejlesztőcsapat és a módszer javítását célzó intézkedéseket is. Ezek után kerülhet sor a következő sprint megtervezésére, ahol gyakran olyan funkcionalitást határoznak meg, amely a sprint eredményes befejezése esetén azonnal használható.

Az agilis módszertan alapelvei

Tekintsük át az agilis szemlélet alapelveit, melyeket ha a vezetéstudomány szemszögéből közelítünk meg, rájöhetünk, hogy nem minden új a nap alatt.

Egy terv legyen hihető (reális): Az innovatív (kockázatosabb, bizonytalanabb) feladatokat (projekteket) csak olyan időtávra érdemes részletesen megtervezni, amelyben a tervtől való eltérés mértéke várhatóan nem lesz elfogadhatatlanul nagy. Ez a tervezési alapelv a klasszikus projektmenedzsment eszköztárából sem hiányzik. Ami újszerűnek tekinthető az agilis világban, az a tervezés mindenhatóságába vetett hit megkérdőjelezése.

Az önszerveződés javíthatja a csoport teljesítményét: Az agilis munkavégzés további sajátossága, hogy a munkatársak maguk vállalkoznak egyes feladatok elvégzésére. Ez sem nevezhető új ötletnek, hiszen az önszerveződő csoportok előnyei már régóta ismeretesek. Az önszerveződő csoportok jellegzetessége, hogy a csoport tagjai maguk döntik el, mely munkafázissal foglalkoznak, az egyes tagok képesek többféle munka ellátására, és maguk határozzák meg a jutalmazás és munkakövetés módját.

Az önszerveződő csoportokban dolgozók csoportkohéziója erősebb, és így termelékenysége gyakran meghaladja a szokványos munkaszervezéssel vezetett csoportokét. Nem meglepő tehát, hogy az agilis fejlesztési módszerek eredményesebbnek és hatékonyabbnak bizonyulnak, amennyiben az elvégzendő feladat természete lehetővé teszi annak önszerveződő csoport általi elvégzését.

Nyilvánvalóan a csoport tagjainak száma és személyisége is befolyásolja azt, hogy ez a fajta vezetési módszer alkalmazható-e. 10 főnél nagyobb létszámú csoportoknál gondokba ütközhet a kommunikáció. A csoport tagjainak képesnek kell lenniük arra, hogy elvégezzék a vállalt feladatot, és elég ambiciózusnak ahhoz, hogy kellően kezdeményezők legyenek.

A feladatok nyomon követése alapuljon tényeken, és legyen transzparens: Mint korábban láttuk, a Scrum módszer előírja a „napi Scrum” alkalmazását, ami tulajdonképpen az előrehaladás kontrollja. A csapat minden tagja láthatja, hogy a többiek mit végeztek el egy nap alatt. Az átláthatóságot segíti az is, hogy a csapat tagjai egy helyiségben dolgoznak. Az előrehaladást és a hátralevő feladatokat lehetőleg grafikusan, mindenki által jól látható helyen teszik közzé. Nincs kizárólag a feladatok követésével foglalkozó munkatárs, mindenkinek egyszerre kell dolgoznia és a nyomon követéssel foglalkoznia.

A vizualizáció, a nyomon követés eszköze: Az agilis fejlesztések további jellegzetessége a vizualizáció, ami legtöbbször egy nyomon követést szolgáló tábla alkalmazását jelenti. Ez a módszer – feltéve, hogy a táblán a valósággal megegyező adatok szerepelnek – egyfajta demokratikus hozzáállást tükröz: mindenki számára egyértelmű, hogy ki mit végzett el, és mi lesz a következő lépés. Ez tulajdonképpen a projekt követésének olyan eszköze, ami éppen a nyilvánossága miatt egyfajta kényszert is jelent a projekttagok számára, ugyanis nemcsak a vezető látja az elvégzett munkát, hanem a csoport összes tagja azonos képet kap.

Az ügyféllel legyen megfelelő a kapcsolattartás: Az agilis fejlesztés sajátossága, hogy szoros kapcsolatot tételez fel a szoftver felhasználója és fejlesztői között. Másképp fogalmazva, a fejlesztés csak akkor lehet eredményes, ha az érintettek közötti kommunikáció megfelelő mélységű.

Tartsunk önreflexiót: Az agilis módszertan jellegzetessége a gyakori visszacsatolás, az önreflexió. A Scrum sprintjei végén előírt visszatekintés célja a munkavégzés módszerének javítása. A tanulás végső soron javítja a csapat (szervezet) eredményességét és hatékonyságát. A tapasztalatok kiértékelése szintén régóta része a projektmenedzsment technikai repertoárjának. Az agilis módszertanban ezek gyakorisága nagyobb a megszokottnál.

Az agilis módszertan leginkább a szoftverfejlesztés során terjedt el, de az elvei átvihetők más feladatokra is. Gondolja át, hogy az ön területén miként látja alkalmazhatónak, és milyen lépéseket tesz az agilis szemlélet megvalósítása érdekében!

Az agilis módszertanról szóló fenti összefoglalást a Corvinus Egyetem Vezetéstudomány c. kiadványában megjelent kutatási munka alapján készítettem. Megjelenéshez a kiadvány szerkesztője hozzájárult. 

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. ”