R.I.P. BitBucket - avagy egy eddigi szép világ halála

A munkahelyen még valamikor a ködös távoli múltban (egészen pontosan 2011-ben), döntöttünk arról, hogy a Subversion-t új projektek esetén lecseréljük Mercurial (HG) kódtárakra. A csere oka az volt, hogy az akkori SVN branch-merge abban az esetben, amikor kénytelenek voltunk egy projektben párhuzamos fejlesztési szálakat vinni (és erről a megrendelők szerencsére gondoskodtak, hogy legyen ilyen), akkor meglehetősen nyögvenyelős kézimunka volt a merge folyamata.

Azt reméltük, hogy egy osztott verziókezelő esetén - ami kifejezetten arról szól, hogy párhuzamosan vannak fejlesztések, és sűrű a merge, így azt nagyon támogatni kell - sokkal jobb támogatást kapunk. Ez be is jött, határozottan sokat javultak a lehetőségeink.

Az akkori választásnál mérlegeltük a lehetőségeket, és oda jutottunk, hogy jobb nekünk a Mercurial a Git helyett. Ennek akkor több oka is volt, ezek együttesen billentették a mérleget. Nagyjából erősorrendben a következők voltak:

• Alapvetően Windows platformon dolgoz(t)unk, legalábbis a fejlesztői gépeken, de akkor még a szervereink is Windows Server 2008-ak voltak, és 2011-ben a Git messze nem volt jól támogatott Windows alatt.
• Akkor már pár éve a FogBugz feladatkezelőt használtuk (aminek akkor még volt itthon is értelmezhető árazással helyben telepíthető verziója) és akkoriban jelent meg hozzá a Kiln kiegészítés, amely segítségével a feladatkezelővel szorosan integrált Mercurial kódtárkezelést és code review lehetőséget is kaptunk. Jó kis cucc volt :)
• Az SVN után a Mercurial parancsai és opciói egyszerűbben kezelhetőnek tűntek.

Az azóta eltelt évek során nem is volt gondunk a kódtárkezeléssel, és azt gondolom, hogy rendesen be is gyakoroltuk a Mercurial használatát azon módszertan alapján, amit követünk (master branch az átadásokra, default-on megy alapvetően a fejlesztés, kivéve, amikor párhuzamos fejlesztés vagy valamilyen nagyobb feature van, az saját branch-en megy). Ami változást jelentett, hogy megszűnt a FogBugz és a Kiln azon, helyben telepíthető verziója, amit használtunk, így, előrenézve a jövőbe, 2017-ben úgy döntöttünk, hogy áttérünk a BitBucket-re, és szépen lassan átvittük a Mercurial kódtárainkat BitBucket alá.

Idén augusztusban aztán szomorúan olvastam, hogy úgy döntött az Atlassian, hogy beszántja a Mercurial támogatást a BitBucket-ben. De nem csak úgy simán beszántja, hanem sóval fel is hinti a helyét, biztos ami biztos.

Ez számomra elég hihetetlen volt. Igaz, lehet, hogy még változik a helyzet, mert a fenti linken olvasható tartalom is már legalább kétszer át volt alakítva, finomítva az elmúlt három hétben, amikor (gondolom, látva az első reakciókat), a korábbi kemény kijelentéseket igyekeztek finomítani.

Nyilván érthető, ha egy cég a profitra koncentrál, hiszen bizonyos értelemben ez a célja. Ugyanakkor, egy olyan kódtár szolgáltatásnál, amely:

• Mercurial-ra épült és később jött hozzá a Git, és kifejezetten deklarálta is azt a versenyelőnyét, hogy mindkettőt támogatja,
• Kifejezetten támogatta a nyílt forráskódú projekteket,
• Privát kódtárak esetén (>5 felhasználónál) pénzt kér a szolgáltatásáért,

Egyszer csak úgy döntenek, hogy 1 éved van arra, hogy - lényegében részükről mindenféle támogatás nélkül - elköltözz vagy konvertálj (ami szintén elköltözés, Git kódtárakba, csak kérdés, hogy a szolgáltató ez esetben marad-e, vagy azt is váltja az ember), és utána törlünk mindent.

És ez a törlünk mindent az, ami engem nagyon zavar. Megértem, ha nem támogatják már tovább a Mercurial kódtárakat, mert valóban, a Git (saját véleményem szerint sajnos) sokkal jobban elterjedt, és nem azért, mert "jobb".

De azzal, hogy egy csomó szolgáltatás felé volt integrációs lehetőségük, ahol pl. az egyes commit-okra hivatkozások lettek elhelyezve (pl. egy feladatkezelőben), azzal, hogy nem maradhat meg legalább csak olvashatóan egy állapot még évekig, vagy nem kerül átkonvertálásra statikusan elérhető html oldalakra az egyes commit-ok információja, gyakorlatilag megölik a múltat is. Azaz nem csak a jövőben lesz gondunk, hanem pl. nekünk megszűnik minden olyan feladatnál az általunk használt feladatkezelőben a most ott levő linkek működése, amely segítségével egyszerűen ugorhattam a feladat mellől a kapcsolódó kódmódosításra. Helyette a kódtár felől kell közelítenem, és commit megjegyzéseket kell lekeresnem, hogy össze tudjam szedni, hogy mi történt egy feladat mellett :(

A Google Code amikor bezárt, akkor nem csak támogatást nyújtott áttérésekhez, hanem egy archívumban meghagyta az elérhetőséget, és átirányít minden korábbi url-t az archívumba. Ez az archívum ma (2019. szeptember) is elérhető, több mint 3 évvel a bezárást követően.

Amikor a CodePlex bezárt, akkor nem csak támogatást nyújtott áttérésekhez, hanem egy archívumban meghagyta az elérhetőséget, és átirányít minden korábbi url-t az archívumba. Ez az archívum ma (2019. szeptember) is elérhető, lassan két évvel a bezárást követően, és nem is tervezik egyhamar a végét.

Nagyon örülnék annak, ha végül arra a - talán ésszerű - következtetésre sikerülni jutni az Atlassian-on belül, hogy valami hasonló archívum lehetőséget hasznos lenne biztosítani...

Addig is, a saját személyes BitBucket account-om pár napon belül véglegesen törlődik, átléptem a GitHub-ra, mivel ott is van már lehetőség privát kódtárra, és majd legalább megtanulom a Git használatát is.

Ez is megérne egy írást egyébként, mert normál módon nem is tudtam elindítani a törlést, mivel összekötötték a BitBucket account-ot egy Atlassian account-tal, és itt végtelen ciklusba keveredtek (mivel a BitBucket account-om egyfajta szolgáltatás volt, nem törölhettem a kapcsolódó Atlassian account-om, mert volt hozzá aktív szolgáltatás berakva - viszont ezt a szolgáltatást külön nem tudom lekapcsoltatni...). No mindegy, erről nem akarok már külön regélni :)

Viszont, hogy cégesen mi lesz a döntés és a helyzet, még nem tudom. Nagyon jó lenne megtartani a branch-eket és commit-okat úgy, ahogy most vannak és félek, hogy egy Git migrációval nem lesz 100%-osan ugyanolyan a történetiség. Úgyhogy lehet, hogy maradunk a Mercurial-nál és visszatérünk egy helyi hosting lehetőségre pl. a Phabricator segítségével... ennek meghatározása még egy előttünk álló feladat, ami az egyéb, ügyfelek által adott feladatok mellé most épp nem jött jókor...

Van-e gyakorlati tudás elméleti háttérismeret nélkül?

Olvastam nemrég egy prog.hu fórumtopik-ot, az alábbit:

https://prog.hu/tarsalgo/205333/netbeans-ide-hasznalata-kozepiskolaban

Erről eszembe jutott néhány gondolat, amikről egyébként írtak is egyesek a topik-ban, de az én gondolataimat is megmozgatta annyira, hogy bejegyzés szülessen belőle :)

Szóval, az én gyakorlati tapasztalataim alapján (kb. 25 év szoftverfejlesztés, azon belül már jó 15 éve architektúra-tervezéssel is kiegészítve):

• Teljesen, 100%-osan egyetértek azokkal, akik az alapelvek oktatását hiányolják. Teljesen mindegy, hogy "végül" milyen fejlesztőkörnyezet lesz használva Java vagy C++ programozás tanítására, mert a programozás tanítása - még középiskolás, sőt általános iskolás szinten is - a következőképp kellene, hogy kezdődjön:
• Általános algoritmikus és programozási alapelvek tanítása, úgy, mint mi az, hogy egész szám, lebegőpontos szám, karakter, szöveg, dátum, logikai érték, mit jelent az utasítás, az értékadás, a vezérlés (feltételes elágazás, ciklus), mi az a változó
• A fentieket tanítva akár több különböző programozási nyelvből is lehet olyan egyszerű példákat mutatni, amelyeket látva megértheti a diák, hogy valóban nem a szintaxis megtanulása a célratörő, hanem a mögötte rejlő alapelvek
• Erre jöhet rá később néhány magasabb szintű alapelv (pl. legalább a tömb/lista/halmaz/map adatstruktúrák ismerete, funkcionális programozási alapok, objektum-orientált programozási alapok, aspektus-orientált programozási alapok stb.) bemutatása, szintén, az alapok akár több különböző nyelvből is példákkal illusztrálva - ahol pl. már arra is rá lehet mutatni, hogy milyen nyelven, környezetben milyen típusú megoldás van "natívan támogatva", és mi az, ami nincs, illetve akár arról is lehet kicsit elmélkedni, hogyan lehet valamit megvalósítani, ha az adott környezetben nincs natív támogatása
• A mai, 21. századi informatikában nagyon sok terület, lehetőség van, de ami szinte mindenhol előjön, mint haladó téma, és mindenképpen megéri foglalkozni vele, elméleti és gyakorlati szinten is:
• Párhuzamos, több szálú program végrehajtáshoz kapcsolódó fogalmak és azok működése a kiválasztott környezetben
• Változók, objektumok életciklusa, static typing vs. dynamic typing közötti különbségek, futtatókörnyezetek működési alapjai, "szemétgyűjtés"
• A kiválasztott programozási nyelv esetén a nyelv, a környezet (fordító, linker, virtuális gép stb. hol mi az, ami van) és a nyelvhez tartozó standard library közötti összefüggések, különbségek (hogy egyértelműen értsük, hogy végződik a nyelv és hol kezdődik a library). Ennek része az is, hogy az adott nyelvi környezetben hogyan zajlik az alapvető folyamat, ahol a forráskódból végrehajtható program válik.
• Számomra csak ezt követően jön el az, hogy fejlesztő környezettel kezdünk ismerkedni, hiszen ekkor meg rá lehet mutatni, hogy az adott fejlesztőkörnyezet pl. hogyan támogatja a projektek létrehozását és kezelését, hogyan segít a forráskódból végrehajtható programmá alakulás folyamatában stb. És - a fejlesztő környezettel együtt - fontos néhány további dolgot is tárgyalni, úgy, mint:
• programozott tesztelés: teljesen mindegy, fejlesztők vagy tesztelők leszünk, vagy mindkettő egyszerre :), fontos, hogy értsük és tudjuk, mint jelent a unit tesztelés, az integrációs tesztelés, a kézi és az automatikus tesztelési folyamatok, és azon alapelvek, amelyek segíthetnek jól tesztelhető kódok ill. komponensek készítésében (pl. IOC)
• build eszközök: pl. JVM környezetben (ahol én is dolgozom) ma már teljesen alapvetőnek kellene, hogy számítson a Maven és a Gradle alapszintű használata, a 3rd party lib-ek elérhetősége függőségkezelésen keresztül
• segítő eszközök: a legtöbb környezetben elérhetők olyan eszközök, amelyek segíthetnek a programjainkban a nagyon elemi elírások/hibák észlelésében és felderítésében. Ilyenek pl. a statikus kódelemzők, a tesztfuttatások során "direkt hibákat vétő" megoldások, de ide tartozik a debugger (és azok gondolkodási mód, ami segíthet a hatékony használatában), a naplózási alapelvek és naplózási eszközök és a különböző, a programjainkat futásidőben monitorozó megoldások (profiler-ek)
• további elvi érdekességek: ide sorolhatók pl. a tervezési minták, a SOLID, DRY, YAGNI stb. ismerete, ezek is sokat segítenek a szemléletformálásban

Ha valaki egy olyan oktatónál tud tanulni, aki figyelembe veszi a fentieket, ott biztos lehet abban, hogy a Netbeans, vagy az Eclipse, vagy bármilyen más környezet dolgait fogja elsősorban megtanulni, hanem azt a gondolkodásmódot, amely segítségével valóban szoftverfejlesztővé válhat.

Egy volt kollégám, aki az én első munkás éveimben az egyik fontos mentorom is volt, írt egyszer nagyon velősen arról, amiről Peter Norvig kicsit bővebben, hogy miért nem jelenti ugyanazt egy programozási nyelv megtanulása, mint a programozás megtanulása, és, hogy miért is kell hosszú idő ahhoz, hogy valakiből valóban jó szoftverfejlesztő váljon.

Persze, a mai eszközök és megoldások (akár a Scratch, akár egyéb, "vizuálisan összekattogtatós megoldások") egyre jobban terjednek és azt a feeling-et adják, hogy "ez nem is olyan bonyolult". És, igazuk is van :) Viszont a fejlesztés sosem azért volt bonyolult, mert nehéz a szintaxis. A fejlesztés mindig is azért volt bonyolult, mert:

• Tudni kell megfelelően kialakítani azt az absztrakciót, amely lefedi az aktuális igényeket, és teret hagy a továbbfejlesztésekhez abban az esetben, ha nem változik meg teljesen az alap működési elv
• Ehhez meg kell tanulni szöveget értelmezni, abból absztrakt modelleket felépíteni, azzal összemérni az elvárt igényeket és pl. észrevenni, ha ellentmondásosak az elvárások, ...
• Tudni kell kiválasztani a megfelelő eszköztárat, amely segítségével az adott igény megvalósítása megfelelő színvonalon, ugyanakkor lehetőségek szerint az elvárt határidőn és költségkereten belül megtehető

Persze, nagyon sokféle terület van jelenleg is, amire azt mondjuk, hogy fejlesztői feladat. Nyilván, ha a fő profil, hogy van egy vagy két féle "termék", amelyeket minimális testreszabással szállítunk, és ezen - viszonylag egy kaptafára történő - testreszabásokat fejlesztők végzik, erre a feladatra nem feltétlenül kell olyan fejlesztőt felvenni, aki "nulláról" is képes fejleszteni, és képes új megoldásokat adni felmerülő problémákra.

Ha viszont valaki túl szeretne valaha lépni az "emelt szintű fejlesztői segédmunkás" szerepkörön, az kénytelen a fenti - nyelv- és környezetfüggetlen - alapelvekkel is megismerkedni, mert ezek nélkül viszonylag hamar "meg fog rekedni" egy szinten...

Visszatérve egy gondolat erejéig a Netbeans "betiltására", ami a témaindító topik volt. Kollégáimmal:

• A 90-es évek végén Java fejlesztésre a Visual J++ eszközt használtuk, mert fényévekkel gyorsabb és kezelhetőbb volt, mint akkoriban bármilyen versenytársa (a 233Mhz-es MMX Pentium processzorral és 128MB memóriával szerelt fejlesztői gépen mindenképp)
• Utána tettünk kitérő Visual Café, Forte (a Netbeans elődje), Borland JBuilder irányokba is, sőt megnéztük az Emacs-ot is a JDEE-vel; mindegyikkel végeztünk produktív szoftverfejlesztést
• Végül rátaláltunk az Eclipse-re (ekkor még az Eclipse 2.0 volt aktív fejlesztés alatt :) ), és utána egészen sokáig az Eclipse maradt, illetve később az STS (SpringSource Tool Suite)
• Végül, 2016-ban váltottunk az Intellij IDEA-ra, és azóta azt használjuk

A lényeg: mivel kollégáim ismerték/ismerik az alapelveket és megvan a szükséges háttértudásuk, gyakorlatilag mindegyik váltásnál gyakorlatilag a 2. napon már teljesen produktívan tudtak dolgozni, aztán persze még jobban megismerték az eszközöket és még hatékonyabbá váltak. Nem azt tanulták meg, hogy "és akkor az eszköztáron a 8. ikont, ami olyan izé... színű és formájú, ha megnyomom, akkor utána tudom majd futtatni a programomat", hanem azt, hogy "hol van a build menüpont" :)

2019-es "álom" fejlesztői eszköztáram :)

Lassan eljön 2018 év vége és beköszönt 2019. És immáron legalább 5 éve, hogy a "mainstream" fejlesztési feladatokból "kiestem", helyette főleg architekt ill. business analyst jellegű feladatokat látok el néhány projektünknél. Viszont próbáltam azért minél kevésbé "visszaesni", bár a Pat Kua által említett "még foglalkozzunk programkód írással" (https://www.thekua.com/atwork/2018/02/5-tips-for-being-an-effective-tech-lead/ 2. pontja) nem nagyon megy, főleg, mivel a tech lead mellett más szerepkörökben is helytállok (business analyst ill. 2. és 3. szintű ügyféltámogatás egyes projektekben). Viszont arra ügyelek, hogy minél jobban lelassítsam a teljes kiesést, így azért néhány szituációban még programozom, ill. olvasok kódot, azaz nem szakadtam el teljesen a kódbázistól:

• néhány kiosztott feladatnál én vagyok a reviewer (elsősorban olyan feladatoknál, ahol nem az API használat a lényeges, hanem bizonyos algoritmikus / üzleti megoldások, így ugyanis, hogy napi szinten nem kódolok, a forráskód elviségét tudom elsősorban áttekinteni és véleményezni, nem a helyes külső API paraméterezéseket)
• főleg nagy átadások során (akár UAT, akár éles átadás után), ahol az első hetekben azért sok apróság tekintetében jön visszajelzés, egy-egy, az adott projektnél teljesen "lokális" probléma esetén én végzem el a javítást (szintén általában ott, ahol elvi probléma volt a korábbi megvalósítással, és nem valamilyen rossz paraméterezés)
• időről időre felmerül kisebb, belső használatú, vagy projektnél egyszer lefutó kis utility-k készítése, ahol messze nem feszítő a határidő, azok közül is van, amit még bevállalok
• van egy nagy álmom is :) bár alapvetően a projektjeink dokumentálva vannak, még érzek "fehér foltokat" kifejezetten a belső fejlesztői dokumentáció tekintetében (azaz, kellene egy olyan anyag, ami mélyebb/más jellegű, mint az ügyfelek felé átadott informatikai specifikáció, viszont továbbra is főleg a felső szintű áttekintést biztosítja, viszont ezt fejlesztői oldalról, segítve az adott projektben új embereket a minél gyorsabb bekapcsolódásban)

Persze, amellett, hogy igyekszem azért "kódközelben maradni", viszonylag rendszeresen figyelem azokat a változásokat, újításokat, amelyek segítségével az eszköztárunkat hatékonyan lehet bővíteni / fejleszteni. Mi JVM alapú rendszereket készítünk, középméretű (néhány százezer "saját kódsor") nagyvállalati szoftvereket, ahol vagy webszolgáltatás alapú API-t biztosítunk, vagy webes felhasználói felületet, és jellemzően kell más rendszerekkel kommunikálni, ill. oda kell figyelni a nagyvállalati biztonsági és egyéb előírásokra. Java-ban (most már a 8-as verzióban is), illetve Spring keretrendszer, Hibernate, JOOQ viszonylag nagy tapasztalattal rendelkezünk, de, mivel a projektek közül sok már jó néhány éve kezdődött és azóta is működik (rendszeres finomítással/továbbfejlesztéssel), már sok külső könyvtárral ismerkedtünk meg, amelyeknél most már vannak ügyesebbek / jobbak / "teljesebbek".

Ha most, 2018 év végén, 2019-ben kellene új rendszert kezdeni a fenti területen, akkor szívem szerint a következő technológiai stack-et használnám (amiről úgy érzem, hogy nem hátráltatna, és a mostanában nálunk futó nagyvállalati projektkörnyezetben is kiválóan alkalmazható lenne):

• Futtatókörnyezet: JVM, Java 8 vagy Java 11
• Programozási nyelv: Kotlin 1.2
• Felhasznált 3rd party keretrendszerek, könyvtárak:
• Egyszerűbb esetekben:
• DB kezelés: Spring JDBC vagy, ha csak alapok kellenek, akkor Exposed (https://github.com/JetBrains/Exposed)
• Web API: Ktor (http://ktor.io/)
• Kiegészítések a standard Java / Kotlin osztálykönyvtárakhoz:
• Eclipse Collections (https://github.com/eclipse/eclipse-collections/)
• Spring Framework (IOC konténerhez)
• Ha nagyobb/bonyolultabb dolog kell / web GUI kell hozzá, akkor a fentiekhez kiegészítésképpen:
• Web GUI: követelményektől / körülményektől függően ReactJS (+PrimeReact: https://www.primefaces.org/primereact/#/) vagy JSF (PrimeFaces: https://www.primefaces.org/showcase/)
• Backend: Spring Boot 2 (https://spring.io/projects/spring-boot) és függőségei
• Unit és integrációs tesztelés: JUnit 5 és Mockk (a https://blog.philipphauer.de/best-practices-unit-testing-kotlin/ cikk alapján)
• Fejlesztőkörnyezet: IntelliJ IDEA Ultimate :)
• Build és CI környezet (amennyire lehet, Docker konténer alapokon összeállítva :) ):
• kódtár: Mercurial (BitBucket-en keresztül) - tudom-tudom, nem Git, de ebben sokkal nagyobb a tapasztalatunk és nem érezzük egyelőre a saját munkamenetünkben, hogy a kódtár sajátosságai miatt hátrányos helyzetben lennénk
• build környezet: Gradle (https://gradle.org/)
• CI környezet: Jenkins LTS (https://jenkins.io/) + SonarQube LTS (https://www.sonarqube.org/) a Sonar-Kotlin kiegészítéssel (https://github.com/arturbosch/sonar-kotlin)

A közeljövőben jobban bele szeretném / fogom ásni magam a Kotlin és a kapcsolódó eszköztár környezetbe, hogy lássam, mennyire jól mértem fel, hogy ezzel a nyelvvel hatékonyan előreléphetünk a JVM alapú feljesztésben a Java-hoz képest :)

Pengeélen

Nemrég egy igen komoly rendszerfejlesztés/átalakítás első fázisát fejeztük be. Komoly volt az alábbi értelemben:

• Egy, már öt éve működő (és ezen időszak alatt is folyamatosan bővülő, finomodó) rendszer került szinte teljesen új alapokra, de NEM újraírásra
• Az öt év tapasztalataiból nagyon sok mindent felhasználtunk és a legfontosabb struktúrális és elvi problémákat sikerült is kezelnünk
• A rendszer teljes mértékben támogatja a korábbi folyamatokat, ugyanakkor teljesen új folyamatokat és irányvonalat is alkalmaz (pl. elektronikus dokumentumkezelés, érintőképernyős aláírások kezelése, teljes tablet- és mobiltámogatás, ami még nem volt a rendszerben a 2012-es indulásakor)
• A számos új lehetőség és folyamat miatt az adatmodell (táblák és mezők) száma kb. 40%-kal, a kódbázis pedig kb. 50%-kal nőtt (így lett kb. 440e sornyi saját kód a rendszer aktuális állapotában), ugyanakkor a teljesítmény nem csökkent, sőt több helyen nőtt (a struktúrális átalakítások következtében)

Minden naptári időben kb. 15 hónapot vett igénybe, 5-6 kollégával. Az eddigi pályafutásom talán legkomplexebb feladata volt. Szerencsére sikerrel vettük az akadályt, gyakorlatilag határidőre és egészen jó minőségben sikerült leszállítani a rendszert.

Maga a projekt ütemezési/belső technikai része is érdekes volt: pl. milyen metodikával tudtuk elérni, hogy "nem törtük szanaszét" a rendszert a teljes átalakítás során, erről később írok.

Ami a projekt kapcsán leginkább megmaradt bennem, az, hogy mennyire sokféle területen van szükség "egyensúlyozásra" annak érdekében, hogy a projekt sikeres legyen, és sokszor mennyire nehéz ezen egyensúlyozás végrehajtása. Gyakorlatilag több dimenzióban is folyamatosan "pengeélen" táncol az ember, és bármelyik irányba lép nagyot, abból tuti zakózás lesz.

Ebben a fejlesztésben - mai divatos szavakat használva - voltam business analyst, architect, product owner, tesztelő és ügyfélszolgálatos is (utóbbiak leginkább a kollégák tehermentesítése céljából, hogy legyen idejük és lehetőségük az elmélyült és alapos munkára, legalábbis annyira, amennyire az ütemezés és a feladatok komplexitása ezt lehetővé tette).

Mindegyik szerepkörben voltak nagyon érdekes kérdések, amelyek felmerültek, és nagyon nem volt egyértelmű, hogy mit kezdjen vele az ember. Ennek oka elsősorban a "tipikus nagyvállalati szoftverfejlesztés" háttere volt:

• A megrendelő részéről nem volt egy dedikált projektfelelős, aki kézben tartotta és priorizálta volna a feladatokat, hanem több üzleti területnek voltak delegált tagjai, akiknek - az egyébként is túlzsúfolt és adminisztrációval telített - napi operatív feladataik mellett kellett (volna), hogy a rendszerrel kapcsolatos elvárásaikat meghatározzák, és olyan szinten dokumentálják, ami alapján már értelmezhető a feladat. Látszott, hogy igyekeznek megfelelni a feladatnak, de erős hátrányból indultak már eleve ezen körülmények miatt.
• Több üzleti területtől voltak olyan delegált tagok, akik gyakorlatilag nem is ismerték a rendszer aktuális változatát, mivel az még az ő tevékenységüket nem támogatta, de az átalakítás és bővítés után már nekik is ebben a rendszerben kell dolgozniuk. Ez egyrészt kihívás volt (teljesen más fogalomrendszer használata, számunkra sokszor ismeretlen üzleti folyamatok), másrészt jó volt abban az értelemben, hogy kiderült, hogy a támogatott üzleti folyamatok sem úgy vannak teljesen a valóságban, ahogy az a rendszerben működik (mertháthogy nem nagy az eltérés, és erre az adaptációra, amikor a folyamatunk megváltozott, nem akartunk pénzt költeni).
• Láthatóan mindenkinek a célja a saját elvárásainak kielégítése volt, és nem igazán voltak olyan megrendelői egyeztetések, ahol az egyes üzleti területek egymással tisztázták volna a prioritásokat. Így időnként
• A napi munka melletti tevékenységnek és a korábbi rendszer "nem ismeretének" volt egy olyan mellékhatása is, amitől egyes megbeszéléseknél egyértelműen az 50 első randi című film jutott eszembe. Voltak olyan folyamatok, amelyeket a tervezési fázisban négyszer, a fejlesztési fázisban szintén négyszer alakítottunk ki/át teljesen, majd a tesztelési fázisban is sikerült alaposan felforgatni egyes területeket. És nem azért, mert az üzleti folyamat változott, hanem azért, mert igazából nincs definiált üzleti folyamat, hanem a szereplők nagyjából így és így dolgoznak, de igazából minden nap egy kicsit másképp. Hiába volt bármi leírva, ha a napi munka mellett nincs idő elolvasni, így, ha egy kérdés újra felmerült, már más volt a válasz, mint korábban (akár egy héttel azelőtt).
• Mindezek mellett ugyanakkor a teljes projekt egy, a projekt elején készített specifikáció alapján fix határidős, fix költségvetésű projektként ment. Ezért egy idő után a közös érdek mellett (ti. hogy legyen egy jól használható, hatékonyan működő rendszer, ami az üzleti elvárásokat megvalósítja és a felhasználók is szeretik használni a célszerűsége miatt) megjelentek a saját érdekek is (beszállítói oldalon értelemszerűen, hogy ne nyújtsuk túl a projektet, megrendelői oldalon pedig a "ezért a projektért sokat fizetünk, így ez még bele kellene, hogy férjen" merült fel teljesen természetes emberi hozzáállásként).

A fenti körülmények által létrehozott univerzumban minden szerepkörömben érdekes "pengeéles" szituációk voltak. Ezek közül amelyek a legjobban megmaradtak bennem, az alábbiak voltak:

• business analyst-ként:
• Ha már letárgyaltunk és specifikáltunk valamit, majd attól elkezdünk eltérni, mennyire hívjam fel erre a figyelmet és kérdezzek vissza, hogy mi az oka a változásnak? Vagy inkább figyeljem meg, hogy mik azok a területek, amelyek "folyamatosan változnak" és ott specifikáljuk úgy a folyamatokat, hogy rugalmasan kezelhető/módosítható legyen?
• Mennyire kérdezzem ki a valós üzleti folyamatot, mennyire erőltessem a nem tiszta / nem egyértelmű megfogalmazások letisztázását? Látszólag erre a kérdésre egyszerű a válasz, mert legyen minden egyértelmű, ugyanakkor teljesen más az a szint, ami egy, az adott üzleti területen gyakorlott embernek "egyértelmű", és más az, amikor egy, az adott üzleti területen relatíve kevés tapasztalattal bíró fejlesztő számára "egyértelmű".
• Ez egyébként két irányban is problémát jelentett. A megrendelővel való kommunikációban én voltam a "gyenge láncszem", nekem voltak hiányos háttérismereteim az üzleti folyamatról. A fejlesztő kollégákkal való kommunikációban viszont fordított volt a helyzet, hozzájuk képest én rengeteget tudtam az üzleti folyamatról, amit ők (joggal) nem tudtak.
• A különböző üzleti területek keveset egyeztettek egymással, és mivel nem volt üzleti oldalon priorizálási felelős, a beszállítónak (nekünk) kellett ellátni ezt a meglehetősen hálátlan feladatot (hiszen itt valakinek mindig "rossz lesz", ha egymással ellentétes elvárásokból kell kihozni "valami jót"). Ugyanakkor muszáj volt ezt megtenni, másképp könnyen halastóvá válhatott volna a projekt, és az még rosszabb lett volna. Viszont ezt a szerepet sem szabad túltolni, mert akkor nagyon rossz híre lesz a beszállítónak a megrendelőnél ("azok a kötözködősök már megint...").
• architekt-ként:
• Hogyan legyen az alap úgy felépítve, hogy az üzleti igények folyamatos változása és átalakulása a legtöbb esetben ne alapjaiban rengesse meg a felépítményt, hanem még beleférjen a koncepcionális modellbe? De ne legyen túltolva ez sem, mert akkor meg sosem lesz konkrét rendszer belőle...
• Lépjünk előre mindig mind a rendszerfelépítés, mind a felhasznált eszköztár tekintetében (cél, hogy ne váljunk "dinoszaurusszá" azzal, hogy görcsösen a már megismert környezetekhez és lib-ekhez ragaszkodunk), de ugyanakkor ne túl nagy lépésben, mert akkor a projekt helyett eszköztanulással töltjük az összes időt.
• Fontos az üzleti folyamat támogatása, de (majdnem) ugyanilyen fontos a rendszerben a "transzparencia" (problémafelderítésre, auditálásra és belső ellenőrzési feladatokra is alkalmas log-ok), a biztonság (mindenki csak ahhoz férjen hozzá, amihez kell) és a minél egyszerűbb üzemeltethetőség/frissíthetőség. Ja, és persze a teljesítmény is jó legyen :) Szóval ezen területek között is érdekesen lehet "lavírozni", és nagyon könnyű elcsábulni valamelyik faktor erősítése felé a többiek rovására.
• product owner-ként (bár itt kicsit többről/másról van szó, egy kicsit projekt menedzserként, egy kicsit vezető fejlesztőként és egy kicsit Scrum master-ként is tevékenykedtem ebben a projektben):
• Hogyan legyenek a feladatok úgy szétosztva a kollégák között, hogy mindenkinek legyen feladata; ne legyen túlterhelve de ne is tudjon "takubakuzni"; miközben figyeljünk az egyes személyek kompetenciájára, aktuális tapasztalatára, erősségeire is, építsünk rá, de engedjük továbbfejlődni/kiteljesedni is - de persze nem a feladatvégzés kárára. És persze, nem utolsósorban, a prioritásoknak és a felépítésnek megfelelő sorrendben végezzük a feladatokat.
• Ha valamit úgy lát az ember, hogy "nem megfelelő", az kivel milyen módon, formában, lehetőleg előremutatóan legyen kommunikálva.

Szóval, érdekes volt. Sokat tanultam magamról is, meg a világról is, és sikerült továbbfejlődni kommunikáció terén is (bár, néha nem vagyok biztos abban, hogy a továbbfejlődés a megfelelő szó... :) ). De az biztos, hogy ez a projekt is megmutatta, hogy a szoftverfejlesztés egy bizonyos szint felett (amikor komplex feladatokat kell több embernek sok hónapon keresztül megfelelően elvégeznie, folyamatosan változó követelmények mellett) meglehetősen embert próbáló feladat. 

Le a kalappal azok előtt, akik a következő komplexitási szinten (több millió soros projektek, több tucat szereplővel, több éves átfutás alatt) képesek irányítói szerepkörben megfelelően teljesíteni.

Így lettem anyagilag (és más téren is) sikeresebb

Nemrég olvastam az egyik követett blog-on egy bejegyzést és a kapcsolódó kommenteket arról, hogy lehetünk anyagilag (is) sikeresebbek.

Ennek kapcsán átgondoltam, hogy a saját életemben sikeres vagyok-e, vagy sem. Végül arra jutottam, hogy sikeres vagyok, mert:

• szerető családban élek, a napi összezörrenéseken túl nincs konfliktus :)
• alapvetően az egészség is megvan, bár a kor már mintha kezdene látszódni...
• szép helyen élünk, megfelelő infrastruktúrával, hitel nélkül
• a család havi bevételei fedezik a kiadásokat, van lehetőség megtakarítani is, és közben egy, számunkra teljesen normális életszínvonalat tudunk biztosítani magunknak, amelyben megvan mindenünk, amelyre igényünk van (igaz, nincsenek luxus igényeink)
• normális munkahelyen dolgozom, a főnökeim és a kollégáim is megbecsülnek, és én is őket, abszolút működik a közös munka és teljesen ismeretlen a "másik fúrása"
• azt gondolom, hogy azon emberek többsége, akiket akár a magánéletben, akár a munkán keresztül megismertem, normális és korrekt embernek tart, legalábbis ezeket a visszajelzéseket kapom :)

No, de mit tettem én ezért? Jó kérdés, és nem is nagyon tudnék rá válaszolni, mert sok esetben tyúk-tojás kérdésről van szó (példa: azért tudok olyan ember lenni, amilyen, mert jó munkahelyem van, vagy azért lehet jó munkahelyen, mert olyan ember vagyok, amilyen?). Ezért csak úgy, abszolút véletlenszerű sorrendben, ahogy eszembe jutott, leírok pár dolgot, amiről azt gondolom, hogy hozzájárultak az én utamon ahhoz, hogy elérjek oda, ahol jelenleg vagyok:

• rendszeres sport, legalább gyerek- és fiatalkorban: szerencsére szüleim ragaszkodtak hozzá, hogy sportoljak kb. 8 éves koromtól kezdve suli mellett, és addig próbálkoztunk, amíg nem találtunk olyan sportágat, amit nagyon megszerettem. Nekem ez a kajakozás volt, 6 éven keresztül suli előtt és suli után edzésre jártam. Valószínűleg sokat segített abban, hogy a sulit is jobban bírtam, illetve a szervezetem kellően megedződött. Később volt még harcművészet, néptánc, súlyzós edzések, futás, úszás, egészen kb. 26 éves koromig legalább heti 4-5 alkalommal edzettem. Sajnos azóta visszaesett a dolog, és érzem is...
• hitelesség: ha valamit megígérek, azt betartom. Ha esetleg nem sikerül és már látom, hogy nem fog, akkor jelzek róla annak, akinek megígértem. Ezt nagyon-nagyon fontosnak tartom, két okból is:
• egyrészt viszonylag kevesen művelik (sajnos), ezért csak ezzel az egy dologgal nagyon "ki lehet emelkedni" a tömegből,
• másrészt ha valaki hiteles, akkor tényleg bízni fognak benne, annak minden előnyével (és felelősségével) együtt
• problémamegoldási hajlam: ha feladat van, akkor arra megoldást kell találni, és nem azon gondolkodni, hogy miért nem én, miért nem most és miért nem úgy. Nem tudom, mi kell hozzá, hogy ez ki tudjon alakulni (én sokat olvastam, ez biztosan segített), de ez is egy nagyon fontos tulajdonság.
• kilépés a komfortzónából: az előzőhöz szorosan kapcsolódik. Olyan feladatunk van, amit még előtte nem csináltunk? Nem berezelni kell tőle, hanem utánamenni :)
• prioritások kezelése: sajnos sokszor hajlamosak vagyunk a leggyorsabban és legkényelmesebben intézhető dolgokat intézni először, és a nehéz (és sokszor nagyon fontos) dolgokat halogatjuk. Aki ezt képes megfordítani, és először a valóban fontos feladatokkal végezni, az minden normális munkáltató számára kincset ér :)
• gyermeki nyitottság, érdeklődés fenntartása: minden nap érjen úgy véget, hogy tanultunk aznap valami olyat (bármit, akármilyen témában), amit aznap reggel még nem tudtunk. Lehet ez családi dolog, munkával kapcsolatos, bármilyen hobbival kapcsolatos, a lényeg, hogy dolgoztassuk meg minden nap a kis buksinkat.
• empátia, figyelmesség, odafigyelés a másikra: ugye nekünk is jól esik, ha valaki törődik velünk, figyelmes és észreveszi, ha valami, számára apró dologgal nekünk nagy segítséget tud adni (akár csak azzal, hogy figyelmesen meghallgat bennünket)? Legyünk mi is ilyenek a számunkra fontos emberek számára, de akár bármilyen hétköznapi helyzetben is lehetünk figyelmesek. 

Van még persze egy csomó dolog biztosan, de a fentieket érzem talán a legfontosabbnak.