Junior Java programozó képzés egy zsák pénzért

Fórumok

Ismerősöm gondolkozik karrier váltáson és kinézte magának az IT-t. Teljesen a nulláról, olyan user-t kell elképzelni, akitől ha megkérdezed, hogy milyen telefont használ, akkor első körben az a válasz, hogy Android-osat, második körben, hogy Samsung-ot. Miután elnavigálod a beállítások közé, utána megnézni neked, hogy melyik típus.
Nem akarok reklámot csinálni, de muszáj linkelnem, hogy értsétek miről van szó:
Junior Java programozó képzés
Szóval azzal kecsegtetnek, hogy befizetsz egy zsák pénzt és hozzád vágnak egy 250k HUF nettó állást.
Meg vannak ilyen oldalak is, hogy:
Crossover
Az oldal alapján van egy ilyen képlet, hogy: x év tapasztalat = xM Ft / HUF havi gázsi.

Több fenntartásom van a fent linkelt Junior Java programozói képzéssel kapcsolatban.
Az első, hogy van egy ikertestvérem, aki BME Infót végzett és láttam, hogy hogy néz ki, amikor szoftverfejlesztő lesz valakiből. Erős alapok (pl. algebra), programozás elmélet, architectúrák, algoritmusok, hálózatok és rendszerek, stb. Lehet szidni a magyar felsőoktatást, de láttam, hogy mit tanult és nem lett belőle hülye gyerek. Random programnyelvet egy manual és 2 tutorial alapján 2 óra alatt elsajátít. Pontosan emiatt hiába kezdtem C64-en a BASIC után gépi kóddal a hobbi programozói evolúciómat, sohasem fogom magam szoftver fejlesztőnek nevezni. Az általa írt kód jobban átgondolt, jobban struktúrált, jobban megtervezett és jövőállóbb, mint amit én összekontárkodok. A tesóm szerintem zseni, de neki is évek kemény munkájára és utána szakmai tapasztalatra volt szüksége ahhoz, hogy megszerezze a mostani szaktudását. Most pedig, amikor egy projektbe embereket keresnek, sokszor a párnájába sikítana a jelentkezők színvonalán.
A második, hogyha megnézek egy rendes álláshirdetés portált, ott a junior programozói pozíciókat is felsőfokú végzettséghez kötik. Természetesen fizetést nem írnak, de tudom, hogy kevesebb, mint a fenti hirdetésben promózott összeg.
A harmadik, hogy hasonló képzést (vagy pont ezt) az index-en is nyomattak videóban, ahol a vágó képeken a jelentkező zene lejátszót dobott éppen össze. Lehet vitatkozni persze, de a saját tapasztalataim alapján az index kiváló iránytű abból a szempontból, hogy amit ott nyomatnak, abban elkezdek erősen kételkedni.

Nem zárom ki, hogy jó érzékkel rendelkező, informatikára fogékony embereket fél év alatt meg lehet tanítani programot fejleszteni. A tesóm tapasztalataiból kiindulva tudom, hogy nagyon híg a felhozatal (külföldön legalábbis biztosan). Meg szeretném nyugtatni azokat is, akik esetleg sértve érzik magukat, hogy a felső fokú diplomát előhoztam. Jól tudom, hogy az nem garancia arra, hogy valakiből jó mérnököt faragnak (habár a tesóm évfolyamtársaiból (korábbi gimnáziumi osztálytársaink) szintén jó képességű szoftver fejlesztő lett). De akad ellenpélda is.

Szóval: kérlek segítsetek nekem:
1. Találkozott már valaki olyannal, aki ilyen képzéssel sikeres karrier váltást hajtott végre a nulláról? Netán az ellenkezője: ablakon kidobott pénznek bizonyult?
2. Léteznek ilyen pozíciók, ahol felsőfokú végzettség nélkül egyből jól kereső álláshoz lehet jutni, vagy ez is olyan, mint a kislányoknak meghirdetett modell képzés (lehúzás) - hogy befizeted a tanfolyamot, utána jó pénzért készítenek egy portfoliót és a végén mégsem viszi el a gyereket a világ 10 legjobb modellügynöksége közül az egyik?

Kíváncsi lennék pozitív vagy negatív tapasztalatokra. HR-esek se kíméljenek!

Köszönettel:
Dw.

Hozzászólások

Eddig két tapasztalatom van ilyesmi kurzusokat illetően:

1. Egyszer interjúztattunk egy (talán GreenFox-nál végzett) embert. Nem volt rossz, bár volt egy-két nagyon homályos terület. Ami miatt nem kapott junior ajánlatot, az a hálózati ismeretek teljes hiánya.

2. Egyik haver végzett el egy ilyen sulit, azóta dolgozik, és el tudok vele beszélgetni szakmai dolgokról.

Nyilván számít az, hogy honnan indul. Fél év alatt lehet, hogy nem helyeztek hangsúlyt a TCP handshake-re, meg az OSI rétegekre. Meg gondolom nem konfigurálnak állapot tartó csomagszűrőt sem.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Na jó, azért egy átlag C programozóknak sem kell leásnia a TCP handshakeig, ott is socket van, ahol mire visszatér a connect/accept, meg volt a handshake. :) Aki hálózati stacket fejleszt, annak valóban kell ezzel is foglalkoznia...

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Pont erről írok lentebb. Egyrészt a java amennyire látom, legtöbbször pont hogy mérföldekre van a vastól, nem is erre van. Minek tanítanád neki, ez már specializáció (ráadásul ha jól sejtem tényleg nem sokan oldják meg a vasközeli feladatokat java-ban).

Véletlen jött szembe pár napja-hete:

https://www.youtube.com/watch?v=kyPLy5rp7QI

Ezt követve gyakorlatilag a programozónak inkább matematikusnak kéne lennie, elte progmat irányt nem ismerem, de kb. úgy tudom elképzelni. A fél év java arra jó, hogy el tudja dönteni, hogy ő ezt akarja-e csinálni évekig, illetve ez az eszköz szerinte úgy változtat-e a világon, ahogy ő akarja, látja hasznosnak. Egy rakás bölcsészt láttam, aki elméletileg szereti amit csinál, gyakorlatilag utálja, hogy kb. semmi érdemi hasznosulását nem látja annak, amit csinál. Programozó is biztos van, akit zavar, hogy amit csinál mondjuk 2 kiscégnél van csak használva, és ott is mondjuk 2 ember munkahelyét számolta fel (nem kéne, de béna a vezetés, stb.).

Én Orosz Lászlóval vagyok. Tömegesen összetévesztjük az egyetemi szintű képzettséget a szakemberrel. Sőt, mostanában az egyetemtől azt várnák, hogy szakembereket képezzenek.

Teljesen más témában olvastam egy cikket, és ott írták, hogy aki műszaki dolgot tanul, annak a harmadik évfolyamra elavul amit az első évben tanult. Na, ami 3 év alatt elavul, az nem egyetemes tudás, hanem valami hájpolt technológia kézikönyve.

A matematika, a fizika, at információ és kódelmélet, az algorimuselmélet nem avulnak el.

Igaz lehet az is, hogy létezhet olyan, aki ezen elméleti dolgokból jól képzett, jól érti és mégsem lesz jó mérnök. De ennek azért elenyésző a valószínűsége, és ha esetleg előfordul, akkor az azért van mert nem szereti a pályát, és akkor úgyis el fogja hagyni, nem okoz gondot.

Ezzel nem azt mondom, hogy nem lehet létjogosultsága a nem egyetemi szintű programozóképzésnek. Aki nem akar vagy nem tud valódi egyetemi szintű tudást felszedni, annak is legyen képzés. Csak ne az egyetemi képzést húzzuk le hozzájuk, hanem legyen az egy külön szint. Ahogy régen voltak is főiskolák, amiknek nagyjából ez volt a célja. De a mostani kor mániája, hogy mindenkit a lehető legmagasabb szinten kell oktatni. A valóság viszont az, hogy a legtöbb ember erre nem vágyik. Ahelyett, hogy belátnánk, hogy nincs szüksége az emberek 50%-ának egyetemi képzésre inkább az egyetemi képzés színvonalát húzzuk le, hogy az emberek 50%-ának megfeleljen.

A probléma ezzel az, hogy így az 5-10%-nyi elit nem kapja meg a szükséges képzést ahhoz, hogy valóban szárnyalhassanak.

Bármi, ami államilag van dotálva, és nincs mérve a kimenete, az ilyen lesz. Senki nem kérdezi meg, hogy miért lesz első évről fele annyi a létszám a második év elejére, ráfogják, hogy nem oda valók. Ha egy gyár 50%-os hatékonyságot mutat, azért van olyan téma, ahol nem néznek viccesen a főnökök :).

Az első hök-ös vagy milyen újság címoldalán amit az újdonsült BME-sek kezébe nyomnak az első év elején (vagy sikeres felvételi után?) ott virít nagy betűkkel, hogy a "felvettek feléből soha nem lesz mérnök". Vagy már megszűnt ez a szép hagyomány? :-)

Normális HUP-ot használok!

+1

Mérnökinfo, első két félév gyakorlatilag kapkodás, elmélet épphogy elmagyarázva, hivatkoznak arra, hogy hát aki info középsulis volt, az ezt tudja (az voltam, nem tudtuk, mert a város legjobb iskolája is teli volt nemtörődöm diákokkal), analízisen ugyan ez volt a gimnáziumra hivatkozva. Majd félévnél beismerték, hogy hát így lesz a 400-ból azt hiszem 200, vagy 150, mert annyi van másodéven fizetve államilag. Gyakorlatilag az oktatás hiányos és direkt nehezített volt ezek alapján, az élte túl, aki a szerintem ésszerűnél is tovább volt hajlandó szenvedni, kérdezősködni a felsőbbévesek között, akik nem pedagógusok, épphogy el tudták mondani (!!!) amit elvileg már megtanultak 1-2 éve. Majd elmondták, hogy de ne félj, sose lesz haszna, ezt a szakmában dolgozók mondják nekik. Kösz, motiváció maximumon.

Nem mellesleg egy ponton érdemes lenne elgondolkodni az ágyútölteléknek (vagy inkább kartácsnak) használt embereknek, hogy anyád-apád pénzét vagy a diákhiteled nem biztos, hogy megéri egy olyan egyetemi oktatásra fordítani, aminek nem célja, hogy eljuttasson téged a végéig.

Ezért kérdeztem alább, hogy van-e alternatíva, teljes tematikai lefedettség és struktúra egyetemi kereteken kívül, mert az, hogy áááá annélkül is megy az nem válasz. Illetve de, ahogy írja a kolléga fentebb, coder sulik mutatják, hogy lehet ám rookie codert nevelni, csak utána a cégnél tanítják meg úgy ahogy tudják (nem oktatásból élők, akik kommunikálni nem tudnak olyan jó szinten, mint egy kicsiszolt könyv tud), ha elég remény csillan meg az illető homlokán.

+1

Velem is pontosan ez tortent 1999/2000-ben, elso felevre felvettek 400+ diakot Muszinfora Kecskemeten, megkaptuk az arcunkba az "usszal bmeg" mentalitast, masodik felevre a 400+ diakbol lett 150 (a mienk volt az utolso ev akinek meg nem volt kreditrendszer).
Utolag kiderult (az egyik tanszekvezeto arulta el) hogy elso felevre annyit fizet az allam amennyi diakot felvesznek, masodik felevre pedig mar megszabott 150 fos keret volt. Micsoda meglepetes.
Itt be is fejeztem az ismerkedest a magyar felsooktatassal.
Szerencsere par eve mar Magyarorszaggal is.
Eddig mindketto nagyszeru dontesnek bizonyult.

"Tömegesen összetévesztjük az egyetemi szintű képzettséget a szakemberrel."

Nincs az összetévesztve. Egyszerűen változott a világ.

Korábban, amikor Orosz László fiatal volt, akkor kellett 1000 emberből
- 10 elméleti zseni, akik elmentek egyetemre,
- 90 jó eszű ember, akik elmentek főiskolára és középiskolába,
- 900 favágó, akik elmentek szakképzőbe vagy oda se.

Most meg kell 1000 emberből
- 10 elméleti zseni,
- 890 jó eszű ember, akiket 5-8 évig képzeni kell a feladatára,
- 100 favágó, akik elmentek szakképzőbe vagy oda se.

Értem én, hogy Orosz László ugyanúgy a 10 elméleti zsenit akarja tanítani, csak az iparnak meg kell egy csomó nagyon jól képzett gyakorlati szakember és a képzésükhöz a fizikailag adott feltételek a főiskolákon és egyetemeken vannak meg, ahol viszont vannak Orosz László szerű emberek, akik képtelenek megérteni, hogy nekik nem 10 elméleti zsenit kell tanítani, hanem mellette a 890 gyakorlati embert is, hogy legyen elég adóbevétel a fizetésére például.

"A matematika, a fizika, at információ és kódelmélet, az algorimuselmélet nem avulnak el."

Csak tudod, kurvára nem érdekel senkit az iparban, amikor ezeket nem használják fel. Igen, lehetne OKJ képzésben is tolni a programozást, lehetne csak arra koncentrálni, amire kell.

Én azt hittem ezt fogja megoldani a coder school-ok megjelenése, de azóta csak rosszat hallottam róluk. Lehet majd kiforrnak, de az is lehet, hogy még a cégeknek kell változni, és nem svájci bicskákat kell a sulikból várniuk, hanem vajazókéseket.

(Egyébként amit írtál a társadalom felépítéséről, az az egyik legnagyobb kérdés a bolygón, mert hogy nem jöttek rá még az okosok, hogy hogy is lehetne 890 jó eszűt csinálni, amikor a társaságban 900 még csak nem is biztos, hogy Turing pozitív, és közben egyre kisebb szüksége van a 10+90-nek a 900-ra, viszont a 900 még mindig le tudja nyomni a 10+90-et egy jó kis forradalommal, vagy akár csak egy demokráciában.)

Az tény, hogy a coder school-ok úgy néz ki alá lőttek, amit hallottam az alapján az van, hogy ezt-azt megcsinálnak a tanulók, de a cégek nem tudták hova tenni őket a fél-másfél év képzés után a cégen belül, ergo vagy hosszabb lesz a képzés (megyünk az egyetemi nagyságrend felé), vagy a cégek alakulnak hozzájuk.

Turing pozitívról annyit, hogy évek óta mondom így, napokban 444-en láttam talán egy cikket, amiben magyar, talán kutató, mondta ugyan így, úgyhogy megnyugodtam. Megnézel egy hibabejelentő online form kimenetet, vagy találomra bármelyik chat platformon a beszélgetések szinvonalát, és rögtön bizonyítva is van :).

"egyszer regen irtam egy irc botot awk-ban
a turing teszten ugyan elbukott csufosan, de a sulinet tesztet 99%ban teljesitette
ertsd: rengeteg sulinetes user kepes volt vele fel oranal tovabb beszelgetni, egy-ketto kuldott kepet is magarol, telefonszamot is sikerult beszerezni...
az eredmeny eleg szomoru, tekintve, hogy 200 mondatnal hosszabb "szokincse" nem volt a botnak"
-kajastancos, HUP.hu

Szoval van lejjebb.
Pl. Ott van Justin Trudeau alakitasa..

--
If you get a good wife, you'll become happy; if you get a bad one, you'll become a philosopher. -Socrates

A kóder school azért nem oldja meg, mert komoly szükség van a mérnöki tudásra, csak nem úgy, ahogy azt az egyetemek gondolják.
Azt sem mondom, hogy az elméleti tudásra ne lenne szükség, viszont hogy abból mit kellene tanítani, az szerintem már inkább vita téma.
Nálunk pl. minden egyes kis hülye tételnek kellett tudni vizsgára a bizonyítását. Ez nagyon jó, de erre valójában semmi szükség nem volt
(főleg olyan tételre, aminek vagy 3 oldalas volt a bizonyítása, és aki kihúzta szóbelin, az mind mehetett is haza).
Ezek helyett sokkal inkább szükség lett volna gyakorlatiasabb képzésre, ahol lényegesen több valós, gyakorlati példával találkozunk, ahol
megértjük, hogy a sok absztrakt elméletnek hol van a helye. Most 37 éves fejjel jutottam el odáig, hogy ha MOST végezném újra azt, amit
18 évvel ezelőtt tettem, akkor esélyem lenne VALÓBAN érteni azt, amiről a tanárok beszéltek, anno egyszerűen azért, mert mostanra lett annyi
gyakorlati tapasztalatom, hogy a legtöbb dolgot tudnám mihez kapcsolni, és nem csak lebegne a levegőben.

Tehát ami szerintem az alapvető baj a mostani egyetemi képzéssel, hogy 18 éves gyerekektől olyan gyakorlati és elméleti tudást vár el, amivel
egyszerűen nem rendelkeznek, és nem is rendelkezhetnek. Mindent IS meg akarnak tanítani (valójában csak le akarják adni), ami annak az említett
20 embernek megy, aztán meg jön a csodálkozás, hogy "milyen hülyék ezek a diákok".

"Én azt hittem ezt fogja megoldani a coder school-ok megjelenése, de azóta csak rosszat hallottam róluk."

Miért oldaná meg? Segít rajta valamennyit, de attól még kellene képezni egy csomó gyakorlati szakembert, akiknek a képzése amúgy 3-5 év minimum, mert annyi szakmai ismeretre van szükség már területre specializáltan is.

Értem én, hogy Orosz László kurvára szeretne 400 főnek kvantummechanikát tanítani, csak épp ebből a 400 főből talán egy lesz olyan, hogy erre szüksége van, de ő is képes lenne önerőből utánanézni, ha megnéz felvételről egy előadást a témában. A többi 399 mérnök soha az életben nem fogja használni és alkalmazni olyan mélységben, amilyen mélységben tanítanák. Ellenben egy csomó olyan IT elméletet nem tanulnak meg, amely viszont nagyon-nagyon-nagyon hiányzik a pályakezdőkből.

És lehet mondani, hogy az egyetem szemléletet ad. Lófaszt az szemlélelet, akik odamennek, azokról már az általános iskola végén messziről érezni, hogy van tehetségük bizonyos dolgokhoz, aztán vagy bírják az egyetem "szemlélet-formálását" és később elfelejtik vagy kibuknak, mint annyian és alapítanak valami fasza céget inkább.

--
https://iothub.live

Szerintem te magadból indulsz ki, ahogy mindenki, aki szerint szemléletet ad. Neked már _volt_ szemléleted, amikor odakerültél, nem ott kaptad, maximum megszűri az egyetem a jelentkezőket és a hallgatókat, de ez a szűrés se feltétlen optimális, sokan kerülnek be és végeznek, akik végül pályaelhagyók lesznek és sokan esnek ki, akik az egyetem nélkül is remekül megállják a helyüket. Azt felejted el, hogy aki odakerül, az már egy fölözés abból a sokaságból, akiket nem vettek fel és pláne abból a sokaságból, akik meg se próbálkoztak a felsőoktatással.

"Rengeteg lehetőséget a tanulásra. Nem feltétlenül órán. Aki csak az órákra jár, elvégzi az egyetemet és utána béna kezdő az magára vessen."

De ehhez akkor minek az egyetem? És miben segít egy Certified Reboot Engineer napi munkájában az, hogy fél éven át Orosz Lászlót hallgatja a kvantummechanikáról?

Szerintem adott egy szemléletet, egy rendszert. Nem zárom ki, hogy ezt egy x munkahelyen is megkaptam volna, de a tény attól az marad, hogy én a BME-n kaptam mérnöki szemléletet és hozzáállást a dolgokhoz.

Minek az egyetem? Koncentrált tudás, erőforrás.

Az egyetemi oktatás szerintem hasonlít az alapkutatásra. Nem feltétlen látszik azonnal, hogy mire lesz jó az eredménye de abban nagyjából mindenki egyetért hogy ha nincs alapkutatás akkor nincsenek szintlépések a tudományban és a technikában.

Btw provokatív kérdés: ha a műszaki egyetem felesleges akkor a bölcsész egyetem micsoda? :D

--
Gábriel Ákos

"Szerintem adott egy szemléletet, egy rendszert. Nem zárom ki, hogy ezt egy x munkahelyen is megkaptam volna, de a tény attól az marad, hogy én a BME-n kaptam mérnöki szemléletet és hozzáállást a dolgokhoz."

Miből gondolod, hogy ez benned nem volt meg előtte és ott kaptad meg? Én például több évet tanítottam középiskolában, nagyon markánsan látszott, hogy kiben van mondjuk műszaki tehetség és kiben nincs; kinek van problémamegoldó szemlélete és kinek nincs. Ezek mindegyike csak minimálisan tanulható és fejleszthető soft-skill, kaphatsz persze 'aha'-élményt, de csodák nincsenek, nem lesz műszaki érzéked azért, mert megtanulod. Egyébként az a helyzet, hogy nem én adtam hozzá, sőt, nem is én hoztam ki ezeket a diákból, maximum elnyomni tudtam volna, ahogy annyi konzervatív és vaskalapos tanár.

Egyszerűen az a helyzet, hogy akiben volt ilyen tehetség és szemlélet, ment tovább a felsőoktatásba, ahol aztán ezt vagy elnyomták benne vagy túlélte valahogy. De ott nem kapott ilyet, mert ezt nem lehet csak úgy adni.

"Az egyetemi oktatás szerintem hasonlít az alapkutatásra."

Vagy megszépíti az idő vagy nem ugyanarról beszélünk.

"Btw provokatív kérdés: ha a műszaki egyetem felesleges akkor a bölcsész egyetem micsoda? :D"

Ugyanannyira felesleges, de nem ez volt a kérdésem mögött, hanem az, hogy aki végigtolja az egyetemet úgy, ahogy azt kell, az egy béna kezdő.

"Aki csak az órákra jár, elvégzi az egyetemet és utána béna kezdő az magára vessen."

Ezek szerint nem kap mindenki szemléletet? Biztos, hogy azt az egyetemen adják?

Nem a konkrét tananyagra, vagy előadóra reagálok, mivel nem tudom hol mit tanultál. Viszont elvileg nagy haszna is lehet, ha valaki fejlesztő. Pl nagyon jó dolog, ha utasításkészletet raksz össze, vagy algoritmusokat is könnyebb úgy tanulni, ha már ezt tudod, valamint kódelmélet és ezzel párhuzamosan gyakorlatnál is. Sok olyan dolog van ami nem mindennap használatos dolog, ritkán kell, de akkor nagyon jól tud jönni. Egy kicsit más példa, de fejlesztő haver mesélte, kellett holtpont nélküli algoritmust összedobni bonyolúltabb problémára. Első körben elkeztek rajzolgatni és szakértették nagy erőkkel. Aztán mikor elfogyott a tudomány feldobták a PETRI hálót és onnan már viszonylag könnyen megoldották a problémát. Elmondása szerint szökőévente egyszer kell, de akkor nagyon nagyot lehet nyerni.

Az másik kérdés, hogy ilyen technikákat szerintem csak nagyon jóarc oktatóknak lenne szabad tanítani, mert amikor nem látszik az azonnali haszon, akkor amikor ritkán kell és jó élmények vannak az adott dologról könnyebb elővenni, míg ha keménykednek a hallgatóval, akkor se veszi elő ha tényleg iszonyatosan nagyot nyerne vele.

A kérdés számomra a képzettség és folyamatában tanuláshoz kanyarodva az, hogy ha nem tanulta volna a PETRI hálót, akkor tudta-e volna, hogy azt kell ott alkalmazni, vagy a problémára segítséget keresve van-e olyan eszköz, ami rövid idő alatt erre irányította volna, és megtanulhatta-e volna (vagy fordítva? volna-e?) rövid idő alatt?

Eloszor is, en is imadom a batyam es azt mondom egy zseni. :D

Masodszor, az egyetemi kepzes nekem kb. nem sokat adott tobb, mint husz evvel ezelott (orok baratsagokon kivul). Amit ma tudok, azt onkepzessel ertem el, illetve a munkatapasztalat adta. Persze lehet a BME mas. Bar ismerek korosztalyombol BME-st akinek ugyanez a velemenye. :D

Harmadszor, junior java kepzesbol dunat lehet rekeszteni a youtube-on, ingyenes konyvek segitsegevel onkepzessel, stb, stb.

Negyedszer, voltam oktato es az a velemenyem, hogy egy oktatasnak nem csak az ismeretek atadasa a fontos, de a tudasanyag strukturalasa is. Ez utobbin mulik, hogy a kikerulo ember mennyire tdja majd megallni a helyet. Sajnos lattam/latok olyan treningeket, amik atadjak ugyan a tudast, de azt nem strukturaltan teszik, igy hamar kiszall a fejekbol illetve meg sem ragad ugy es ott, ahogyan annak kellene.

Otodszor, igen talalkoztam olyannal, aki sikeresen atkepezte magat elmeletei fiziksbol java programozonak.

Hatodszor, leteznek olyan helyek, ahol nem nagyon szamit aq diploma csak is a tudas. Ezek foleg multinacionalis vallalatok, ahol problemara keresnek embert, akiben biztosak akarnak lenni, hogy meg is tduja oldani azt es nem "keresunk egy embert oszt majd csinal valamit ahogyan tudja, de legyen diplomaja".

Azert arra erdemes figyelni, hogy mivel tenyleg hiany van programozobol, lehet hogy kevesebb tudassal is el tud helyezkedni egy-egy ilyn "lehuzos" ceg tanfolyama utan, azaz nem lesz hiabavalo. Persze nem szabad a sultgalambot varni. Ha meg a szerzodese garantalja, hogy kap munkat a kepzes utan, akkor ezzel nincs gond. Az egyetlen gond lehet, ha fixen kikotik, hogy veekig annal a cegnel kell dolgoznia majd es nem lephet le egy jobb helyre. De van ilyen? Lehet ilyet?

Az elméleti fizikus egy jó alap. Nem olyan, mintha valaki egészségügyből képezné át magát.

Fogalmam sincs milyen szerződések vannak egy ilyen képzésnél.

Mondjuk van némelyiknél bootcamp, de az sem 1 peták.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

2 belemenősebb, szerintem már elvibb kérdés:

- kell-e minden jelenleg abból, amit (maradjunk a példánál) a BME tanít az alapképzésben? kell-e minden ebből ahhoz, hogy elinduljon valaki junior-ként? mindenkinek kell, vagy minden amit a BME tanít kell majd valamelyik tanulójának, de nem mindnek? van-e olyan része, ami belátható önszorgalmi idő alatt nem tanulható meg éles helyzetben? (elégséges ütemezés mellett, előre tudva a cég és az egyéni karrier irányát) ez a "van-e élet diploma nélkül körkérdés"

(a minden definíciója alatt akár a testnevelést és a közgázt és az analízist is értem, szerintem úgy helyes az összehasonlítás, ha az egész csomagot, de még a nyelvvizsgát is nézzük, ami mondjuk IT-ben jó, ha angol, de kérdés, hogy elviselhetetlen-e nélküle az élet, és pótolhatatlan-e később)

- van-e BME szintű tananyag elérhető formában BME keretein kívül? könyvek, video tanfolyamok, rövid és hosszú tanfolyamok (hosszú alatt a fentieket értem) formájában? van-e tanmenetnek megfelelő struktúra pl. egy könyvkiadónál, vagy lehet-e tudni merre kéne tovább menni? van-e megfelelő mentorálásra lehetőség?

Tuti, hogy csak egy részét használja majd, aki egy egyetemet elvégez. Nem csak az informatikára vonatkozik. Jó eséllyel boldogulni tud random környezetben.

Az egyetemi képzésnek van hova fejlődni pont azokat a területeket illetően, amit írsz. Nem csak IT-re vonatkozóan.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Mármint szerintetek az egyetemi képzésnek az lenne a célja, hogy szakmunkás diplomásokat dobáljanak ki a kapun, akik pontosan egy dologhoz értenek? Az egész oktatási rendszer (a bolognai rendszer bevezetése óta a felsőoktatás még inkább) arról szól, hogy a megfelelő és széles látókört biztosító alapok elsajátítása után lehet specializálódni adott rész-szakterületre és abban elmélyülni.

Az IT annyiból különleges, hogy a jogi környezet lassabban reagál, mint ahogy új szakterületek kialakulnak és megszűnnek, úgyhogy nagyon nehéz specializált képzéseket indítani (humán erőforrás és tudás összeszedése, infrastruktúra biztosítása, akkreditáció, szakalapítás stb.).

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Pont nem erről írtam, olvasd újra. Elsődlegesen az a kérdésem volt több részletben, hogy az egyetem pótolható-e, tárgyilagosan a tudás elérhető-e egyáltalán adatként, és munka mellett lehet-e lépésekben felszedni a tudást, vagy mindenképp kell az az izoláció a termeléstől, amit egy 3-6 éves egyetem jelent (hagyjuk a gyakorlatot, itt a napi 6-8 óra munka vs egyetemi tanulmányok mellett végzett munka mennyisége a kérdés). Ez struktúrális kérdés, nem az a kérdésem, hogy egyetemen egy konkrét dologra képezzenek-e, mert arra a válasz NEM. De nagy kérdés, hogy az évekig mindenfélét bemutatunk, aminek nagyon nagy részét kidobod az ablakon, és csak egész kicsit befolyásolja a világnézeted, az jó megoldás-e. És az is nagy kérdés, hogy ha egyetemi tanulmányok helyett / nélkül nekivág valaki programozni, lépésekben fel tudja-e szedni a tudást úgy, hogy nem vonul el fél-1 évre egy adott területet tanulni. Lentebb írják, és másik témákban is rendszeresen feljön, hogy még a diplomás programozó is néha évek, mire önálló tud lenni, emellett ért olyan dolgokhoz, amiket sose fog érinteni. Ehelyett megoldás lehet-e egy cégnél a folyamatos képzés, akár napi óraszámban, számolva azzal, hogy akkor viszont olyanra nem térünk ki, ami tényleg felesleges az adott témakörben.

Disclaimer: Ismét vélemény-rovatunk következik.

Elsődlegesen az a kérdésem volt több részletben, hogy az egyetem pótolható-e, tárgyilagosan a tudás elérhető-e egyáltalán adatként, és munka mellett lehet-e lépésekben felszedni a tudást

Erre a válasz természetesen igen. Ha más nem, úgy, hogy megveszed a könyvesboltban az egyetemi jegyzetet és végigolvasod. Vagy elvégzel a Coursera-n egy-két kurzust, ami éppen kell neked.

Ami viszont lényegesebb (és ezért a fentebb idézett mondatod nem idézett második felére a nem lenne a válaszom), hogy az egyetemi végzettség nem az aktuálisan felmerült problémára ad neked egy megoldást (Probléma: akarok Java-ban kódolni. Megoldás: Feliratkozom egy Course-ra kurzusra), hanem (jó esetben) úgy van összeállítva a tanterv, hogy találkozz benne mindennel (legalább felületesen), amivel az adott végzettséggel a szakmában elhelyezkedve találkozhatsz (pl. fentebb írták példának a 3-way handshake-t... fejlesztőket nagy valószínűséggel max. wireshark dumpban fogsz vele találkozni egy brutálisabb debug session környékén; ha viszont odakerülsz, hogy egy brutálisabb debug session közepén kapsz egy wireshark dumpot, akkor nagyon fog hiányozni a hálózatok kurzus). Persze csinálhatod azt, hogy végigcsinálsz majdnem minden kurzust, amit látsz egy egyetemi tantervben, de akkor már egyszerűbb (és mivel papírt is kapsz róla, hatékonyabb), ha végigcsinálod az egyetemi képzést :)

még a diplomás programozó is néha évek, mire önálló tud lenni, emellett ért olyan dolgokhoz, amiket sose fog érinteni.

Igazából olyan statisztika lenne érdekes, hogy a felsőfokú végzettséggel rendelkezők és nem rendelkezők esetében mennyi idő alatt érik el az önálló produktivitás szintjét és utána tudják-e növelni a munkavégzésük szintjét/hatékonyságát (értsd pl.: mennyi idő alatt veszik el a pozíciójuk elől a junior jelzés és megérik-e a cégnél senior cím kiérdemlését, vagy időközben nagyon elbasznak-e valamit :) ).

De nagy kérdés, hogy az évekig mindenfélét bemutatunk, aminek nagyon nagy részét kidobod az ablakon, és csak egész kicsit befolyásolja a világnézeted, az jó megoldás-e.

Ha az elméleti rész csak kicsit folyásolja be ( :) ) a világnézeted, akkor valamit rosszul csinálsz. :) Egyébként élek a gyanúperrel, hogy ezt többnyire azok hangoztatják, akik általában "elfelejtettek" bejárni a nem kötelező órákra, és tisztán a jegyzetekre/tankönyvekre/puskákra támaszkodva csúsztak át a vizsgákon. Mert ott (akár csak egy fél mondattal is), de elhangozhatnak olyan dolgok, amik a könyvben nincsenek leírva, viszont a "nagy kép" összeállásában segítenek (triviális példa: valamelyik matekos tárgyon [nálunk diszkrét matematika] találkozol a gráf definíciójával, azzal, hogy mi merre hány lépés, néhány bot egyszerű gráfokkal kapcsolatos algoritmussal/tulajdonsággal, amit még magadtól felfedezni sem nehéz, de ott a szádba rágják. Ezután egy elméleti infós tárgyon [nálunk algoritmusok és adatszerkezetek] már feltételezve azt, hogy tudod mi-merre-hány-méter egy gráf, találkozol azzal, hogyan lehet/mitől függ, hogy hogyan érdemes őket tárolni (és pl. elég annyit mondani, hogy sparse/ritka, és tudod, mit jelent, nem kell megnézned a definícióját), hogy milyen tök jó algoritmusok vannak rájuk stb. Aztán találkozol ilyen gráfokkal az ezer másik specializációs kurzuson.

Az elméleti alapoktól az egyre gyakorlat-közelibb alkalmazási lehetőségekig szépen egymásra vannak építve a dolgok és a stabil elméleti alapok miatt érteni fogod. Ha mindig csak az aktuális problémára keresel megoldást (pl. "legrövidebb út három település között", tuti találsz stack overflow-n kulcsrakész megoldást és tudod használni, viszont a megfelelő alaptudással a problémát a megfelelő absztrakciós szinten tudod kezelni). Ugyanígy, végigcsinálhatsz egy mondjuk JSP kurzust on-line, ha ott nem részletezik az alapoktól ([IP+]TCP+HTTP+SSL/TLS+Servlet konténer/kiszolgáló), akkor lesz egy csomó hiányos tudásod. Meg tudod írni a hello world-öt? Persze, meg. Meg tudsz írni mondjuk egy hatékony menetrend alkalmazást útvonaltervezővel? Nem biztos, mert ugyan tök jól JSP-zel, de nem _biztos_, hogy valaha hallottál gráfokról.

És visszajutottunk oda, hogy: "Persze csinálhatod azt, hogy végigcsinálsz majdnem minden kurzust, amit látsz egy egyetemi tantervben, de akkor már egyszerűbb (és mivel papírt is kapsz róla, hatékonyabb), ha végigcsinálod az egyetemi képzést :)"

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

A szálindítóban jobban kifejtettem a témát, ahogy írod is, nem csak a tárgy tartalmi elérhetősége a fontos, hanem a struktúra, hogy ne akkor kezdjen bele egy 2-3 hetes kutatásba, amikor belefut a kérdésbe. Megjegyzem így is biztos, hogy van amibe belefut egy végzett mérnök ÉS kutatni kezd, csak persze nem biztos, hogy erre van építve a cég körülötte, kiszervezik inkább a feladatot, vagy van a problémára egy piacon elérhető megoldás. De az se lehetetlen, hogy a hálózati problémába belefutva egy !junior / senior kijelöli a továbbiakban tanulandókat, megoldja ő a problémát.

"Ha az elméleti rész csak kicsit folyásolja be ( :) ) a világnézeted, akkor valamit rosszul csinálsz. :)"

Nem az volt a mondatom célja, hogy "minden amit tanulok kicsit befolyásol csak", hanem hogy van egy rakás dolog a tanított anyagban, ami esélyes, hogy nem mindenkinek kell, és igazából a logikámat sem fejleszti, az nem hatékony.

Nekem az alapvető kérdésem (még csak kialakult véleményem sincs, csak a kérdést vetettem fel) az volt, hogy van-e más terv, mint az egyetem. Lehet bővítenem kéne a kérdést állami egyetemre, vagy több éves inkább elméleti központú egyetemre, ..., a probléma amit próbáltam jelezni számomra az, hogy egy állami egyetem papírja nem biztos, hogy kéne annyit érjen, amennyit most ér, a tudásnak kéne, ami mögötte van, csak ezt ugye nem találta ki sok cég, hogy hogy kéne máshogy mérni, mint a diplomával. Láttam már programozói tesztet (nem konkrét nyelven, inkább algoritmus elméleti tudást mért), és utána személyes elbeszélgetést, ahol konkrét technológiákról kérdeztek nagyrészt (nagyon kevés elméleti tartalommal), látom a probléma nagyságát. Csak nem tudtam van-e alternatíva, és itt nem a "végigcsinálsz mindent"-re gondolok, hanem hogy ha bemegyek az egyetemi könyvkiadóhoz, akkor egyáltalán elérhető-e minden tananyag, vagy az elmélet egy része, a gyakorlatokon bemutatott példák már nem, hisz senkinek nem érte meg legyártani könyvben, úgyse keresik, ...

hanem hogy ha bemegyek az egyetemi könyvkiadóhoz, akkor egyáltalán elérhető-e minden tananyag, vagy az elmélet egy része, a gyakorlatokon bemutatott példák már nem, hisz senkinek nem érte meg legyártani könyvben, úgyse keresik, ...

Az elméleti része meg lesz (ha van egyáltalán jegyzet és nem valamelyik vaskos könyvet követi a kurzus, pl. a Tannenbaum-féle szentháromságot), a gyakorlatok anyagai szinte biztosan nem, egyrészt pont azért, amit írsz (kereslet hiánya), másrészt ott is ott lenne az átfutási idő, ami miatt mire a lektorhoz kerül, már elavult, harmadrészt pedig... a kereslet hiányára sokszor mondják, hogy persze, hogy senki nem keresi a kurzushoz tartozó 3-5-8k HUF-ba kerülő könyvet és ilyenkor általában a tanár hibáztatják, hogy mekkora kapzsi rohadék... pedig nem, a legjobb esetben is max. akkora tiszteletdíjat kapnak, amit itt egyesek órabérnek is keveselnének, egyszerűen nem lehet gazdaságosan kis példányszámú könyvet előállítani tisztán piaci alapon - ezért van az, hogy ha megnézel az elmúlt pár évben itthon született oktatási anyagot, a legtöbbjén lesz valamilyen pályázati logó.

Az open access és úgy általában a tisztán elektronikus kiadás egy kicsit úgy tűnik, hogy ha lassan is, de javít ezen, mert bár ott is ott van, hogy nem éri meg a beleölt órákat (kivéve, ha támogatott, persze), de nem pár tíz-száz emberhez juthat csak el, ami egy-két embernél jelent akkora pluszt, hogy mégis nekiáll (mások szemében meg ez minuszos is lehet, persze).

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Pár éve vannak kiváló minőségű IT előadássorozatok youtube-on is, konkrét egyetemi előadások felvéve, tananyaggal belinkelve, ezért merült fel bennem, hogy oké, de ezekből valakinek össze kéne rakni egy struktúrált oktatási tervet. Némelyik előadásnál meg is beszélik a gyakorlati órán mit kellett volna átlátni, csak részben, de még ez is jó. Ötletem sincs elsőre, hogy itt mi a megtérülés alapja.

vö. a szállóigeként hangoztatott 50 év lemaradásunk.
Annyira bele vagyunk (ti. oktatók) épülve a 5 éves képzésbe, hogy a bscben is egy 5éves képzést látnak, képzelnek, erőltetnek. Persze, hogy szar.
A bolognai rendszer egyik sarokköve, azaz a kreditrendszer lényege az, hogy ha elköltözök/dolgozok, akkor különösebb hiszti nélkül át tudom vinni máshova a kreditjeimet, vagy szüneteltetni tudom a tanulmányaimat.
Itthon mi van? Ugyanazt a szakot külön akkreditálják az külön egyetemek, így nem átjárható, meg Debrecenben pl az volt a móka, hogy max 2 félévet szünetelhetsz egymás után (és összesen 4-et), különben buktál mindent. És ha én 2 éves kiküldetésen vagyok épp Malajziában? Akkor rábasztam, ennyi, minek dolgozom.
Ez pont az ellentéte, mint ami a bolognai rendszer elve lenne.

Az kéne hogy mikor kikerül az egyetemről a diplomás "szakmunkás" akkor a széles látókör melett legalább egy dologhoz értsen is.

===============================================================================
// Hocus Pocus, grab the focus
winSetFocus(...)

http://c2.com/cgi/wiki?FunnyThingsSeenInSourceCodeAndDocumentation

Hali,

szerintem a 250k nettó elég alap Bp-en, nem is tudom, hogy ad-e valaki kevesebbet fejlesztő melóra. Egyébként nálunk pld. az a lényeg, hogy legyen egy diplomája a fejlesztőnek, de az mindegy, hogy mi: szóval van aki kémiás, van aki pénzügyi területes. Fél év alatt szerintem annyira lehet kinevelni max egy embert, hogy felügyelettel már tud csinálni ezt-azt, de még akkor is inkább a tapasztaltabb fejlesztők idejét viszi el ez az egész, szóval hosszútávú befektetés ez egy cégnek.

Nekem is pont ez jutott eszembe. 250k még kezdő fizetésnek is nagyon kevés. Szerintem nem mindegy, hogy milyen diploma, mert például ha valamiért mégiscsak szükség lesz azokra a fent emlegetett hálózati ismeretekre akkor lehet folytatni a házon belüli nevelést mert vegyész szakon ilyet nyilván nem oktattak. Az pedig idő, a tapasztalt fejlesztők továbbképzésre lekötött erőforrásai mert oktatnak fejlesztés helyett és így pénz.
Az is igaz, hogy kevés a fejlesztő szóval megértem amit írsz, de még akkor sem mindegy mi az a diploma. Mert egy vegyészből lehet jó fejlesztő de egy bölcsész csak kerékkötőnek jó.

Normális HUP-ot használok!

> Mert egy vegyészből lehet jó fejlesztő de egy bölcsész csak kerékkötőnek jó.

Azert szerintem a UX design / research korul is sokat szamithat az emberkozelibb ismeretanyaguk.

Ugyan nem kimondottan fejlesztes, de azert manapsag az IT nem csak kabelek dugdosasabol, meg programkodok irasarol szol. Nagyon sok lehetoseg van mas tudomanyteruletekrol erkezoknek is hasznosnak lenni a technologiai iparban.

Menjen el egy programozoi kepzesre, jojjon ra, hogy ez nem feltetlen neki valo, de talalja meg a lehetosegeket, ahol fel tudja hasznalni az ujonnan szerzett tudast is.

Mondjuk kerdes, hogy product owner eseten mi a jobb. Ha volt mar korabbi programozoi tapasztalata, es ha igen mennyi, vagy nem? Jobb az, ha sejti, hogy ez mennyi effort, vagy jobb az, ha a programozokra tamaszkodik? Vajon melyik a jobban meggyozhetobb egy refactoralasrol? :)

"A második, hogyha megnézek egy rendes álláshirdetés portált, ott a junior programozói pozíciókat is felsőfokú végzettséghez kötik. Természetesen fizetést nem írnak, de tudom, hogy kevesebb, mint a fenti hirdetésben promózott összeg."

Akkor se biztos hogy kötelező ha oda van írva. Engem felvettek olyan pozira aminek a leírásában szerepelt, és elmentem dipi nélkül. Nem számított. :)

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

"kinézte magának az IT-t"

Mi az, hogy "kinezte"? Mert az sok penzt fizet? Mert az IT-sek egesz nap a gep elott ulnek es vakargatjak a tokeiket? Mert azt a huje is meg tudja csinalni? Akkor mar miert nem megy politikusnak? :)

Egyaltalan, hogyan jutott el az IT-tol addig, hogy "Java programozo"? Akkor mar miert nem Javascript? Vagy PHP?

Miert nem kezdi mondjuk tesztelessel, ahhoz tenyleg nem kell mas, csak logikus gondolkodas, es az adott business ismerete (ezek gyorsan elsajatithatok olyan szinten, amivel mar onalloan lehet produktiv).

A programozassal az a baj, hogy ilyen gyorstalpalo tanfolyam utan programozni kabe olyan, mint orvosi egyetem nelkul/helyett egy elsosegelynyujto tanfolyam utan elmenni sebesznek, mert ott ugyis csak vagdosni kell jobbra/balra, azt meg a sogor is meg tudja csinalni, amikor disznooles van, nem?

+1. Aki egy ilyen képzésről kijön arra lesz jó hogy el tudja indítani a mavent meg az intellij -t de az első problémánál hívni fogja a szomszéd seniort, hogy segítsen már, mert malformed a settings.xml nála és fingja sincs mit kezdjen a helyzettel. Alapozni lehet hogy jó, de produktív munkára garantáltan alkalmatlan lesz az emberke. Majd ha "tűzben edződik" 1-2 évig.

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

A seniorok munkájának igencsak része az, hogy segítsen a junioroknak. Lehet, hogy egy senior egymaga elvégzi 1.5 ember munkáját, de ha mondjuk az ideje nagy részében segít 5 juniornak, és őmaga így már csak 0.5 ember munkáját végzi el, akkor az összesen 5.5, ami sokkal több. (És tegyük hozzá, azért a junior ne legyen teljesen hülye.) Persze ez egy széles spektrumon mozoghat, aminek az egyik végén 100% kódolás, a másik végén 100% tech leadership/people management van. Hosszabb távon nézve egy karriert (már ahol létezik ilyen), puszta kódolással nem lehet egy adott szint fölé menni.

Teljesen igazad van, csak szerintem van különbség aközött a junior között aki gyerekként már kódolt, és hobbiszinten fejleszti magát, elvégezte / folyamatban van az egyetem neki, csak még nem látott éles projektet, meg aközött a junior között aki tetszőleges egyebet csinált, csak "megtetszett" neki a szakma huszon/harminc X évesen. Akár rögtön azzal kezdve hogy egy raklap hard skill nincs meg neki.
--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

Kezdje teszteléssel, nulla tudás mentén? mit fog akkor "tesztelni-e", ha azt se tudja mit kellene "tesztelni-e"? :)
a business logic ismerete egyáltalán nem elég...sőt...az kb a teszt 2%-3%át teszi ki...csak épp azt a részt a developer is "teszteli", hisz az készül el a kódja által...a tesztelés maradék 97%-a meg arról szól amire a developer nem gondolt, vagy csak simán lexarta, mondván úgyis jó az... :)

Én rossz ötletnek tartom az ilyen gyorstalpalókat. Én 10 éve fejlesztek különböző nyeleveken, de nem merném magam profi fejlesztőnek nevezni...

Az meg hogy melyik programnyelvvel kezdi, majdnem mindegy is...ha rendesen akar programozni, akkor papír ceruza kell hozzá...számítógép majd kb a 4.-5. hónaptól kezdve...addig papír ceruza...sok matek, meg különböző programozási paradigmák megismerése...algoritmusok...

forráskódot írni én meg nem engendnék senkinek, max 7-8. hónaptól...

Így marad az utolsó mondat. azzal egyet értek.

4-5 hónapig papír ceruza, tudod mit mond erre a bakter. Tökéletes módszer arra, hogy a diákok fele sírva elfusson, a maradék 90%-a meg az elméletet sosem megértve túlesik rajta. Írjon kódot az elejétől, ütközzön problémákba, amikre ismertessék a megoldást, és ha már látja hol mi a gyakorlati értelme, akkor lehet rá elméletet rakni. Pont mint ahogy a valóságban történt..

+1
Az elmelet szorgos uldozeset el kellene mar felejteni, ahol gyakorlati eszkozokre nincs penz, hat magoltassunk szemletetet.

Semmit nem er az egesz ha nincs mihez kotni, azaz nincs gyakorlat mogotte. Kettot egyutt a legjobb csinalni.

Elmondom h a kolkok mit csinaltak altalanos iskolaban:
-GPS-el a kezukben jartak korul a tankertet es szamoltak keruletet
-Szakkoron lezervagoval nyomtattak katapultot, ratettek microbit-et es megneztek milyen gyorsan lovi ki a lovedeket
-Arduinoval merik a vizi novenyek levegotermeleset kornyezettol fuggoen. Webes interface-en keresztul latjak az eredmenyeket a telefonjaikon (most epp en is segitek egy ilyen rendszert letrehozni.)
-Robotversenyek
-Csirket vagtak es megfoztek, lattak honnan jon a kaja.
-Fiuk hegesztettek
-Lanyok tancolnak, zongoraznak (igazi es szintiken), mas hangszerrel jatszanak.
-Tortenelem oran anyaghoz kapcsolodo dolgok elkeszitese pl egyiptomi ekszerek, fejdiszek stb.
Ez csak egy egyszeru allami suli. Van kevesbe technika orientalt suli is, nekik vannak lovaik.

Tobbi nem jut eszembe. Mivel rengeteg mindent csinalnak, ezert amikor elhagyjak a sulit, jobban tudjak milyen szakmat/tovabbtanulast akarnak valasztani, jobb az egyuttmukodes is egymas kozott, tobb gyakorlatot szereztek.

Igaz, nem M.o-n elunk, es valahogy tobbet rak az onkormanyzat az oktatasba stadionepites helyett.

+1 Ha az elméletet sikerül gyakorlattal jól összekapcsolni (sorrend szinte mindegy:), az hasznos mindenkinek, jobban is megmarad. Random belenézve pl. Yt-on Primitive Technology sorozatokba merem állítani, hogy jól iskolázott, okos emberkék is küzdenének erősen ha szokatlan területen, támogatás nélkül kellene helytállni. Ilyenkor jön jól ha megtanultak gondolkodni, infót keresni és feldolgozni és nem kétségbe esni :)

Nem értek egyet teljesen, de ettől szép az élet...Én azért vagyok képes fejleszteni Java, C#, C++, Javascript, PHP, bármely SQL, Typescript, Android, Python, Bash, és egy kis létradiagrammos PLCzés is, mert annó (ezek azok a nyelvek amikkel alkottam már maradandót, idézem "tarháért":) )
fősulin megtanítottak, számítógép használat nélkül "fejleszteni". Képet kaptam arról, hogyan működik maga a szofter fejlesztés mindegy milyen a programnyelv, milyen alapok vannak amelyek mindig ugyanazok. Én a feladathoz választom a programnyelvet, ha pedig nem ismerem a választott nyelvet, akkor rövid időn belül képes vagyok elsajátítani...
De ehhez igen is kellett a papír ceruza. Először én sem értettem, hogy miért. Persze nem azt mondom, hogy másképp nem lehet, de azt merem állítani, hogy ez így biztos alapokat ad.

Mndig jot derulok ezen a rovid idon belul megtanulok barmilyen nyelvet kijeletesen. Mert ez kb arra igaz, hogy eljutsz arra a aszintre, hogy megirj jol egy zh-t. De attol meg honapokig olyan kodot fogsz irni egy uj nyelvben, hogy a veteranok elsirjak magukat. Legalabb tucatnyi peldat lattam erre, c# szakiknatjottek javazni, volt aki par honap utan maga kerte vissza magat, a tobbsegnek meg kb fel ev kellett felvenni az uj konvenciokat. A valo elet tobbrol szol, mint hogy lefordul a kodod, ezt ido kell felvenni, es ezt a tudast nem papirrol veszed fel..

Ez nagyjából igaz, és nagyon szépen látszik ezen a Dunning-Kruger-hatás is. Az igazán tapasztalt ember belátja, és érzi, hogy ha új nyelven szar kódot ír, és utánanéz a konvencióknak, mielőtt bármit kiad a kezéből. Ezért van pl. a Google-nél readability minden programnyelvre.

"Mert az sok penzt fizet? Mert az IT-sek egesz nap a gep elott ulnek es vakargatjak a tokeiket?"

Bizony léteznek ilyen szempontok is. Rack szekrény összerakásakor könnyen bekoszolódik a DKR cipő és elszakadhat az iPhone headset - hacsak nem bluetooth-os.

"Egyaltalan, hogyan jutott el az IT-tol addig, hogy "Java programozo"? Akkor mar miert nem Javascript? Vagy PHP?"

Java-st dob fel leghamarabb nekik a facebook. Egyébként én is a JavaSript-et emlegettem - ha már valami trendi nyelv kell. A PHP-ba most nem mennék bele, mert elvinné a beszélgetést.

"Miert nem kezdi mondjuk tesztelessel, ahhoz tenyleg nem kell mas, csak logikus gondolkodas, es az adott business ismerete (ezek gyorsan elsajatithatok olyan szinten, amivel mar onalloan lehet produktiv)."

Ez nagyon jó ötlet és az ismerősöm is gondolt rá! Sajnos egy interjúja nem volt sikeres, mert nem volt elég erős a nyelvtudása. Egy tovább fejlődési út lehet, hogy rágyúr a nyelvre és elmegy egy kicsit tesztelni.

"A programozassal az a baj, hogy ilyen gyorstalpalo tanfolyam utan programozni kabe olyan, mint orvosi egyetem nelkul/helyett egy elsosegelynyujto tanfolyam utan elmenni sebesznek, mert ott ugyis csak vagdosni kell jobbra/balra, azt meg a sogor is meg tudja csinalni, amikor disznooles van, nem?"

Hát igen, orvosi területen mozgok. Ott is szakember hiány van és az egyik lehetséges megoldás, hogy a jól képzett szakszemélyzet tudjon egyre több feladatot elvégezni. Itthon egyesek számára felháborítónak tűnik, ha a sürgősségin triázs nővér osztályozza először és nem egyből az osztályvezető főorvos tekinti meg személyesen. Közben a 20 évvel ezelőtti Vészhelyzetben is azt lehetett látni, hogy az enyhe esetek 6-10 órákat várnak és orvoshoz akkor kerül, amikor a szakdolgozó nővér referálja. Előtte már elintézi a laborokat és alapvizsgálatokat, stb.
De vissza programozáshoz. Egy coder school is lehet hatékony. Azért érdekelne, hogy a kikerülő tanuló által produkált kód minősége és időtállósága milyen. Nyilván nagyon függ az egyéni képességektől is.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

"Egy tovább fejlődési út lehet, hogy rágyúr a nyelvre"

Szerintem megfogtad a lenyeget.

Egyebkent a triazs nover (de jo szo :)) megfeleloje az IT-ban a level 1/2 support, akik _nem_ fejlesztok (jo esetben), a level 1-nek meg akar szamitogepet sem kell latnia, csak a leggyakoribb problemakra tudni valaszolni azok megertese nelkul (illetve nyilvan a legfontosabb itt az empatia, hogy naponta 10-szer elkuldik a fenebe, es o megis mosolyog). Ez is egy beugrasi lehetoseg.

> Azért érdekelne, hogy a kikerülő tanuló által produkált kód minősége és időtállósága milyen.

Szar, mint mindenkié kezdőként, akár BME-n tekergeti az oszcilloszkópot akár a Tojás nevű ürge segít neki a GreenFox-nál.

A kóder szakmához elengedhetetlen hogy érdekeljen a téma, ezért szokták a kollégák a "mert sok pénzt fizet?" kérdést feltenni mert az így nekiinduló emberek 99%-ban kiégnek az első 1-2 évben a szakmától. Az érdeklés itt azt jelenti, hogy szabadidődben hobbiból kódot írsz mert élvezed. Ha a barátod úgy nézte ki magának a Java programozást hogy nem írt pár száz sort eddig benne és jövő hétvégén nem tervezi megírni a következő százat, akkor rossz helyen próbálkozik és csak kifogja dobni a pénzét, mert amit megtanult most az 3 év múlva irreleváns lesz és nem lesz benne érdeklődés a következő iteráció elsajátításához, főleg munka mellett.

Alapvetően egyetértek, de szerintem a 99% erősen túlzás.
Vagy ha igaz, akkor nincs túl nagy jelentősége.

Vannak olyan országok, ahol teljesen megszokott jelenség az, hogy az emberek programozónak tanulnak, mert az jól fizet.

Ezért van, hogy Brazíliában pl. informatika karon az egyetemen kb. 50-50% a nemek aránya, és ezért van, hogy Indiában pl. óriási mennyiségű ember végez IT-ban minden évben.

Biztos sokan ezek közül soha az életben nem lesznek jó programozók. De a tömeg jóval több, mint 1%-a azért évtizedeken át szépen eldolgozgat a területen, és azért nem 99%-ban haszálhatatlanok az így készített programok.

Az elmúlt 8 évben szinte kizárólag ide-oda kiszervezett fejlesztőcsapatokkal dolgoztam.
Voltak oroszok, ukránok, lengyelek, észtek, magyarok, kazahok, indiánok.

A legrosszabb minőségű kódot nem az ilyen kiszervezettektől, hanem egy Párizsban dolgozó franciától láttam.

A legnagyobb gondom nem a kód minőségével volt, hanem vagy a kommunikációval (főleg oroszok hiányos nyelvtudása miatt), vagy az makacssággal, rugalmatlansággal (főleg oroszoknál és ukránoknál), de ez sem a kódolásban jelent meg, hanem vagy nem voltak hajlandóak azokat a folyamatokat követni, amit az ügyfél kért, vagy pl. az architect olyan architektúrát talált ki, még a fejlesztés megkezdése előtt, ami az adott feladatra nem volt jó, és aztán nagyon nehéz volt ezen változtatni (embercsere kellett végül).

Amikor ezeken a nehézségeken az elején átküzdöttük magunkat, a végeredmény általában használható volt.

Továbbra sem azt mondom, hogy ezekkel az emberekkel szeretek dolgozni, meg azt sem, hogy minden jó, amit csinálnak.
A számot, a 99%-ot tartom erős túlzásnak. Ennyi.

OFF:

"mint a kislányoknak meghirdetett modell képzés (lehúzás) - hogy befizeted a tanfolyamot, utána jó pénzért készítenek egy portfoliót és a végén mégsem viszi el a gyereket a világ 10 legjobb modellügynöksége közül az egyik?"

A kislányok közül az jár jól, akit csak pénzzel húznak le és nem viszik sehova.

(Csak felig) OFF:

https://www.theregister.co.uk/2018/06/22/oracle_announces_java_se_subsc…

Az Oracle konfiguralja a penzszivattyut, jovore indul a mandula!

(Jo vilag lesz itt 20 ev mulva, egy vagon penzt fogok keresni azzal, hogy olyan oskovuletekhez ertek, mint a Java, tisztara mint ma a mainframe-esek. A bankok jol meg fogjak fizetni ezt, mert 40 eves kor alatt nem lesz senki, aki ertene hozza. Mar csak addig kell kibekkelni valahogy - talan elmegyek Android fejlesztonek, azt legalabb lehet Kotlinban is.)

Most is hallok időről időre olyant, hogy "nincs valaki ismerősöd aki ért AIDA-hoz?", majd visszakérdezek, hogy az mifene, közlik, hogy ááá semmi csak egy katonai bázison azt használták valami szimulátorhoz, és hát még most is használják, és hát kb. 3x-os pénzt fizetnek, csak menjek már. Mint a holt nyelvek fordítói, adott nyelvnek van 3 ember aki ismeri minden szavát, és évente van egy kőtábla amit előásnak :). Lehet megérné ilyen irányba továbbképződni, a php-js-css-html nem igazán exotic.

Nem, konkretan ugyanaz a forras (es a binaris) a 9-es verziotol kezdve.
A lenyegi kulonbseg a licenszeles, es a bugfixek/patchok lete/nemlete.

Mostantol aki nem akar fizetni a licenszert, az vagy azonnal upgrade-el, amint megjelenik az uj verzio (mert a regihez nem lesz onnantol patch), vagy bevallalja, hogy nincs tobb patch. Lassuk be, mindket lehetoseg komolytalan.

Egy Oracle-es fejlesztot kerdeztem az egyik meetupon, hogy most akkor mi lesz, mire megvonta a vallat, es kozolte, hogy majd valaki mas atvallalja a kimeno verziok supportjat, legalabbis egy darabig (pl. Azul).

Szoval a lenyeg osszefoglalva: jatszogatni tovabbra is ingyenes a Java, de kommerszialis felhasznalasra nem. Ezzel persze az uj Java rendszerek gyakorlatilag megszunnek, hiszen most mar annyi alternativaja van a JVM-nek a piacon, hogy nem igazan szol mellette komoly kizarolagos erv, ellene viszont igen. Persze akinek Java rendszerei vannak, az nem fogja csak ezert kidobni, ezert meg hosszu-hosszu evtizedekig (akar az orokkevalosagig) ez egy tuti cash-cow az Oracle-nek.

(ui: Emese kolleganknak igaza volt, amikor megjegyezte, hogy ez nem uj info, nem is azert irtam, csak szabadon asszocialtam arra - az egyebkent friss - hirre, hogy most mar lehet tudni, mennyibe fognak kerulni a licenszek, versus "junior Java fejleszto" kepzesnek van-e ertelme, vagy nincs...)

> Nem, konkretan ugyanaz a forras (es a binaris) a 9-es verziotol kezdve.
erre forrás?
párszor már elmondták, hogy cél az, hogy azonos legyen, de eddig én sehol nem láttam kimondva, hogy teljesült is.

> jatszogatni tovabbra is ingyenes a Java, de kommerszialis felhasznalasra nem.
az OpenJDK ingyenes lesz továbbra is. Supportot meg eddig sem kaptál az Oracle JDK-ra, szóval. Legalábbis én nem látom a hatalmas váltást. S a Paas idejében nem is én akarok venni a JDKra supportot, vegyen a Heroku/Amazon.

Ugy erted, nem tunik fel az Oracle logo a hivatalos openjdk-s oldalon (http://jdk.java.net/10/)?
Vagy hogy a Release Notes mar rogton Oracle oldalra dob (http://www.oracle.com/technetwork/java/javase/10-0-1-relnotes-4308875.h…)? :)

"Supportot meg eddig sem kaptál az Oracle JDK-ra"

De folyamatosan jottek ki a bugfixek es a patchek. Hanyas update-nel tart most a 8-as Java SE? Na ennek lesz most vege (konkretan 2019-tol).

a JDK8-nál is van oracle-ös oldalra vivő link, oszt' arról tudjuk, hogy nem azonos a két build.

> De folyamatosan jottek ki a bugfixek es a patchek.
Ezek mostantól is fognak, az akutális verzióhoz (1, vagy kettő, ebben nem vagyok biztos).

Egyedül az LTS-re való backportolást hagyja el az Oracle, de az AdoptOpenJDK ezt felvállalta, s a Java 11, Java 17, etc. várhatóan ugyanúgy 5 évig kap security fixeket, open source keretek között.

Aki eddig is üzletileg kritikus megoldást az ingyenes Oracle update-re épített, annak az AdoptOpenJDK semmivel sem rosszabb.

Jol hangzik ez az AdoptOpenJDK-s projekt, errol lemaradtam, igy mar kisse mas a leanyzo fekvese.

Erdekes, hogy az LJC-s meetupon beszelt az Oracle-s ficko a release-ek valtozasairol (ha ot elfogadod hivatalos forrasnak (https://opentechcalendar.co.uk/event/6914-docklandsljc-the-java-roadmap/) - sajnos a slide-jai nincsenek meg, de valtig allitotta, hogy ugyanaz az OpenJDK es az OracleJDK), viszont az AdoptOpenJDK-t "elfelejtette" megemliteni. Na igy higgyen az ember egy Oracle pre-sales engineer-nek! :)

ui: az LJC hivatalos szponzora az AdoptOpenJDK-nak... no comment. (https://adoptopenjdk.net/sponsors.html)

> Na igy higgyen az ember egy Oracle pre-sales engineer-nek! :)
:)
én megvárnám azt a blogposztot, vagy konf-videót az előadásról, amiben ezt számon lehet kérni utáni bárkin.

nem gondolom, hogy sok difi lenne az OpenJDK/Oracle JDK között (én boldog OpenJDK felhasználó vagyok), de... szóval az Oracleről van szó, írják csak le.

> Jol hangzik ez az AdoptOpenJDK-s projekt, errol lemaradtam, igy mar kisse mas a leanyzo fekvese.
állítólag évekig döglődő projekt volt ez, s most a release változása miatt támadt fel.
meglátjuk, lesz-e rá valakinek pénze, hogy 5 évig tényleg legyen backport.

openjdk.java.net :)

Valójában mindig is ugyanaz volt, csak a telepítők csomagolásánál hozzáadtak pár dolgot (pl a windowsos installer :D, Java WebStart, az eddig zárt Java Mission Control újabban, trusted keys a cacerts-ben, ...).
De maga a JVM, a JRE, etc tökugyanabból a forrásból fordul.

"De maga a JVM, a JRE, etc tökugyanabból a forrásból fordul."

Meg hozzábasznak némi Oracle fűszert, hogy jobb legyen. Mint például kriptográfia és azt külön le kell töltened és baszakodnod vele, hogy menjen minden cipher. Meg ilyen finomságok, amivel napokat tudsz eltoszni.

meg aztán az Oracle JRE-ben van JIT ARMre, míg az OpenJDK-ban nincs.

néha előjönnek ilyen dolgok, s persze, hallomásból nincs nagy különbség. de az utolsó ~hivatalos infó erre egy Java7-es időkből származó mondás, s akkor is csak annyi volt, hogy apróságokban tér el a kettő. aztán meg kiderül, hogy mégiscsak előfordul, hogy valami még mindig nem ugyanolyan.

Szóval majd akkor hiszem el, hogy a két build pont ugyanaz, ha az Oracletől valaki kimondta és felkerült YT-ra videón, vagy blogban az Oraclehöz.

innen indultunk: „Nem, konkretan ugyanaz a forras (es a binaris) a 9-es verziotol kezdve.”
majd erre ráerősítettél, hogy „Valójában mindig is ugyanaz volt, csak”
mostmeg: „igen, vannak extrák.”

szóval akkor most ugyanaz-e az OpenJDK mint az Oracle-ös (amit egy jóideje célként emleget mindenki, az Oracle tája házáról, és tök üdvözlendő), vagy még nem jutottunk el ide?

hallod...
Megpróbálom megint:
A "mellétesznek programokat" nem jelenti azt, hogy a "jdk forrásba belegányolnak" (mert minek, gyakorlatilag az övé). A beletákolás a google és a twitter reszortja :D nekik van privát openjdk repójuk (ergo privát forkjuk).

Jelenleg a (oracle) Java SE egy telepítő, belebaszva sokmindennel. Az openjdk csak egy referencia implementáció.
Az openjdk-s """installer""" az egy tar.gz (windowsra is: http://jdk.java.net/10/ ), amit kézzel csomagolsz ki, meg másolgatsz .so-kat, hogy legyen java plugin a böngésződben.

Értem én, hogy nem akarjátok érteni ám :D

Innen nézve te nem akarod érteni, hogy ha néhány dolog másképp van benne és vannak dolgok, amik a másikban benne sincsenek, akkor nem ugyanaz, maximum közös ősről lehet beszélni ilyenkor. Mint írtam, igen, hozzá lehet szigszalagozni a cipher csomagot is az OpenJDK-hoz, csak néha köhögni fog, hogy NoSuchMethodError.

Mutass már rá, hol állítottam ilyet, pls. de tényleg. Még csak a threadben sem, nemhogy ebben a szálban.

Én csak annyit mondtam, hogy erősen kétlem (amíg valaki, aki tényleg ezen dolgozik, ért hozzá, s a jogászokkal is jóváhagyatja, le nem írja), hogy az OracleJDK és az OpenJDK teljesen ugyanaz. (Ugye, az eredeti szál még arról szólt, hogy a bináris _ugyan az_ a 9es óta.)

Aztán jöttél te, aki azt mondtad, hogy _mindig_ is ugyanaz volt, ami tényszerűen meg nem igaz. Lásd a linkelt HUPos blog, ahol tapasztalat útján, s a linkelt Oracle-ös forrás, ahol dokumentáció útján tudjuk, hogy a két java terjesztés nem volt ugyanaz.

De azt senki, sehol nem vonta kétségbe, hogy mindkettő (s még millió plusz egy JVM implementáció) átmegy a TCKn. Szóval örülnék, ha személyeskedés helyett idézetekkel, forrásokkal bombáznál. Köszönöm.

Az, hogy az ARMos JIT az egyikben fasza, a másikban nem, szerinted nem az """alaprendszert""" része, csak terjesztésbeli kérdés? Mert ilyen alapon az Azulos, az IMBes, és az Oracles JDK is ugyanaz, hisz képes futtatni ugyanazt (~átment a TCKn). Ha a Jikes RVMt egyszer eltolják odáig, hogy átmegy a TCKn, akkor az is ugyanaz az alap JRE lesz?

Vagy az ARMos JIT hiányát az egyikből már vehetjük lényeges különbségnek az alaprendszerben? Mert akkor megint nem igaz, hogy mindig is ugyanaz volt.

Senki nem írta, hogy nincs kompatibilitás semerre se, én ezeket írtam:
"Lényegi különbség nincs, apróságok vannak, amelyekkel szopni lehet. Néha sokat, máskor még többet."
"Meg hozzábasznak némi Oracle fűszert, hogy jobb legyen. Mint például kriptográfia és azt külön le kell töltened és baszakodnod vele, hogy menjen minden cipher. Meg ilyen finomságok, amivel napokat tudsz eltoszni."

Emlékszel még, amikor olyanokkal baszkódtak az opensource projektek, hogy Hollandiában hostolták, mert így kerülték ki az amerikai export controlt? Én még igen.
Szerintem te is.

Másik:
Akkor használj openjdk-t, senki, _senki_ nem tart vissza.
Ha meg olyan cuccot kapsz, ami CSAK oracle jdk-n fut, az egy jelzés, hogy az adott termék alapjaiban szar. (s itt a jirára nézek)

Elhiszem, hogy neked nem tetszik. Nekem se tetszik sok minden XD

Mondok egy példát: Ugye épp a Java 10 az aktuális verzió (és még az idén a 11 lesz az), de a latest weblogic csak java 9-et(!) támogat max. Hogy mondjam azt, hogy "update-elj geci", ha az egyik fő appserver se támogatja még?

> Hollandiában hostolták, mert így kerülték ki az amerikai export controlt?

Na ja, kivéve azokat az ágrólszakadtakat (pl. Fedora) amik US jurisdiction alatt voltak a szervezeti felépítésük miatt, ők a hajukra kenhették Hollandiát, 3rd party repóval lehetett csak a libdvdcss-hez hasonló illegális (sic) szoftvereket beszerezni.

(El van kefélve a rendszer? Amúgy igen, de ez van.)

Na, megvan végre: http://www.oracle.com/technetwork/community/javase-ace-javabriefing-176…
Ez mindkettőnk álláspontját részben alátámasztja :)
Bocs, én a Sun J2SE release-eket nem tekintettem Oracle Java SE-nek. Meg akkoriban kb pont leszartam :)
Tehát igazad van, régen (Java 6-ig bezárólag) tényleg nem az openjdk volt a referancia. Aztán megvette az oracle a sun-t, és kidobta a sun jdk-t és áttért az openjdk-ra.

Ezt továbbra is csak közös ősnek tudom tekinteni, nem pedig azonosnak... azonosnak akkor tudom tekinteni, ha felteszem az OpenJDK-t és _minden_ pont ugyanúgy megy, mint Oracle JDK-val. Amíg ez nincs így és lépten-nyomon baszakodni kell apró szarságokkal, addig nem ugyanaz, bárki bármit is mond.

Egyébként loop: https://hup.hu/node/159820#comment-2243648

"az vagy azonnal upgrade-el, amint megjelenik az uj verzio (mert a regihez nem lesz onnantol patch), vagy bevallalja, hogy nincs tobb patch. Lassuk be, mindket lehetoseg komolytalan."

Miert lenne komolytalan? Windowst bezzeg mindenki azonnal frissit, de hirtelen a Java verzio frissitese fel-egy evente komolytalan?

"Szoval a lenyeg osszefoglalva: jatszogatni tovabbra is ingyenes a Java, de kommerszialis felhasznalasra nem."

Kurva nagy eltévelyedésben vagy.

Azt mondják ahhoz hogy egy szakmában "szakértő" legyél ahhoz legalább 1000 órát el kell benne tölteni.
Abban egészen biztos vagyok, hogy ha csak a tanfolyamot csinálja végig és nem tesz bele pluszba energiát akkor az nagyon kevés lesz.
Ha "éjjel-nappal tolja" akkor egy év alatt elég jó szintre el tudhat jutni, mint ahogy a motivált egyetemisták is eljutnak.
Ők se az egyetemen tanultaktól hanem a saját motivációjuktól jutnak előre - más kérdés hogy jó közegben vannak.

Vannak olyan cégek (jellemzően kis-közép fejlesztőcégek) ahol kellő alázattal gyenge pénzzel el lehet kezdeni dolgozni és ha valaki teljesít és bizonyít akkor meredeken emelkedik a fizetése diplomától teljesen függetlenül.

És egy év alatt már rendes pénzt, három-öt év után meg már senior fizetést kaphat bárki.

--
Gábriel Ákos

Ehhez kapcsolódik h annyira szeretem amikor a 450 bruttóért felvett junior simán azt gondolja magáról hogy ő valóban ér ennyi pénzt.
Igazából persze nyilván nem ér ennyit, sőt effektíve negatív pénzt ér, hiszen inkább viszi a pénzt mint hozza - az első félévben biztosan.

A benne levő potenciál ér - vagy érhet - valamennyi pénzt, de óriási a kockázat mert pillanatok alatt elviszik ha nem figyelsz.

A senior programozó az, aki már több pénzt termel mint amennyibe kerül, ezért is éri meg felvenni.
Csak hát "véges a készlet", ez a juniorok szerencséje.

Nem egyszerű a szakma manapság...

--
Gábriel Ákos

2. ponthoz igen, építőiparban ha valaki odateszi magát, és jó csapathoz kerül, akkor meglehetősen jól lehet keresni. Cserében fizikailag elfárad pöppet az ember estére.

2. Léteznek ilyen pozíciók, ahol felsőfokú végzettség nélkül egyből jól kereső álláshoz lehet jutni, vagy ez is olyan, mint a kislányoknak meghirdetett modell képzés (lehúzás) - hogy befizeted a tanfolyamot, utána jó pénzért készítenek egy portfoliót és a végén mégsem viszi el a gyereket a világ 10 legjobb modellügynöksége közül az egyik?

Ehhez annyit tudok hozzátenni, hogy sok olyan cég keres munkaerőt, akik nem szabják feltételnek a felsőfokú végzettséget.

Magyarországi fizetésekben nem vagyok képben, a kérdésnek erre a részére semmit nem tudok mondani, de a kiírt pozíciókban megajánlott fizetést megkapja az ember, ha felveszik. Nincs két különböző összeg a hirdetésben, egyetemi diplomásoknak egy magasabb és diploma nélkülieknek egy alacsonyabb.

Mondjuk ha én lennék 0 tapasztalattal, és junior pozícióba jelentkeznék, nem számítanék rögtön hatalmas fizetésre, viszont arra igen, hogy ahogy növekszik a tapasztalatom, növekedni fog a fizetésem is és pár év után már viszonylag magas lesz. Elképzelhető, hogy közben állást kell váltanom, ha valahol a fizetés nem akar emelkedni.

Két ismerősöm két különböző oktató cégnél tanultak, beszélgettem velük elég eltérőek a tapasztalatok - az egyiknél katasztrófa , lehet hogy bírósági per is lesz belőle...

Ránéztem erre a braininghub-ra, az durva hogy UML-t meg swinget tanít, hát ez azért elég antik.

Semmi.

UML-t tanulnia felesleges, nem fog találkozni vele. Vagy ha igen, onnan jobb ha inkább elszalad. Junior szinten egyébként is amit tudni kell az 2 nap alatt megtanulható.
Egyébként is >10 éves technika.
Scrum-ot tanulni meg nagyon is érdemes: ez az aktuálisan legmenőbb és eléggé elterjedt módszertan.

Szerintem.
--
Gábriel Ákos

"UML-t tanulnia felesleges, nem fog találkozni vele. Vagy ha igen, onnan jobb ha inkább elszalad. Junior szinten egyébként is amit tudni kell az 2 nap alatt megtanulható.
Egyébként is >10 éves technika."

Na most nem tudom, hogy sirjak vagy rohogjek, ezert inkabb kerdezek.

Miert nem fog talalkozni UML-lel? Es ha megis miert kellene onnan elszaladni? Miert baj az onmagaban, ha egy technologia tobb, mint 10 eves?

"Scrum-ot tanulni meg nagyon is érdemes: ez az aktuálisan legmenőbb és eléggé elterjedt módszertan."

Szoval a Scrum meno. Ez tetszik. Aztan azt a kerdest fel szabad-e tenni, hogy vajon jo is, vagy csak meno? Szoval attol, hogy ez a modszertan most divatos, sajnos a legtobbb helyen teljesen tevesen eroltetik, ugyanis az adott szervezetben az adott feladatra tokeletesen alkalmataln.

De tovabbra sem ertem, hogy egy fejlesztonek miert nem kell megtanulnia szoftvert tervezni es modellezni, es ezt mi modon helyettesiti egy munkaszervezesi modszertan megtanulasa.

A feleségem Agile BA.

Scrum-os fejlesztőkkel dolgozik kb. 7 éve. Nagyon sok helyen elvárás, hogy UML-ben dokumentáljon különböző dolgokat.

Class diagramot nem szoktak tőle kérni, de pl. sequence diagramot vagy állapot diagramot nagyon gyakran. Így dokumentálják a követelményeket, ahol ilyesmit kell.

Az, hogy egy fejlesztő Scrum vagy Waterfall projekten dolgozik, az csak annyiban eltérés, hogy máshogyan választják ki a feladatokat, és más időtávra terveznek.

A követelményben, ha ilyesmit kell leírni, azt ugyanígy fogják megtenni, mindegy, hogy Agile vagy Waterfall.

Teljesen mindegy, hogy miben rajzolod.

Úgy emlékszem, az anekdota szerint szalvétára firkálásból alakult ki.

Az egész UML-nek csak annyi a lényege, hogy ha az UML szerinti alakokat használod, akkor ha valaki ránéz az összefirkáld szalvétádra, akkor azonosítani tudja, hogy mi micsoda, hol az eleje, hol a vége.

Szoktam olyat, hogy tegye fel a kezét, aki tervezett már UML-ben. Aha, elég sokan. Oké, tegye fel a kezét, aki napi szinten frissíti az UML modellt, ahogy fejlődik a rendszer? Aham, senki.

Az a baj, hogy ez az UML alapú tervezés egy bullshit, kilóra legyen meg a dokumentum, mert a projektmenedzser még úgy tanulta, hogy kell mindenféle HBR és RNBR doksi, amit aztán az életben többé senki nem használ, nemhogy frissen tart. Lehet vele villogni hozzá nem értő vezetők előtt, mert tele vannak a doksit szép színes ábrákkal, nyilakkal, dobozokkal és szövegekkel. Aztán később, amikor hozzá kell nyúlni egy rendszerhez, a legutolsó dolog, hogy előveszik a fejlesztési dokumentációt, mert mindenki tudja, hogy az bullshit volt már akkor, amikor leadásra került és azóta senki nem nyúlt hozzá.

"A feleségem Agile BA."

Ja, agile BA nem létezik... olyan létezik, hogy egy waterfall fejlesztési modellre ráhúzzák, hogy most agilisen csináljuk, de azon kívül, hogy van daily standup, minden ugyanúgy megy, mint régen. Ahogy például a Fortran programozók bármilyen programnyelven képesek Fortran programot írni, úgy a vízesés modellhez szokott cégek bármilyen módszertan esetén képesek vízesés modellben gondolkodni, miközben felveszik az adott módszertan külsőségeit.

"Az, hogy egy fejlesztő Scrum vagy Waterfall projekten dolgozik, az csak annyiban eltérés, hogy máshogyan választják ki a feladatokat, és más időtávra terveznek."

A nagy lófaszt. Az agile alapvetően arról szól, hogy egy jól záródó fedő alá teszik a projekt _összes_ résztvevőjét az ügyféltől kezdve a tesztelőkön és a fejlesztőkön át az üzemeltetőig és a techwriter-ig, hogy senki ne zaklassa őket egy fél óránként egy öt perces feladattal és nem szépen formázott dokumentumokon keresztül kommunikálnak, hanem személyesen, a nap minden órájában és akkor jönnek ki a fedő alól, amikor az ügyfél felteszi a kezét, hogy kész a termék vagy elfogyott a pénze.

Általában az a probléma, hogy nagy cégeknél jön egy parancs, hogy holnaptól agilisek lesztek és holnaptól mindenki agilis. Na, lófaszt lesz agilis. Megtartják a daily stand up megbeszélést 5 perc alatt, ahol minden mindig tökéletes, aztán először hetente, aztán két hetente végül havonta terveznek sprint-et, ami egyre inkább pont olyan, mintha egy kicsi waterfall lenne, egyre inkább öt perc pontossággal becsült feladatokkal, aztán csinálnak mindent úgy, mint régen. Közben az üzlet vérszemet kap, hogy minden megcsináltathat azonnal a fejlesztőkkel, így tényleg mindent megcsináltat, legyen az bármilyen faszság, mert ugye üzleti értéket nem mérnek vissza, mert visszamérni is faszság, persze hogy dőlni fog a pénz, ha egy gomb máshol van, minek azt visszamérni. Persze nem ülnek egy helyen a projekttagok, mert az milyen faszság, hogy ezért ürítsenek ki egy tárgyalót vagy építsék át az egész emeletet, jó lesz mindenki ott, ahol van, elég, ha a daily stand up öt percében látják egymást, majd írnak emailt és olvassák a doksikat. Persze, mivel nem ülnek búra alatt és mindenkinek van még 10 feladata, amit nem lehet róluk levenni, mert akkor ki csinálná, ezért 15 százalékban lesznek agilisek, a többi 85 százalékban meg nem, ezért aztán mindig vadászni kell a projekttagoknak megfelelő időt a megbeszélésekre, mert soha nincs olyan idő, ami mindenkinek jó.

Erzek egy kis felfogasbeli aomaliat. A fejlesztesi dokumentacio az valami olyasmi, ami a fejlesztest (utolag) dokumentalja, tehat nem annak a resze. Az UML szamomra egy tervezo eszkoz, tehat ezen keresztul oldom meg a feladatot, azaz a fejlesztes szerves resze a modellezes. Az hogy a kod-modell konzisztenciat nem sikerult megoldanotok, ez mar masokkal is elofordult. Nekem van erre bevalt metodikam es eszkozhatterem, ami kivaloan mukodik a gyakorlatban.

A Scrumrol leirtakkal melyen egetertek. Nem valo az a legtobb cegnek/szervezetnek, ahova meg valo ott meg mukodik abelkul is, hogy nevesitenek, meg eloadnak a felalltunk/leultunk bohockodast. Ez pont az a szinhaz resz, ami azoknak a szervezeteknek kell, ahol a lenyeg nem mukodik.

Alapvetően egyetértek, csak pár érdekességet szeretnék beírni (ha már tudtátok mindezt, akkor bocs):

A felállunk / leülünk bohóckodás nem a Scrum része. A Scrum Guide Scrum meetingről beszél, nem standupról. A Standup az Extreme Programmingból jön.

Azt nem tudom igazán, hogy az XP-ben miért találták ki a Standup meetinget, de van az ücsörgés utáni felállásnak egy olyan előnye, hogy intenzívebben kezd dolgozni a keringés, plusz oxigén jut az agyba, és az agy hatékonyabban dolgozik. Hallottam valami +30% teljesítményt, de nem emlékszem a pontos számra, és most hirtelen nem találtam olyan oldalt, ahol a tanulmány konkrét számait mutatnák. Az is lehet, hogy ez a 30% csak egy légbőlkapott szám.

https://www.forbes.com/sites/daviddisalvo/2017/10/09/why-standing-inste…

+ előnynek szokták tartani, hogy aki kényelmesen ülve sokat beszél, esetleg ácsorogva rövidebbre fogja. Személy szerint ebben nem hiszek, ismerek olyan embert, akinek mindegy, hogy ül vagy áll, úgy kell lelőni, mert egyébként nem fogná be.

A daily standup az nem egy meeting, hanem gyakorlatilag 3 kérdés megválaszolása 3 mondatban.

- Mit csináltál tegnap?
- Min fogsz ma dolgozni?
- Van-e bármi, ami miatt nem tudsz haladni, kell-e segítség..

Ez megelőzi azt, hogy a junior fejlesztő csak szöszöl, szöszöl, szöszöl, és nem történik az égadta világon semmi.

Hát pedig. Ahol csak a standup-on derül ki, hogy egy junior legalább egy napja kapar egy helyben, ott más problémák is a szőnyeg alá vannak söpörve és semmi érdemi kommunikáció nincs a csapattagok között. Ha nem veszi észre senki, hogy a légtérben erőteljesen megnövekedett a WTF/óra, akkor az ott nem csapat, hanem egymás mellett dolgozó indivídumok laza halmaza.

Persze, nyilván jobb, ha másnap kiderül, mint egy hónappal később... de ahol csak másnap derül ki, ott már mérgezett a légkör, klikkesedések vannak, akadozik a kommunikáció és nem figyelnek egymásra a csapattagok.

A Scrum arról szól sokszor, hogy hogyan lehet egy nem tökéletesen működő csapatot jobbá tenni.
Amit te írsz, az a végállapot - a tökéletes csapat.
A Scrum master már akkor elégedett ha a csapat működése _javul_.

A daily scrum (tapasztalatom szerint) a csoportnyomás kialakításának kiváló eszköze.
Persze ez nem ultimate megoldás, vannak olyanok akiken ez sem segít.
Ők nem valók a csapatba. Ez előbb-utóbb mindenki számára nyilvánvaló lesz és az ember kikerül a csapatból.

--
Gábriel Ákos

"A Scrum arról szól sokszor, hogy hogyan lehet egy nem tökéletesen működő csapatot jobbá tenni."

Nem, a scrum oktatás és a scrum bevezetés szólna arról, hogy miképpen lehet egy nem tökéletes csapatot jobbá tenni.

Igen, értem, hogy a csapatok sokszor igen messze vannak nemcsak az ideálistól, de még a jótól is. Csak erre a problémára nem megoldás egy napi pár perces meeting, az csak tűzoltás és tüneti kezelés, ami sokszor ront az információáramláson ("majd a standup-on elmondom"). Ha nem zárod össze és zárod el a csapatot minden mástól, amíg az adott feladaton dolgoznak, akkor abból soha nem lesz jó csapat.

"A daily scrum (tapasztalatom szerint) a csoportnyomás kialakításának kiváló eszköze."

Hát... ez már egy jelentős torzítása a gondolkodásmódnak. Egyáltalán nem erre való a daily standup, ez olyan, mintha feleltetéssel akarnék fegyelmet tartani egy osztályban.

"Ők nem valók a csapatba. Ez előbb-utóbb mindenki számára nyilvánvaló lesz és az ember kikerül a csapatból."

Ennek nem a standup-on kellene kiderülnie... :/

Igen, értem, hogy a csapatok sokszor igen messze vannak nemcsak az ideálistól, de még a jótól is. Csak erre a problémára nem megoldás egy napi pár perces meeting, az csak tűzoltás és tüneti kezelés

Annak a meetingnek nem is ez a célja.

A csapat együttműködésének javítására a retrospective a kötelező esemény és ezen felül persze lehet még egy csomó más (nem meeting féle) módon is tenni az ügy érdekében.

Junior simán megcsinálja, hogy elszórakozik egy taszkkal, és egyszerűen nem képes felismerni, hogy ő most megakadt. Na,
ebben az esetben tök jó a daily sprint, ahol a senior fejlesztőnek azért fel fog tűnni, hogy már második napja küzd vele
a szerencsétlen, lehet, hogy segíteni kellene neki, mert csak nem tudja megoldani.

"Mert úgy egyébként módszertantól függetlenül mit tapasztaltál eddig, általában milyen a csapatkommunikáció?"

Nagyon jó csapattól nagyon rosszig sikerült már csapatban dolgoznom. Ha rossz volt a csapatkommunikáció, akkor a standup nem javította a kommunikációt, hanem csak rontotta...

Nagyon szerencsés helyzetben vagy, ha csak olyan helyen dolgoztál eddig, ahol nem volt haszna egy daily scrum meetinghez hasonló meetingnek.

Én láttam már olyan csapatot, akik folyamatosan együtt dolgoztak mindenen, és nekik* tényleg nem hozott a daily scrum meeting semmi újdonságot.

De a legtöbb csapatnak, akikkel dolgoztam, hasznos volt a napi egyszeri mindenki összejön és mindenki mindenkinek elmondja, hogy mi a pálya. Beszélgettek ők egymással, csak ha több, egymással szorosan nem összefüggő dolgon dolgoznak (mondjuk egynél több backlog item van a sprintben), akkor már simán lehet, hogy nem mindenki mindenkivel folyton.

* még egy dolog: a scrum meeting nem csak arról szól, hogy a csapaton belül mindenki képben legyen és felfedezzük a problémákat, hanem lehetőséget ad arra is, hogy ha valaki, aki nem a csapat tagja érdeklődik, akkor megjelenjen, füleljen és képet kapjon arról, hogy hogyan mennek a dolgok.

"Én láttam már olyan csapatot, akik folyamatosan együtt dolgoztak mindenen, és nekik* tényleg nem hozott a daily scrum meeting semmi újdonságot."

Jó reggelt, csókolom, erről szól a scrum és az agilis fejlesztés.

"egymással szorosan nem összefüggő dolgon dolgoznak (mondjuk egynél több backlog item van a sprintben), akkor már simán lehet, hogy nem mindenki mindenkivel folyton"

Mi a lófasz? Ez intézményesített anarchia és szőnyeg alá söpört balfaszkodás... mi az, hogy szorosan nem összefüggő dolgon dolgozik egy scrum csapat?!

Hadd találjam ki: van külön üzemeltető agile csapat, agile BA csapat, és akár külön van az agile mobil-, az agile backend- és az agile frontend-fejlesztés csapata is, ugye? Meg van a projektmenedzserek agilis csapata, akik product owner-nek nevezik magukat és a főnökük a Scrum Master. Szóval tulajdonképpen ugyanazok a csapatok vannak, mint korábban, csak a csapatok neve elé odakerült, hogy "agile" és mindenki ugyanúgy százféle feladaton dolgozik egyszerre és ugyanúgy, mint előtte, csak havonta újraterveznek valamit valami alapján.

"egymással szorosan nem összefüggő dolgon dolgoznak (mondjuk egynél több backlog item van a sprintben), akkor már simán lehet, hogy nem mindenki mindenkivel folyton"

Mi a lófasz? Ez intézményesített anarchia és szőnyeg alá söpört balfaszkodás... mi az, hogy szorosan nem összefüggő dolgon dolgozik egy scrum csapat?!

A való élet?

Tudod, az, hogy min dolgozzon a csapat, az a PO felelőssége. Ha a PO úgy ítéli meg, hogy A és B a két legfontosabb cucc, és a kettő két független funkció ugyanabban a termékben, szerintem nyugodtan felveheti a team.

Igen, a Scrum Guide is kb. azt írja, amit te, hogy egy sprinten belül csak összefüggő dolgokon dolgozhat a csapat.

A Scrum Guide-ban se szeretem ezt a részt.
Szerintem előnyös, ha ez így sikerül, de ha ezt kőbe vésett szabálynak vesszük, akkor vagy nem lehet az "A" sztorit sosem sprintbe venni, mert egymagában túl kicsi, és semmi más nincs, ami mellé téve ugyanazon a területen dolgoztatná a többieket, vagy indítunk egy sprintet, amiben csak az "A" van, és aztán a team másfél héten át malmozik, mert "A" elkészült de más nincs.

Szerintem ez lenne az ostobaság.

"A való élet?"

Ja, én kérek elnézést.

De akkor ez bizony nem scrum, hanem intézményesített anarchia és szőnyeg alá söpört balfaszkodás... ja, ezt már mondtam.

"Tudod, az, hogy min dolgozzon a csapat, az a PO felelőssége. Ha a PO úgy ítéli meg, hogy A és B a két legfontosabb cucc, és a kettő két független funkció ugyanabban a termékben, szerintem nyugodtan felveheti a team."

Ja, ilyen van. Csak ugye ilyenkor a csapat az egyiken dolgozik, aztán ha az kész, akkor a másikon. Ha pedig nem fér bele az időbe, akkor nem két félkész funkció lesz demonstrálva, hanem egy kész és egy félkész. Egy adott időpillanatban mindenki mindig csak egy sztorit tol.

"Szerintem előnyös, ha ez így sikerül, de ha ezt kőbe vésett szabálynak vesszük, akkor vagy nem lehet az "A" sztorit sosem sprintbe venni, mert egymagában túl kicsi, és semmi más nincs, ami mellé téve ugyanazon a területen dolgoztatná a többieket, vagy indítunk egy sprintet, amiben csak az "A" van, és aztán a team másfél héten át malmozik, mert "A" elkészült de más nincs."

A sprintbe egy csomó sztorit fel lehet venni. Két hetes sprintbe fel lehet venni akár húsz darab kis független sztorit is, ha úgy jön ki. Viszont mindenki mindig egy sztorin dolgozik. Ha az kész, akkor jön a következő. Ha valami blokkolja a feladatot, akkor mindenki azon dolgozik, hogy feloldja ezt a blokkolást. Ha ilyenkor szétszélednek és mindenki keres magának valami söpörni valót a saját portája előtt, amíg egyvalaki körbeszopja a problémát, az nem scrum.

Igen, néha lesznek üresjáratok némelyik területen, de akkor odaülsz a másik mellé és nézed vagy ha minden kötél szakad, akkor olyan dolgot csinálsz, ami nem nyomja el az aktuális feladat emlékeit és könnyen félbe lehet hagyni. Mondjuk ilyenkor lehet tanulni új dolgokat, cikkeket olvasni, fórumban segíteni akárkiknek, kávézni, csocsózni vagy bármi egyéb. De mindig legyél ott fejben és fizikailag, ha szükség van rád, akkor ne várjon ezért egy-kettő-sok ember arra, hogy felszabaduljon egy emberi erőforrás.

Ha nincs egy full stack csapat, akkor szokott olyan baszkolódás lenni, hogy kell egy nyomorult adatbázis mezőt felvenni egy nyomorult táblába és fel kell adni egy ticket-et, hogy ezt valaki-valamikor megcsinálja; mivel nincs ott a mező, ezért hopp, következő feladat, ott hiányzik egy redirect a webszerveren, erre is fel kell adni egy ticket-et, hogy majd valaki valamikor megcsinálja; hopp, következő feladat, ahol az üzlet/ügyfél véleményére kell várni; hopp, következő feladat, aztán ugrál a csapat cikk-cakkban a félkész sztorik között, mint a mezőn menekülő nyúl, de soha semmi nincs kész, hónapokon át nullás egyenes a burnout chart, kis rezgésekkel, mint egy agyhalott EEG-je, aztán valamikor hónapokkal később születnek sztahanovista sprintek, amelyekben minden korábbi híg fos hirtelen összeáll egy kemény szardarabbá, de igazából senki nem tudja, hogy melyik funkció mikor fog elkészülni és ami elkészült, azt mikor kellett volna szállítani és amit átadtak, azt hogy kell élesíteni és ha élesbe került, akkor ki üzemeltesse és hogy javítsák a hibákat. Ja. De agilis a projekt.

De miért ne lenne meeting?

Vagy ez csak ilyen szemantikai dolog, hogy mit nevezünk meetingnek?

Hagy idézzek a Scrum Guide-ból:

Daily Scrum
...
The structure of the meeting is set by the Development Team and can be conducted in different ways if it focuses on progress toward the Sprint Goal. Some Development Teams will use questions, some will be more discussion based.

Az Agile Manifesztóból idézted az egyik Value-t, nem a Scrum alapelvek között szerepel ez, de ez részletkérdés.

Azt azért látni kell, hogy az Agile Manifesto írói programfejlesztők voltak, és az egészet program fejlesztés szemszögből írták meg. Ez a használt szavakból is jól látszik.

Ugyanakkor az Agile gondolkodásmód nagyon sok mindenhol használható, és konkrétan Agile delivery keretrendszereket / metódusokat, mint pl. Scrum, vagy DSDM, vagy Kanban simán lehet szoftverfejlesztésen kívül más feladatokra is használni.
Pl. IT operations, karbantartás, de akár mérnöki tervezés, kutatás, építkezés, stb.

Az igaz, hogy az Agile Manifesto azt írja, hogy Working Software over comprehensive documentation, de ha hátrébb lépünk, akkor ez valójában kész (funkcionlális) terméket jelent, az értéktelen dokumentáció helyett.

Ha nem egy szoftver fejlesztő csapat dolgozik Scrum keretrendszert használva, hanem mondjuk egy termékfejlesztő csapat, akkor simán lehet, hogy az ő kész termékük az dokumentáció.

Ugyanígy, egy új szoftver elkészítésénél is lehet egy leszállítandó "termék" valamilyen rendszer dokumentáció. A Product Owner feladata annak az eldöntése, hogy ehhez milyen business value társul és az, hogy mik az elvárások a rendszerdokumentációval kapcsolatban.

Ebben az esetben is követhetjük az általad is idézett értéket: Az a lényeg, hogy a szükséges termék (dokumentáció), használható legyen (működjék), de onnantól kezdve, hogy elértük ezt a pontot, nem szükséges tovább dolgozni rajta és felhízlalni több száz oldal terjedelműre (gold plating), nem szükséges olyan fejezeteket hozzátenni (pl. dokumentum történet), ami nem hordoz információt a felhasználó számára. És persze nem kell a dokumentáció elkészítését teljeskörűen dokumentálni egy másik dokumentumban :-)

Megegyszer: en nem dokumentacio keszitesrol beszeltem, hanem tervezesrol. Ez a feladat megoldasank a resze. Ha neked ugy tetszik: ez produktiv munka, es nem "termeketlen" dokumnetacio. Ha az elemzes es tervezes lepeseket nem hajtjuk verge (explict es iterativ modon), akkor azok a kodolas kozben hajtodnak vegre - kovetkezeskepp szarul.

Mese:
Ez a felismeres eleg regi, es ennek kovetkezteben volt a rettentesen nagy igyekezet a 90-es evekeben szoftverfejlesztesi metodikakat kesziteni a szoftverminoseg javitasara. Ennek a tezisnek reszebn (de tenyleg csak reszben) antitezise az agilis modszertan, mert rajottek, hogy atlagfejlesztokkel, es atlag tool kornyezettel, es atlagmanagementtel finanszirozhatatlan projektek jonnek letre, raadasul a kivant minoseget sem sikerult elerni. Hiszen a minoseg nem a modszertanon, hanem az emebreken mulik. Ezert a modszertant a szervezethez kell valasztani, es tok mindegy, hogy agil vagy nem, mert a lenyeg a csapat osszevalogatasaban rejlik, na meg, hogy szepen hagyjak oket nyugodtan dolgozni. A management meg olyan modszerrel onkielegit, amilyennel csak akar.

versus 2x mérj, egyszer vágj. Igen, prefer code over documentation, de nem mindegy, milyen dokumentációról beszélünk.

A SCRUM nem azt jelenti, hogy agyatlanul nekiállunk void main-től kódot írni, aztán lesz, ami lesz, majd csak mindig
jobb lesz (nem), meg skálázódni fog (nem), meg integrálódni fog harmadik rendszerrel (nem).

> nagy cégeknél jön egy parancs, hogy holnaptól agilisek lesztek és holnaptól mindenki agilis

Addig nem éltél igazán, amíg nem láttál pilot projektet agilis módszertan bevezetésére: jön egy parancs, hétfőtől csütörtökig dolgozzatok rendesen a projekten, de minden péntek legyen agilis, aztán majd meglátjuk, beválik-e.

(Based on a true story.)

Szoktam olyat, hogy tegye fel a kezét, aki tervezett már UML-ben. Aha, elég sokan. Oké, tegye fel a kezét, aki napi szinten frissíti az UML modellt, ahogy fejlődik a rendszer? Aham, senki.

Az a baj, hogy ez az UML alapú tervezés egy bullshit, kilóra legyen meg a dokumentum, mert a projektmenedzser még úgy tanulta, hogy kell mindenféle HBR és RNBR doksi, amit aztán az életben többé senki nem használ, nemhogy frissen tart. Lehet vele villogni hozzá nem értő vezetők előtt, mert tele vannak a doksit szép színes ábrákkal, nyilakkal, dobozokkal és szövegekkel. Aztán később, amikor hozzá kell nyúlni egy rendszerhez, a legutolsó dolog, hogy előveszik a fejlesztési dokumentációt, mert mindenki tudja, hogy az bullshit volt már akkor, amikor leadásra került és azóta senki nem nyúlt hozzá.

Ez is olyan, mint minden dokumentáció. Lehet rosszul és jól is csinálni.

Waterfall esetén jellemző az, hogy előre készítenek egy nagy doksit, amit aztán jellemzően (szinte) senki nem olvas el. Pont, ahogy mondod. Legyen meg az elvárt mennyiség, de haszna nincs.

Agile esetén ha követelményeket ír le valaki, akkor az a dokumentum kb. addig érvényes, amíg fejlesztenek belőle, szóval tipikus esetben mondjuk kb. 4 hétig.

Te a rendszer dokumentációjáról beszélsz, ami dokumentálná, hogy működik a rendszer, és később hozzá lehet nyúlni.
Az igazság szerint nem szoktam ilyen dokumentációt látni. Lehet vitatkozni azon, hogy ez jó vagy rossz, de a gyakorlat az, hogy a megrendelő, aki a pénzt adja és meghatározza, hogy mit kér érte, nem szokta ezt kérni.
Waterfall esetén lehet, hogy azért, mert azt hiszi, hogy a 2 éve elkészült és sosem frissített követelmény doksi erre is jó, nem tudom. Agile esetén egyszerűen nem szokták kérni. (Vagy ha igen, akkor valami nagyon ligh leírás szokott születni, esetleg egy-két rész kicsit mélyebben, viszont ezt jellemzően karban is tartják később).

"A feleségem Agile BA."

Ja, agile BA nem létezik...

Banyek, akkor biztos ruszki kém! :-)

Komolyra fordítva a szót: miért ne lenne? A Product Owner felelőssége, hogy legyen Product Backlog, de a konkrét elkészítését nyugodtan delegálhatja. És szokták is. És ezeket az embereket, akik kitúrják a kívánságokat, elvárásokat és vagy leírják, vagy ott vannak, hogy megválaszolják a kérdéseket, BA-nak szokták hívni.

Ha Proxy Product Ownernek hívom, az jobban tetszik?

Az agile alapvetően arról szól, hogy egy jól záródó fedő alá teszik a projekt _összes_ résztvevőjét az ügyféltől kezdve a tesztelőkön és a fejlesztőkön át az üzemeltetőig és a techwriter-ig, hogy senki ne zaklassa őket egy fél óránként egy öt perces feladattal és nem szépen formázott dokumentumokon keresztül kommunikálnak, hanem személyesen, a nap minden órájában és akkor jönnek ki a fedő alól, amikor az ügyfél felteszi a kezét, hogy kész a termék vagy elfogyott a pénze.

Beidéznéd az Agile Manifesztóból azt a részt, ami ezt így definiálja?

Vagy hogy téged idézzelek, mondhatnám azt is, hogy a nagy lófaszt.

Az Agile az egy gondolkodásmód. Sok mindenről szól, én kiemeltem egy aspektusát, te kiemelted egy másik aspektusát (meg melléírtál pár dolgot, ami segít egy termék fejlesztésében, de semmi köze az Agile-hoz).

Se a tiéd, se az enyém, sőt még együtt a kettő sem fedi le mindazt, amiről az Agile megközelítés szól.

"Te a rendszer dokumentációjáról beszélsz, ami dokumentálná, hogy működik a rendszer, és később hozzá lehet nyúlni."

Kevés _használt_ rendszert ismerek, amelyikhez nem kellett utólag hozzányúlni... :)

"Agile esetén egyszerűen nem szokták kérni."

Ahja, hányszor hallottam már, hogy "ezt a projektet már nem tudjuk időben befejezni waterfall szerint, csináljuk mostantól agilisan, akkor nem kell tesztelni és dokumentálni."

Nem kéri az ügyfél, ja. Valaki csak elmondta neki, hogy ne is kérje. Pedig kellene legyen.

"Banyek, akkor biztos ruszki kém!"

Nem, nem ruszki kém.

"A Product Owner felelőssége, hogy legyen Product Backlog, de a konkrét elkészítését nyugodtan delegálhatja. És szokták is. És ezeket az embereket, akik kitúrják a kívánságokat, elvárásokat és vagy leírják, vagy ott vannak, hogy megválaszolják a kérdéseket, BA-nak szokták hívni."

Így van. Csak ekkor a product owner tulajdonképpen project manager, álruhában. Lehet product owner-nek nevezni, de ha úgy beszél, mint egy project manager, úgy viselkedik, mint egy project manager és úgy néz ki, mint egy project manager, akkor nem product owner, hanem project manager.

"Ha Proxy Product Ownernek hívom, az jobban tetszik?"

És ez mire is jó? Ott vagyok egy csapatban, például backend fejlesztőként, jobbra tőlem ott van egy frontend fejlesztő, balra egy mobil fejlesztő, szemben egy üzemeltető, tőle balra a product owner, jobbra pedig az ügyfél. Miért kellene nekem egy proxy product owner? Ha valamit nem értek, akkor rábaszok a nagy piros gombra, aztán megbeszéljük ott helyben az érintettekkel, hogy mi a problémám és megpróbáljuk megoldani. Mihez kellene ehhez egy proxy product owner, aki csak egy vízzáró réteg a információ áramlásban, amikor ott ül velem srévizavé maga a product owner?

Ja, hogy nem egy helyen ülünk? Ja, hogy nem ugyanazon a feladaton dolgozunk? Ja, hogy nem csak egy feladaton dolgozunk? Hát, akkor az már el van baszva... nem is kicsit.

"Az Agile az egy gondolkodásmód."

Úgy érted agile külsőségek? Persze, lehet színészkedni.

"A Product Owner felelőssége, hogy legyen Product Backlog, de a konkrét elkészítését nyugodtan delegálhatja. És szokták is. És ezeket az embereket, akik kitúrják a kívánságokat, elvárásokat és vagy leírják, vagy ott vannak, hogy megválaszolják a kérdéseket, BA-nak szokták hívni."

Így van. Csak ekkor a product owner tulajdonképpen project manager, álruhában. Lehet product owner-nek nevezni, de ha úgy beszél, mint egy project manager, úgy viselkedik, mint egy project manager és úgy néz ki, mint egy project manager, akkor nem product owner, hanem project manager.

A waterfall Projekt Manager szerep feladatai szét vannak osztva mások között. Van, amit a Scrum Master csinál, van, amit a Product Owner, van, amit a Development Team, és vannak olyan dolgok, amiket a Scrum keretein belül senki (de a Scrum-on kívül valaki általában igen).

Szóval a PO-t PM-nek nevezni az erős túlzás.

Az általam írt esetben a PO-nak nincs semmivel több projekt irányítási szerepe, mintha csak egyedül dolgozna, egyszerűen a saját feladatát nem ő egyedül végzi, hanem egy kis csapat, akiket ő irányít.
Miért csinálják ezt? Két példát láttam eddig: vagy azért, mert az ügyfél olyan embert jelölt ki PO-nak, akinek egy csomó egyéb dolga is van, ezért nincs elég ideje erre, vagy annyira nagy és komplex a rendszer, hogy egy ember nem tudja az egészet részleteibe menően lefedni, hiába dolgozik 100%-ban ezen.
Ilyen esetekben a PO megőrzi a döntéshozási szerepet, de az apró részletek kikutatásába, megbeszélésében, dokumentálásában a csapat többi tagja is részt vesz (sokszor ők csinálják az oroszlánrészét).

"Ha Proxy Product Ownernek hívom, az jobban tetszik?"

És ez mire is jó? Ott vagyok egy csapatban, például backend fejlesztőként, jobbra tőlem ott van egy frontend fejlesztő, balra egy mobil fejlesztő, szemben egy üzemeltető, tőle balra a product owner, jobbra pedig az ügyfél. Miért kellene nekem egy proxy product owner? Ha valamit nem értek, akkor rábaszok a nagy piros gombra, aztán megbeszéljük ott helyben az érintettekkel, hogy mi a problémám és megpróbáljuk megoldani. Mihez kellene ehhez egy proxy product owner, aki csak egy vízzáró réteg a információ áramlásban, amikor ott ül velem srévizavé maga a product owner?

És ha a PO nem ül veled szemben srégen ott a PO?

Mert ugye a PO-nak munkája is van. Ő sem mindent tud, csak képviseli az egész business-t. De ehhez neki beszélnie kell a mindenféle népekkel, akik különféle dolgokat akarnak.
Szóval ha csak simán a PO munkát végzi, akkor se lesz mindig ott, de sok esetben a PO feladatokon kívül megörököltek más feladatokat is, amiket továbbra is el kell látniuk.

Dolgoztam olyan projekten, ahol a PO a Demón és Sprint planningen kívül hetente kb. fél órára volt elérhető kérdezz-felelekre.

Jó ez így? Nem. De ettől még ha ezt dobja ki a gép, akkor ugyan elmagyarázhatod az ügyfélnek, hogy ez így nem lesz jó, de általában nem változik semmi, és az adott kontextusban elérhető dolgokból kell kihozni a legjobbat.

És ez a legjobb sok esetben egy BA, aki veled szemben átlósan ott ül, és ha megnyomod a nagy piros gombot, akkor jön, és válaszol a kérdéseidre, és ha döntés kell, akkor felírja, hogy miben kell dönteni, és elmegy és idővel meghozza a választ.

Igen, idővel, nem azonnal. Ezért ez nem ideális eset, de az adott helyzetben a legjobb, ami elérhető.

Amúgy az a benyomásom, hogy vagy nagyon idealista vagy, vagy nagyon szerencsés környezetben dolgoztál eddig, de a való világot nem nagyon ismered (vagy nem hagyod, hogy a valóság megzavarjon)

"A waterfall Projekt Manager szerep feladatai szét vannak osztva mások között."

Nem. Bocsánat, de lófaszt van szétosztva a PM szerep feladatai egy agilis projektben.

"Az általam írt esetben a PO-nak nincs semmivel több projekt irányítási szerepe, mintha csak egyedül dolgozna, egyszerűen a saját feladatát nem ő egyedül végzi, hanem egy kis csapat, akiket ő irányít."

Nem, a PO nem _irányít_. A PO dönt. Mégpedig azonnal és helyben. Nem mondja meg, hogy ki és mit csinál. Azt mondja meg, hogy a fejlesztett termék mit kell tudjon és priorizál. Nincs irányító szerepkör egy agilis csapatban. Ha van irányító, ha van hierarchia, ami nem szakmai hierarchia, akkor az már rég nem agilis csapat.

"Két példát láttam eddig: vagy azért, mert az ügyfél olyan embert jelölt ki PO-nak, akinek egy csomó egyéb dolga is van, ezért nincs elég ideje erre, vagy annyira nagy és komplex a rendszer, hogy egy ember nem tudja az egészet részleteibe menően lefedni, hiába dolgozik 100%-ban ezen."

Nincs más dolga. Ha más dolga is van, főleg sok dolga van, akkor az nem scrum és nem agile. Az egy intézményesített anarchia és szőnyeg alá söpört balfaszkodás... ja, ezt már mondtam. Lehet több PO, de egy sztorinak egy PO-ja van és amíg a csapat azon a sztorin dolgozik, addig az adott PO ott és csak ott van, mind fejben, mind fizikailag, hogy a hiánya ne blokkolja a munkát.

"És ha a PO nem ül veled szemben srégen ott a PO?"

A PO ott ül. Ha nem srégen, akkor szemben vagy mellettem. Ha nem ül ott a PO, akkor nem product owner.

"Dolgoztam olyan projekten, ahol a PO a Demón és Sprint planningen kívül hetente kb. fél órára volt elérhető kérdezz-felelekre."

Na, ő nem PO volt, hanem egy folyamaton teljesen kívüli üzlet/ügyfél. A projekt pedig csak külsőségekben volt agilis.

"Amúgy az a benyomásom, hogy vagy nagyon idealista vagy, vagy nagyon szerencsés környezetben dolgoztál eddig, de a való világot nem nagyon ismered (vagy nem hagyod, hogy a valóság megzavarjon)"

Kevés jó példát láttam. A legtöbb példa egy külsőségekben agilis, ám gondolkodásmódjában vízesés volt. Sok egyéb meg külsőségekben agilis, egyébként meg anarchia és káosz. Pont ilyen példákat mondtál, mint - szerinted - agilis projekt. Nem, ezek nem agilis projektek voltak... :/

"A waterfall Projekt Manager szerep feladatai szét vannak osztva mások között."

Nem. Bocsánat, de lófaszt van szétosztva a PM szerep feladatai egy agilis projektben.

Hanem?

Beszéljünk most Scrum-ról, ne csak úgy általában agilis projektről! Meséld el, hogy szerinted azokkal a feladatokkal akkor mi történik!

"Az általam írt esetben a PO-nak nincs semmivel több projekt irányítási szerepe, mintha csak egyedül dolgozna, egyszerűen a saját feladatát nem ő egyedül végzi, hanem egy kis csapat, akiket ő irányít."

Nem, a PO nem _irányít_. A PO dönt. Mégpedig azonnal és helyben. Nem mondja meg, hogy ki és mit csinál. Azt mondja meg, hogy a fejlesztett termék mit kell tudjon és priorizál. Nincs irányító szerepkör egy agilis csapatban. Ha van irányító, ha van hierarchia, ami nem szakmai hierarchia, akkor az már rég nem agilis csapat.

Szövegértelmezés? Nem is érted, hogy mit írtam.

Egyszerűen, hátha az segít:
- azt írtam, hogy a PO irányítja azokat az embereket, akiknek ő delegálta a munkát. Érted. Nem a fejlesztőcsapatot.
- "A PO nem irányít, hanem dönt", ez a Scrum Team esetében igaz. Én ugyan nem erről beszéltem, de legalább nem mondtál butaságot itt.
- "Mégpedig azonnal és helyben." DAFUQ? Ha valaki felhoz egy problémát, amiről a PO-nak nincs információja, mi a fenéért hozna azonnal döntést? Számomra az egész Agile világ egyik szépsége az, hogy információk alapján döntünk, nem pedig csak amúgy waterfall módra, hasracsapással, mint ahogy szerinted kéne. Nem. A PO mérlegeljen és döntsön, ha van információja. Ha nincs információja, akkor meg az lesz a döntés, hogy ezt most parkoljuk, és közben a PO megszerzi a döntéshez szükséges információt.
- "Nincs irányító szerepkör egy agilis csapatban. Ha van irányító, ha van hierarchia, ami nem szakmai hierarchia, akkor az már rég nem agilis csapat." Azt ugye tudod, hogy Agile != Scrum?

Nézd meg a szerepeket pl. ezen az ábrán:

"DAFUQ? Ha valaki felhoz egy problémát, amiről a PO-nak nincs információja, mi a fenéért hozna azonnal döntést? Ha nincs információja, akkor meg az lesz a döntés, hogy ezt most parkoljuk, és közben a PO megszerzi a döntéshez szükséges információt."

Mert minden információja megvan. Ott és helyben. Ezért tettük egy fedő alá az egész bagázst, mindenki ott van, akinek köze van az adott feladathoz, a "PO megszerzi az információt" annyit jelent, hogy odafordul jobbra vagy balra és megkérdezi. Ha ehhez neki annyi idő kell, hogy érdemes elővennie a csapatnak egy másik sztorit, akkor rosszul van összerakva a csapat kompetenciája.

Ahol a PO-nak egy csomó idő kell, amíg információt szerez és közben parkolnia kell a feladatnak, az nem scrum, az színtiszta baszkolódás. Ott a PO egy PM, a scrum csapatnak pedig nem tagja mindenki, akinek kellene... de ezt is írtam már... ilyenkor van az, hogy:

"Ha nincs egy full stack csapat, akkor szokott olyan baszkolódás lenni, hogy kell egy nyomorult adatbázis mezőt felvenni egy nyomorult táblába és fel kell adni egy ticket-et, hogy ezt valaki-valamikor megcsinálja; mivel nincs ott a mező, ezért hopp, következő feladat, ott hiányzik egy redirect a webszerveren, erre is fel kell adni egy ticket-et, hogy majd valaki valamikor megcsinálja; hopp, következő feladat, ahol az üzlet/ügyfél véleményére kell várni; hopp, következő feladat, aztán ugrál a csapat cikk-cakkban a félkész sztorik között, mint a mezőn menekülő nyúl, de soha semmi nincs kész, hónapokon át nullás egyenes a burnout chart, kis rezgésekkel, mint egy agyhalott EEG-je, aztán valamikor hónapokkal később születnek sztahanovista sprintek, amelyekben minden korábbi híg fos hirtelen összeáll egy kemény szardarabbá, de igazából senki nem tudja, hogy melyik funkció mikor fog elkészülni és ami elkészült, azt mikor kellett volna szállítani és amit átadtak, azt hogy kell élesíteni és ha élesbe került, akkor ki üzemeltesse és hogy javítsák a hibákat. Ja. De agilis a projekt."

Remekül megerősítetted ezeket. Pont ezt a működésmódot írtad le... :/

Tehát nálatok a product owner 100%-ban ismeri a projekt requirementjeit, és egy személyben tud mindenről dönteni (felhasználóbarátság, teljesítmény, jogi/jogszabályi környezet, rendszer(ek) amihez illeszteni kell, pénzügyi folyamatok, stb.)?

Illetve, mi köze van a csapat kompetenciájának ahhoz, hogy a PO mennyi idő alatt tud dönteni, hogy ő mit is szeretne?

Ja. Csak sok helyen a PO az egy PM, akinek fogalma nincs a termék részleteiről, nincs döntési jogköre, se kompetenciája... és pont úgy viselkedik, mint egy PM.

Mondjuk megértem, mert ha kimondják odafönték, hogy agilisek leszünk, akkor nagyon egyszerű ugyanazt csinálni, mint eddig, csak azt "már agilisen" csináljuk.

Így lesz a PM-ből PO, a PM főnökből Scrum Master, a csapatok pedig nem sztori orientáltak, hanem lesz külön fejlesztő csapat, üzemeltető csapat, tesztelő csapat, és így tovább, ahogy volt mindig is. Sok helyen tényleg csak dísz az agilis jelző ilyenkor, de mindenki eufóriában van, hogy most aztán minden jobb lesz. Azonnal.

Láttam jól és olajozottan működni. Kevés helyen.

És láttam egy csomó helyet, ahol csak alibiznek, ami ott van, az nem scrum és nem is agile, csak úgy tesznek, mintha. Intézményesített anarchia van agilis külsőségekkel, waterfall gondolkodásmóddal és waterfall termékfejlesztésből visszamaradt emberekkel, akiknek nincs igényük arra, hogy másképp dolgozzanak, mint tették 15-20 éven át. Ez egyébként nem probléma, mert meg kell ugye tanulni és az idő-idő-idő... ez akkor probléma, ha ők váltig állítják, hogy márpedig agilisek, elértek az agilis nirvánába és mindent jól csinálnak. Pedig messziről bűzlik, hogy mennyire nem. Mindegy, nem dohogok tovább.

Én egészen pontosan azt írtam, hogy a "PO megszerzi az információt" annyit jelent, hogy odafordul jobbra vagy balra és megkérdezi.

Nem teszünk félre sztorit addig, amíg kész nincs, kivéve, ha világvége van. Mindenki ott van egy légtérben, akiknél a döntéshez szükséges információ megvan és a döntés azonnali.

És ez, amit írsz, hülyeség.

1: a PO-nak a Product Backlog feltöltése is a feladata (egy csomó más mellett). Ha folyton ott ül a fejlesztők között, nem tudja a munkáját csinálni.

2: Egy Product Backlogon még sima Scrum esetén is dolgozhat több csapat is. Ha a PO leül az egyik csapathoz, akkor közben nem tud a másik csapatnál is ott ülni, szóval a te ideális világodban egy workstreamen max. 1 csapat tud dolgozni.

3: A Product Backlog készítéséről beszélünk, még mindig. Ehhez a PO-nak üzleti stakeholderekkel, jogi osztállyal, marketinggel, végfelhasználókkal, stb. kell beszélnie, hogy megtudja a szükséges információkat. Nem tudom, te hogy gondolod, de senki sem születik úgy, hogy mindent tud, ami egy termék feljesztéséhez most és a jövőben bármikor szükséges lesz.

3bis: amennyiben azt képzeled, hogy a fejlesztőcsapat mellé odaültetjük a PO mellett az összes business stakeholdert, a marketing osztály képviselőjét, egy jogászt a jogi osztályról, egy halom végfelhasználót, stb. azért, hogy ha kérdés van, a PO-nak ne kelljen felemelnie a fenekét és utána járni a dolgoknak, hanem csak átkiabál a szoba másik oldalára, és meg is van a válasz, akkor valami nagyon elvarázsolt világot képzelsz el.

Oké, a fekete billentyűk hangosabbak... én itt már csak további jó agilis vízesést tudok kívánni. Egyszer látnál rendes agilis csapatot, rájönnél, hogy mennyire más világ, mint a big corporate enterprise "agile".

"amennyiben azt képzeled, hogy a fejlesztőcsapat mellé odaültetjük a PO mellett az összes business stakeholdert, a marketing osztály képviselőjét, egy jogászt a jogi osztályról, egy halom végfelhasználót, stb. azért, hogy ha kérdés van, a PO-nak ne kelljen felemelnie a fenekét és utána járni a dolgoknak, hanem csak átkiabál a szoba másik oldalára, és meg is van a válasz, akkor valami nagyon elvarázsolt világot képzelsz el"

Aham, dolgoztam ilyen helyen, tényleg elvarázsolt világ a nagyvállalati balfaszságokhoz képest... igen, mindenki ott van, akinek érdemi köze van egy sztorihoz, tényleg mindenki. Ettől működik a dolog. Ha ez nem adott, akkor az nem működik. Lehet, hogy jobb egy kicsit, mint volt, de igen-igen-igen messze van attól, amire egy valóban agilis módon működő csapat képes.

Ha kurva tömör akarok lenni, akkor az egész agilitás egyetlen paraméterrel mérhető: mennyi idő alatt jut el a reggeli kávé mellett felmerült ötlet az éles rendszerig. Minden más bullshit és színjáték.

mindenki ott van, akinek érdemi köze van egy sztorihoz, tényleg mindenki. Ettől működik a dolog.

Nem ettől működik. Ez persze nem hátrány, de nem is szükséges.

Sajnálatos, hogy nem érted meg azt, hogy Agile != Scrum, és a világban nem csak 10 emberes startupok léteznek.

Ha kurva tömör akarok lenni, akkor az egész agilitás egyetlen paraméterrel mérhető: mennyi idő alatt jut el a reggeli kávé mellett felmerült ötlet az éles rendszerig. Minden más bullshit és színjáték.

Nem.

Azt nem érted, hogy én nem azt mondom, hogy az a szitu, amit leírsz, az nem jó és hatékony.

De az, csak éppen az egy nagyon keskeny szelete az agilis világnak, ahol éppen az kell. Márpedig az Agile meg a Scrum, meg az összes többi is csak eszközök. Arról szólnak, hogy egy adott problémát megoldjunk.
Te a gombhoz akarod alakítani a kabátot, és nem érted, ha azt mondom neked, hogy nem látod a fától az erdőt.

Az a baj, hogy annak ellenére, hogy nem tudod, miről szól az Agile és nem ismered a Scrum szabályait, nagy hangon azt bizonygatod, hogy minden, ami nem az, ahogy te félreértelmezed ezeket, az szar.

Engem nem zavar az, ha nem akarod ezeket igazából megismerni, mert boldog vagy a saját kis világodban, csak az zavar, ha másokat leugatsz.

Amennyiben esetleg megadod az esélyét annak, hogy kicsit szélesíts a látókörödön, azt javasolnám, hogy olvasd el először az Agile manifesztót, Másodjára nézd meg a State of Agile report néhány példányát (de a 8. report 7. oldalát mindenképp nézd meg), végül ha van elég lelkierőd hozzá, olvasd el a Scrum Guide-ot, plusz nézz meg néhány Agile metódust, ami nem Scrum. Mondjuk SAFe, DSDM jó lehet, hogy egy kicsit szélesítsd a látásmódodat. Nem kell nagyon elmélyedned ezekben, valami leírást, hogy miről szólnak, mi a megközelítésük, elég lesz elolvasni.

További szép napot!

Nézd, egy ideje az a meggyőződésem, hogy ezt vagy jól érdemes csinálni vagy sehogy.

Ahogy egy Fortran programozó remek Fortran programokat tud írni mindenféle programnyelven, úgy a régi és nagy múltú cégek remekül tudnak vízesés modellben dolgozni minden módszertan és eszköz esetén.

Egyszerűen erről hoztál folyamatosan példákat, hogy miképp lehet a lehető legkisebb szervezeti átalakítással és gondolkodásmód váltással látszólag agilisen dolgozni. Az agilis képzések is szinte mind erről szólnak, hogy miképp lehet a lehető legkisebb szervezeti átalakítással és gondolkodásmód váltással látszólag agilisen dolgozni. Erről adnak papírt is, nekem is van, tulajdonképpen szart se ér.

Azért ér szar se, mert nem arról szól, hogy miképp kell a céget agilissé tenni, hanem arról, hogy melyik módszertan felel meg a legjobban a cég jelenlegi folyamatainak és melyik rugalmas annyira, hogy át lehessen alakítani úgy, ahogy nagyjából a cég napi szinten működik. És ilyenkor lesz egy agilis projektben a JIRA ticket workflow 27 lehetséges státuszú, amelyeket nagyjából 97 transition köt össze. Megtörtént eset.

Agilis csapathoz sajnos az kell egy érett cégnél, hogy kibasszanak az utcára száz melósból hetvenet és felvegyenek húsz másikat, akik hoznak új szemléletet magukkal valahonnan. De ez ugye hatalmas kockázat, szóval ezek a cégek szépen befizetnek valami konzultációs céghez egy rahedli pénzt, hogy majd ők megoldják azt, hogy maradjon a száz melósból mindenki, plusz még fel kell venni pár agilis hozzáértőt és majd mindenki megtalálja a maga szerepét. Ebből lesz az, hogy mindenki ugyanazt fogja csinálni, mint korábban, ugyanannál az asztalnál, ugyanaz lesz a névjegykártyáján, csak lesznek agilis külsőségek, de nem javul se a minőség, se a kihozatal. Sőt.

Odamész dolgozni, büszkén mondják, hogy van náluk CI/CD, amikor pedig jobban megnézed és belekérdezel, akkor mondják, hogy "ja, igen, nálunk continuous delivery van, igen, de csak a fejlesztő környezeten, tesztre két hetente megy, élesíteni pedig kéthavonta szoktunk, mert egy ekkora cégnél nem lehet naponta többször új funkciót kitenni". Megtörtént eset.

"Amennyiben esetleg megadod az esélyét annak, hogy kicsit szélesíts a látókörödön"

Az én látóköröm sajnos elég tág ebben a tekintetben és ezen nem nagyon tágít, ha újra elolvasok pár bullshit oldalt vagy megnézem, hogy a rahedli pénzt leakasztó konzultációs cégek még mindig így működnek-e. Így. Szóval, ha nálatok az agilis módszertan bevezetésekor nem rúgtak ki szinte senkit, akkor ott is pont ez van. És innen ez látszik is. Lehet, hogy idővel te is látni fogod ugyanezt. Széllel szemben amúgy se lehet hugyozni csak szarni.

Az első kérdés:

1, és ezt jogi és anyagi felelőssége teljes tudatában teszi meg?
2, a második kérdést szerintem megválaszolták fent, de jól értem-e? Az azonnali válaszadás azokra a story-kra vonatkozik,
amik az adott sprintben vannak, a többivel kapcsolatban pont az a dolga, hogy olyan állapotba hozza őket a sprintre,
hogy ne kelljen várni olyan válaszokra, amire nincs szüksége?

"1, és ezt jogi és anyagi felelőssége teljes tudatában teszi meg?"

Igen.

"2, a második kérdést szerintem megválaszolták fent, de jól értem-e? Az azonnali válaszadás azokra a story-kra vonatkozik, amik az adott sprintben vannak, a többivel kapcsolatban pont az a dolga, hogy olyan állapotba hozza őket a sprintre, hogy ne kelljen várni olyan válaszokra, amire nincs szüksége?"

Igen.

"Ahol a PO-nak egy csomó idő kell, amíg információt szerez és közben parkolnia kell a feladatnak, az nem scrum, az színtiszta baszkolódás."

Nem, ez nem feltétlen igaz. A PO a product backlog azon elemeivel amik még "messze vannak" és nincsenek rendesen kidolgozva (mert még nem is kell hogy ki legyenek) tetszőleges mennyiséget "baszkolódhat". Az aktuálisan a sprintben és a következő sprintben (under refinement) levő PBI-kkel kapcsolatban viszont full képben kell lennie.

Disclaimer: CSM és CSPO vizsgáim megvannak

--
Gábriel Ákos

"Az aktuálisan a sprintben és a következő sprintben (under refinement) levő PBI-kkel kapcsolatban viszont full képben kell lennie."

Hát pedig erről van szó... egészen konkrétan arról, hogy aktuális sprintben teszünk parkolópályára sztorikat, mert a PO épp PM-et játszik és vadássza az információt, a csapat meg közben vagy kávézik vagy szétszéled és foglalkozik valami mással...

Nem tudom, te melyik csatornát nézed, de nem erről volt szó eddig.

Azt írtam, hogy a product backlog készítése feladatot a PO delegálhatja BA-nak (ami szerinted nem létezik). Ezt a BA csapatot vezeti. Erre te azt írtad, hogy nem vezet, hanem dönt. Azonnal, ott helyben.

Szó sem volt Sprintről, sprint backlogba beválogatott backlog itemekről és fejlesztőcsapatról.

Amit ebben a szálban írtok egyik nem zárja ki a másikat.
Létezik Scrum projektben is BA, aki segít a PO-nak sztorikat kidolgozni.
Láttam ilyet nagy cégnél, jót is meg rosszat is. A jó BA kincset ér, tud a dolog működni.
Nyilván annyival a csapat előtt kell járjon a PBI-k kidolgozásával hogy 1-2 sprintre való meló mindig ott legyen készre specifikálva.
A rossz BA meg béna sztorikat produkál amikkel csomót kell szenvedni refinement alatt, adott esetben annyit hogy elfogy a backlog és nem lesz "ready" story a következő sprintre.
Ilyenkor van a sprintbe fintorogva behúzás és a fejlesztés közbeni kérdezgetés (és persze szar estimate-ek).
Láttunk ilyet is.
Attól még a Scrum jó, az agile jó, lehet nagy cégben is jól csinálni. És lehet rosszul is.

--
Gábriel Ákos

Ha nincs információja, akkor meg az lesz a döntés, hogy ezt most parkoljuk, és közben a PO megszerzi a döntéshez szükséges információt."

Mert minden információja megvan. Ott és helyben.

Az eddigi beírásaid alapján azt hittem, hogy ismered a Scrum keretrendszert, van elképzelésed, hogyan működhetne egy ideális világban, csak nincs igazán tapasztalatod. Szeretek Agile-ról beszélgetni emberekkel, és megismerni a véleményüket, tapasztalataikat.

De látom, hogy elképzelésed sincs, hogy a PO mit csinál. Innentől kezdve nem tudom, mennyire érdemes komolyan vennem, amit írsz.

Főleg, miután a korábbi nagy lendületű kinyilatkozásaidra is amikor konkrétan rákérdeztem, akkor csak nagy kuss volt a válasz.

Ha tévednék, és voltaképp tudod, hogy miről beszélsz, és folytatni szeretnéd értelmesen a beszélgetést, akkor légyszi először válaszolj a konkrét kérdésekre, aztán a jövőben gyors válasz írás és indulatos fröcsögés előtt próbáld meg értelmezni azt, amit mások írnak, mert eddig össze-vissza beszéltél.

Munkát keres, nem? Ha a CV-jében UML van akkor sajnálni fogják szegényt, ha Scrum akkor meg örömmel felveszik, ennyikeh.
Igen, ha mérnöknek vagy programtervező matematikusnak készülsz, akkor fogsz találkozni UML-el, mert bizonyos nagyon magas szinten még mindig hasznos tudomány lehet.
De ezek Gyalog Béla programozók, 99%uknak soha nem lesz szüksége UML-re.
Mert a piac túlhaladta.

Már nagyon más a technológiai környezet, nagyrészt integráció és testreszabás van, frameworkok vannak ezerrel, és nincsenek nulláról írt feladatok.

--
Gábriel Ákos

Az UML egy grafikus ábrázolási módszer, amit jobb helyeken arra használnak, hogy működést/struktúrát gyorsan, kb.
mindenki számára egységes módon felvázoljanak (mi whiteboard + marker-t használunk, aztán fotó).

A Scrum pedig egy hogyan működjön a projektünk, hogyan tudjunk tervezni és becsülni módszertan.

Kb. mintha arról vitatkoznátok hogy a káposztásrétes jobban ízlik-e mint ahogy a BMW gyorsul?

> Kb. mintha arról vitatkoznátok hogy a káposztásrétes jobban ízlik-e mint ahogy a BMW gyorsul?

+1, nem kötelező UML-t használni, meg biztos vannak jobb megoldások, de az nem feltétlenül baj, ha egy csapat egységes nyelvet használ a kommunikációra tervezéskor (is). Hogy ez az UML vagy valami más, az tökmindegy.

Az UML-nek van egy általánosan használt (és valóban jól használható része): az entity relationship model rész.
De ez az UML tudásanyagnak mondjuk 5%-a. Ha megnézed az enterprise architectet brutális mennyiségű dolgot le lehet tervezni, más kérdés h mennyi értelme van (nem sok).

Amit érdemes tudni róla az fél óra alatt megtanulható kb :)

--
Gábriel Ákos

https://tallyfy.com/uml-diagram/

Ebből én párat szoktam használni (component, class, communication, sequence), de vannak olyanok, amiket eddig még
nem láttam, bár néha hasznos lehetne.

Arányaiban messze a communication, sequence a legtöbb, amit használok, a class-t csak néha (megbeszélésnél), a
use-case-t pedig analízisnél.

Nekem egy projektem volt, valahogy 99 környékén, ahol A-tól Z-ig használtuk a tervezés során az UML-es CASE eszközt.

A diagramok nagy részét azóta soha nem is használtam.

Maga az elképzelés és a tool egyébként ügyes volt.

Úgy emlékszem, valami Business Relationship Diagrammal vagy esetleg Process diagrammal indított, ami igazán sokat nem adott ugyan hozzá a dologhoz, de ebből valahogy hirtelen use case diagrammokhoz jutottunk (talán a processz lépésekhez tartozott egy-egy use case diagram).

Ott ugye listáztam a use case-eket, és akkor mindegyikhez keletkezett egy sequence diagram.
A sequence diagramon ahogy adogattam hozzá a objekteket, úgy jöttek létre automatikusan az osztálydiagramok, és ahogy az egymásnak küldött üzeneteket adtam hozzá, úgy adta hozzá automatiksan a függvényeket.

Szóval az egész use-case és sequence végiggondolás és lerajzolás után volt egy félig kész class diagrammom, amibe már csak propertyket kellett beleírnom.

Valami hasonló most is jó lehet, ha valaki programot tervez, de az igaz, hogy Agile fejlesztés során a programot nem egy ember szokta az utolsó szögig előre megtervezni, hanem darabonként különböző team-ek.

Agile projektekben inkább azt szoktam látni, hogy a külső rendszerek kapcsolódását, az integrált (általunk fejlesztett + külső rendszerek) kommunikációját, illetve különféle folyamatok és állapotok leírására szokták használni. Pl. van egy áru rendelés workflow, mindenféle trigger pontokkal, elágazásokkal. Ezt le lehet írni szövegesen is, (van, ahol ezt kérik), meg le is lehet rajzolni (és ha rajzot kérnek, akkor ugyan sok helyen nem elvárás, de örülnek, ha UML-ben jön a rajz)

Az, hogy nincs becsomagolva nem feltétlenül probléma, ha adhatod a programoddal ingyen és szabályosan.

Sok esetben már eleve az alkalmazás mellé csomagolják a JVM-et, mert ésszerűbb mint arra építeni, hogy majd a user telepíti a kellő verziót, de nem megy előre amikor nem kéne. Melléteszed a JVM-et, és akkor lényegében nincs külső függőséged, csak működik minden.

Egyik progsulitól van nálunk több srác is. A legrégebbi úgy 1 éve. Kb ugyanazt lehet elmondani róluk is mint a friss diplomás juniorokról. Tudnak annyit, hogy el lehet kezdeni velük dolgozni. Akit érdekel a téma tényleg és szorgalmas az gyorsan tud fejlődni. Akit nem érdekel és "csak a pénz" miatt az meg vergődik végül kiesik... Igen látványos különbséget lehet tenni közöttük.