Az agilis elvek (3. rész)

Szerző: | 2018. 12. 11. | Agilis transzformáció az IT-ban

Állandó téma minden szervezetben, annak méretétől függetlenül, az agilitás. Mit is jelent ez, és milyen kihívásokkal szembesülhetünk ennek kapcsán?

Ez a cikk egy három részes sorozat utolsó része. Ha az előzőket nem olvastad, tedd meg itt:

10. Elengedhetetlen az egyszerűség, azaz az elvégezetlen munkamennyiség maximalizálásának művészete.

➔ A hagyományos, szigorúan fázisokra szakaszolt projektek kiterjedt felmérést alkalmaznak az összes követelmény összegyűjtésére. Mindent össze kell írni, ugyanis mindenki tudja, hogy ha valami nincs betervezve, akkor azt később változáskezelés révén már sokkal problémásabb megvalósítani: a büdzsé és a határidő általában adott. Kutatásokból tudjuk, hogy az így lefejlesztett rendszer feature-einek 30-80%-át végül egyáltalán nem vagy csak alig használják. Ez pedig óriási pazarlás.

Ha folyamatosan szállítunk, akkor mindig a legfontosabb feature-öket fejlesztjük le először. Ez végül lehetőséget biztosíthat arra, hogy a nem fontos feature-ök ne kerüljenek kifejlesztésre. Így a rendszerünk kisebb komplexitású lesz, mint egy, a félelem és bizalmatlanság miatt mesterségesen felduzzasztott rendszer. A kisebb komplexitás végül kisebb költséget eredményez. Ez rövidebb távú, projektalapú működés esetén már egy óriási előrelépés a korábbiakhoz képest.

A véget nem érő termékfejlesztések vagy hosszú távú projektek (1+ év) során a rendszer komplexitásának folyamatos alacsony szinten tartása még nagyobb kihívássá válik. A felesleges funkciók, amiket csak alig vagy nem használnak, és a túlbonyolított technikai megoldások, amik olyan esetekre készültek, amelyek soha nem következnek be, nem csupán egyszeri pluszköltségként jelennek meg, hanem az általuk generált extra komplexitás folyamatosan lassítani fogja a további új fejlesztéseket, valamint visszatérő hibákat is okoz („Ami elromolhat, az el is romlik.”). Egy bonyolult rendszert nehezebb karbantartani, valamint annak komplexitását nehezebb és fárasztóbb megérteni.

Egy rendszer egyre komplexebbé válásáról az üzleti oldal és a fejlesztői oldal egyaránt tehet, ezért fontos, hogy a két oldal szorosan, partneri kapcsolatban és a bizalomra alapozva dolgozzon együtt.

Kihívások:
  • „Time and materials” alapú elszámolás esetén a fejlesztői oldalnak nem érdeke az egyszerűségre törekvés.
  • A komplexitást a kód ismeretében a fejlesztők látják, „érzik”. A következményeket sok esetben nem lehet világosan megfogalmazni és átadni a nem fejlesztők számára.
  • Bizalom, szoros együttműködés és partneri kapcsolat szükséges az üzleti oldal és a fejlesztő között az optimális eredmény elérése érdekében. Alá-fölérendeltség esetén a fejlesztő követi az üzleti oldal által diktált követelményeket, ami gyakorlatilag lehetetlenné teszi az üzleti oldal részére történő visszajelzés adását.
  • A fejlesztői oldalnak akarnia kell, és képesnek is kell lennie az üzleti oldalnak és annak problémájának megismerésére (empátia), hogy szükség esetén tudjon (és merjen) alternatív megoldásokat javasolni, amik az egyszerűséget szolgálják.
  • Paradox módon az egyszerűségre való törekvéssel ugyan jelentős időt és költséget spórolhatnánk meg, de időnyomás alatt az egyszerűség mint szempont bizony háttérbe szorul. Képesnek kell lennünk időnként megállni egy pillanatra.
  • Az egyszerűségre való törekvésre sokan nem képesek, mert számukra az nem érték.
  • Az egyszerűség elérése sok esetben csak akkor lehetséges, ha képesek vagyunk magasabb nézőpontból tekinteni az összefüggésekre. Erre nem mindenki egyformán képes.
  • Az egyszerűségre való törekvés gyakran korai általánosításhoz/optimalizációhoz vezet, ami éppenséggel még komplexebbé és rugalmatlanabbá teszi a rendszert.

Egy rendszer komplexé válásáról az üzleti-, és a fejlesztői oldal egyaránt tehet, ezért fontos a szoros, partneri kapcsolat és a bizalom közöttük.

11. A legjobb architektúrák, követelmények és rendszertervek önszerveződő csapatoktól származnak.

Elég gyakori még mindig, hogy a szoftverfejlesztésben a fontos döntéseket specialisták hozzák meg (pl. architectek, infrastruktúra-specialisták stb.). Már számtalanszor bebizonyosodott, hogy ez sokszor vezet túltervezett (overengineered), ezáltal feleslegesen komplex, gyakorlatiatlan megoldásokhoz, amik a hatékonyság rovására mennek (ld. az előző 10. pont).

Mindemellett ezen döntések általában a projekt elején, előre meghozott döntések, amik nem veszik figyelembe azt a lehetőséget, hogy a csapattagok a projekt során folyamatosan tanulnak, és a megtanult leckék alapján korrekciót alkalmaznak.

Ennek alternatívája az, hogy a megvalósító csapatot bízzuk meg a „legjobb” megoldás megtalálásával. Az autonóm csapatnak így lehetőséget biztosíthatunk a hibáikból történő tanulásra és a folyamatos korrekcióra.

Kihívások:
  • A bizalom kiépítése a csapatban, valamint az, hogy lehetőséget és kellő időt biztosítsunk a csapatnak a fejlődésre akkor is, ha annak tagjai az elején még sokszor hibáznak.
  • Megfelelő motiváció megléte a csapaton belül, hogy a csapattagok folyamatosan fejlődni és tanulni akarjanak, továbbá fontos esetükben a reflexiós képesség/akarat kifejlesztése is.
  • Megfelelő szakértelem a csapatban, hogy a tagok képesek legyenek olyan rugalmas designt és architektúrát létrehozni, amelyen később még lehet változtatni (ld. refaktorálható kód, evolúciós architektúra).

12. A csapat rendszeresen mérlegeli, hogy miképpen lehet nagyobb hatékonyságot elérni, és ehhez hangolja és igazítja a működését.

➔ Gyakori eset, hogy egy meghatározott terv szerint kell végrehajtani egy projektet (a terv időnként frissítésre kerül). A terv végrehajtásáért a projektmenedzser vállal felelősséget, aki akár egy olyan nagyobb hierarchikus szervezetet is irányíthat, amelyben a különféle szervezeti egységek tagjai és külső alvállalkozók a résztvevők. Habár itt sem lenne lehetetlen, de általában elmaradnak azok a rendszeres beszélgetések, amelyek lehetővé tennék a reflexiót a projekt során, így a részt vevő felek megvitathatnák, hogyan változtassanak a projekt működésén. A hierarchia általában egy bebetonozott rendszer, amiben a felelősségek élesen szétválnak (ld. alvállalkozók), tehát menet közben egyáltalán nem, vagy csak korlátozott lehetőség nyílik a működési modell megváltoztatására.

Ezzel szemben az agilis módszertanok minél kisebb méretű (10 fő alatti), keresztfunkcionális csapatok létrehozását sürgetik, amik autonóm módon képesek saját hatáskörben változtatni a működésükön. A rendszeres retrospective-eken lehetőségük nyílik a csapatoknak az elmúlt időszak eseményeinek elemzésére, azokból a megfelelő következtetések levonására, ezáltal a működésük megváltoztatására a hatékonyságnövelés érdekében.

A kihívások hasonlóak a 11. pontban megfogalmazottakhoz:
  • A bizalom kiépítése a csapatban, valamint az, hogy lehetőséget és kellő időt biztosítsunk a csapatnak a fejlődésre akkor is, ha annak tagjai az elején még sokszor hibáznak.
  • Megfelelő motiváció megléte a csapaton belül, hogy a csapattagok folyamatosan fejlődni és tanulni akarjanak, továbbá fontos esetükben a reflexiós képesség/akarat kifejlesztése is.

Konklúzió

A 2001-ben a szoftverfejlesztés akkori szaktekintélyei által aláírt Agilis kiáltvány a következőket nyilvánítja ki:

A szoftverfejlesztés hatékonyabb módját tárjuk fel saját tevékenységünk és a másoknak nyújtott segítség útján. E munka eredményeképpen megtanultuk értékelni:

  • az egyéneket és a személyes kommunikációt a módszertanokkal és eszközökkel szemben;
  • működő szoftvert az átfogó dokumentációval szemben;
  • megrendelővel történő együttműködést a szerződéses egyeztetéssel szemben;
  • változás iránti készséget a tervek szolgai követésével szemben.

Azaz annak ellenére, hogy a jobb oldalon szereplő tételek is értékkel bírnak, mi többre tartjuk a bal oldalon feltüntetetteket.

A kiáltvány mögötti 12 elv segít a kiáltvány további értelmezésében, és magas szintű gyakorlati útmutatást nyújt annak megvalósításához.

Az agilitás a korlátlan ideig tartó, gyors és könnyed haladást jelenti. A szervezet nem lassul be az idő előrehaladtával, és képes a változások gyors lereagálásra.


Ez a cikk egy három részes sorozat utolsó része. Ha az előzőket nem olvastad, tedd meg itt:

<a href="https://agiluu.hu/author/istvan/" target="_self">Marhefka István</a>

Marhefka István

9 éves koromban kezdtem a programozást, professzionálisan pedig több mint 20 év tapasztalattal rendelkezem szoftvertermékek kifejlesztésében. Jónéhány agilis csapatban dolgoztam különféle szerepkörökben (vezető szoftverfejlesztő, architect, termékfelelős, scrum master stb.), ahol az erős csapatmunkára építve hoztunk létre sikeres termékeket. Dolgoztam magyar KKV-knál, multiknál Magyarországon és Svájcban. Korábbi saját startupom, az amerikai irodát is működtető Be-novative nevű cég, amelyből már exiteltem, a mai napig sikeres. Agilis szervezetfejlesztői és DevOps tanácsadóként 2017 óta dolgozom. Elsősorban hazai kkv-k és nagyvállalatok agilis és digitális transzformációs törekvéseit támogatom.

Az Agiluu támogatja a szervezeteket, hogy agilisabbá váljanak.

Tetszett az írás? Iratkozz fel a blogra, hogy mindig értesülj az új írásokról!