Pár hete megkeresett e-mailben egy személyzeti tanácsadó cég:

Kedves István,

egy álláslehetőségünket szeretném a figyelmébe ajánlani.

SCRUM mastert keresünk egyik ügyfelünk fejlesztő csapatába. Ebben a pozícióban is vannak fejlesztői feladatok, de a napi munka kb. 50 %-ban, a többi feladat más jellegű (meetingek szervezése, határidők figyelése, feladatok leosztása stb). A munka határozatlan időre szól, nem projekt jellegű.

A cég telekommunikációs hátterű nemzetközi, stabil háttérrel rendelkező cég és ebben a csoportban kifejezetten C++ fejlesztés folyik. Egy teljesen új termék/szoftver kifejlesztése a feladat, tehát nem meglévő termék karbantartása.

Amennyiben Önnek érdekes lehet vagy van olyan ismerőse, aki nyitott lenne a pozícióra, alábbi elérhetőségeim bármelyikén tudnak keresni, nagyon szívesen adok több információt a részletekről.

Vannak más pozícióink is egyébként, fejlesztőket, szakmai csoportvezetőket is keresünk (szintén határozatlan időre).

Köszönöm figyelmét, további kellemes napot,

üdvözlettel:

XY

Nem hagyhattam válasz nélkül a megkeresést, mert több szempontból is zavart a dolog.

Kedves XY!

Köszönöm a megkeresését! A pozíció jelenleg számomra nem aktuális (saját startup cégemnél dolgozom).

Jómagam kb. 6 éve napi szinten gyakorlom a Scrum keretrendszert, és más agilis és lean megközelítésű módszertanokat. Agilis szoftverfejlesztőnek tartom magam, és jelenleg CTO pozícióban dolgozom. Évekkel ezelőtt el is végeztem a Scrum Alliance ScrumMaster képzését, amelyről a nemzetközi szervezet által kiállított oklevéllel is rendelkezem. Több szektorban is szállítottam sikeres projekteket, mind hazai, mind nemzetközi környezetben (banki szektor, oktatás, telco, energiipar, gyártás, hadsereg …).

Engedje meg, hogy felhívjam a figyelmét pár dologra a pozícióval kapcsolatban.

A ScrumMaster szerepkört gyakran összekeverik a projektmenedzser szerepkörrel. A Scrum módszertan szerint a ScrumMaster egy olyan facilitator szerepkörre utal, amelynek a feladata nem a csapat számonkérése, hanem a csapat segítése/mentorálása a megvalósítás során felmerülő problémáknak a megoldásában/elhárításában, és hogy biztosítsa a Scrum által meghatározott folyamatok betartását – amelyet természetesen mindig az adott céghez, megrendelőhöz és megvalósító csapathoz kell illeszteni. A ScrumMaster leggyakoribb feladatai általában a következők szoktak lenni:

• segít a csapatnak a fejlődésben: hogy csapatként, hatékonyan tudjon működni, a csapattagok megbízzanak egymásban, tiszteljék egymást és a munkájukat,
• védi a csapatot a sprint közben előforduló külső behatásoktól, tipikusan a menedzsment és az ügyfelek által támasztott asap jellegű feladatok azonnali végrehajtásától,
• csökkenti a nyomást a csapaton, hogy nyugodt környezetben tudjon dolgozni,
• napi szinten felmerülő problémák megoldásában facilitálja a csapatot, hogy magától megoldja őket,
• napi szinten felmerülő problémákat, amit a csapat nem tud maga megoldani, megold (pl. az egyik csapattagnak új székre van szüksége, elintézi, hogy legyen neki),
• tanulási folyamatot alakít ki a csapattal (ezek formálisan a sprint végén esedékes retrospective-ekbe be is vannak építve),
• segít a csapaton belüli konfliktusok feloldásában, az eltérő vélemények kompromisszumos megoldásában,
• kialakítja a csapat szintű felelősséget: a csapat egyként tartozik felelőséggel a teljesítésért,
• hiányzó kompetenciák felismerése a csapaton belül, és ezek pótlása a menedzsmenttel együttműködve,
• szervezetfejlesztési feladatkör: a menedzsmentet és a csapatot felkészíti a Scrum, ill. agilis fejlesztésre, szállításra és szervezeti működésre.

A ScrumMasterrel a fentieket figyelembe véve a következő elvárások fogalmazhatóak meg:

• agilis coach/mentori attitűd,
• magas szintű empátia,
• jó kommunikáció- és diplomáciai készség (a csapattagokkal és a menedzsmenttel is),
• emberi tisztelet: ő is tiszteli a munkatársait, és őt is tisztelik,
• ismeri a szoftveres projektek jellegzetességet: magas fokú bizonytalanság, becslési pontatlanságok, emberi problémák, jellegzetes mérnöki problémák, kommunikációs félrecsúszások, és ezek kezelése,
• ismeri az agilis/lean szoftverfejlesztési (mérnöki) technikákat, elsősorban az Extreme Programmingben is alkalmazott módszereket (pl. Behaviour Driven Development, Domain Driven Development, Test Driven Development, Continuous Integration/Delivery).

Mivel a ScrumMaster egy facilitátor szerepkör, aki nem dönt a csapat helyett(, és nem is kéri számon az egyes embereket), nagyon fontos, hogy a ScrumMaster ne a megvalósító csapat tagja legyen.

Remélem, segíthettem abban, hogy a pozíció esetlegesen pontosításra kerülhessen, hogy ügyfelük számára a legalkalmasabb jelentkezőt találják meg. Ha véleményemet külön visszacsatolnák ügyfelükhöz, az talán még nagyobb haszonnal járhatna, hogy a menedzsment az elvárásait még jobban céljai megvalósításához tudja igazítani.

Blogomon fellelhetőek agilis fejlesztéssel kapcsolatos írások: http://infokukac.com

Ha segítségükre lehetek, tapasztalataim alapján szívesen válaszolok bármilyen kérdésre.

Üdvözlettel,
Marhefka István
http://be-novative.com
CTO

Szerintem ilyen egy ideális ScrumMaster. Ti mit gondoltok?

Az utóbbi másfél évben egy saját startupot építünk. A startupunk neve Be-novative, és célja, hogy globálisan lehetővé tegye a közösségi kreatív fejlesztést úgy, hogy közben egymást inspiráljuk és segítjük. (A fejlesztést tágabb értelemben gondoljuk, nem csupán a szoftverfejlesztésre összpontosítunk.)

A beharangozott prezentáció leírása:

Case study: be-novative, egy közösségi brainstorming platform technológiai stackje

Avagy hogyan alkalmazza egy start-up a legújabb szilícium völgyi trendeket egy magyar innovációban

A Java a közfelfogásban a nagyvállalati alkalmazások platformja, mégis vannak olyan nagy cégek (Amazon, Google, Yammer), akik ezt használják olyan piaci szolgáltatások megvalósítására, amelyek tömegek kiszolgálását végzik. Ugyan az elmúlt években a Java, mint nyelv fejlődése megtorpant, magának az ökoszisztémának a virágzása az Open Source közösségekben a mai napig zajlik.

Milyen szempontok alapján választotta a Be-novative a Java-t egy tömegeket kiszolgáló rendszer felépítéséhez? Hogyan lehet megbízható rendszert építeni pehelysúlyú Java alapú technológiákkal?

Kulcsszavak: Agile, Clean Code, Continuous Delivery, google-gson, Git, Google Guava, Google Guice, Hamcrest, IntelliJ IDEA, Jetty, Joda Time, Jsoup, Lean, Maven, Mockito, MongoDB, NoSQL, Servlet, Socket.io, Thumbnailator

Feltöltöttem a prezentációt, az előadás pedig megtekinthető a Youtube-on (köszönet Auth Gábornak a felvételért, a szervezőknek a jó hangulatú rendezényért és a Training360-nak a hely biztosításáért).

A JUM oldalán a további előadások is megtekinthetőek (Tamás Viktor: Devoxx 2012 élménybeszámoló, Ujhelyi Zoltán: Eclipse plug-in fejlesztés: lehetőségek és tapasztalatok).

A Facebookon elérhető a fejlesztői közösségünk, ahol követhetitek, milyen technológiákkal/módszerekkel kísérletezünk, mik kerülnek a látókörünkbe.

A cégnél, akiknek dolgozom, több csapat is azt a módszert alkalmazza, hogy a Continuous Integration eszközéből (Hudson/Jenkins ill. TeamCity) deployál a tesztkörnyezetekbe. Minden tesztelőnek van egy saját környezete, és mindegyik környezethez tartozik egy nyomógomb a CI eszközben. Ha a tesztelő megnyomja a környezetéhez tartozó gombot, akkor a CI eszköz deployálja az SVN trunkben lévő utolsó revisionhöz tartozó verziót a környezetébe.

A héten fültanúja voltam egy beszélgetésnek, ahol a cég vezetői fejlesztői beszélgettek. Az egyik vezető fejlesztő, akinek a csapatában nem alkalmazzák a fenti módszert, arról próbálta meggyőzni a többieket, hogy felesleges időtöltés azzal foglalkozni, hogy a tesztelő gombnyomásra tudjon telepíteni magának saját verziót. A tesztelő Putty-tyal belép a linuxos szerverre, majd elindít parancssorból egy szkriptet, ami leállítja a Tomcatet, előveszi a legújabb wart, bemásolja azt a Tomcat könyvtárába, és elindítja a Tomcatet. Az alkalmazás indulása során a tesztelő figyelje a logot, ha esetleg valami oknál fogva nem indulna el az alkalmazás.

A vezető fejlesztő azzal érvelt, hogy úgyis nézni kell, hogy van-e hiba a deploy folyamat során, és szerinte elfecsérelt idő lehetőséget biztosítani arra, hogy egy webes felületen kényelmesen gombnyomásra lehessen deployálni úgy, hogy ha hiba történik, akkor azt a felületen is jelezzük. Egyszerűbb belépni Putty-tyal, és figyelni a logot.

Végülis ha megnézzük, tényleg nincs sokról szó: egy bejelentkezés, egy parancssori futtatás és a napló figyelése. Nem?

NEM.

Automatizálás

A Continuous Delivery elv lényege röviden az, hogy a releaseadás, deployálása folyamata megbízható és bármikor megismételhető legyen. Ennek érdekében minden lépést, amit automatizálni lehet, automatizáljunk. Az okok egyszerűek: kevesebbszer fogunk hibázni (mert alig végzünk manuális műveletet) és gyorsabban is végzünk. Természetesen az automatizálásnak is van költsége, de a hosszú távú, több éves életciklusú termékfejlesztéseknél nehezen lehet vitatkozni azzal, hogy ezen automatizmusok kidolgozása, bevezetése ne hozná be a ráfordított időt/költséget. Ráadásul senki nem mondta, hogy elsőre tökéleteset kell alkotnunk, az automatizálást apró lépésekben, a hibákból tanulva, a projekt növekedésével párhuzamosan meg lehet alapozni, és soha nem késő vele foglalkozni.

Az alkalmazás logja általában egy szemét, sokszor nehezen lehet benne észrevenni fontos információkat. Miért a tesztelőnek kell figyelnie azt a naplóból, hogy sikeres volt-e a deployálás? (Odaültetném azt a fejlesztőt a logokat bányászni, aki ezt gondolja.) Nem lehetne a tesztelőt ettől tehermentesíteni? Másrészt, ha a tesztelőnél derül ki, hogy valami miatt nem indul el az alkalmazás, akkor úgy érzem, egy kicsit már késő. Minél hamarabb ki kell derülnie, hogy az alkalmazás nem indítható.

Amikor commitálunk, miért nincs egy automatikus smoke test is a unit teszteken kívül? Az automatizált szkriptünk deployálná az alkalmazást, bejelentkezne a felhasználói felületen keresztül, és lefuttatna egy alapfunkciót. Semmi bonyolult dolog, csak egy egyszerű, gyors teszt. A unit tesztek gyorsan lefutnak, egy smoke teszt is hamar lefuthat. Így meglesz az az előnyünk, hogy commit után pár percen belül visszajelzést kapunk (max. 5p), hogy az alkalmazásunkban nagyjából minden rendben. Nem szívnak a fejlesztők, tesztelők azzal, hogy a kódbázis éppen egy használhatatlan hulladék, ami blokkolja a munkát, mert az alkalmazást el sem lehet indítani. Ez kb. hasonló szintű probléma, mint az, hogy a kódbázis le se fordul.

Ha azonnali visszajelzést kapunk, a gyors korrekcióval a többieknél sem akad fenn a munka. A probléma orvoslása pedig akkor a leghatékonyabb, amikor éppen a hibát elkövettük. Ha pár órával később kell javítani, már nehezebben fogjuk tudni, mi okozhatta a gondot, és az se biztos, hogy egyből tudjuk majd, hogy ki követte el a hibát.

Absztrakció a szállítási folyamatban

Fejlesztőként szeretünk a kódban absztrahálni, az ismétlődéseket felismerve általánosítani. Ez része a szakmánknak. A duplikációk megszüntetésével karbantarthatóbbá válik a kódunk, kevesebb a copy/paste (másképp: editor inheritance J), ezáltal magasabb absztrakciós szintet érünk el nem csak a kódban, de a megoldandó probléma megértésében is. Ez a fajta absztrahálás nem csak a kódírásban, de a szállítási folyamatban is fontos.

Azzal, hogy felismerjük, hogy a gombnyomásra deployálás egy jó dolog, az igazolása annak, hogy jó irányba tartunk. Bennünk a vágy, hogy mindent egyszerűsítsünk, beleértve a teljes szállítási folyamatot. Ha gombnyomásra deployálunk tesztkörnyezetbe, akkor akár élesbe is telepíthetnénk gombnyomásra, nem? Mi akadályoz meg minket abban, hogy a committól kezdve az élesbe telepítésig valami megakasszon minket, és ne deployálhassunk élesbe naponta akár több tucatszor is? Ezt elérni persze nem egyszerű, de nem lehetetlen. De ha nem is érjük el (mert azért ezt a körülményeknek is támogatnia kell), törekedhetünk rá. És ez előnyére válik a projektnek, és a cégnek is, akiknek dolgozunk. A megrendelőről pedig nem is beszéltem még, aki a megbízható, automatizált szállítási folyamat révén stabil szoftvert kap, hatékonyan.

Coolság

Valakik, a Hudsonra szirénát vagy egyéb spéci eszközt kötnek. Ha a build elszáll, a szirénna villog és vijjog.

Nem cool?

Pár évvel ezelőtt a korábbi munkahelyemen Scrumot alkalmaztunk. A főnököm megkérdezte egyszer: “Nem lenne jobb valamilyen elektronikus eszköz, amin a feladatokat nyilvántartjátok? Nem kellene a fal, amire cetliket gyártotok, és nem kellene a falon a cetliket tologatni!”

A fizikai tábla azonban kézzel fogható. Bárki bejöhet a szobába, megnézheti, min dolgozik a csapat. Fejlesztőként büszke vagyok arra, hogy elkészültem egy feladattal, és a tábla következő oszlopába helyezhetem. A reggeli standupon a tesztelő kélyes mosollyal helyezheti át a tesztelés alatt álló cetlit a hiba oszlopba, ami arra készteti a fejlesztőt, hogy tanuljon a hibából, és legközelebb lehetőleg ne kövesse el azt még egyszer. A tábla a csapatot és a munkáját képviseli. Bárki, bármikor láthatja. Nincsenek titkok. Ha végzünk egy feladattal, felállunk a helyünkről, oda megyünk, áttoljuk a cetlit. Ezek vagyunk mi.

Nem cool?

Azzal, hogy fejlesztőként segítünk, hogy a tesztelőnek csak egy gombot kelljen megnyomnia, hogy deployáljon, megkönnyítjük a munkáját. Nem jó érzés azt mondani neki?: “Itt ez a gomb, nyomd meg, és egy-két percen belül kikerül a környezetbe a legújabb verzió”. Voltam ebben a helyzetben, büszke voltam arra, hogy megcsináltam, és segíthettem valakinek a munkáját. Hónapokkal később is használták a tesztelők a gombnyomásra történő deployálást, ez a napi folyamat természetes részévé vált.

Nem cool?

Konklúzió

Még az az egyszerű kérdés is, hogy egy tesztkörnyezetbe gombnyomással telepítsünk-e, vagy belépjünk-e inkább a távoli linuxos szerverre, és ott parancssorból deployáljuk-e az alkalmazást, miközben figyeljük a logot, hogy nem történt-e hiba, messzire vezet.

Hatékonyság, megbízhatóság, átláthatóság, egyszerűség. Ezek elérése, ill. az ezekre való törekvés belső motivációt teremt bennünk és a körülöttünk lévőkben, amitől szívesebben végezzük a munkánkat. A szakmai tökéletesség a cél.

Úgy gondolom, ezen elvek felismerése és érvényesítése része kell, hogy legyen professzionális attitűdünknek.

Pár év fejlesztés során a rendszerbe folyamatosan kerültek be az újabbnál újabb funkciók, amely egy iszonyúan komplex (vagy bonyolult?) rendszert eredményezett. Nagyon jól értettem az üzleti elvárásokat, azt is értettem, hogy ezek hátterében mi húzódik meg, és nagyon jól értettem a kódot, mert magam is aktívan fejlesztettem. Egy idő után az ügyfél által elvárt újabb funkciók komoly dilemmát jelentettek a szoftver továbbfejlesztésében. Ha lefejlesztjük az újabb funkciót, akkor az még bonyolultabbá teszi az eddigi modellt, amellyel az üzleti környezetet próbáltuk leképezni.

Legtöbbször ilyenkor egy fejlesztő cég próbálja lepattintja magáról a továbbfejlesztési (változáskezelési) igényeket, mert már nem képes kezelni a kódban fellépő komplexitást. Természetszerűleg mi is törekedtünk arra, hogy minél egyszerűbb megoldást vállaljunk be, de még így is sokszor nehézségekbe ütköztünk. Ekkor vetődött fel a gondolat:

Miért ne töröljünk régi kódokat, kódrészleteket, miért ne egyszerűsítsük őket, ha tudjuk, hogy nincs rájuk szükség?

Ha ezt nem tesszük, egyre csak lassítjuk a munkánkat, mert az új funkciók implementálása és a jelentkező hibák javítása egyre tovább tart.

De…

Sokszor próbálkoztunk azzal, hogy meglévő funkcionalitást kiirtsunk a kódból. Igen nehéz volt ez véghezvinni… Ha azonban sikerült, igen boldog voltam, mert sok részét gyakhattam ki a kódnak, amit nem sajnáltam, mert így sokkal egyszerűbb volt egy-egy új funkció kifejlesztése, és kisebb lett a kód.

Azonban sokszor a funkciómegszüntetés, -egyszerűsítés nehezen végig vihető:

• Szállítói oldalon: szerződésben, korábbi megbeszéléséken, írásos formában bevállaltuk, hogy megcsináljuk a funkciót, ezért nem lehet kivenni a kódból, amit már lefejlesztettünk. Ettől kezdve a saját menedzsmentünk nem támogatja a meglévő funkciók törlését.
• Terméket fejlesztünk, jól mutat a prospektusban az, hogy egy (haszontalan) funkciót nem csak a versenytársunk, de mi is implementáltunk (vagy éppen a versenytársunk nem tudja, de mi igen). Ez jó kis csali szokott lenni a potenciális ügyfelek előtt, akiknek az a célja, hogy minél többet tudjon a dobozos szoftver.
• Mit fognak szólni hozzá a konkrét felhasználók, ha elveszítenek egy funkciót? Ha megkérdezzük őket, akkor nem akarják, hogy egy “ilyen hasznos” funkció kikerüljön a rendszerből, mert ki tudja, mikor lehet rá szükség… Jó az, ha megvan…
• Se a megrendelő se a szálltító nem tudja, hogy a felhasználók pontosan hogyan is használják nap mint nap a rendszert, és milyen hatása lesz annak a napi folyamatokra, ha kiveszünk egy funkciót a rendszerből. Nem merik vállalni a kockázatot. (Nagy a felhasználószám, nagy a rendszer.)
• Maguk a szoftverfejlesztők látják azt, hogy mennyire bonyolult a kód, és mennyire nehezen tudnak már egy idő után újabb funkciókat implementálni. Azonban a fejlesztők nem is mernek abban gondolkodni, hogy kódot töröljenek a célból, hogy egyszerűsítsék azt. Nem értik, pontosan mik is a kód hátterében meghúzódó üzleti elvárások, döntések, ami miatt egy-egy kód elkészült, ezért nem is tudják felmérni, hogy egy adott kódrészletre valóban szükség van-e vagy sem, vagy akár lehetne-e egyszerűsíteni rajta. Ezt a helyzetet általában még tovább nehezíti az, hogy a kód nem érthető, és csak nehezen fejthető belőle vissza az eredeti üzleti szándék, elvárás.
• Automatizált tesztekkel nem támogatott Legacy code esetében nem is mernek hozzányúlni a meglévő kódhoz, nehogy elrontsanak vmi mást. (Szerencsére nálunk nem ez volt a helyzet.)

Arról áhítozunk sokszor, hogy a szoftverfejlesztésben létezzenek egzakt metrikák, amik mutatják, hogy jó-e vagy rossz, amit csinálunk. Ez itt is segítene, mert igazolhatná a menedzsmentnek és az ügyfélnek a funkciótörlés (-egyszerűsítés) jogosságát a költségmegtakarításon keresztül. De ilyenek sajnos nincsenek…

Nálunk nincsenek felesleges funkciók!

Vannak bizonyos felmérések, amik mutatják, hogy egy-egy rendszerben az egyes funkciók hány százalékát milyen gyakorisággal használják: “a rendszerek szolgáltatásainak 19%-ra ritkán, míg 45%-ra gyakorlatilag soha sincs szükségük.”

Egyesek talán úgy gondolhatják, hogy a saját projektjükre nem jellemző, hogy felesleges funkciók lennének benne, és arra is hivatkozhatnak, hogy régi a tanulmány, és az ő agilis projektjükben megvalósított funkciók kevéssé “feleslegesek”, mert végig prioritás szerint haladtak a megvalósítás közben. (Szemben a hagyományos, a “gonosz vízeséssel” fejlesztett szoftverekkel.) Én úgy gondolom, minden szoftverfejlesztési projektben, ahol van megrendelő, létezik a felesleges funkcionalitás jelensége:

• Szerződünk (mi szállítók) bizonyos funkciókra, amikről utólag kiderül, hogy a valós felhasználás szempontjából feleslegesek. Ennek oka az, hogy a megadott pénzért a megrendelő minél több funkciót akar beletömködni a szoftverbe, hogy a projekt zárása után biztonságban érezhesse magát, és ne kelljen állandóan a szállítóhoz fordulnia pluszmegrendelésért, ha valamire nem gondolt volna.
• Menet közben állandóan előfordul, hogy politikai okokból bevállalunk egy-egy funkciót. Ennek sokféle oka lehet, tipikus adok-kapok játék megrendelő és szállító között. (Jobb esetben már menet közben is tudjuk, hogy nem lesz a funkcióra szükség, és nem “csicsázzuk” túl.)
• Ugyan az ügyfél természetszerűleg a pénzéért minél több funkciót akar, azonban lehet ezt “ésszerűen” is csinálni, prioritások mentén, amely elvileg csökkenti a felesleges funkcionalitást. Azonban még így is előfordulhat, hogy legjobb szándékunk ellenére egyszerűen rosszul priorizálunk (tipikusan agilis projekt, termékfejlesztés esetében). Rosszul mértük fel a piaci igényeket, menet közben változtak a piaci igények, rosszul értettük meg a megrendelőt, esetleg ő maga sem tudta pontosan meghatározni a prioritást.
• A sikeres termékek hosszú évekig tartanak. Menet közben változhat az üzleti/jogszabályi környezet.

A lényeg, hogy felesleges funkcionalitást valósít meg a termékünk, ami növeli a termék komplexitását a kódban, ezáltal minden újabb funkció vagy hibajavítás megvalósítása drágább lesz (egyáltalán a hiba előfordulási valószínűsége is nagyobb). Arról nem is beszélve, hogy nemcsak kód szinten, de a funkcionalitás szintjén is komplikáltabb a szoftver, ami a felhasználók számára is bonyolulttá teszi a használatot, így több felhasználói tévedést, frusztrációt, hosszabb betanítási periódust eredményez.

Mi lenne, ha…?

Michael Feathers, a Working effectively with legacy code c. könyv szerzője felveti azt az ötletet, hogy mi lenne, ha éles környezetben mérhetnénk a kódlefedettséget: mi lenne ha valahogyan mérni tudnánk, hogy a kód egyes sorai milyen gyakran hívódnak az éles használat során? Ezáltal betekintést kapnánk abba, hogy milyen kockázattal járhat a kód egyes részeinek módosítása, és ez valójában egy indikátor is lehetne, hogy mely kódrészletek, funkcionalitások azok, amelyek a valóságban nem használtak. Ezáltal tudatosan irthatnánk a haszontalan funkciókat.

Feathers mostanában megjelent egy másik cikke, még sokkal izgalmasabb. Egy érdekes gondolatkísérletettel kacérkodik: mi lenne, ha minden kódsor, ami implementálásra került, három hónap elteltével eltűnne a kódbázisból? Ennek több hozománya is lenne. Egyrészt a fejlesztők a már meglévő funkciókat sokkal célravezetőbben, és valószínűleg jobban érthetőbben is implementálnák. Ennek oka az, hogy már ismerték a korábbi kódot, vannak tapasztalataik a rendszer korábbi implementációjáról és a már megvalósított funkcionalitás valódi üzleti felhasználásáról is. Az egyes újraírásokat egyre hatékonyabban végeznék el ezen információk birtokában, ami a kód felépítésében egy egyszerűbb rendszert eredményezne. (Tudják, hogy pontosan mire van szüksége a felhasználóknak, és megtanulják, hogyan lehet azt a legjobban, legegyszerűbben implementálni.) Amit viszont még fontosabbnak tart Feathers az az, hogy ez a fajta metodika komoly komprosszimukra kényszerítené az üzletet a funkcionalitás viszonylatában. Amiatt, hogy kevés funkciót tarthat meg (mert az implementált kód úgyis eltűnik 3 hónap után), komolyan végig kell gondolnia, hogy mik maradjanak meg, hogy azokra valóban szüksége van-e. Feathers azt gyanítja, hogy hosszú távon az ilyen módon fejlesztett szoftver költség szempontból sokkal kedvezőbb, mert a feleslegesen és/vagy rosszul implementált kód cipelése jelentős költséget képvisel, amellyel jelenleg senki nem számol.

A jövő a bátraké

Feathers szerint azon (szoftverfejlesztő) cégek nyernek a jövőben, akik felismerik, hogy hogyan lehet stratégialiag a termékeikből kódot törölni. A költséghatékonyság egyik módja már eleve az, ha nem fejlesztünk ki nem profitábilis funkciókat, a következő lépes azonban az, hogy hogyan irtsunk ki gyökerestől funkciókat a kódból. A kódcipelés költsége több, mint gondolnánk, és ez kompetitív előnyt jelenthet számunkra.

A könyv a Scrum és a Kanban módszerek egyik legjobb összefoglalását adja. Mindenkinek ajánljuk, akik az agilis projektvezetési módszertanok iránt érdeklődik akár megrendelői vagy szoftverfejlesztői oldalon, ezen belül is üzleti elemző, projektmenedzser, fejlesztő vagy akár tesztelő szerepkörben.

A könyv eredeti verziója – az azóta több nyelven is elkészült fordításokkal – elérhető az infoq oldalán.

Ketten dolgoztunk ennek a provokatív, figyelemfelkeltő álláshirdetésnek az elkészítésében. Pont ez a provokáció volt az, ami nekem tetszett az egészben. A cég vezetőségében viszont úgy döntöttek, hogy finomítanak az eredeti megfogalmazásunkon, és a szövegben fellelhető “vadhajtásokat” lenyesegetik. Az egyik mondat, amelyikre a legbüszkébb voltam (és akár egy buddhista tanításnak is beillene), végül kikerült a végleges szövegből:

A jó szoftverfejlesztő nem lepődik meg azon, ha állandóan “változnak a követelmények”, mert tudja, hogy valójában azok nincsenek is, mert egyetlen cél létezik csupán: a végén jó szoftvert előállítani.

Egy új szoftverfejlesztési projekt a követelményfelméréssel szokott kezdődni. Csutorás Zoltán írt arról egy igen elgondolkodtató cikket, hogy a követelményeket célszerű inkább elvárásokként tekinteni. Ugyanis:

“[…] a követelmények részben a környezeti kényszerek, részben a megrendelők adott pillanatban, adott információk alapján kialakított elvárásainak rögzített leképezése. A gond az, hogy ezek mind változnak. […] A megrendelőt […] nem érdeklik a követelmények. A megrendelőnek elvárásai vannak, amiknek megfelelő rendszert akar látni. Az üzleti megrendelő szemében a követelmény csak egy szükséges rossz, amibe az előzetes követelményspecifikáción alapuló fejlesztési kultúra belekényszeríti a tervezhetőség látszatának fenntartása érdekében.”

Mi köze van ennek az egésznek egy szoftverfejlesztőhöz?

Nagyon is sok. Sok helyen a szoftverfejlesztőket (vagy szofverfejlesztő cégeket) droidként kezelik. Átadják nekik a követelményeket: “Tessék, ezt kell megcsinálni!”. A szoftverfejlesztők pedig engedelmeskednek. Eszükbe sem jut, hogy valójában a követelménylistában megfogalmazott egyes tételek hátterében mi húzódhat. Mennyi mindent nem érdemes megcsinálni belőle, mennyi mindent lehetne másképpen, jobban csinálni. A határidő szorításában szolgaian lefejlesztik valahogyan a benne felsorolt funkciókat, eredményezzen az bármilyen szoftvert.

A nagyobbik baj, hogy a szoftverfejlesztők el is hiszik magukról, hogy nekik ez a feladatuk. Pedig ennél lehetne jobban is csinálni. Ha hagynánk, hogy a szoftverfejlesztők megértsék a követelmények mögött rejtőző elvárásokat, megérthetnék, hogy a megrendelőnek mi a valódi célja rendszerrel, és így sokkal jobb szoftvert tudnának szállítani. A szoftverfejlesztőktől érkező visszajelzéseket vissza lehetne csatolni a megrendelő felé, akivel egyeztetve revidiálni lehetne a korábbi elképzeléseket.

A szoftverfejlesztők (szoftverfejlesztő cégek) sok projektet csináltak már végig, sok esetben projektről projektre egy-egy újabb és újabb szakmát elsajátítva. Nem csak kódot írnak, hanem ők azok, akik tudják, mik egy fejlesztés buktatói, hogyan érdemes és nem érdemes dolgozni. Kár lenne ezt a lehetőséget kihagyni…

Amikor úgy fogalmaztam, egy jó szoftverfejlesztő tudja azt, hogy változó követelmények valójában nincsenek is, a valódi cél pedig a jó szoftver előállítása, akkor arra gondoltam, hogy a jó szoftverfejlesztő nem foglalkozik azzal, amit éppen követelményként rázúdítanak. Tudja, hogy ezen követelmények egy hibás fejlesztési folyamatnak, módszertannak az eredménye, és azon sem lepődik meg, ha ezen követelmények változnak.

A követelmények buta követése helyett a jó szoftverfejlesztő mindig megkérdőjelezi, amit mondanak neki. Folyamatosan ezen kérdések pörögnek a fejében: “De miért?”, “És mi lenne, ha…?”. Meg akarja érteni, hogy hogyan alakult ki egy képtelen szituáció, és abból megpróbál segíteni kitörni. A korábbi tapasztalatai alapján tudja, hogy nem szabad elfogadnia semmilyen helyzetet. Ha érzi, hogy tud egy jobb megoldást, akkor azt nem szabad magában tartania.

Félreértés ne essék, nem arról van szó, hogy a jó szoftverfejlesztő egy rendszeren kívüli elem, aki önkényesen felülbírál és kritizál minden korábbi döntést. Csupán arról van szó, hogy képes arra, hogy korábban megszerzett tapasztalatából adódóan hangot adjon véleményének, és ezzel segít cégénék, ill. a megrendelőnek abban, hogy végül egy jó (jobb) szoftver készülhessen.

Ha pályakezdő vagy, szeretsz Javában szoftvert fejleszteni, és kíváncsi vagy arra, hogy mit gondol munkádról a szakmai zsűri, mindenképpen ajánlom, próbáld ki magad!

A célunk, hogy egy viszonylag egyszerű feladat megvalósításával hívjuk versenybe az érdeklődőket, és a legjobbakkal hosszátávú együttműködést alakítsunk ki.

Nem kell hosszú hetekig “reszelni”, inkább azt teszteljük, hogy hogyan készíted el az alkalmazást.

A feladatot pár héten belül publikáljuk, további részletekről keresd a verseny honlapját: http://legjobbfejleszto.com

Ahogy telnek az évek, és egyre idősebbé válik az ember, annál többet nosztalgiázik. “Bezzeg az én időmben!” – hangzik a sokat nem érő kijelentés.

SOA, SOAP, BPEL, Workflow, Design Patterns, EJB, GUI-technológiák, cluster, mindenféle alkalmazásszerverek. Folytathatnám a sort. Nincs jó kedvem, amikor rájuk gondolok. Bezzeg, amikor még Turbo Pascalban írtam az alkalmazásokat, és assembly-betétekkel interruptokat hívtam! Saját MOD-lejátszó. Azok voltak ám a szép idők! A BGI-driverrekkel én magam rajzoltam a Hercules monitorra, és mindig tudtam, hogy mi történik… CTRL-F9: fut a program!

Ma már nem így van. Elindítjuk az IDE-t, össze-vissza klikkelünk, generáljuk a forráskódokat, írjuk a build-szkripteket, és nem is tudjuk, pontosan mi is történik. És szívunk. Kétes technológiákat integrálunk, amik annyira absztraktak, és persze, “mindenre” jók!

Magával ránt a környezetünk. A menedzsment és a tanácsadók azt szajkózzák: “Portál alá fejlesszünk! JSR-168, ez a tuti! Ide workflow kell meg SOA! Ez most a király!”

Az Oracle meg a Microsoft meg jön a világmegváltó technológiáival. Fusion Middleware, Workflow foundation. KIT ÉRDEKEL?!

Már meg is fájdult a fejem.

Szoftverfejlesztőként egyet szeretnék: jó szoftvert írni, amivel az ügyfél elégedett.

A mai világban két dolognak örülök: a gazdasági világválságnak (jelentsen is bármit) és az értelmetlenül rövid határidőknek. Megmondom, miért. Mert rákényszerít minket arra, hogy értelmesen dolgozzunk.

… hogy pehelykönnyű alkalmazásokat írjunk, amik mentesek a technológia függőségektől… hogy megértsük a valódi igényeket, és ne erőltessünk rá használhatatlan szupermegoldásokat az ügyfélre, amitől ő boldogtalan lesz.

…és hogy e közben – saját magunk örömére is – értéket teremthessünk…

2010. szeptember 23-25. között kerül megrendezésre Prágában Közép-Európa legnagyobb webbel foglalkozó konferenciája a WebExpo 2010. Fókuszban a webfejlesztés, design, az internetes businessek és az agilis szoftverfejlesztés.

A jelentkezés díj augusztus 31-ig 160 EUR, utána 200 EUR. (Diákoknak 80 ill. 120 EUR.) Részletek a rendezvény oldalán, a http://webexpo.net címen. A program folyamatosan bővül, ezért érdemes vissza-vissza tekinteni az oldalra.

Ajánlom mindenkinek, aki szeretne találkozni a téma legjobbjaival a gyönyörű Prágában!