A cikket meg is hallgathatjátok: itt.
Számtalan szoftverfejlesztési projektet rendelnek meg Magyarországon, ámde úgy tűnik, mintha nem tanultunk volna az elmúlt 20-30 év tapasztalataiból.
A legtöbb megbízó a mai napig valami gyártási folyamat analógiájára építi a szoftverfejlesztési megrendelését. Így szerződik, így árazza és a teljesítést is ehhez hasonlóan próbálja meg kontroll alatt tartani.
Még szomorúbb, hogy a legtöbb megrendelő beletörődött, hogy a “szoftverfejlesztési projektek már csak ilyenek”. Naná, hiszen mindenkinek kivétel nélkül ezek a tapasztalatai. Mindenki nem hibázhat!
De igen!
Mi ebben a blogpost sorozatban arra vállalkozunk, hogy megmutassuk, hogyan lesz a “Te szoftver projekted más”.
Szoftver projekt
A szoftverfejlesztési projektek legfontosabb fejezetei (nem sorrendben):
- Termék szintű tervezés
- Release szintű tervezés
- Roadmap szintű tervezés
- User story szintű tervezés
- Napi koordináció
- Szoftver architekturális tervezés
- Adatbázis tervezés
- Unit tesztelés
- Integrációs tesztelés
- Terheléses tesztelés
- Végfelhasználói viselkedést modellező tesztelés
- Front-end fejlesztés
- Back-end fejlesztés
- Adatbázis fejlesztés
- Élesítés
- Üzemeltetés
- Fejlesztői dokumentáció
- Felhasználói dokumentáció
A lista koránt sem teljes.
Aki mindezeket tudatosan kezeli, valószínűleg nem olvassa ezt a bejegyzést, hanem épp nyaral. Ez a bejegyzés elsődlegesen az épp nem nyaraló üzleti szereplőknek szól.
Az a célom, hogy adjak egy olyan eszközrendszert, amivel a szoftver projekteket irányban lehet tartani, miközben a transzparencia segítségével pontos képünk van arról, hogy hol tartunk, mi van kész, mennyi van még hátra (becslés!), mennyibe került eddig, és még sok egyéb elem.
Általában igaz, hogy ahol a fejlesztők valami használhatót szeretnének létrehozni, amit az üzlet a piacon érvényesíteni akar, többnyire minden adott egy kiváló partnerkapcsolathoz. Egy ilyen közegben nincsenek ellenérdekelt felek. Hozzuk hát ki ebből a maximumot.
A szoftverfejlesztési projekteket az Agile Contracting eszközrendszerével érdemes megközelíteni.
Miről szól az Agile Contracting?
A szoftverfejlesztési projekteket körbe kell bástyázni nagyon szigorú, folyamatos(!) minden stratégiai szinten külön-külön értelmezett, megfogható kimeneti elemmel rendelkező tervezési munkával. Ez minden üzleti környezetben kivétel nélkül igaz.
Az Agile Contracting, (AC) fő célja, hogy a termék- és a fejlesztési oldalakat közös érdekek mentén kösse össze. A konkrét fejlesztési metodológiával és technológiai varázslattal nem foglalkozik.
Ideális esetben a szoftverfejlesztési projektet támogató és vezérlő keretrendszerként az Agile Contractingot használjuk, a szállítási feladatokra pedig az Agile Delivery Teameket.
A jó hír az, hogy a szállítói (fejlesztő) oldal mára sokszor előrébb tart a helyes szoftverfejlesztési metodológia alkalmazásában, mint az üzleti oldal. Így, nagyon idézőjelben, “nincs más dolgunk, mint megtanulni, miként tudjuk a szállítói oldal metodológiáját a projektünk és az üzletünk előnyére alkalmazni”
A gyönyörű ebben az, hogy valójában mindkét oldal alig várja, hogy legyen végre egy mindkettejük motivációját és a termék érdekeit egyaránt figyelembe vevő működési keretrendszer.
Modularitás, skálázhatóság
Amíg az Agile Contracting fejlődésének forrása a nagyvállalati projektek optimalizálása volt, addig a szolgáltatást le lehet skálázni kis projektekre, KKV szintű szervezetekre is.
Az AC elemei egytől egyig, projektmérettől függetlenül, hasznosak. Az elemek használatának mértéke és intenzitása az, ami meghatározza azok céljainkhoz és méreteinkhez történő illeszkedését.
Az AC moduláris szerkezete lehetővé teszi, hogy ne kelljen minden elemét szükségszerűen használni. Úgy építettük fel, hogy két specializált szakértő bármikor, bármilyen körülmények között, össze tudja rakni azt az Agile Contracting szolgáltatásmixet. Egy Agile Coach és egy vállalati szerződésekben gyakorlott döntéshozó.
Kontrolling és szerződések
Az Agile Contracting moduljainak mindegyike rendelkezik egy hozzá tartozó mikroszerződéssel. Ezek a mikroszerződések részletesen tartalmazzák az adott AC modul működésének sajátosságait, a kimeneti pontok elvárt szállítási- és elfogadási kritériumait.
Az AC szoftver szállítási fázisaiban működtetett transzparenciája a full scale és valós idejű kontrolling alapja.
Tranzíció? Természetesen… nem!
A SAFe (scaled agile framework) nagyon hatékonnyá teszi az egész szervezetet, de csak azután, hogy egy óriási feszültségekkel járó komplex tranzíciós folyamatot a vállalat végigcsinált, illetve folyamatosan csinál.
Az Agile Contracting ezzel szemben nem akar vállalati tranzíciót csinálni. Csak és kizárólag eszközei vannak a különböző projekt problémákra. Az AC szakértői abban a legerősebbek, hogy ezeket az eszközöket úgy igazítják a szervezeti viszonyokhoz, status-quo-khoz, hogy az surlódást nem okoz, mivel non-intruziv módon működtethetőek az AC elemei.
Ha csak eszközöket vezetünk be mások eredményességének támogatására, akkor az ellenállás is sokkal kisebb az újdonságokkal szemben. Ez sokáig elegendő is.
Az Agile Contracting természetesen nem zárja ki a SAFe bevezetést, sőt… bármikor párosítható vele, vagy akár előkészítő elemként is alkalmazható.
A sorozathoz tartozó következő cikkünkben az Agile Contracting elemeit boncolgatjuk. Egyesével.
Az agilis módszertani átállás során a szervezetek egységnyi időre vetített termelő képessége átlagosan 150-300%-kal nőtt. A HVG Akadémia, Agile Recruiter sorozatának módszertani vezetője.