Ez a cikk egy három részes sorozat első része. Ha a többit is el szeretnéd olvasni, tedd meg itt:
➔ Állandó téma minden szervezetben, annak méretétől függetlenül, az agilitás, a szoftverfejlesztésen kívül is. Mit is jelent ez, és milyen kihívásokkal szembesülhetünk ennek kapcsán?
Mindenki az agile-ról beszél manapság, és már nagy szervezetek is fontolóra veszik az agilis működésre való teljes átállást. A vezetők az agilitástól a szervezet megújulását várják, ami így jobban tudja majd kiaknázni az emberekben rejlő potenciált, ezáltal a szervezet sokkal hatékonyabban tudja majd meglévő termékeit/szolgáltatásait fejleszteni, illetve új termékeket/szolgáltatásokat bevezetni a piacra.
Nagyvállalati vezetőkkel beszélgettem (nem szoftverfejlesztő cégeknél), és úgy találtam, hogy a vezetők a saját szervezetükben történő agilis bevezetés kapcsán inkább megfigyelő pozícióba helyezkednek, abban bízva, hogy az agilishájp egyszer csak lecsillapodik. Nehezen megfogható számukra, hogy az agilitás miben változtatná meg a jelenlegi munkájukat, és nehézséget okoz számukra abban újraértelmezni a szerepüket is.
Az is teljesen világossá vált a beszélgetések során – ami talán nem annyira meglepő -, hogy agilitás alatt mindenki mást ért.
Honnan is jön az agilitás?
➔ Az agilis szoftverfejlesztésnek, agilitásnak, agilis szervezetnek nincs elfogadott definíciója. Az agilitás a szoftverfejlesztés területéről indult hódító útjára; 2001-ben az akkoriban nemzetközileg meghatározó, szoftverfejlesztéssel foglalkozó szaktekintélyek aláírták az Agilis kiáltványt.
Az akkori uralkodó szemlélet szerint egy projektet felülről lefelé szerveztek meg, tehát a rendszerszintű megközelítést részesítették előnyben a projektek megvalósításában. A fő mumus a vízesésmodell volt (és még mindig az), ami előre meghatározott fázisokon keresztül vezette végig a projektet (követelményelemzés, tervezés, megvalósítás, tesztelés, telepítés, üzemeltetés), előírva a szigorú dokumentációs rendet és a szabályozott működést.
Az Agilis kiáltványban lényegében az embereket és a gyakorlatiasságot helyezték előtérbe a top-down, rendszerszintű gondolkodásból fakadó modellel szemben.
Az Agilis kiáltvány „melléklete” az a 12 alapelv, amely részletesebben leírja, hogy mit is értenek a szakemberek az agilis elvek alatt. Olyan ez, mint a Biblia: ha újra és újra elővesszük, egyre mélyebb jelentésrétegek tárulnak fel.
Érdemes ezeket átnézni és értelmezni, majd 20 év elteltével újra leporolni.
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.
➔ Korábban a projektek feletti kontrollt alapos tervezéssel és dokumentálássál igyekeztek fenntartani. Ez nagyon lassúnak, költségesnek és rugalmatlannak bizonyult.
Az első alapelv megfogalmazza, hogy sokkal fontosabb, hogy minél hamarabb elkészüljön egy működő szoftver, amit aztán folyamatosan továbbfejlesztenek. A cél ma már az, hogy a szoftver minél hamarabb a piacra kerüljön, ahol aztán valódi visszajelzések alapján lehet majd továbbfejleszteni.
Kihívások:
- Az állandó változások stresszelhetik a végfelhasználókat.
- Olyan szervezet kialakítása szükséges, amely képes a változásokat lereagálni.
- Az állandó fejlesztés és szállítás hatására a rendszer instabillá válhat.
- A dokumentáció és a tervezés háttérbe szorulhat.
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.
➔ Korábban alapos követelményelemzés és rendszertervezés után kezdődhetett csak el a rendszer implementálása. Ez a fajta szemlélet nem volt eléggé rugalmas az esetlegesen felmerülő változásokkal szemben. Az alapos elemzés és tervezés pont a későbbi bizonytalanságokat volt hivatott kiküszöbölni, de a valóságban ez korántsem bizonyult hatékony megoldásnak.
Az agilitás üdvözli a változásokat, azokat egy projekt természetes velejárójának tekinti.
Az agilitást ma már sokkal tágabb perspektívából szemléljük; például megrendelő sincs mindig. Termékfejlesztés esetén gyakorlatilag nem is beszélhetünk arról, hogy a fejlesztésnek vége lesz, inkább egy „élő”, folyamatosan változó termékről van szó. (Akkor van csak vége a termékfejlesztésnek, ha a termék kivezetésre kerül a piacról.) A követelmény szó már idejétmúlt (nem is illik használni). Azon cég esetében, amely saját terméket vezet be a piacra, értelmezhetetlen a követelmény szó, hiszen maga a cég találja ki, hogy mire van szüksége a piacnak.
Kihívások:
- A változásokat csak akkor lehet a kódban és az architektúrában lekövetni, ha a fejlesztett rendszer kellően rugalmas. (Ez különösen a nagyobb rendszerekre igaz.) Ezt csak megfelelő minőségű mérnöki munkával lehetséges elérni.
- Az emberek többsége ellenáll a változásnak, ezért nehéz egy szervezet esetében elérni, hogy az természetesnek vegye a változásokat.
3. Fontos, hogy minél gyakrabban szállítsunk működő szoftvert, azaz néhány hetenként vagy havonként, lehetőség szerint a gyakoribb szállítást választva.
➔ Régen nem volt ritka jelenség az sem, hogy akár egy évet vagy még többet is kellett várni az első működő szoftverre, így viszont megfosztották a felhasználókat a korai visszajelzések adásának lehetőségétől.
A folyamatos szállítás kardinális jelentőségű, pár hetente, de legfeljebb pár havonta képesnek kell lennie egy csapatnak az új verzió szállítására.
Ma már vannak olyan cégek, amelyek képesek naponta többször is új éles verziót kiadni a szoftverükhözanélkül, hogy a végfelhasználók azt észrevennék. Itt persze nem arról van szó, hogy az alkalmazás a végfelhasználó számára is ilyen gyorsan változna, inkább az a fontos, hogy a technikai lehetőség adott. Ennek az az előnye, hogy hiba esetén képesek vagyunk gyorsan korrigálni, illetve hogy a fejlesztett funkció nagyon hamar kijut, és ezáltal tesztelésre kerül valós környezetben, ezzel nagyon korai visszajelzést biztosítva.
Kihívások:
- Hosszú távú projektek/termékfejlesztés esetén: Hogyan hozhatunk létre olyan szervezetet, amely képes ilyen rövid szállítási ciklust megvalósítani? Ez csak részben szervezési kérdés, szükségünk lesz a legjobb szakemberekre is, hogy fenntartható módon tudjon a szervezet szállítani.
4. Az üzleti szakértők és a szoftverfejlesztők dolgozzanak együtt mindennap a projekt teljes időtartama alatt.
➔ Korábban az volt az általános, hogy a fejlesztők nem találkoztak az üzleti szakértőkkel, hanem dokumentációkban szembesültek a rendszerrel kapcsolatban megfogalmazott követelményekkel, tervekkel.
Vagy ha esetleg mégis sikerült közvetlen kapcsolatot létesíteniük az üzleti szakértőkkel, azok gyakran nem voltak elérhetőek. 10-15 évvel ezelőtt sajnos még találkoztam hasonló esettel: Amikor az üzleti megrendelőtől próbáltunk kérdezni fejlesztés közben, akkor azt mondták, hogy ők nem érnek rá, mert nekik a saját üzletükkel kell foglalkozniuk. Sőt, amikor agilis fejlesztést akartunk eladni nekik, külön kikötötték, hogy őket ne zavarjuk fejlesztés közben.
A 4. agilis alapelv a két terület (üzleti szakértők és technológusok) közötti nagyon szoros, napi együttműködést emeli ki.
Ma már ott tartunk, hogy a két területnek össze is kell olvadnia, a szoftveres terület is az üzlet részévé válik, vagyis nincs külön üzlet meg fejlesztés, csak fejlesztés van, folyamatos fejlesztés, ami nemcsak a szoftver fejlesztésére, hanem a termék/szolgáltatás egészére vonatkozik. Napi szinten együtt dolgozik minden résztvevő. A cél egy olyan sikeres termék létrehozása, amelyet közösen, folyamatosan fejlesztünk.
A technológia és a technológusok ma már képesek arra, hogy lekövessék a szükséges változásokat, amit az üzlet diktál. Viszont a két terület fúziója lassan megy végbe. Inkább az a jellemző, hogy a technológiai hátterű cégek egy addig sikeres üzleti területből kiharapnak maguknak egy szeletet, és utána igyekeznek egyeduralkodóvá válni az adott területen (ld. bankok vs. fintech cégek).
Kihívások:
- Általában az történik, hogy az üzlettel foglalkozó szakemberek vizionálnak egy rendszert, aminek a fejlesztésével megbízzák a szoftvereseket. Két külön siló. Ezt fel kell számolni, az üzleti szakembereknek partnerükké kell tenniük a technológusokat.
- A technológusok magukat „csak” technológusnak tekintik, és nem hajlandóak az üzleti célokkal azonosulni, megérteni az üzleti problémát. Mind a két oldalnak nyitottabbnak kell lennie, és ha a két oldal képes nyitni a másik oldal felé, sőt feloldódni egymásban, akkor együtt csodákra lesznek képesek. Ez egy hatalmas lehetőség mindkét fél számára.
5. A projektet motivált egyénekre kell építeni, akik számára pedig biztosítani kell a megfelelő környezetet és támogatást, valamint maximálisan meg kell bízni bennük azzal kapcsolatban, hogy elvégzik a munkát.
➔ Korábban a top-down modell és a rendszerszintű gondolkodás igyekezett biztosítani a kontrollt a projekt felett.
Az agilis elvek szerint természetesnek tekintett változások megfelelő kezeléséhez szükséges egy olyan környezet, és szükségesek azok a megfelelő egyének, ami és akik képesek a magas minőség megteremtésével fenntartható fejlődést biztosítani, és rugalmas rendszereket kialakítani. De nem is csupán a megfelelő rendszer kialakítása a cél, hanem az egyének ösztönzése is, hogy előállhassanak saját ötleteikkel, aminek köszönhetően biztosított a folyamatos innováció a szervezetben. Ez nem lehetséges motivált egyének és biztonságos környezet nélkül, ugyanis ezek teremtik meg a lehetőséget az egész szervezet számára a minőségi ugrásra.
Kihívások:
- Dilemma előtt állnak a vezetők: Ha túl nagy kontrollt gyakorolnak, azzal csökken a munkatársak motivációja, ha viszont nem avatkoznak bele semmibe, előfordulhat, hogy nem abba az irányba fognak haladni a dolgok, amerre kellene. Kulcsfontosságú a megfelelő szereplők megtalálása, az ő egyéni szempontjaiknak a maximális figyelembevétele és balanszírozása. Ösztönözni kell a szereplők egyéni felelősségvállalását, az egyéneket és a csapatokat pedig folyamatosan fejleszteni kell. Jelenleg nincs olyan eszköz vagy módszertan, amely ezt garantálná.
Ez a cikk egy három részes sorozat első része. Ha a többit is el szeretnéd olvasni, tedd meg itt:
