Szakmaiság, empátia és költséghatékonyság – talán leginkább e három elemben ragadható meg az a plusz, amelyet a BlackBelt csapata nyújtott, amikor az Avon hitelvizsgálati monitoring rendszerét korszerűsítette.

Adott egy nemzetközi kozmetikai nagyvállalat, amelynek régiós IT bázisa Budapesten van. Adott továbbá egy vállalatirányítási rendszer, amelynek egyik funkciója két, a régióhoz tartozó mediterrán országban is enyhén szólva idejétmúlt. Mit jelent ez? Azt, hogy ha egy ottani ügyfél a rendelésének státuszáról érdeklődött, vagy tudni szerette volna, belefér-e a hitelkeretébe, akkor a cég munkatársaitól csak meglehetősen nehézkes körülmények között kapott információt. Pontosan válaszoltak ugyan a kérdésére, ám ehhez egy klasszikus fekete képernyőn zöld és fehér betű- és számtengeren kellett átevezniük, jellemzően két-három billentyű együttes lenyomásával.

A vállalatnál így aztán néhány éve gondoltak egyet, és úgy határoztak: korszerűsítik az említett két országban a megrendelések hitelvizsgálatának monitoring rendszerét annak érdekében, hogy az özönvíz előtti képernyő helyett testreszabott, felhasználóbarát felületről, egér segítségével juthassanak információhoz a kollégák. Hogy a User Experience valóban élményszámba menjen.

KŐMŰVESEK HELYETT

„Három potenciális jelölt közül választottuk ki a BlackBeltet. Már hosszú évek óta együtt dolgoztunk: üzleti elemző, rendszerfejlesztő, tesztelő, projektvezető kompetenciákkal segítenek bennünket. Azért kerestük meg őket e megoldáskeresés kapcsán is, mert úgy gondoltuk: az a minőség és tudás, amit számunkra ekkor már jó ideje nyújtottak, komoly értéket képvisel és valószínűleg ezt máshol is tudnánk kamatoztatni” – idézi fel Murvai-Buzogány László, a vállalat IT termékfejlesztési vezetője. Mint mondja, addig elsősorban tudást vásároltak a BlackBelttől, most úgy gondolták, hogy magát a teljes szolgáltatást is tőlük szeretnék megkapni. „Amikor tudást kölcsönzünk, az olyan, mintha kérnénk két ácsot meg három kőművest és megmondanánk nekik, hova rakják a téglát, és hova kerüljön a tetőszerkezet. Ám amikor szolgáltatást vásárlunk, akkor generál kivitelezőt várunk. Olyasvalakit, aki e kérdésekre önállóan tud válaszolni, majd elmegy a tervezőhöz és egyeztet vele anélkül, hogy a részletekbe minket bevonna. Lényegében elfedi ennek az egész folyamatnak a komplexitását. Mi a BlackBeltet választottuk ki generálkivitelezőnek, és 2016 nyarán elkezdődött a munka.”

A megbízás tehát így szólt: készítsenek egy a megrendelések hitelvizsgálatának monitoring rendszerének támogatására szolgáló adminisztrációs felületet. Olyat, amelyen az illetékes ügyfélszolgálati munkatárs meg tudja nézni, hogy a hitelértékelés milyen paraméterek mentén történt, milyen eredményt hozott, és adott esetben ezt az eredményt módosítani is engedi, rögzítve, hogy ki és mikor hozta meg az ehhez kapcsolódó üzleti döntést.

KÉZ A KÉZBEN

A munka két fázisban zajlott: a felmérést a tervezés szakasza követte. Előbbi alapozta meg az egész fejlesztési folyamatot, és ügyfélinterjúk formájában történt. A BlackBelt munkatársai arra keresték a választ, miképpen néznek ki a folyamatok, mi az a támogatás, amit a meglévő felület nyújt az ügyfél vállalatánál dolgozók számára, és mit szeretnének ezen felül. Az időkeret miatt elég jól kellett sáfárkodni azzal, hogy mit melyik fázisban valósítanak meg. Lefolytatták ezeket az egyeztetéseket, megtervezték a projekt szakaszait, majd elkészítették azokat a képernyőterveket, amelyek ábrázolták, hogyan is néz majd ki ez az üzleti rendszer. Azaz – a korábbi példánál maradva –, megtervezték az épület alaprajzát, majd a tervekkel visszamentek a majdani rendszer felhasználóihoz. A következő interjúban megtörtént az ellenőrzés, a tervek validációja, a módosítási kérések azonosítása. Egy vizuális ellenőrzés és véglegesítés után pedig átléptek a megvalósítási fázisba.

Hibrid együttműködést kell elképzelni: a felhasználói felületet a BlackBelt készítette, a mögötte lévő adatmódosító programokat, interface-eket – amelyek specifikus és lokális tudást igényeltek – pedig a megbízó.  E fázisban értelemszerűen rendkívül erős volt az együttműködés. A folyamatos egyeztetések révén nagyon hamar sikerült egy olyan kooperációs modellt kialakítani, ami lényegében minimálisra szorította a személyes kommunikáció szükségességét. Ezt többnyire telefonon és e-mailben intézték. „Ehhez egy olyan eszközrendszert is javasolt a BlackBelt, amit azóta is aktívan használunk. Számomra emellett lenyűgöző volt, hogy csak nagyon keveset kellett utólag módosítani az elkészült elemeken. Hamar eljutottunk egy olyan pontra, ahol az az elvárt működés, amiben megegyeztünk, megvalósult.”

Ez részben az agilis metódusnak, részben a felmérés-elemzés fázis alaposságának volt köszönhető. Nagyon lényeges, hogy itt a felhasználó agyával kellett gondolkozni, és megalkotni egyfajta élményszerűséget színekkel, formákkal, működési módozatokkal. Logikus, kézre eső, ergonomikus és kényelmes felhasználást szeretett volna az ügyfél és ezt az egyensúlyt sikerült jól eltalálni az elemzés-tervezésben. A vezérfonalon, amit együtt lefektettek, nem kellett módosítani, és folyamatosan pozitív visszajelzések érkeztek az eredmény kapcsán.

BÜDZSÉN BELÜL

„Amiért javaslom a BlackBeltet, az elsősorban talán az a fajta rugalmasság, kitüntetett figyelem és szakmai tudás, amit kaptunk tőlük. És a tervezés során tanúsított empatikus készség: a BlackBelt szakmai csapata igenis bement a probléma közepébe, megértette azt. Nem sablonos tervet, megoldást szerettek volna nekünk leszállítani, amit esetleg valamelyikük már látott máshol működni. Márpedig itt nekünk kell az az érzés, hogy valami egyedit kaptunk, hogy ez egy vállalatspecifikus eredmény, felület. Ezt sikerült megfogni és a visszacsatolások alapján ugyanezt érzik a felhasználók is. Nem utolsósorban pedig IT projektre nem jellemzően bőven a tervezett büdzsén belül fejeztük be a projektet! Bízom benne, hogy a későbbiekben is tovább tudjuk vinni e megközelítést. Hiszen a BlackBelttel máris tervezzük a következő együttműködést.”

Szeret vásárolni? A nők zöme e kérdésre vélhetőleg igennel felel, a férfiak esetében talán árnyaltabb a válasz. Az azonban bizonyos: az online shoppingolás lehetősége mindkét nem számára megkönnyíti az életet. A hétköznapokon is, ám a karácsony közeledtével főleg. Jószerével nincs olyan ajándékötlet, amelyet pár kattintással ne lehetne valóra váltani.

Ám elgondolkodtak már azon, milyen mértékű professzionalitást és kapacitást kíván meg mindez informatikai szempontból? Az, hogy a webshopok akciók ideje alatt vagy más, turbulens időszakokban zavartalanul üzemeljenek, ma már természetes elvárásunk, ám jó pár éve még korántsem volt magától értetődő, hogy egy félnapos netes kuponakció okozta roham nyomán nem fagy le az egész weboldal.

Mára ez a kérdés viszonylag egyszerűen megoldhatóvá vált.

A szakemberek ugyanis választ találtak arra a kérdésre, miképpen lehet számítógépes rendszerek teljesítményét minél kevesebb emberi interakcióval, terheléshez alkalmazkodóan, dinamikussá tenni. Régen szakítottak már azzal a koncepcióval, amely egy óriási, erős computer építésével igyekezett nagy teljesítményt elérni – ezt vertikális skálázásnak nevezzük –, hiszen egy idő után azt már nem lehetett tovább erősíteni, kapacitása korlátozott volt, gazdaságilag nem érte meg. Ehelyett az erőforrások optimális kihasználása érdekében sok hétköznapi számítógép teljesítményét adják össze. Utóbbi megoldás – a horizontális skálázás – olcsóbb és rugalmasabb megoldást biztosít.

E módszer a konténerizáció technológia révén is kihasználható.

Ez azt jelenti, hogy a különböző alkalmazások egységes módon, „csomagban” kezelhetők. Azokat konténerben szállítják, magukat a konténereket pedig egy erre kitalált platform futtatja. A fejlesztő az elkészített programot beteszi tehát egy konténerbe: a sok kis gépből összeállított klasztert – ezt a „végtelenül” skálázható erőforráshalmazt – csupán arra kell fölkészíteni, hogy konténereket tudjon futtatni.

Miért forradalmi a konténerizáció megjelenése? Mert míg a hagyományos virtualizáció alatt hosszú percekig tart, míg egy virtuális gép elindul, a konténerizáció révén mindez milliszekundumok kérdése. Képzeljük el, hogy mondjuk egy karácsonyi akció indulásakor, amikor plusz 100 ezer felhasználó özönlik a webshopba és kezd el vásárolni, mekkora mértékben ugrik meg a teljesítményigény. A hagyományos, régi eszközök korában ilyenkor a rendszergazda kapott egy piros lámpát, majd elkezdte bekapcsolgatni az új gépeket. Várni kellett. A látogatók meg gutaütést kaptak a hibaüzenetektől. A konténerizáció jóvoltából a vásárlók mindebből ma már semmit nem érzékelnek: automatizált az egész folyamat. Szenzor figyeli a leterheltséget, és a küszöbérték elérésekor újabb erőforrásokat von be. Emberi beavatkozás nélkül adaptálódik a rendszer a teljesítményigényekhez.

A konténerizáció és a horizontális skálázás egyik lehetséges támogató eszközét a Google pár éve nyílt forrású szoftverré tette. Fejlesztéséhez programozók ezrei szabadidejükben, non-profit módon járulnak hozzá.

A neve: Kubernetes.

A görög szó – amelyből egyébként a kibernetika is származik – kormányost jelent. Az ókorban a tengerészeknek merészségre, leleményre volt szükségük: térkép és navigációs eszközök nélkül hajózva folyamatosan önálló gondolkodásra kényszerültek. Vélhetően így tettek kései örököseik, azok az informatikusok is, akik a Google-nél néhány éve megalkották ezt a fejlesztés gyorsítására és a műveletek egyszerűsítésre használható konténermenedzsment-eszközt. Használata révén a szoftverfejlesztőknek kevesebbet kell az infrastruktúra menedzselésével bíbelődniük, több idő marad az alkalmazások fejlesztésére.

Erre szükség is van.

Ma már egyre több webshop hirdet meg pár órás akciókat, amikor brutálisan alacsony áron lehet a termékeikhez jutni. Ilyenkor néhány órára a korábbi sokszorosára duzzad a forgalom. Nem lehet tudni, hogy a technológiai háttér elérhetősége indukálta e kampányokat, vagy az igény nyomán lendültek bele a fejlesztők a munkába, de tény, hogy manapság nem jelent gondot a technológiai háttér biztosítása az efféle „rohamok” idejére.

A háttérben pedig az történik, hogy a fejlesztő jelzi a Kubernetes felé, hogy egy bizonyos alkalmazásból fusson – mondjuk – minimum három, maximum tíz, a forgalom alakulásától függően. A rendszer pedig automatikusan eldönti, hogy a száz gépből álló pool-ból melyik gépen futnak majd az alkalmazások.

A fejlesztők pedig mindeközben levegőhöz jutnak. Ezt ki is használják.

Sokan éppen arra, hogy az ilyen jellegű eszközöket tovább fejlesszék.

 

(A cikk 2. része itt olvasható)

Kipattan egy jó üzleti ötlet. Jönnek a társak, s a latolgatás: versenyképes lesz-e az elgondolás. A potenciális befektetőnek azonban pár mutatós dia a jövőképről, stratégiáról nem elég. Ám hogyan lehetne a lehető legszínvonalasabban bemutatni a prototípust? Wolf András, a BlackBelt Technology értékesítési igazgatója a kihelyezett termékfejlesztést (outsourced product development) ajánlja.

„Mi akkor jövünk a képbe, ha a színes-szagos, már meglévő honlap nem elég és működő technológiai megoldásra, alkalmazásra van szükség” – hangsúlyozza a szakember.

Céljuk, hogy egy kezdő vállalkozást már a legelején a legmegfelelőbb, az adott cégre szabott technológiával indítsanak el. Ne kelljen hajmeresztő összegeket kidobni akkor, ha történetesen egy kockázati tőkésnek vagy üzleti angyalnak kell bemutatni termékének, szolgáltatásának egy már működő prototípusát. „Már akkor elkezdjük a munkát, amikor egy startupnak még csak pár ügyfele van, és együtt megyünk velük egészen a többezres kliensszámig. Egy kezdő cég nem tudná magától így felskálázni a kapacitásait, márpedig ez egy rejtett műszaki kockázatot jelent. Szolgáltatásunk tehát afféle biztosítás a kisvállalkozások és befektetőik számára is.”

Sokan „okosban” próbálják ezt megoldani: gyorsan fejlesztenek valamit a prezentációra, ám minthogy menet közben a startup és az ötlet is módosul, kikristályosodik, e kezdeti rendszerek általában a kukában landolnak. „Mi ellenben egy stabil, cég specifikus, egyedi műszaki környezetet alkotunk, amely alkalmas a módosításra, modellezésre, akár új prototípus létrehozására. Ettől időtálló és hosszútávon működő a megoldásunk”.

Szerverparkok helyett

Nagyon lényeges elem, hogy ezek nem a startup cégek saját szerverén futnak, hanem egy webes központi rendszeren keresztül, amely felhő alapú, s azokra jellemzően weboldalon keresztül lehet regisztrálni. E megoldás skálázható, azaz a szolgáltató által nyújtott szint szabadon alakítható a cég ügyfeleinek számától, kihasználtságtól függően. „A lokális hardverrel rengeteg probléma van, és jellemzően néhány év alatt elavul. Szakembereink ezzel szemben felhőbe költöztetik az alkalmazást, és azt méretben folyamatosan optimalizálják. A különbség havonta komoly összegekben mérhető”. A BlackBeltnél távoli eléréssel dolgoznak; a legprofesszionálisabb hazai és nemzetközi felhőszolgáltatókkal állnak kapcsolatban, őket ajánlják ügyfeleiknek. Segítenek az időtálló és megfizethető technológia kiválasztásában.

Ügyfeleiknek saját fejlesztésű JUDO platformjuk mellé konzultációt (ún. DEVOPS tanácsadást) is biztosítanak. Együtt gondolkoznak klienseikkel, fejlesztéseik a termékfejlesztés életciklusát is követik, vezérlik.

Problémák helyett rendszerek

Szakmai rutin és jelentős megtakarítás – e kettőt garantálja a BlackBelt. Mindehhez nincs szükség nehézkes tárgyalásokra, találkozókra. „Szükség esetén videokonferenciákon egyeztetünk, ha pedig azt kéri az ügyfél, akkor a teljes megoldást üzemeltetéssel átadjuk számára. Be tud jelentkezni azokba a szerverekbe, ahol fut az alkalmazása. Ha ellenben úgy dönt, hogy ránk bízza az üzemeltetést, azt is vállaljuk. A lényeg: problémákkal keresnek meg bennünket, az együttműködésünk végén pedig létrejön egy új és egyedi rendszer”.

Számos szektorban dolgoztak már a telekomtól a pénzügyin, kiskereskedelmin át a logisztikáig és az orvos technológiáig. Nemcsak magyar, de nyugati piacokra is fejlesztenek. „Azáltal, hogy sok iparágban működünk, változatos üzleti problémákkal találkozunk. Mi ezeknek vagyunk a specialistái. Olyan helyzetekre keresünk megoldást, amelyeket korábban még senki nem orvosolt.”

A BlackBelt a fiókban lapuló üzleti ötletek megvalósításában is segít. Melyik cég ne ismerné a problémát, ami abból fakad, hogy a menet közben felmerülő innovációk idő és erőforrás hiányában évekig kallódnak, és sok esetben végleg el is felejtődnek? Minthogy a fő tevékenység hozza a bevételt, onnan nem lehet forrásokat átcsoportosítani. Wolf András csapata azonban vállalja, hogy e terveket valóra váltja. Közben pedig – minthogy ők hangsúlyozottan csak a technológiai oldalt ismerik és képviselik professzionálisan – az üzleti ötlet is biztonságban van. „Nálunk jó kezekben vannak a megvalósítandó üzleti elképzelések. A saját iparágunkhoz értünk, más cégek ötleteinek piacképességét nem tisztünk megítélni, így azzal nem foglalkozunk. Elkötelezettek vagyunk azonban a régóta dédelgetett tervek technológiai megvalósításában. Ügyfeleink hosszú távú, megbízható partnerei szeretnénk lenni.”

 

Látott ön már rögbi meccset? Akkor biztosan megvan a jelenet, amikor a támadók egymással szemben, összekapaszkodva, előrenyomással igyekeznek megszerezni az oldalról bedobott labdát. Ez a tolongás vagy viaskodás, angolul scrum.

Az agilis metódus egyik, talán legnépszerűbb módszertana is ezt a nevet kapta, vélhetően arra utalva, hogy a (fejlesztő) csapat tagjai egymással itt is szoros együttműködésben küzdenek a sikerért. Mindenkinek mindenkivel össze kell dolgoznia – ebből adódnak a scrum előnyei: a folyamatos egyeztetések, iterációk, melynek révén az ügyfelek néhány hetente rálátnak a projektre, és azt módosítani, pontosítani tudják. Az eredménnyel nem a projekt végén találkoznak, hanem már menet közben.

A módszer nyilvánvaló előnyei dacára azonban sok cégnél még mindig tartanak az egyeztetések következtében menet közben módosuló büdzsétől.

Pedig a költségek kontrollálhatóak.

Mégpedig a következőképpen: adott egy specifikáció – ezt az agilis metódusban backlognak (BL) nevezzük –, amelyet részfeladatok, un. sztorik alkotnak. Fontos, hogy a sztorik rövidek és lényegre törőek legyenek, ezáltal a megvalósítás nagyfokú szabadságát meghagyják a fejlesztőknek. A sztorikhoz tartozó időigényt az 5-8 tagú team tagjai megbecsülik, ezek alapján sztori pontokat rendelnek a részfeladatokhoz. Ezek is jelenthetik a költségbecslés alapját.

Nézzünk egy példát! Egy webshop esetében például úgy szól a BL, hogy a honlapnak tartalmaznia kell az összes funkciót, amit az ügyfél szeretne. Legyen egy adminisztratív felület, ahova feltölti a termékeit, legyen ügyfélfelülete, tudjon fizetni a vevő, és be lehessen állítani, hogyan jut majd a termékhez. Ebben az esetben a regisztráció az első sztori, a bejelentkezés a második, a vásárlás a harmadik és így tovább. A csapat megbecsüli – a részletesen szabályozott backlog refinement nevű meeting keretében –, hogy az egyes funkciók összesen hány sztori pontot érnek, majd pontonként kikalkulálnak egy összeget. A regisztráció viszonylag egyszerű, jellemzően két pontot ér. A pontonkénti árnak tehát a kétszeresébe kerül, mondjuk kétszázezer forintba. Elképzelhető, hogy az ügyfél ennél olcsóbb megoldást szeretne – erre, a Vízesés modellel szemben, itt van mód. Dönthet úgy például, hogy webshopjában regisztráció nélkül is lehessen vásárolni, de úgy is, hogy egyáltalán nincs szükség regisztrációra. Ilyenkor újra megbecsüli a csapat a sztori pontok számát – ezáltal a költségeket is.

Az ügyfél pedig máris megspórolt egy felesleges funkciót – és akár egy jelentősebb összeget.

A scrum módszertanban minden, így a szerepek is pontosan definiáltak. A Product owner (PO) írja a sztorikat az ügyféllel együtt, ő a BL „gazdája”. Összekötő a csapat és a megrendelő között. Ám nem ő, hanem a team dönti el, hogy a következő néhány hetes etapban mennyi feladatot tudnak bevállalni. A projekt szemlélet az elkötelezettségen, a felelősségvállaláson alapul.

A Scrum master részletesen ismeri a módszertant. Ő az, aki a folyamatok, vállalások betartásáért felel. Projektmenedzseri feladatokat is ellát: felelős a csapat összetartásáért, a felmerülő problémák elhárításáért. Ő vezeti a Scrum guide-ban részletesen szabályozott, maximum 15 perces, daily standup meetingeket, ahol a csapattagok beszámolnak egymásnak arról, mit végeztek előző nap, milyen feladatok várnak rájuk aznap, felmerült-e bármilyen, a munkát akadályozó tényező. E három témáról kell nyilatkozniuk a teamtagoknak tehát minden reggel.

A guide kötelezővé teszi továbbá a retrospektív megbeszéléseket is: a kétheti összejöveteleken a fejlesztők visszatekintve értékelik az elmúlt iterációban elvégzett munkákat, levonják a tanulságokat, illetve kijelölik a további fejlődési irányokat.

Az ügyfélnek pedig nincs más dolga, mint néhány hetente beülni egy terembe, megnézni – kipróbálni –, hol tart a számára készülő fejlesztés, és ha szükséges, beavatkozni.

Ez régen elképzelhetetlen lett volna.

Tapasztalatom szerint az ügyfelek mind inkább igénylik a transzparenciát, és szeretnek élni beleszólási jogukkal is. Az agilis szerződésben szerepel az egységnyi költség, a fejlesztő csapat pedig biztosítja, hogy mindig azt készíti el, ami fontos a megbízó számára. A kétheti megbeszéléseken nyomon tudja követni, hol tart a munka, sőt az is előfordul, hogy találkozik a fejlesztőkkel – erre korábban csak közvetetten, a projekt menedzseren keresztül nyílt mód.

A scrum oktatására ma már iparág is épül: tréningeken, workshopokon lehet tanulni e módszer gyakorlati alkalmazását. A lényeg azonban három szóban összefoglalható: rugalmasság, elkötelezettség és valódi, összedolgozó csapat.

Mint a rögbi meccseken.

Kinek ne jönne elő rémálmaiban egy elégedetlen ügyfél, egy félrecsúszott fejlesztés, egy kommunikációs hiba okozta határidő-csúszás? Az Agilis Kiáltvány aláírói másfél évtizede lefektették egy új szoftverfejlesztési megközelítés alapjait. A módszer tapasztalataink szerint is remekül működik.

Képzeljünk el egy nagy, komplex projektet. Másfél évig dolgozik a fejlesztő csapat, szóról szóra követik a szerződésben foglaltakat. Határidőre le is szállítják a szoftvert, és meggyőződésük: mindenben az ügyfél kívánságai szerint jártak el.

Csakhogy a várt ováció elmarad. Nem arat sikert a regisztrációs felület. QR kódot kell használni azonosításra, holott a megbízó – bár ezt nem nevesítette a szerződésben – vonalkódra gondolt.  Meg sem fordult az ügyfél részéről aláírók fejében, hogy más megoldás is létezhet. A projekt elkészült a megcélzott határidőre, de mindkét fél csalódott. A rengeteg energia nem a várt eredményt hozta. Ismerős a sztori? A szoftverfejlesztés világában dolgozó szakemberek nagy része átélt már effélét. Sokan tudják is, mi áll a háttérben.

A visszatérő problémát ugyanis a Vízesés modell (Waterfall) alkalmazása jelenti.

winston royce waterfall

A tradicionális módszertanok közül máig legjelentősebb megközelítést az amerikai Winston W. Royce írta le egy tanulmányában. A végcél hosszas egyeztetése után induló projekt, pontos határidővel és büdzsével; állandó tagokból álló teamek; a fejlesztés ideje alatt minimális interakció az ügyfél és IT team között – röviden és sommásan ez jellemzi a Vízesés modellt. És noha Royce már a hetvenes években felhívta a figyelmet a metódus hiányosságaira, nem hittek neki. A hosszas előkészítés és a méretes dokumentáció azt a csalfa érzést keltette, hogy mindent nagyon jól előkészítettünk, mindent tudunk és ismerünk, pontosan látjuk az előttünk álló feladatokat. Bár valójában csak egy délibábban gyönyörködtünk.

Vannak persze olyan iparágak, ahol nem nagyon van mód más logika és projektmenedzsment módszer alapján dolgozni. Tipikusan ilyen az állami cégek és közbeszerzések világa vagy a banki szektor. Itt nincs mese: „pontosan” meg kell mondani, hogy a fejlesztők mit, mikorra szállítanak, és persze mennyiért. A hierarchikus szervezetek és a pályáztatás logikája miatt szorosra van kötve minden érintett keze – és ez nemcsak a hazai viszonyok közt igaz.

Az üzleti életben, a saját termék fejlesztésben, a „laposabb”, decentralizáltabb szervezetekben azonban rendkívül kevés feladat olyan, ami indokolja a Vízesés modell alkalmazását, ha létezik másik lehetőség is.

Márpedig létezik.

1986-ban két japán szervezeti kutatással foglalkozó szakember a modell hátrányait kiküszöbölendő javaslatot tettek néhány újításra: önszerveződő, rugalmas csapatok felállítását szorgalmazták, és a folyamatos tanulás fontosságát hangsúlyozták a szervezeteken belül.

A ’90-es évek második felére aztán ezeket a javaslatokat több szoftverfejlesztési úttörő már a gyakorlatban is sikeresen használta, mint Kent Beck az Extreme Programming megálmodója. Sőt: Jeff Sutherland és Ken Schwaber arra vállalkoztak, hogy az addigra már megjelent gyakorlati elemeket rendszerbe foglalják – amiből megszületett a Scrum. Rugalmasan kell válaszolni az ügyféligényekre! – vallották. Ennek nyomán született meg 2001-ben 17 szoftverfejlesztési guru egyetértésével az Agilis Kiáltvány (Agile Manifesto).

AgileManifesto

A legritkább esetben fordul elő, hogy egy ilyen akció mögött nem történelmi-politikai okok, hanem üzleti, szakmai indíttatás rejlik.

Az Agile Manifesto e szempontból is kivétel.

Legfontosabb ajánlásai a megrendelővel történő szoros együttműködésre, hatékony kommunikációra és a változás iránti nyitottságra vonatkoznak. Az agilis módszertan szoftverfejlesztési problémákból nőtt ki, ezért kulcseleme a rugalmasság: a fejlesztés egymásra épülő fázisokra osztva zajlik, minden etapot az ügyféllel történő egyeztetés előz meg, követ és sző át. Az alapokat itt is részletes átbeszélés során fektetik le, ám menet közben – az 1-3 hetes fázisok során – van mód a változtatásra, módosításra, finomhangolásra. Nem ritka, hogy maga az ügyfél kéri eredeti koncepciója megváltoztatását. Fontos elem még a fejlesztési fázisok végi retrospektív, azaz a folyamat áttekintése annak fényében, mit lehetne legközelebb másként, jobban csinálni.

Volt cég, amely korán felismerte az agilitás erejét, mások az elmúlt években fokozatosan térnek, tértek át a modellre.

Vannak persze, akik számára máig idegen ez a megközelítés.Az averzió mögött pedig jellemzően két ok húzódik meg. Egyfelől a tény, hogy nem lehet a projektekhez kőbe vésett végső határidőt és kapcsolódó forrásigényt sem rendelni, sokak számára nehezen kezelhető. Másrészről pedig visszatartó erő lehet a felismerés: a folyamatos egyeztetések a megrendelő cég erőforrásaira is igényt tartanak. Azaz az ügyfélnek időről időre foglalkoznia kell az éppen futó informatikai projekttel, jóvá kell hagynia, vagy éppen meg kell változtatnia annak menetét. Ez figyelmet, energiát kíván. Ráadásul nemcsak a fejlesztésnek, de az abban részt vevő szervezeteknek is agilisaknak kell lenniük, amely lényege: rugalmas vállalat, gyors döntéshozatal, hatékony kommunikáció. Ez megint csak nem mindenütt adottság.

Ezzel szemben áll a mérleg másik serpenyője.

Ebben hajszálpontos végeredmény szerepel: olyan informatikai megoldás, amelyet a megbízó megálmodott. A hibalehetőségek minimálisak, az ügyfél pontosan azt kapja, amit várt. Nincs fölöslegesen kidobott pénz. Ha valahol, itt száz százalékig megáll a „Jó munkához idő kell” igazsága.

Összességében úgy vélem, azok a szervezetek, amelyek már „megégették magukat”, azaz ahol megérett a helyzet a változtatásra – előállt a „sense of urgency” – nagy eséllyel soha többé nem szeretnének visszatérni a Vízesés korszakába. Nem véletlen, hogy tőlünk nyugatabbra az agilis módszertan elterjedtsége sokszorosa az itthoninak.

Jóllehet az átállás sosem fájdalommentes, tapasztalatom szerint a befektetett munka minden esetben meghozza a gyümölcsét.

És a megérdemelt ovációt is.

Az ügyfélportál elkészülte csak a jéghegy csúcsa volt. Ennél fontosabb, hogy a BlackBelttel közösen megvalósított projekt során korszerűsítették, majd összekötötték egymással az informatikai rendszereiket, és megtisztították az adatokat. Ahogyan az ügyfélszolgálati vezető fogalmaz: áteveztek egy új világba.

2015-ben kezdődött. Az Invitel akkori vezetése ekkorra ismerte fel: ahhoz, hogy a versenyképességet jelentősen növeljék, vonzóbbá kell válni. A modernizálás igénye számos program elindulásában öltött testet, ezek egyike az ügyfélportál fejlesztése volt. „Nem volt olyan online felületünk, amelynek révén ügyfeleink önkiszolgáló módon és a nap 24 órájában el tudták volna intézni az ügyeiket, vagy megtekinthették volna azt, hogy mi mit tudunk róluk. A technológiák eközben ekkortájt kezdtek megérni arra, egy kényelmesebb önkiszolgáló rendszert lehessen fejleszteni, ahol az ügyfél nem azt érzi, hogy dolgozik, hanem hogy halad. Ez fontos szempont volt” – emlékszik vissza Ilosvay Csaba vállalati ügyfélszolgálati vezető.

Egyfajta katarzis

Az ügyfélportál kapcsán kiírt tenderre tíz cég jelentkezett, közülük nyert a BlackBelt. „Mindegyiküknek adtunk egy próbafeladatot. A BlackBelt az átadott adatbázis elemekből visszafejtette a működésünket, sőt, még egy működő prototípust is hozott a legegyszerűbb funkciókra. Az adatforgalom struktúrából összerakták az adatbázis hierarchiát és lemodellezték az üzleti folyamataink egy részét. Meglepődtünk, hogy ennyi információból ezt képesek voltak megcsinálni. Tették ezt olyan professzionális módon, hogy akkor nekünk magunknak sem volt ilyen komoly dokumentációnk az adatkapcsolatainkról. Azonnal látszott, hogy pillanatok alatt reagálnak, ha kell, és az is, hogy fejlesztési keretrendszerük, a Judo, megfelelő paraméterezés mellett rendkívül gyorsan tud produktumot előállítani.”

A Judo, azaz a BlackBelt által készített fejlesztői környezet jóvoltából egy-egy kérés felmerülésekor nem kódolni kellett elkezdeni, hanem csupán kiválasztani és cégre szabni a modulokat. Mindemellett Ilosvay Csaba hangsúlyozza: kezdetben rengeteg egyeztetésre volt szükség. Nekik, mint ügyfélnek sok esetben markáns elképzelésük volt a megvalósítás menetéről, ám a BlackBelt szakemberei tapasztalataik alapján ezt – építő jelleggel – nem egyszer megkérdőjelezték.  A két cég folyamatos együttgondolkodása kellett ahhoz, hogy a létező legjobb eredmény születhessen meg. „Erős kézzel vezettek minket végig az úton, nem hagytak beesni a szakadékba. Partnerként álltak hozzánk, gondos gazdaként, mintha a saját portáljuk készülne. Eközben nekünk is fel kellett nőni a feladathoz: a portálfejlesztés csapatmunka, s ehhez a saját háttérrendszerünket is fejlesztenünk kellett. Megdolgoztunk egymásért. Elakadáskor elvonultunk, mindenki gondolkodott egy kicsit, majd utána jött a kreatív, közös ötletelés, melynek nyomán egyfajta katarzis élményt éltünk át. Ily módon számos felesleges költségelemtől megmentettek minket és az egész projektet egyaránt, így összességében nagyon hatékony projekt volt.”

Isten hozott a jelenben, irány a jövő!  

A szakember szerint az ügyfélportál voltaképpen egy kívánatos eleme volt egy olyan hosszú folyamatnak, melynek során rendet tettek: korszerűsítették, majd összekötötték egymással informatikai rendszereiket, és megtisztították az adatokat. Ügyfeleikre partnerként gondolnak: a portál használata során így ők ugyanazokat az adatokat látják, mint az ügyfélszolgálatos kollégák. Ily módon az ügyfélszolgálati munka a közös megoldásra való törekvést jelenti. A felületet – a vizuális megjelenítést, a belső folyamatokat és megoldásokat – folyamatosan fejlesztik, azt ma már több száz ügyfelük használja.

Nem mellesleg a projekt révén új korszak kezdődött az ügyfélszolgálat életében is. A call centeres kollégák számára az integrált rendszerek által és a biztonságos informatikai csatornák megnyitásával egyszerűvé vált a távmunka, hetente több alkalommal is élhetnek ezzel a lehetőséggel – amely az új, potenciális belépők számára is vonzóvá teszi a céget. A projekt tehát nemcsak ügyfeleik, de a kollégák igényeit is kiszolgálja. Ez pedig munkaadóként megfizethetetlen.

„A pályázatok elbírálásakor annak idején szempont volt, hogy a projektnek milyen társadalmi és emberi haszna van. A közös munka egyfajta spirált indított el itt a cégnél, amelynek eredményeképpen ma már elmondhatjuk: az Invitech a jelen legjobb technológiáival felvértezte magát, így immár a jövőbe tudunk tekinteni.”

 

Hullafáradt, több tízezer soros alkalmazások felett görnyedő fejlesztők lélegezhetnek fel, ha nagy projektek esetén a TypeScript nyelvet választják. Mi, a BlackBeltnél sok esetben ezt tesszük. Az eredmény: kevesebb hibalehetőség, fenntarthatóbb, probléma mentesebb használat – elégedettebb ügyfelek.

Több mint húsz év telt el azóta, hogy a Netscape Communications kijött a JavaScript (JS)-tel. Kezdetben, a statikus weboldalak idején még csak amolyan „mórickás” volt: jelentéktelen kiegészítő eszköznek tartották, amely olyan kaliberű feladatokat oldott meg, mint a háttér színének megváltoztatása vagy egy-egy ablak „felugratása”. Később, a fogyasztói igények növekedésével aztán megérkeztek a felhasználói élményt (user experience – UX) növelő megoldások, amelyek révén a weboldalak letisztultabbak, funkcionalitás tekintetében pedig szofisztikáltabbak lettek. Ekkoriban értékelődött fel a JS szerepe. Mind nagyobb komplexitású alkalmazásokat kezdtek el vele építeni. Ma pedig már ott tartunk, hogy a webes oldalak jelentős része ezzel fut – a kis webshopoktól a legnagyobb közösségi hálókon át a tudomány sok területéig.

Ennek nyomán persze megnőttek a kódok méretei is – és itt álljunk is meg egy pillanatra.

Képzeljünk el egy szótárat, amely egy nyelv szavait tartalmazza. A könnyebb eligazodás kedvéért az igéket vastagon szedi, a főneveket pedig aláhúzza – azaz szófajonként használ valamilyen megkülönböztető jelölést. Könnyű benne megtalálni egy-egy kifejezést? Nos, nem igazán. Az eltérő betűtípus segít egy picit, de minthogy kizárólag fekete betűket tartalmaz, egy pillanat alatt átfutva egy oldalpárt, aligha talál oda automatikusan a szem a keresett szóra.

A JS nyelv szókincse, azaz a kódbázis némiképp hasonló logika szerint tagolódik. Van egy kis segítség a szófajok – típusok – beazonosításában, de érdemi támogatást nem kapnak a fejlesztők. Erre mondjuk, hogy a gyengén típusos nyelvek közé tartozik.

Amikor tehát a JS alkalmazási területe – és ezáltal a használt kódbázis – szélesedett, ez a gyenge típusosság időigényesebbé tette a fejlesztők munkáját. Amikor ugyanis sok, akár több tízezer soros, bonyolult alkalmazások kódjának szövegezésében nem jelennek meg a típusok, a fejlesztő csak egy rendkívül absztrakt, semmitmondó adatokból álló „szöveget” lát. Márpedig ebből nehéz dolgoznia. Minél nagyobb a kódbázis, annál problémásabb a hibátlan értelmezés. Két választása lehet: vagy tudja fejből értelmezni – ez komplexebb alkalmazásoknál persze nem jellemző – vagy dokumentációt csinál magának (és társainak) róla. Utóbbi megint csak időigényes, és bár sok esetben szükséges, de fejlesztés közben nem a leghatékonyabb módszer.

Nincs más megoldás?  De igen! Az egyik lehetőség erre a TypeScript (TS).

Ez a nyelv szuperszettje a JS-nek: más programnyelvekből behoz már ismert típusokat és alkalmazható módszertanokat. Programozás közben pontosan tudja, hogy a kódnak melyik pontjával dolgozik éppen, nem kell találgatnia, próbálkoznia, dokumentációt olvasnia hozzá. A szótáras metaforánál maradva, most már nem vastagítás és aláhúzás segít, hanem színes szövegkiemelők: ha sárga, akkor ige, ha piros, akkor számnév. A TS egyszerűbb esetekben is alkalmazható, de igazán a problémásabb kódbázisok okán született. Olyan projektek esetén segítség igazán, amelyeken több ember dolgozik egyszerre, gyakori konzultációt igénylő feladatok megoldásán.

Minthogy kódolás közben folyamatosan meg kell adni a típusokat – használni kell a „szövegkiemelőt” – a munka némiképp lassabb, mintha gyengén típusos programnyelvet használnának. Ám később a befektetett idő megtérül: kevesebb hibalehetőséget rejt a kész program, fenntarthatóbb, tartósabb, használata problémamentesebb lesz. Mint ahogyan ezer szót megtanulni egy idegen nyelven tovább tart, mint húszat, ám mennyivel könnyebben boldogul aztán az ember a megszerzett tudásával!

TS-t ma még kevesebben használnak, mint JS-t. Ám mi itt a BlackBeltnél nagyon fontosnak tartjuk az új kollégák támogatását, segítségünkkel hamar elsajátítható e programnyelv használata.

Meggyőződésünk, hogy megéri.

Egyfelől mert a Microsoft áll mögötte, ez szakmai garanciát, folyamatos fejlesztést és bővülő eszköztámogatottságot jelent. Olyan eszközökét, amelyek meggyorsítják a programozást és redukálják a hibalehetőségeket. A JS-hez kapcsolódó eszközök messze nem ilyen hatékonyak.

S hogy mit jelent mindez az ügyfél szempontjából?

Ahogy azt már említettem, a TS révén stabilabb alappal, biztosabb működéssel kell számolni. A program segítségével kisebb a valószínűsége annak, hogy hibát ejtenek a fejlesztők. Ha mégis becsúszna, később azokat gyorsabban és könnyebben lehet korrigálni.

A TS kód egyébként, amit a fejlesztők használnak, egy fordítási eljárással átalakul JS-be. Azaz: magyarul írom a könyvem, mert ezen a nyelven tudom magam igazán szabatosan kifejezni, de angol a célközönségem, ezért lefordíttatom. Mivel a fordító a TypeScript forráskódból JavaScript kódot generál, a program bármely JavaScript futtatására alkalmas böngészőben vagy akár a szerver oldalon is működni fog. Nincs szükség külső programra vagy plugin telepítésére.
Mindezeket figyelemben véve tapasztalataink szerint nagyobb vagy bonyolultabb projektek esetén a TS a kézenfekvő megoldás.

S nemcsak mi gondoljuk így: az alábbi grafikon a TS iránti megnövekedett érdeklődést mutatja:

Móricka nagykorú lett.

Nehéz? Olyan, mint egy vizsga? Sajnálom, én így interjúztatok! – hangoztatja Privitzky Gábor, a BlackBelt Technology műszaki-technológiai igazgatója, aki kezdetektől ragaszkodik a komoly szakmai felvételihez. A céghez csak a legjobbak kerülnek be, ám ők aztán jellemzően úgy érzik: végre egy munkahely, ahol nap mint nap tovább lehet fejlődni. És még a csapat is remek!

Developers„Előfordult, hogy miután az ügyfelünk is meghallgatott néhányat a hozzá delegálandó embereink közül, egy idő után azt mondta: a többieknek most már csak a neveit diktáljátok le, őket már nem hallgatjuk meg. Egészen biztosan jók lesznek!” – meséli büszkén Privitzky Gábor. Mint mondja, a cégnél általa meghonosított szigorú szakmai szűrő, noha erőforrásigényes, hosszú távon mindenképpen megéri: bizalmat épít partnereik körében, szorosabb üzleti kapcsolat alakul ki köztük. „Ha ügyfeleink, akik tanácsadó szolgáltatást vásárolnak tőlünk, azt látják, hogy közös projektjeinkhez mindig felkészült, jó szakembereket küldünk, máskor is bennünket hívnak majd.”

 

Kicsit, mint a Vágó-vetélkedőben

Privitzky Gábor

Az igazgató hosszú évek tapasztalatai alapján már a BlackBelt alapításakor ragaszkodott ahhoz, hogy komolyan vegyék a szakmai felvételiztetést. Korábbi munkahelyein vele is gyakran előfordult, hogy szakmailag nem értett szót egyik-másik kollégával, ez pedig nyilvánvalóan gátja a hatékonyságnak. „Léteznek olyan vállalatok, ahol csupán önéletrajz alapján döntenek. Értesz a C++-hoz? És még Linuxot is láttál? Szuper! Fel vagy véve! Csakhogy ezzel a szűrőt áttolom az ügyfélhez. Ez így nem fair. A kiválasztást nekünk kell megejtenünk.”

Persze nemcsak a szűken vett lexikai tudást, hanem a szakmai rátermettséget és hozzáállást is nézik: mennyire szeretne itt dolgozni a jelentkező, milyen a szakmai érdeklődési köre. Az igazgató hangsúlyozza: azt mérik fel, hogy az egyetemen mennyire figyeltek oda a jelentkezők. „Mondják is azok, akiknek nem sikerült az interjú: ez olyan volt, mint egy egyetemi vizsga. Nos, igen! Én így interjúztatok. A jelöltek gyakran kapnak algoritmizáló jellegű feladatot. Sokszor nem is a konkrét megoldás, hanem az érdekel, hogyan gondolkodik a felvételiző. Tudja-e, hogy mekkora a szóban forgó algoritmus időbeli bonyolultsága? Rájön-e, hogy ez egy exponenciális, polinomiális, négyzetes, esetleg lineáris probléma? Ha már találkozott az egyetemen hasonlóval, vagy gondolkodott valaha ilyesmin, akkor jó választ fog adni. Persze volt már olyan, hogy nemcsak a gondolatmenetet, de a konkrét megoldást is megmondta valaki. Az illető most is nálunk dolgozik.”

Eközben számít az is, hogy a jelentkező egy esetleg számára túl nehéznek bizonyuló feladatot miképpen kezel. Nem jó, ha magabiztosan mellébeszél, de az sem, ha feladja. Ilyenkor célszerű, ha inkább elkezd hangosan gondolkodni, honnan közelítene a megoldás felé. „Kicsit olyan ez, mint annak idején a Legyen Ön is milliomos!-ban. Körbe lehet járni a témát, szabad segítséget kérni” – jegyzi meg Privitzky Gábor.

 

Tudni illik

Így tett a gyakornokként két hónapja itt dolgozó Stasz Balázs is az interjún kapott feladat kapcsán. Noha megoldása nem volt tökéletes, a jó megközelítéssel állt a feladathoz. „A felvételit általánosságban nem éreztem túlságosan nehéznek. Úgy gondolom, a feltett kérdésekre adott válaszok jó részét minden fejlesztőnek illik tudnia” – véli a Budapesti Műszaki és Gazdaságtudományi Egyetemen januárban diplomázó hallgató, aki jelenleg JAVA fejlesztőként bővíthet ismereteit a BlackBeltnél.

A felsőoktatással kapcsolatos tapasztalatok alapján Privitzky Gábor úgy látja: azok a jó képzések, ahol a hallgatókat a megszerzett tudás felhasználására készítik fel, és gondolkodni tanítják meg ahelyett – sajnos néhány intézménynél ez sem ritka –, hogy az aktuálisan fontosnak gondolt technológiák részleteit magoltatnák be.

Mindemellett a nyelvtudást is muszáj még felmérni, ez rendkívül fontos, ha valaki nálunk szeretne dolgozni – fűzi hozzá az igazgató.

 

Szédítő tempó

Van persze olyan is, hogy nem ő interjúztat, de a szakmai szűrőn akkor is át kell esniük a delikvenseknek. Mocsányi Ákos senior fejlesztő nemrégiben például DevOps Engineer (azaz fejlesztő és egyben üzemeltető) munkakörhöz választotta ki a legjobb jelöltet. „A személyiségre voltam kíváncsi, az üzemeltetési tapasztalatra, és arra, mennyire magabiztos a jelentkező. Fontos volt, hogy ne szeppenjen meg, amikor az interjú egy pontján megkérem: írjon egy programot, én pedig nézem közben. A feladat egyébként nem volt túl nehéz. Az érdekelt, hogyan kezel egy ismeretlen gépet, eszközöket. Mégis voltak páran, akik ettől leblokkoltak.”

Nem így László Levente, aki a megmérettetés során a legjobbnak bizonyult, és néhány hete meg is kezdte a munkát a cégnél. „Nem volt nagyon izzasztó – tízes skálán mondjuk úgy ötös nehézségű lehetett a feladat –, de azért kicsit esetlenné tett a helyzet, ki is zökkentett. Kezdetben zavart lesz az ember, hiszen új a környezet, de aztán átállítottam pár dolgot, és megoldottam. A légkör egyébként kellemes volt, tapasztalataimról, ügyfélkezelésről és az érdeklődési körömről egyaránt beszélgettünk”.

Ez persze nem véletlen. Az öt évvel korábban megszerzett ismeretek már-már elavultnak számítanak, fontos tehát az erős szakmai érdeklődés. „Aki lemarad, néhány éven belül képtelen lesz betölteni a munkakörét” – állítja Mocsányi Ákos. Ezért is lényeges feltérképezni, hogy a jelentkező mennyire nyitott és kíváncsi a legfrissebb technológiai trendekre, képes-e befogadni az újdonságokat. Szédítő tempóban változik a szakma – lépést tartani csak a legjobbak tudnak.

A fekete övesek.

A bitcoinra megjelenésekor egy világ legyintett – ma pedig ott tartunk, hogy a prognózisok szerint társadalmunk alappilléreit formálhatja újjá. A bitcoint életre keltő technológia középpontjában a blockchain áll, mely egyesek szerint olyan jelentőséggel bír, mint maga az internet.

De hogyan is kezdődött?

A múlt évtized végén Satoshi Nakamoto* egy olyan decentralizált rendszer részleteit publikálta, melyben a klasszikus pénzügyi szereplők (bank, clearing house) mellőzésével lehet pénzt tárolni és mozgatni meghamisíthatatlan** és utólag módosíthatatlan módon. Ehhez kidolgozta a blockchain nevű adatstruktúrát, valamint az új tranzakciók hozzáfűzésének protokollját. Ezek révén lehetővé vált, hogy harmadik fél bevonása nélkül tudjunk elektronikusan pénzt kezelni.

Képtalálat a következőre: „blockchain”

A blockchain blokkok láncolatát jelenti, blokk alatt pedig ebben az esetben egy olyan csomagot értünk, amely akár több száz, a Föld bármely pontján lezajló pénzügyi tranzakciót tartalmaz. A világszerte indított tranzakciók rákerülnek a blockchain hálózat tranzakciós listájára. Amikor pedig összegyűlt körülbelül 350 tranzakció***, azokat egy blokkban a lánchoz kell fűzni. A blokkok pedig úgy vannak összekapcsolva, hogy nem lehet kivenni egyet és összekötni azokat, amelyek ezután egymás szomszédjai lennének. A lánc utólag nem módosítható, és a blokkok egymáshoz fűzése csak egy költséges műveletsor elvégzése árán történhet meg.

És itt jönnek a képbe a blokkbányászok.

A bányászok nagy teljesítményű számítógépeket állítanak munkába, amelyek rejtvényt fejtenek, mert blokkot létrehozni és a lánchoz fűzni csak egy bonyolult feladvány megfejtésével lehet.

Hogy néz ki a feladvány?

Ehhez előbb meg kell értenünk a hash fogalmát. Ez egy karaktersorozat, melyet a hashfüggvény állít elő – utóbbi lényege, hogy egy bármekkora adattömegből egy lényegesen rövidebb (fix méretű) karaktersorozatot (hasht) készít. A „bányagép” először kiszámítja a blokk hashét. A feladvány pedig így szól: találd meg azt a számot (nonce), amit ha hozzáhashelünk a blokk hashéhez, akkor az új hash bizonyos jellemzőknek megfelel – például négy 0-val fog kezdődni.  És ezt megtalálni nehéz.

Amint a világ blockchain-bányái érzékelik, hogy összegyűlt egy blokknyi tranzakció, versenyezni kezdenek az aktuális feladvány megoldásáért.

Világszintű verseny kezdődik.

Igen, a jutalomért. Ez pedig egy kriptodeviza-adag, ami a leggyorsabban megoldást szállító bányászt illeti. A kriptodevizának (bitcoin, ether stb.) pedig dollárban, euróban stb. rögzített aktuális árfolyama van.

A bitcoin tehát blockhain alapú digitális pénz, protokollja, szoftvere révén a számítógépek hálózata egy megosztott könyvelést működtet a világhálón keresztül. Jóllehet a bitcoin piaci kapitalizációja a legnagyobb, de ma már több száz kriptodeviza létezik.

E rendszereket világszintű decentralizáltságuk révén nem lehet leállítani, megszüntetni. Nincs olyan geopolitikai helyzet, vagy titkosszolgálat, amely a működésüket leállíthatná. A blockchaint nem lehet kikapcsolni.

Képtalálat a következőre: „bitcoin”

Kik állnak a bányagépek mögött?

Akárki, aki össze tud rakni egy kb. két- háromezer dollárt érő célgépet.

A nagyobb bányák viszont óriási géptermek, hangárok, melyekben több tízezer gép csap elég nagy zajt. Cégek, magánszemélyek, államok a tulajdonosok, akik olcsó és megbízható energiához férnek hozzá a bányák folyamatos és óriási energiaszükségletének kielégítésére. Ehhez, jelenleg úgy tűnik, Kínában a legmegfelelőbbek a feltételek. De hírek szerint Oroszországban állami szinten készülnek kriptodevizát bányászni, ahol áramszolgáltató cégek igyekeznek bányászokkal szövetkezni, számukra olcsóbb áramot biztosítva. Valamint az utóbbi hetekben úgy tűnik, Észak-Korea is nagyszabású bányászakcióba kezdett.

Ausztriában pedig egy lány testvérpár néhány éve HydroMiner néven alapított céget: a bányászathoz vízierőművekben előállított olcsóbb és környezetbarát áramot használnak.

De mennyire jó üzlet ez?

Az évtized elején könnyű volt bitcoint bányászni, és sokan kíváncsiságból bányászták is. Városi legendák szerint egy egykori pesti informatikushallgató egyetemi évei alatt bányászott bitcoinjai idén nyár elején több, mint 300 milliót értek, és azt tervezi, ha felszalad az áruk egymilliárdig, nyugdíjba megy.

Bitcoint bányászni ma már nehéz, más valutákat – például ethert – lényegesen könnyebb. A piacon azonban hozzá lehet jutni a kriptodevizához, és annak árfolyamát kizárólag a kereslet-kínálat alakítja, központi szereplő törvényes eszközökkel nem befolyásolja. Ennek persze megvannak a hátulütői is. Jelenleg például az árfolyam rendkívül volatilis: egyetlen nap alatt harminc százalékot is képes mozogni egyik irányba, majd húszat a másikba. A kriptodeviza piac most a spekulánsok játszótere, ám jelenleg az össznépi játékban csak a Föld népességének kevesebb, mint egy százaléka vesz részt. Ez az arány egészen biztosan emelkedni fog.

Előrejelzések szerint a bitcoin árfolyama is óriásit robban majd az elkövetkező tíz évben. Egyesek szerint akkorra 50 ezer dollárra rúghat. Jelenleg azonban ettől még messze vagyunk. És bár ma még jellemzően befektetési eszközként tekintünk rá, fizetni egyre több helyen lehet majd vele.

Japánban már most sok helyen elfogadják a bitcoint. A kasszagép egy QR-kódban megjeleníti a tranzakció adatait (összeg, bitcoin cím, tranzakció-azonosító), a telefonon levő pénztárca pedig leolvassa azt, és indítja a fizetést. A tranzakció pedig – ahogyan arról már szó volt – egy blokkba íródik. A bankszámlát ebben a kontextusban címnek nevezik, arra és arról könyvelődnek az összegek. A telefonról elküldött összeg pedig a bolt címére kerül.

De hogy jön ide a tulipánmánia?

A címben említett virághagymákat Törökországból a bécsi udvar isztambuli nagykövete hozta be Európába, majd egy holland botanikus terjesztette tovább Hollandiában az 1500-as évek végén. Az emberek megőrültek értük, a tulipánmániának tízezrek köszönhették meggazdagodásukat. Aztán egy árverésről egyszer csak elmaradoztak a vevők. Noha a háttérben a bubópestis állt, a lufi pillanatok alatt kipukkadt, a tulipántőzsdézésnek befellegzett. Sokan idézik a sztorit a bitcoin kapcsán is.

Ám az eddigi fejlemények azt mutatják: a kriptodevizák kora előtt állunk.

 

* személy vagy társaság – kilétüket homály fedi

** a tranzakció indításához a pénz birtokosának digitális aláírására van szükség

*** eredetileg 1 megabájtnyi, de ez blockchainenként változó

A Kubernetes technológiáról korábbi cikkünkben már részletesen írtunk. Akkor a horizontális skálázással kapcsolatban emeltük ki a megoldás előnyeit. Léteznek azonban más helyzetek is, amelyekben áttörést hozott e technológia.

Tekintsük ehhez a szoftverkészítés tevékenységét a korszerű, agilis megközelítésben. Ez egy részfeladatok rendszeres ismétlésére épülő folyamat, mely magába foglalja szoftverfejlesztési életciklus minden elemét. Úgymint: tervezés, elemzés, programozás, futtatható formátumra hozás, egység tesztelés, átvételi tesztelés.

A programozási fázis utáni feladatok nagyban automatizálhatók, amire szükség is van ahhoz, hogy a tesztelés ne vonjon el emberi erőforrást a csapattól, valamint, hogy minél gyorsabb visszacsatolás érkezzen a fejlesztőkhöz a legutóbbi változtatások helyességéről. Ezek az automatikus lépések gyakorlatilag folyamatosan integrálják a fejlesztők által eszközölt forráskód módosításokat az alkalmazásba. Innen a fázis neve: Continuous Integration. Könnyen belátható, hogy ez a módszertan a hagyományos, vízesés jellegű metódusokhoz képest – ahol a visszacsatolásokra sokszor hónapokat kellett várni – sokkal rugalmasabb, alacsonyabb kockázatú, az üzleti környezet folyamatos változásaihoz sokkal könnyebben alkalmazkodni képes projekteket eredményez.

A Continuous Integration továbbgondolása a Continuous Delivery és a Continuous Deployment. A Continuous Delivery az újonnan a programba épített funkció elérhetővé tételét jelenti. Ennek keretében kitelepítik egy tesztszerverre – ez még nem az ügyfélé –, megint csak automatizáltan. Ez egy közbülső rendszer, ahol már a potenciális felhasználók is meg tudják nézni. Itt egyfajta minőségbiztosítási eljáráson esik át a funkció.

A Continuous Deployment pedig az utolsó fázis, amikor mindez – automatizmus útján – kikerül az éles rendszerre.

A cél az egész folyamat során az, hogy idejekorán és automatikusan minél pontosabban leteszteljük a programot. A rengeteg teszt lefuttatása azonban nagyon sok időt vesz igénybe, és nagymértékben leterheli a rendszert. Ehhez erőforrások kellenek.

És itt juthat ismét szerephez a Kubernetes.

Minthogy bizonyos folyamatok több erőforrást igényelnek, mások kevesebbet – a tesztek számától és jellegétől, a tesztelt rendszerelemek szükségleteitől, az automatizmusok párhuzamosítottságának mértékétől függően – dinamikusan kell a végrehajtásba bevont erőforrásokat skálázni. Ennek egyik lehetséges technológiája a konténerizáció, annak pedig egy jól működő, nyílt forrású támogató platformja a Kubernetes.

A feladat ugyanakkor csupán messziről tekintve tűnhet egyszerűnek, ahogy közelebb ér az ember, kiderül, hogy rendkívül komplex. Mint a repülés: jól néz ki, hogy csak felszállunk a gépre és az elrepít nyaralni, de közben a pilótafülke gombok százaiból áll. Itt is ez a helyzet. Könnyű elkezdeni a Kubernetes-szel dolgozni, de a hatékony használathoz már nagyon kell hozzá érteni.

A világ ugyanakkor erre tart.

A fejlesztői társadalom ugyanis valósággal „rácuppant”, hiszen ezzel a megoldással nagyon sok hasznos dolgot el lehet érni, amire eddig nem nyílt lehetőség. A kapcsolódó eszközök fejlődési üteme szédítő: havonta számos újdonság lát napvilágot a közösség jóvoltából, tovább könnyítve a használatát. Folyamatos tanulásban vagyunk.

Az ügyfelek pedig igazán elégedettek lehetnek.

A CI/CD koncepció gyakorlati alkalmazása ugyanis nagyban hozzájárul az erőforrások hatékonyabb kihasználásához, így profibb, kevesebb hibalehetőséget tartalmazó programot kap a megrendelő, kedvezőbb áron.  Hiszen, mint említettem, minden változtatás azonnal tesztelésen esik át, nem veszítünk tehát időt, villámgyorsan zajlik a visszacsatolás. Míg korábban ahhoz is idő kellett, hogy az üzemeltető csapat kitegye a programot az éles rendszerre, itt ez most fel sem merül. A felhasználói élmény (user experience) is azonnal rendelkezésre áll.

Mindennek persze előfeltétele az agilitás. A korábbi, Vízesés modell még a hagyományos, hatvanas évekbeli mérnöki szemléletből – a felhőkarcolók, hidak, látványos beruházások idejéből – ered. A szoftveriparban azonban óriás pazarlás volt ezt alkalmazni, megérett hát az idő a paradigmaváltásra. Hiszen az ügyfél nem ér rá.

Mostantól nem is kell várnia.