Hogyan tehetünk agilissá egy nem agilis szervezetet: első lépések és egy sikeres projekt megvalósítása
Egy megszokott vállalati működésről történő váltás gyakran kihívásokban bővelkedő folyamat. Az első lépés megtétele mindig a legnehezebb, különösen egy nem agilis szervezetben. Ebben a cikkben áttekintjük, hogyan lehet elindítani az agilis működést és sikeresen lebonyolítani egy agilis projektet egy nem agilis szervezetben.
A nem agilis szervezetek működésének jellemzői
Ezek a szervezetek gyakran a vízesés modell (waterfall) szerint dolgoznak, amelyben a fejlesztési folyamatok lineárisan követik egymást. Milyen veszélyeket hordoz ez a működés az esetek többségében?
- Folyamatos időnyomás a fejlesztési ciklusokban
- Elhúzódó tesztelési és hibajavítási ciklusok
- Kockázatos élesítési folyamatok
A fentiek alapján egy 1 hónapos fejlesztési feladat kb. 3,5 – 4 hónap alatt állítható produkcióba, melyek során a csapat további problémákba ütközhet:
- A tesztelőknek és integrátoroknak bele kell tanulniuk az adott területbe és rendszerbe
- Az információ elcsúszások veszteségekhez és kockázatokhoz vezetnek
- A független teamek munkájának összehangolása nehézséget okoz, mivel a tesztcsapatok nem biztos, hogy időben rendelkezésre állnak
Roham tempóban változó világunkban ez a klasszikus modell – ahol alaposan feltárjuk a problémát, mindenre kiterjedően tervezünk, majd a kész tervet végrehajtjuk – sokszor egyszerűen működésképtelen vagy jelentősen visszaveti a hatékonyságot.
A fenti problémákat a szoftveripari szakemberek széleskörben és sorozatosan tapasztalták, így jutottak arra a következtetésre, hogy alapjaiban kell megváltoztatni a fejlesztési projektek módszertanát. 2001 környékén összegyűjtötték a felmerülő problémákat, melyek alapján megpróbálták meghatározni azokat az irányokat és értékeket, melyekkel a szoftverfejlesztési folyamatok hatékonysága növelhető. Arra is rámutattak, hogy a hatékonyság növeléshez nemcsak az előállítás folyamatában, de a vállalati környezetben is változtatásokra van szükség.
De mi az az agilitás?
Meghatározása az agilis manifesztóból indul ki, amely négy alapelvre épül. A két legfontosabb állítás ezek közül: a működő termék előállítása előnyt élvez a dokumentációval szemben, illetve az ügyfelekkel való együttműködés minősége adott esetben fontosabb, mint egy adott szerződéshez való ragaszkodás. Célja a változó üzleti igények rugalmas kezelése, rövidebb és gyakoribb élesítési ciklusokkal.
Az agilis működés alappillérei:
- részletes back log – feladat lista
- függetlenül dolgozó csapatok
- iteratív fejlesztési ciklusok – a munkaciklusok (sprint) 2-5 hétig tartanak és minden sprint után van egy működő eredmény
Előnyei:
- Rövidebb piacra jutási idő
- Kisebb GoLive kockázat és gyorsabb támogatási reakciók
- Gyorsabb megtérülés, hiszen a legfontosabb üzleti funkciók hamarabb használhatóak
- Erőforrás megtakarítás DevOps szemlélettel mind fejlesztői, mind üzemeltetői oldalon
- Jobb vállalati szintű tervezhetőség, kevesebb csúszás ütemtervtől való eltérés
- Összességében jobb termékminőség, ügyfélélmény és alacsonyabb költségek
Az agilis megközelítés lehetővé teszi számunkra, hogy fejlesztett termékünkbe vagy szolgáltatásunkba folyamatosan tudjuk beépíteni az újonnan felmerülő igényeket – így lehetővé téve, hogy a végeredményünk a fejlesztési folyamat során is naprakész legyen.
Első lépések az agilitás felé
Ahogy a bevezetőben is említettük, minden kezdet nehéz. Jó hír azonban, hogy nem agilis szervezetben is elindítható az agilis működés. De hogyan?
Leggyakrabban úgy, hogy a működő szervezetbe egy agilis projektet ágyazunk be, melynek keretében egy nagyobb feladatot kisebb feladatokra osztanak fel, az első feladatlistát elkezdik feldolgozni – miközben a maradék feladat változatlan marad és bármikor újra konfigurálható.
Itt azonban fontos megjegyezni, hogy nem elegendő csupán a fejlesztési projektet agilisan lebonyolítani, hanem a projekt közvetlen szervezeti környezetét is – legalább projekt / termék vonatkozásban – agilissá kell tenni. A projekttel kapcsolatba kerülőknek (vezetők, tesztelők, termék menedzserek) szem előtt kell tartaniuk, hogy a termék mostantól üzleti értéket teremtő iteratív ciklusok sorozatával kerül fejlesztésre. Valamint azonosulniuk kell a gondolattal, hogy az egyes iterációk fix időtartamúak és úgy kell priorizálni az üzleti és technikai igényeket, hogy az adott időszakra rendelkezésre álló erőforrások felhasználásával maximalizálják az előállított üzleti értéket. Az egyes sprintek akkor tekinthetőek sikeresnek, ha a fejlesztések lezárultak és produkcióba álltak. Ellenkező esetben a szoftver nem tudja realizálni az üzleti igény teremtette profitot.
Egy másik fontos megállapítás a témában, hogy nincs olyan, hogy „minden szervezetre és folyamatra egyformán alkalmazható agilis működés”. Minden szervezetnek a saját szükségletei és lehetőségei szerint kell adaptálnia ezt a módszertant – keretrendszerként alkalmazva azt. Ironikus módon az adaptáció legjobb módja az agilis hozzáállás: válasszunk ki egy ideális projektet és agilisan valósítsuk meg. Második lépésben vonjuk le a következtetéseket és nézzük meg, hogy mik azok, amelyeket a további projektjeink során ebből tovább szeretnénk örökíteni, illetve hol kell más megoldásokat alkalmaznunk.
Milyen az ideális projekt?
- 4-5 hónapos időtartam
- 6-8 fős csapat, amelyben fejlesztők és tesztelők vegyesen vannak jelen
- Jól meghatározható üzleti célja van
- Megfelelő vezetői támogatás és felhatalmazás társul hozzá
Nézzünk egy konkrét példát!
A Magyar Posta számára elvégzett legacy transzformációs projektünk jó példa a fentiekre. A belső használatú workflow management alkalmazásuk (ún. CSKR – Csomag Kézbesítési Rendszer) fejlesztése gyors kivitelezést igényelt. A fejlesztés eredetileg vízezés modellben zajlott, de a közel 1000 fejlesztési napos projektet a megszokott működéssel nem lehetett volna megvalósítani. Mivel a fejlesztés kizárólag a mobil alkalmazásra és az azt kiszolgáló middleware-rétegre összpontosított, nem volt technológiai függőség más rendszerektől a kiadás során.
A szűk határidő és a relatív műszaki függetlenség miatt javasoltuk a vízesés modellről az agilis modellre való átállást – mely sikerhez vezetett.
Mit jelentett ez?
- Rugalmas backlog kezelés, egyértelmű DoR és DoD kritériumok definiálása
- Iteratív üzleti érték szállítás
- Rövid távú tervezés 3 hetes iterációkra
- Folyamatos verifikáció az üzleti igény alapján
- Sprint zárás, PO általi elfogadás
- Csapatmunka folyamatos optimalizálása: retrospektív események, nyitottság a változásra
- A klasszikus megrendelő beszállító viszonyok helyett a PO és a csapat együtt szállít a szervezetbe
A projektet sikeresen lezártuk: a várt üzleti érték határidőre elkészült. A Magyar Posta vezetősége jelenleg értékeli az eredményeket, hogy eldöntsék, folytatják-e az agilis módszertan alkalmazását a jövőben.
Konklúziónk tehát: igenis, lehet agilisan működni nem agilis szervezetben. Érdemes egy pilot projektet végig vinni, majd az eredmények alapján döntést hozni az agilis transzformáció folytatásáról. Kezdjük el kicsiben, majd a pilot-ból levont következtetéseket építsük be a további működésünkbe egy szakértő csapat bevonásával, akik hozzák a szükséges üzleti domain tudást és iparági tapasztalatot, így időt és erőforrást takarítva meg a vállalat számára.