RI Consulting
keresési feltétel:

Agilis átalakulás tapasztalatai


Agilis átalakulás során szerzett tapasztalat bemutatása arról, hogy milyen is lenne agilisan működni, illetve érteni a lényegét a működésnek.

Agilis átalakulás kezdete

Az agilis átalakulás története úgy kezdődött, ahogy valószínűleg nagyon sok esetben: adott egy termék, melynek fejlesztése vízesés módszertannal zajlott, életciklusát tekintve már jelentős új fejlesztések nem történtek, elég meghatározó rész a karbantartás. Különböző okok, célkitűzések mentén a menedzsment szakértők bevonásával úgy döntött, hogy átállunk agilis, Scrum fejlesztésre.Megalakultak a Scrum csapatok, Scrum masterrel, product ownerrel. Akik közül nem sokaknak volt mélyebb agilis tapasztalata, mindenki kapott egy pár napos képzést a Scrum-ról és elindultunk. Megismerkedtünk a ceremóniákkal, kialakultak a szokások a csapatokban. Látszólag úgy tűnt, hogy elkezdtünk Scrum szerint működni.

Látszólagos változtatás

Mert nagyon fontos megjegyezni, hogy látszólagos változásról van csak szó! Jöttek a feladatok, a határidők, de azon kívül, hogy kisebb csapatokban, sprintekben dolgoztunk, nem sok minden változott. Többször hallhattuk, hogy ez meg az a product owner, illetve a csapatok felelőssége, de ezzel nem tudtunk mit kezdeni. Sokszor úgy éltük meg, hogy ami eddig más feladata, felelőssége volt, azt most próbálja “lepasszolni” másnak. Hiányzott a változás a gondolkodásmódban, hogy megértsük, hogy mit is jelent agilisnak lenni, nem mindent előre részletesen eltervezni, mit jelent az hogy felhatalmazást kaptunk (product ownerek, csapatok), és hogy ne mástól várjuk, hogy mit kell tennünk, hanem mi magunk határozzuk meg az utat a cél felé.(Persze megjegyzem, hogy azon kívül, hogy azt tudjuk, hogy éppen mi a fontos, de különösebb célok nélkül ez nem is lenne olyan egyszerű.)

Nehézségek és felismerések

Kiragadnék két példát, ami jól mutatja a nehézségeket, és felismeréseket.

Tesztelés minősége

Eléggé hamar világossá vált, hogy a fejlesztés minőség biztosításán (tesztelésén) sokat kellene javítani. Erre azonban nem tudott sor kerülni, mert folyamatosan nagy nyomás volt (nem agilisan leszerződött projektek felől), hogy különböző fejlesztésekkel elég rövid határidővel el kell készülni. Eközben gyűltek az ötletek, hogy a minőségen hogyan lehetne javítani. Sok feladat keletkezett is hozzá, de érdemi előrelépés nem történt. Sőt egy idő után már elvesztünk az ötletekben, és ha kicsit volt is rá idő, akkor az inkább kapkodás volt. Mennyivel jobban kezelhető lett volna, nagyvonalakban meghatározni a szükséges lépéseket, egy roadmap-et készíteni, és mindig csak az éppen következőhöz kidolgozni a részletes feladatokat, mintsem elönteni a csapatokat rengeteg feladattal.

Story pontozás

A másik példa a story pontozáshoz kapcsolódik. Megtanultuk, hogy esztimálni kell, hogy lehessen sprintet tervezni, és azt is hogy nem órákban a legjobb, hanem story pontokban. Ki is dolgoztunk egy nem feltétlenül egyszerű rendszert, úgyhogy képesek voltunk “tudományos” alapon pontokat adni. Sokszor azért ez nem volt egyszerű, mert eléggé bele kellett menni a részletekbe, és tulajdonképpen nem állt messze az időben esztimálástól.Mígnem, némi utánaolvasások, videók megnézése után jött a felismerés, hogy tulajdonképpen mi is a lényege: referenciák alapján meghatározni egy feladat nagyságát, és így tervezésnél egyszerűen meghatározni, hogy mi fér bele, pl. az ilyen fajta feladatból három szokott beleférni, az olyan fajtából öt is. Szemléletesen nézve, tudjuk, hogy mekkora kosarunk van, és azt kell kitalálni, hogy ebbe a különböző méretű gyümölcsökből mennyi fér bele.Megtapasztaltuk, hogy nem mindig könnyű az agilis út, főleg ha az átalakulás támogatottsága megáll azon a ponton, hogy elindultak a csapatok. Visszatekintve, hogy mit gondolok, mit lehetne másképp csinálni? Sokkal több időt fordítani az agilitás, Scrum lényegének a megismerésére. Nem feltétlenül formális képzésekkel, sokkal inkább gyakori beszélgetésekkel agilitásban, Scrum-ban jártas szakemberekkel, agilis coach-okkal, tapasztalt Scrum masterekkel. És ezt minden szinten, a csapattagokkal, Scrum masterekkel, product ownerekkel, és a csapatokon kívüli folyamatokban résztvevőkkel.Úgy gondolom akkor lesz agilis egy működés, ha a résztvevők tisztában vannak vele, hogy ez pontosan mit jelent és a gondolkodás részét képezi. E nélkül, mégha a látszat meg is van, a lényeg veszik el.


Megosztás


Tetszett? Akkor ezeket is nézd meg!


A viselkedésvezérelt fejlesztés szerepe a user story-kban
A viselkedésvezérelt fejlesztés arra ösztönzi a csapatokat, hogy konkrét példákkal hivatalossá tegyék az alkalmazás működésének megértését.

User story-k és user story példák
A user story legfontosabb szerepe, felépítése, tulajdonságai egy példán keresztül kerül bemutatásra ebben a cikkünkben.

Az agilis coaching fejlődésének a története
Ahogy az agilis alkalmazása egyre inkább elterjedt, a jó agilis coaching készségek alapvető definíciója elmaradt. A kezdetek bemutatása.


Kapcsolat


Következő lépések
Írj egy üzenetet nekünk
Mi felvesszük veled a kapcsolatot 48 órán belül