Ez egy kétrészes cikk, a cikk második részét itt olvashatod.
Az első agilis élményem 2007-2010-re datálódik vissza, amikor a Synergonnál dolgoztam senior fejlesztőként/vezető fejlesztőként. A Honvédelmi Minisztérium megbízásából dolgoztunk egy iratkezelő szoftver kifejlesztésén, ami képes volt a teljes Magyar Honvédség igényeit kiszolgálni. A 3 éves fejlesztést (amíg én benne voltam) megelőzte egy korábbi csapat munkája, akik vízesés megközelítéssel dolgoztak, és akiknek a munkája sajnos kudarcba fulladt a megközelítésből származó rugalmatlan hozzáállásnak köszönhetően. Nekünk újra kellett kezdeni, új kódbázis, új csapat, új alapokra helyezve az ügyféllel való kapcsolatot, amiben agilis megközelítést alkalmaztunk.
Amikor mi bekapcsolódtunk, az ügyféllel már egy nagyon rossz viszony volt, ezen kellett változtatnunk. Mondhatjuk tehát, hogy az agilis szemléletmódot krízismenedzsmentre alkalmaztuk, bár ez akkor így nem tudatosult bennünk. Egyszerűen csak nem láttunk más lehetőséget az ügyféligények rugalmas kiszolgálására, mint azt, hogy oda figyelünk az ügyfélre és maximálisan megértjük őt, és inkrementális és iteratív metodológia mentén szállítunk.
A termék fejlesztése a tipikus államigazgatási jellegeket hordozta magán: bonyolult jogszabályi környezet (bár akkor még nem volt naponta változó mint manapság) és az ügyféloldalon történő nehéz döntéshozatal jellemezte. Nekünk ezekhez is sikerült alkalmazkodnunk, és bátran állíthatom, hogy ez az agilis megközelítésnek volt köszönhető.
Erről a történetről sokszor meséltem már különféle fórumokon, mindenféle részletességgel, mégis úgy gondoltam, 15 év után feldolgozom teljességében a témát. Ehhez az emlékeimen túl az akkori csapattársaim segítségét is kértem, akik a cikk végén nyilatkoznak majd arról, hogy ők hogyan élték meg ezt az időszakot, miért lett szerintük sikeres ez a projekt és nekik mit hozott a későbbiekben a szakmai karrierjükbe ennek a projektnek az élménye.
A célom ezzel a cikkel az, hogy egy hiteles beszámolót szolgáltassak arról, milyen egy valódi agilis termékfejlesztés, segítve azokat, akik ebben támpontokat keresnek.
A mai világban sok helyről hallatszik, hogy sikeres agilis transzformáción vannak túl cégek, de sokan ezt már – helyesen – kétkedéssel fogadják.
Az agilis transzformációnak sosem lehet vége. Aki egy ilyen folyamatban részt vett már, az nagyon jól tudja, hogy a folyamat fenntartása örökké tart, az folyamatos figyelmet és gondozást igényel. Hiszen a cél (agilitás) maga az, ahogyan végezzük a munkát, nem pedig egy olyan egyszer elérendő cél, amit közbülső lépések eredményeképpen lehet elérni.
Tapasztalatom szerint ha nem gondozzuk, akkor a kialakított emberi rendszer elkezd erodálódni, és visszacsúszik a folyamatok és rendszerek profán szintjére, ahol a gondosság megszűnik és az emberi szempontok is háttérbe kerülnek. Ennek a folyamatos gondozásnak és fejlődésnek a szükségességéről számolnak be azon cégek beszámolói is, akik pl. nagyvállalati környezetben valósítanak meg teljes önszerveződést. Ezen cikkek legnagyobb tanulságai számomra például nem az elért mintákban és működésben keresendők, hanem abban az útban, abban az egyedi történetben, amin keresztül ők ezt megvalósították.
Sokan tetszelegnek a sikeres agilis szakértő szerepkörében, de valójában nincs láthatósága annak, hogy ők mit is csináltak pontosan a múltban, mi volt a projekt és a szervezeti kontextus, amiben működtek, hogyan élték meg a folyamatot, és végül milyen eredményeket értek el. Nagyon hiányzik az, hogy egy-egy szakértő őszinte beszámolóval meséljen egy-egy sikerről vagy kudarcról. (A szakértők védelmében azért azt is meg kell említenem, hogy nehéz is esettanulmányokat megosztani, hiszen hamar kiteregtésre kerülnének a belső “szennyesek”, amit meg senki nem szeretne.)
Az én történetem (vagyis a mi történetünk) viszont már 15 éves, a Synergon azóta már megszűnt, így számomra már nem jelent gondot a történet részleteinek megosztása.
Utolsó gondolatként mielőtt belekezdek, annyit még mindenképp szeretnék megosztani, hogy szerencsésnek mondhatom magam, hogy rögtön az első agilis élményem nem csak ügyfél eredmények tekintetében, de “szoftverfejlesztés ügyileg” is sikeres lehetett. Ez a 3 éves projekt szoftverfejlesztői szakmai karrierem egyik meghatározó állomása lett, ami 15 év elteltével is még mindig meghatározza a karrieremet, de már nem csak mint szoftverfejlesztő, hanem mint agilis szervezetfejlesztési tanácsadó. Ezt pedig szeretném megköszönni csapattársaimnak, az ügyfelünknek és az akkori synergonos menedzsmentnek, akik ebben mind partnerek voltak.
A cikk első részében a projekt történetéről írok, hogy hogyan valósult meg nálunk az agilitás, a második részben pedig azzal fogok foglalkozni, hogy mi volt a sikerünk kulcsa, ami a környezeten túl a csapatban is keresendő.
Hogyan is indult?
A Honvédelmi Minisztériumnak (továbbiakban: HM) akkoriban volt egy nagyobb szerződése a Synergonnal különféle eszközök (hardver és szoftver beszerzésére). Ez – tudtommal – egy több milliárdos szerződés volt, aminek volt egy relatíve kisebb alprojektje, az “iktató”, amit a Synergonnak kellett kifejlesztenie.
Erre rá is állítottak egy csapatot, akinek megvolt erre a maga projektmenedzsere. Erről az időszakról keveset tudok, mert ekkor még nem voltam a csapatban, csak folyosói pletykákat hallottam.
Annyi jutott el hozzám, hogy az ügyfél elégedetlen, nem azt kapta, amit ő szeretne, a projektet pedig nem lehet keretek között tartani, mert az ügyfél mindig jön elő az újabb és újabb “ötleteivel”.
Végül elég sok huzavona után, kb. 1,5 év fejlesztés után (ebben nem vagyok már biztos), leállították a projektet.
Synergonon belül az “iktató” ügye (így hívta mindenki a cégen belül) a tulajdonosi szintig jutott, és innentől kitüntetett figyelmet kapott.
Scrum – nincs itt kérem semmi látnivaló!
Együtt olvastuk el (a csapat) Henrik Kniberg Scrum and XP from the Trenches c. e-könyvét. Henrik Kniberg volt pár évvel később a Spotify külsős tanácsadója, aki segített a Spotifynak megvalósítani az agilis működést, de ő már abban az időben is ismert volt a nemzetközi publikációi miatt.
Az ő könyvéből értettük meg a scrum működését, és láttunk példát a gyakorlatára. Menet közben is sokat vitatkoztunk, hogy mit hogyan csináljunk. (Ekkor amúgy még nem is létezett a Scrum Guide, ami 2010-ben lett először publikálva.)
3 hetes sprintekben dolgoztunk, talán az elején kísérleteztünk is, mi lenne az ideális hossz, de erre már nem emlékszem. Ezek a 3 hetes sprintek jók voltak arra, hogy a csapat elmélyüljön egy-egy feladatban, meg tudja normálisan beszélni/tervezni, és végig is tudja vinni azokat kevés technical debttel. (A mai világban mindenki hajtani akarja a csapatokkal, és hamar eredményet akar látni, ezért a kéthetes sprintek a megszokottak.)
A retrokat komolyan vettük, és talán mondhatom a többiek nevében is, hogy élveztük is. Változatosan dolgoztuk fel az elénk kerülő témákat. Arra már ennyi idő távlatából nem emlékszem, hogy milyen koncepció szerint történt ez meg, de pl. sokat beszélgettünk arról, hogy mi lehetett az oka annak, ha egy-egy sprint nem a terveink szerint sikerült.
Mi is átmentünk azokon a gyerekbetegségeken, mint általában minden csapat, hogy nem bírjuk normálisan lebontani a backlogunkat. Az elején például egy-egy feature kapcsán rétegekre szedtük szét a feature-t, és azok lettek a sztorik (frontend vs. backend).
Akkor még nem volt hibrid meg remote munka, így az irodában a csapat szobájában volt a falon a board (szerencsére nem open-office-ban dolgoztunk), és kézzel rakosgattuk a cetliket minden nap. Mi szerettük. A product backlogot és sprint backlogot Excelben szerkesztettük (vagyis szerkesztette Csuti), nem volt külön szoftver erre.
Emlékszem, azzal is kísérleteztünk, hány oszlopunk legyen a falon, és ne legyen egyszerre sok feladat függőben. Igyekezzünk lebontani a feladatokat minél kisebbre (Csuti nagyon nyomta hogy 1 napos feladatokra bontsunk le, de erre nem voltunk eléggé érettek, és befogadóak sem.) Definition of Done, Acceptance Criteria – ezekre már nem emlékszem, de úgy rémlik, ezeket is alkalmaztuk, ha nem is “halál pontosan”, de ösztönösen mindenképp.
Úgy gondolom, fontos volt, hogy Csuti jó scrum master akart lenni, és ő is kereste a fejlődés lehetőségét. A saját scrummasteri fejlődésében ő egyedül volt, mi a csapat részéről a termékre koncentráltunk, és a szervezetben is ismeretlen volt még ez a pozíció, ezért másokkal se tudott erről beszélgetni. Ez volt neki az első ilyen munkája.
A titkos fegyver
Csuti, aki a menedzsment oldaláról felhatalmazás kapott, hogy csapatot alakítson az első (waterfall) csapat tagjai közül is meghívott tagokat, és új csapattagokkal is bővítette a csapatot (ebben a merítésben érkeztem én is).
Mivel az első bukott projekt tapasztalatai egyértelműen azt mutatták, hogy az ügyfél problémáját nem lehet egy tetszőleges projekt csapattal megcsinálni anélkül, hogy a csapat meg ne ismerné mélyéségben az ügyfél problématerét (domainjét), ezért az ügyfél oldaláról egy szerencsés megállapodás keretében sikerült áthozni Endrét a csapatunkba.
A bukott projekt idejében ő volt az ügyfél oldalán a projektvezető. Ő lett így a domain szakértőnk, aki az iratkezelést is ismerte, és nem mellesleg a teljes Honvédelmi minisztérium és Magyar Honvédség kultúráját is.
Endre segítségével házon belül lett az a tudás, ami mindig is hiányzott az iratkezelőből. Amikor új felhasználói felületet terveztünk, ezeket azonnal át tudtuk nézetni Endrével. Amikor azt próbáltuk kitalálni, hogy a szoftver hogyan támogasson egy korábbi csak a papíros világban létező funkciót úgy, hogy a jogszabályoknak megfeleljen, a honvédség eszközrendszereiben, szokásaiba, kultúrájába illeszkedjen, erre is Endre volt a válasz. De sokkal alapvetőbb kérdésekben is ő segített, pl. hogy hogy működik egy érkeztetés a valóságban, és mit is jelent ez egyáltalán. (El is vitt egy ügyviteli irodába minket a honvédségnél, ahol megnézhettük a valóságban ezeket a folyamatokat.) Endrével terveztük meg az üzleti folyamatokat, amiket a szoftver megvalósított.
Endre nem volt üzleti elemző – egyikőnk se volt az – de mindannyian analitikus gondolkozásúak voltunk, rendszerszemlélettel, ezért az üzleti elemzés nem okozott számunkra nehézséget sem akaratban, sem képességben.
A közös nyelv
Innentől kezdve, amikor mentünk az ügyféllel egyeztetni és megmutattuk a képernyőterveket, folyamatkoncepciókat, nem volt kulturális szakadék a technológiai beszállító és az ügyfél között. Ugyanazt a nyelvet tudtuk beszélni.
Az ügyfél demókon (Sprint demo) a fejlesztők mutatták be a maguk készített funkciókat.
Az ügyfél is meglepődve tapasztalta, hogy a fejlesztők is ugyanazon a nyelven beszélnek, amelyet ők is használnak. Ez a nyelv nem csak az ügyfél előtt volt használatos, mi magunk is ezeket a fogalmakat használtuk, amikor beszélgettünk egymás között tervezéskor, vagy amikor a kódot írtunk.
Mivel magyar volt az ügyfél, ezért pl. az iktatókönyv fogalom a forráskódban is egy olyan osztályban képeződött le, aminek az volt a neve, hogy “Iktatókönyv”. Fontosnak tartottuk, hogy a legfontosabb üzleti fogalmak egy az egyben, magyar nyelven manifesztálódjanak a kódban és az adatbázisban is.
Bizalom
A közös nyelv rengeteget segített abban, hogy a bizalom kiépüljön az ügyféllel. A közös nyelv alkalmazása szerintem a legnagyobb bizalomépítő eszköz – bár mi ezt nem eszközként használtuk, hanem ösztönösen így kommunikáltunk az ügyféllel és egymás között is, így a kódban is. Az, hogy ugyanazt a nyelvet használtuk mint az ügyfél, az ő maximális elfogadását és megértését hozta magával.
A bizalmat a Scrum önmagától is támogatta a rendszeres demókkal, így az ügyfél meggyőződhetett arról, hogy tényleg készül a szoftver, és az készül el, amiről előzetesen egyeztettünk vele. A korábbi bukott waterfall projekt leginkább egy folyamatos ígérgetés volt, amiben nem voltak látványos változások, csak egy folyamatos birkózás volt a státusz update-eken.
Egy fél év-év elteltével már az ügyfél olyan szintű bizalmat adott nekünk, hogy tulajdonképpen már át is engedte nekünk az irányítást. Látta, hogy sokkal jobban átlátjuk ezt az új elektronikus rendszert, és annak bevezetéséhez kapcsolódó feladatokat, mint ők maguk.
Nagyfokú autonómia
A csapat nagyfokú bizalmat élvezett a Synergon menedzsmentjétől is. Csuti volt az, akinek tulajdonképpen ezt a bizalmat megelőlegezték, hiszen ő a (divízió)menedzsment része volt.
Az üzletágvezetőnk, Groszi, aki az összes fejlesztőnek a line managere volt, is inkább a háttérből követte az eseményeket, és nem akart nagy kontrollt gyakorolni a csapatra. Ez annak is köszönhető volt, hogy jó volt Groszival a kapcsolatunk, és ő is megbízott bennünk.
Mivel jó szakmai menedzsmentünk volt, ezért ők is tudták, hogy mi a legjobb egy szoftver terméket fejlesztő teamnek, és nem akartak mindenáron bele szólni a dolgokba, vagy éppen egyéb projekteket is a nyakunkba akasztani. Meg kell mondanom, hogy a Synergon – ami nem egy kis cég volt – stabilitása is szükséges volt ahhoz, hogy mi csak ezen a terméken dolgozhassunk évekig. Ez kis cégeknél általában nem valósítható meg, csak már akkor, ha sikeres a termék.
Amikor a bukott waterfall után mi elkezdtük az agilis termékfejlesztést, nem volt szigorú költségkontroll a csapaton. Ennek oka az volt, hogy a bukott waterfall projekt nagymértékű presztizsveszteséget helyezett kilátásba a Synergonnak, és a felsővezetés – a divízióvezetés javaslata és támogatása mellett – hagyta, hogy maximálisan előtérbe kerüljenek a szakmai szempontok, és a csapat alkosson.
Ennek a döntésnek a hátterébe én akkor nem láttam bele, mert “csak” fejlesztő voltam, de utólag úgy gondolom, hogy ez óriási bátorságról ad tanúbizonyságot mind a divízióvezetés mind a felsővezetés részéről. A két szint vezetése között akkor amúgy is volt egy feszült viszony, mert a Synergon abban az időben egy tranzíciós időszakot élt át a tulajdonosi kör megváltozása miatt, ezért ez még nagyobb szó.
Lehet mondani, hogy “végtelen büdzséből” könnyű sikeres projektet csinálni, de ez egyáltalán nem igaz. Egyrészt a waterfall projekten is rengeteg pénzt elköltöttek úgy, hogy az eredmény köszönőviszonyban sem volt az ügyfél elvárásaival. Tehát a pénz megléte nem garantálja a sikert.
Inkább azt emelném ki, hogy a projektszemléletben egy folyamatos költségkontrol akadályozta azt, hogy a projektben nyitott lehessen a beszállító (azaz a Synergon), ennek hiányában viszont lehetőség volt a domain rendes megismerésére, az üzleti folyamatok leképezésére, azaz a kísérletezésre.
A cégnek stratégiai érdeke is lehet bizonyos termékek fejlesztése annak ellenére, hogy az közvetlenül (még) nem termel nyereséget, és esetünkben ez volt a helyzet. Egyébként tervben volt, hogy az iratkezelőt máshová is eladja a Synergon a honvédségen kívül is, így került pár évvel később bevezetésre a katasztrófavédelemhez is.
Az iratkezelő sikertörténetének az volt az egyik kulcsa, hogy a legtöbb esetben volt lehetőségünk hosszútávú szempontok alapján meghozni a jelenben a döntéseinket. Mai kifejezéssel élve: termékszemléletben dolgoztunk, nem pedig projektszemléletben. Elegendőnek bizonyult menet közben az a nyomás, amit az ügyfél ránk rakott, hogy lássa, hogy rendben halad a történet, a menedzsment nem rakott ránk még pluszban rövidtávú teljesítménykényszert.
Hol van itt az agilitás?
Az iratkezelőt végül 1,5 év után kezdték el használni próba üzemben, és 2 év után élesben onnantól, hogy én bekerültem. Ennek a legfőbb oka a jogszabályi környezet volt, ami nem tette lehetővé, hogy bármikor használatba vegyék a rendszert, alapvetően csak naptári év elején lehetett. A jogszabályok “teljességet” vártak el funkcionalitás tekintetében, ami azt jelentette, hogy minden iratkezeléssel kapcsolatos folyamatnak benne kellett lennie a szoftverben. A rendszert külső szervezettel is tanúsíttatnunk kellett (Iratkezelési Felügyelet), hogy megfelel-e a jogszabályoknak, mert csak ilyen tanúsított iratkezelő szoftvert használhattak akkor és azóta is a közigazgatásban.
Valójában azért elég nagy mozgásterünk volt így is. Ugyanis az, hogy a jogszabálynak valami megfelel, az nem jelenti automatikusan azt, hogy az jó is az ügyfélnek. Sőt. Így amikor a product backlogot priorizáltuk nagyban építettünk arra is, hogy minél hamarabb megugorhassuk a jogszabályi kötelezettségeket, és emellett arra törekedtünk, hogy a következő naptári évtől bevezethető legyen a szoftver a kiválasztott szervezetben.
Ez a fajta “lassúság” (1,5 év az első release-hez?) a mai világban talán már nem tűnik túl kihívásosnak, így az a kérdés is joggal felmerül, hogy hol van ebben az agilitás? Hol van itt a változó környezet? Hol van a csapat/szervezet adaptibilitása?
Talán a környezet nem hozott olyan változásokat menet közben, amiket ne tudtunk volna könnyedén megugrani, de van egy olyan szempont, amit mindenki figyelmen kívül hagyott, és amire az agilitás volt a megoldás.
Mindenki, aki csak kapcsolatba került ezzel a projekttel (valójában termékkel), alábecsülte a fejlesztendő termék komplexitását. Volt egy gyilkos csapda a termékben, amibe többször is belefuttottunk, és ez volt az első waterfall projekt bukásának is az (egyik) oka. Nevezetesen pedig az, hogy a problématér nagyon bonyolult volt, annyira, hogy azt senki nem látta előre, még maga az ügyfél sem (ő nem értett a szoftverfejlesztéshez).
Ezért a csapat tanulását emelném ki az agilitásból, hogy képesek voltunk iteratíve megérteni a domaint, a problémateret, miközben magát a megoldást inkrementálisan szállítottuk, ami kulcsa volt a sikernek.
A hosszú ideig (kb. 1 év) tartó inkrementális szállítás eredményeképpen elkövetkezett egy olyan pont, amikor a domain átlátásában szintet léptünk, és újra kellett kezdenünk a szoftver fejlesztését. Amit addig csináltunk az kuka volt. Persze, a know-how maradt, és amit tudtunk a kódból, újrahasznosítottuk.
Ennek az újra implementálásnak kettős oka is volt: egyrészt az ügyfél meggondolta magát, és mégsem egy kis katonai szervezettel akarta kezdeni a bevezetést, hanem magában a minisztériumban, ahol a korábban lefejlesztett lineáris folyamat túl merevnek bizonyult, így a rendszert tovább kellett fejlesztenünk, hogy támogassa mindkét működést, ami funkcionalitásban egy nagyságrenddel bonyolultabb volt, és a korábban lefejlesztett szoftver ezt nem tudta volna kiszolgálni.
A második ok, ami miatt újra kezdtük, az a technológiai megvalósítás volt. A csapat nem látta előre azt, hogy nem ért az agilis teszteléshez, és az először megírt TDD tesztek karbantarthatatlanná válnak, ezért ezeket is újra kifejlesztettük. Szerencsére az üzleti változás miatt (máshol akarják bevezetni a szoftvert), nagy bátorsággal tudtunk ebbe beleugrani. Ez számomra megerősíti azt, hogy újraírni szoftvert nem szabad (csak pragmatikusan refaktorálni), kivéve akkor, ha a felhasználók többet is kapnak ennek eredményeképpen.
A következő elemekben mutatkozott meg még az agilitás a termék fejlesztése során:
- Az MVP szemlélet alkalmazhatatlan volt, mert sok olyan funkció volt, amelyeknek együtt is kellett tudniuk működnie, de azt előre nem tudtuk megmondani, hogy hogyan. Pl. érkeztetés során lehet hogy egy iratot egyből irattározni szükséges, és nem kerül be a szignálási folyamatba. Viszont irattározási funkciónk nem volt még. Szerencsére sikerült ezt sokszor leküzdeni, és igyekeztünk annyit szállítani, ami az addig meglévő funkcionalitáshoz elegendő volt. Emlékszem a mondásra, “azon a hídon majd akkor megyünk át, ha…”. Sok kérdésünk volt, hogy mi lesz akkor, ha …, de nem jöttek sehonnan a válaszok, ezért próbáltunk mindig a minimumnál maradni. Az extreme programmingből ismeretes KISS (Keep It Simple Stupid) elvet próbáltuk radikálisan alkalmazni, hogy minél hamarabb körbe érhessen a teljes rendszer, aminek fejlesztése így is 1 év körül volt, és mehessünk tanusíttatni, valamint ezt tudjuk aztán fokozatosan fejleszteni egészében.
- A folyamatos demó miatti 3 hetes timeboxing kezdetben és később is sorsfordító volt. Egyszerűen produktumot kellett létrehoznunk (potentially shippable product) minden iteráció végére, amit ráadásul az ügyfél is látott. Ez az elején elkerülhetetlen is volt az alacsony bizalmi szint miatt az ügyfél részéről.
- A komplexitást folyamatosan próbáltuk minden szinten csökkenteni: mindig is voltak “elszállt” ötletek mind szkópban, mind technológiailag, ezeket folyamatosan nyírbáltuk.
- Az ügyfél bevonása, az ő nyelvének használata szintén egy fontos agilis elem volt, ahogy már korábban említettem.
- A csapat felhatalmazása és csapatként is való működése szintén meghatározó volt. Közös cél megléte nem volt kérdés. Mondhatjuk, hogy tulajdonosi szemlélettel dolgoztak a csapatban az egyének, bár akkor még nem így hívták.
- Miután kiadtuk a szoftvert, és elindult a próbaüzem egy kisebb szervezetben (mégsem a minisztériumban kezdődött), nagyon gyorsan tudtunk javítani minden felmerült problémát. Azok az alapok, amiket kialakítottunk (alacsony technical debt, nagyfokú domain ismeret a csapatban), megfelelőnek bizonyultak. Voltak azért így is meglepetések, de tudtuk őket jól kezelni. A technológia és maga a megoldás is lényegében megfelelőnek bizonyult.
- A műszaki kiválóságra való törekvés szintén része volt a termékfejlesztésnek.
Műszaki kiválóságra való törekvés (csak az olvassa, akit érdekelnek a technológiai részletek)
Egy pár szót a technológiáról (2007-ről beszélünk, a pontos verziószámokra már nem emlékszem):
- Platform: Java, Spring
- Alkalmazásszerver: Jetty (tesztek futtatásánál), Tomcat (élesben)
- Skálázás technológia: Hazelcast (bizonyos funkciók esetén), amúgy Tomcat végezte a session replikációt (alapvetően nem tároltunk semmit sessionben, kivéve a login információt)
- Perzisztens réteg: Hibernate
- Adatbázis: MS SQL
- UI technológia: SmartClient (böngészőben futó fizetős, vastagkliens élményt adó JavaScript library),
- Fejlesztési módszertanok: POJO development, Domain Driven Design, Test Driven Design, Behaviour Driven Design, Continuous Integration
- Eszközök: IntellIJ Idea (csapat nagyobbik része), Eclipse (kisebbik része a csapatnak), Jenkins (először), TeamCity (később), OnTime (bugtracking szoftver, amikor már élesben voltunk), HP QC (manuális teszteléshez)
- Rendszerkörnyezet: brutál nagy fizikai vasakon futott a rendszer natívan konténer/VM nélül, Windows Server op.rendszer
Törekedtünk arra, hogy ún. “gazdag” domain modellünk (rich domain model) legyen (vö. anemic domain model). Így a domain modellt úgy igyekeztünk megvalósítani, hogy objektum-orientált legyen a megvalósítás, azaz az osztályokban legyen az üzleti logika (tehát nem csak buta DTO objektumok legyenek az osztályok, amiket különféle manager osztályok passzolgatnak és settelgetnek egymás között). Nagyon sokat kellett tanulnunk, mire eljutottunk oda, hogy ezt jól is tudjuk csinálni. Azt kell mondanom, hogy még a 3 év is kevés volt ahhoz, hogy ezt tökélyre fejlesszük.
A Hibernate összes nyűgjét megismertük. Rájöttünk, hogy nem lehet csak Hibernate-tel dolgozni a performanciaproblémák miatt élesben. Voltak olyan részek, amikre maradtak a kézzel fabrikált SQL-queryk, amikkel nincs is semmi baj. Az általános irányelv az volt, hogy az írási műveleteket (és az ehhez szükséges olvasásokat is) ORM-mel igyekeztünk megoldani, a tiszta lekérdezéseknél viszont, amikor riporting jellegű funkciókat kellett megvalósítani (tipikusan táblázatok megjelenítése), ott direktben írtunk SQL-queryket a lekérdezésekhez.
Megszállottak voltunk a TDD-vel, amit nem szigorúan test-first alapon közelített meg a csapat. Voltunk páran azért, akik sokat kísérleteztek azzal, hogy test-first legyen, de nem tudtuk mindig megcsinálni. Sokat fejlődtünk ebben, azt hiszem, 3 év alatt kialakult egy elég jó módszertan, amit más üzleti alkalmazások projektjében is sikerült mindenkinek továbbvinni. Később csatlakoztak újabb csapattagok, akiket én már nem ismertem, és utólag hallottam, mennyire rácsodálkoztak a megvalósítás magas színvonalára, amiből ők maguk is sokat tanultak.
A szemléletmódot a csapattagok későbbi munkahelyeikre továbbvitték, és ott is nagyban meghatározták a műszaki kultúrát, és ezek a módszerek a mai napig alkalmazhatóak, és meglepetésemre még mindig sok helyen nem művelik elég magas szinten őket.
A tesztelésre visszatérve azt kell mondanom, hogy nem hiszek a testing pyramid koncepciójában, és túlértékeltnek gondolom a unit-teszteket, mert a konkrét technológiák kimaradnak belőle, és az alkalmazás kódjának jelentős része nem implementálható csak a domain modell szintjén, és az értelmetlen agyonmockolás csak inverz implementációkhoz vezet a tesztkód szintjén, ami miatt duplán implementálódik a produkciós kód a tesztekben. A balansz a fontos a tesztek írásakor, és ebben minden projekt egyedi, hogy ezt hogy jó ott megvalósítani.
A tesztek írása művészet, nem mechanikusan végezhető droidmunka.
A refaktorálás tekintetében kompromisszummentesek voltunk, mondhatnám könyörtelenek (Clean Code). Ez segített abban, hogy a kód megőrizze a rugalmasságát, ahogy egyre jobban megismertük a domaint és az újabb és újabb fejlesztendő funkciókat.
Nagyon sokat szenvedtünk a CI-vel, hogy a tesztjeink rövid idő alatt fussanak. Nem tudtuk megugrani azt, hogy 10 perc alatt lefussanak a tesztjeink. Nem voltak UI tesztjeink (amit a mai napig zsákutcának tartok), és a tesztjeink 99.9%-ban stabilak voltak (nem voltak flaky tesztek).
A honvédségnél jó kapcsolatot ápoltunk az üzemeltetőkkel, akiket utólag képeztünk ki a rendszer üzemeltetésére. Védett hálózaton futott a szoftver, ezért nem volt lehetőség arra, hogy mi távolról hozzáférjünk. Vittük az USB-t és arról telepítettünk. Ha gond volt, a helyszínre kimentünk, és elemeztük közösen a logokat és a db-t.
Az iktató sikere és bukása
Ahogy említettem, az iratkezelő fejlesztésében 3 évig vettem részt, amit megelőzőtt egy másik, waterfall alapú megközelítés. Amíg én dolgoztam rajta, az iratkezelőt egy kisebb katonai szervezetnél bevezették, majd a katasztrófavédelemhez is bekerült.
Az iratkezelőnket végül pár évvel később felvásárolta egy konkurens cég, hogy a saját termékét bevezesse helyette, ennek a HM ellenállt.
A mi csapatunk agilisan működött, de a Synergonban nem terjedt tovább ennek a csapatnak a gyakorlata. Mondhatjuk, az agilis transzformáció nem folytatódott. Igaz, a Synergon kisebb részben foglalkozott csak szoftverfejlesztéssel, és abban az időben elindult a cég leépítése is. Azonban a tagokban mély élményt hagyott az iratkezelő agilis tapasztalata, és ezt mindenki vitte tovább magával a későbbi munkahelyeire, saját cégeibe.
Én 2010-ben elvégeztem a ScrumAlliance Scrum Master tréningjét is (egy rövid ideig SM-ként funkcionáltam a csapatban, amikor Csuti elhagyta a Synergont), de a 3 év agilis tapasztalat után ennek elvégzése már csak laza csuklómozdulat volt.
A mi példánk mutatja, hogy külső tanácsadó nélkül is lehet agilitást bevezetni, de ehhez kell elkötelezett menedzsment, csapat és scrum master, valamint ezek összehangoltsága is.
A cikk második részében azt taglalom, hogy milyen mélyebb okai voltak az iratkezelő termékfejlesztés sikerének, ami – véleményem szerint – a csapat sajátságos összetételében keresendő.