Fontosabbak és értékesebbek a programozók a cégeknek, mint a menedzserek
2017-12-13T10:46:56+01:00
2018-01-20T12:22:29+01:00
2022-07-21T08:21:58+02:00
  • Jaja: A másik dolog meg nem csak a nagyság, de a hosszúság: Bár már rég nem vagyok a projekten, de simán lehet olyan, hogy az egyébként senior ember megkeres azzal, hogy "ez hogyan is volt? Most átáll a projekt Java8-ra, ugye kicserélhetjük OSGi alatt JavaFX-esre a felület egy elemét?" - nyilván kipróbálhatja, de anno nekem már volt rá egy POC-om és tudom, hogy lehetséges. Most amikor ajánlatot kell adni arra, hogy ez az elem végre fogadni tudja majd egy kicsit jobb support-al a word-ből való copy-paste-et, vagy sem, akkor ez a megkérdezés kb. 10 másodperc, míg lepocolni minimum egy óra, rossz esetben akár egy nap.

    Ehhez viszont nem szükséges az, hogy már ne légy a projekten, mert épp elég az, ha csak már olyan nagy, vagy olyan régi, hogy más részerin dolgoztok. Nyilván "kell" ilyenkor beszélni - mármint azért tettem idézőjelbe, mert elméleti lehetőséged mindig van, hogy ne kommunikálj, csak nagyon nem éri meg.

    A lényeg az, hogy az ilyen jellegű kérdezés az szerintem nem kisebbíti a kérdezőt sosem: sőt, ha ez nem történik meg, az sokszor sokkal nagyobb kár... Egyébként pedig meg kell tanulni lerázni az embereket, ha túl sokan kérdezgetnek: mármint ha nincs időm, akkor ezekre egyszavasat válaszolok, ha van időm, akkor megmondom hol keresse a meglévő POC-ot, de semmiképpen nem az van, hogy odasétálok és ott turkálok a kódjában ilyenkor - kivéve ha már napok óta keresi valaki a threading bugot mondjuk...
    Mutasd a teljes hozzászólást!
  • Mondom, itt nagy rendszerekről van szó. Én simán fejre állítok neked egy ilyen rendszert egy sor átírárásával úgy, hogy te utána három hétig keresed azt az egy sort, és az általam átírt fájlnak szinte semmi köze nem lesz ahhoz a ponthoz ahol a rendszer fejre állt. Amúgy amíg csak egyszemélyes projekteken dolgoztam kb. én is így láttam ezt. Aztán úgy 6 év különféle nagyobb projekteken picit megváltoztatta ezt a szemléletmódot.
    Mutasd a teljes hozzászólást!
  • Kiegészítve:
    A jó cég pedig a legjobban kezelje a legkiválóbb programozóit; emberi vonatkozásaiban!
    Ezzel egy időben képes legyen pontos program tervet adni a programozóinak!
    Mutasd a teljes hozzászólást!
  • Már csak önmagában azért sem, mert az teljesen elfogadhatatlan sok project esetében, hogy valami csak egy ember fejében és dokumentációk száz oldalain legyen meg, ahelyett, hogy a nagy része 2-3 ember fejében egyszerre van benne (mi van, ha valaki szabin van, ha felmond, ha beteg, stb.), ehhez pedig az kell, hogy folyamatosan együtt dolgozzanak nagyjából ugyanazon.

    Hát így keletkeznek azok az emberek, akik három éve nem voltak már szabadságon

    Egyébként viccet félretéve - bár sajnos van ahol ez a "trucknumber" tényleg 1 - azt még megértem, hogy valaki esetleg kirúghatatlan akar lenni, vagy ilyesmi, de idővel így tényleg szabira se mehet kb, ami azért már önmagára nézve is problémás.

    Annyi, hogy szerintem jobb, ha a tapasztalatot arra fordítja egy vezető, hogy miként tud a csapat fejlődni és magától is működni - mintsem, hogy ő legyen a főmegmondóember. Ha ő a főmegmondóember és nem meri a fontos dolgok egy részét delegálni, akkor ez így is fog maradni és ő maga lesz a szűk keresztmetszet. Ilyenkor szerintem jobb ha két kolléga helyett megír magának két automatikus kódgeneráló scriptet néha, mert lehet hogy összsebességben azzal lesz gyorsabb a működés .

    Ez fent leírt coach-jellegű felállás viszont azért nehéz, mert természetes félelemérzetet kelt amíg valaki még sose próbálta ezt így csinálni: "mi van, ha túlnő rajtam és ki leszek rúgva?" Ez szerintem eltúlzott félelem és általában nincs valóságalapja. Nem mellesleg elég kevés olyan (szakmai, vagy humán) vezető van, aki képes úgy végrehajtani a projekteket, hogy közben a csapat ennyire fejlődik, mint ahogy ez a felvázolt félelem feltételezné. Ha sikerül, akkor akkor maga ez a tény, hogy ez sikerül, már magában is szellemi fegyvertény
    Mutasd a teljes hozzászólást!
  • Nekem az a véleményem, hogy a jó programozó bármennyi, tehát bármennyi pénzt megérhet cégeknek. Az utóbbi időben belobbiztak enyhébb szintű programozókat is a világháló online poráloknál. De ennek eredménye igazán nem járt sikerrel. 
    Ez olyan mint az ingatlan piac.
    Az értéket teremtőket (programozókat) meg kell fizetni. Ez lehet szellemi érték és lehet ehhez fűződő vagyoni érték is.
    Még magán emberként is ehhez tartom magam.
    Mutasd a teljes hozzászólást!
  • Oké.

    Továbbra is ez a kérdésem: ...

    Szerintem erre nova76-nak az enyémét megelőző hozzászólásából kiolvasható a világos válasz. Az, hogy ez miért nem volt nyilvánvaló szerintem nem annyira lényeges kérdés.

    Nekem mindegy, hogy ez kommunikációs hiányosság, vagy egy korábbi nap más és kicsit magányos farkasabb hangulatának a következménye, vagy akár az, hogy talán olyan közegben van nova76 kolléga, ahol túltolják a "mindent együtt oldjunk meg - azt is amit nem úgy kell" irányt - vagy bármi más a meg nem értés korábbi oka. Szóval ne ekézzük már egymást azért feleslegesen azt látva, hogy "most legalább rúghatok bele azért egyet", mert ez felesleges dolog még a mentális hadakozás terén is

    Most is azt érzem, hogy másként látjuk a dolgokat pl. én és nova76, de nem azért, mert az ő elképzelése "nettó ostobaság", hanem inkább csak más az álláspontunk néhány dologban itt most.

    Nekem mondjuk herótom van attól, amikor túl rigidek a dolgok és minden papírozottan, meg pozíciók szerint próbál atombiztosított lenni és még el se kezdődik semmi, de már mindenki a hátsóját, a saját zárt világát védi. Na de nem azért, mert nem szeretem a rendet! Hanem azért, mert ahogy én tapasztaltam, ez általában a legnagyobb káoszhoz vezet és egyfajta "fétishez" ahol az emberek megpróbálják a legközelebb is ugyanúgy, mert biztos meg lehet csinálni és majd mi jobban megcsináljuk - hiába van, hogy előtte 1-2 csapat ugyanígy ment félre akár mondjuk... Aztán ott van az is, hogy aki balfék, az akkor is balfék, ha modern és cuki éppen aktuális technikákkal próbálja ezt elfedni és ebből meg pont mondjuk nova is leszűrheti, hogy ha valahol nincs mondjuk vezető fejlesztő, ott biztos teljes a káosz és nem arról van szó, hogy a folyamat másodlagos és a munka az elsődleges - hanem arról, hogy szimplán egyáltalán nincs és nem is akar lenni folyamat, vagy szerepkör és mindenki random cselekszik, de ezt valamilyen hangzatos módszertannak hívják, hogy modern-ek legyenek és ehhez hasonlók. Holott ez nem igaz, bár bizonyos tapasztalati környezetben így tűnhet!

    Egyébként ahogy minden nyelven lehet FORTRAN programot írni, minden módszertanból lehet vízesést is csinálni. :D

    Aztán pedig ha meg valaki már azt is rosszul csinálta - na azt talán jobb ki se gondolni, hogy az milyen eredménnyel jár, amikor az olyan emberke a neten böngészve "modern dolgokat" keresgél és random applikálgat a csapataiban, vagy cégében. Szerintem olyankor jön ki az, amikor vezérigazgatói kötelező utasítás, hogy el kell menni a falmászó csapatépítésre és még az se zökkenti ki az üzleti hatékonyságnövelési flow-ból az arcot, ha valaki 1300kg és a legkevésbé se akar falat mászni mondjuk, a másik ember meg így most nem tudja lefőzni a pálinkát a hétvégén és megbüdösödik a cefre . Az a helyzet, hogy a szervezési kérdések azért a leginkább csak eszközök: ha pedig valaki antiszervező, annak aztán mindegy hogy csavarkulcsot, vagy kalapácsot adsz, mert ez nem sokat oszt vagy szoroz...
    Mutasd a teljes hozzászólást!
  • "Nyilván bele lehet kötni az én szavaimba is."

    Nem a szavaidba kötök bele, hanem nem tudtam, hogy te csak a teameken kívül engeded meg a kooperációt. Ez így pedig még annál is furcsább, mint amit eddig gondoltam, hogy mondasz.

    "Ők egy csapat. Ilyen csapatból több is lehet egy cégnél. Egyáltalán nem kötelező minden csapatnak mindennel foglalkozni. Az egyik mondjuk a főkönyvet viszi, a másik a számlázót, a harmadik a raktárkezelő programot."

    Ebből pedig az következik, hogy soha nem kell megbeszélniük semmit? A vezető fejlesztők pedig az utolsó sorig mindent megmondanak? Akkor minek kell a csapat? Hogy begépelje?

    A példáidat elnézve az is lehet, hogy egyszerűen nem dolgoztál még olyan feladaton/projecten, ahol csapatmunka nélkül sehová sem jutsz (mert annyi a munka és olyan sok mindenhez kellene értened).

    "A csapattagoknak, a beosztottaknak van ebbe beleszólásuk? Szerintem nincs. Kikérhetik a beosztottak tanácsát, de ez a vezetők felada."

    Egyrészt ez csak delegáció kérdése, miért ne kaphatna a csapat olyan feladatot, hogy találjon ki valamit, másrészt, a tanács kérés már önmagában valamilyen értelemben beleszólás, mert különben minek kérnék ki a véleményüket, ha kategorikusan úgyis lényegtelen.

    "Ők fogják kitalálni azt is hogy az egyes szolgáltatások mostantól kezdve egy közösen elérhető táblában kell lenniük, ha eddig nem voltak, hiszen majd főkönyvi számot is kell rendelni hozzájuk."

    A te scenáriódban csak ennyi, amit meg kell beszélni. Más projecteken ennek többszörösét. Meg nem is kettő, hanem mondjuk nyolc embernek, mert olyan a feature. Esetleg még a csapatoknak is van szerepe, mert a részletek is számíthatnak, mindennapi terepmunka tapasztalatok.

    "De ennek ellenére sem viszik el az egész csapatot, mert ez a 2 vezető dolga kitalálni. Mert akár az egész cég ott ülhetne a megbeszélésen, hátha valamelyik titkárnőnek, vagy akár az egyik könyvelőnek lenne jobb ötlete (nem elég ha a főkönyvelő lenne ott, mert akkor a könyvelő csapatból is mindenki legyen ott) ."

    Így van, épp ezért érthetetlen, hogy miért a szélsőségeket emlegeted. Az pl. simán előfordulhat, hogy minden csapatból 1-2 ember megy csak, sima fejlesztők is mehetnek, csak azok, akikre szükség van. Ha közben kiderül, hogy pont a másik kollégára van szükség, akkor vagy behívják a meetingre, vagy átteszik akkorra, amikor mindenkinek jó. Itt számít igazán, hogy egy helyen dolgoznak-e. Nem csak a klasszikus hierarchikus munkaszervezés létezik. Meg jól leírta itt más is: vannak rendszerek, ahol mindenkinek (akár project-/csapatfüggő) szerepei vannak, nem pedig állandó hivatali pozíciója.

    "Itt akkor most pontosítok (a fentiek alapján szükséges), azokra a seniorokra gondolok, aki egy csapaton belül vannak beosztottként és nem a cégnek nevezett csapatról beszélek, tehát két vezető fejlesztő továbbra is összedughatja a fejét. Tehát ilyen példából eddig egy ilyen esetet olvastam tőletek, vagyis hogy két fejlesztő egymás mellett ülve debugol egy kódot, hogy megtaláljanak egy hibát, mert egyedül nem értik meg olyan hamar."

    Elvi szempontból sem érthető, hogy mi a gondod. Ha egy rendszer egy adott szintjén van mit megbeszélni, akkor miért ne lehetne egy szinttel lejjebb is megbeszélni valamit? Az is egy alrendszer, tehát rendszer. Lehet, hogy azt a fejlesztők beszélik meg egy adott szinten (ami az architect szintjénél sokkal lejjebb van), hogy két osztály között mi legyen a kapcsolat, vagy milyen metódusok hogyan hívják egymást. Vagy egyéb olyan részletkérdést, amit az architectnek tök nem dolga kitalálni. A te csapatod kóderekből áll, amit én mondok, az meg programozókból, bizonyos mértékű autonómiájuk és együttműködési képességük van. Az nem működik, hogy mindenkinek egyénileg fogni kelljen a kezét. Az utóbbiból lehet, hogy lesz raktárkezelő szoftver, de photoshop, autocad, meg erőművi szoftver biztos nem. Már csak önmagában azért sem, mert az teljesen elfogadhatatlan sok project esetében, hogy valami csak egy ember fejében és dokumentációk száz oldalain legyen meg, ahelyett, hogy a nagy része 2-3 ember fejében egyszerre van benne (mi van, ha valaki szabin van, ha felmond, ha beteg, stb.), ehhez pedig az kell, hogy folyamatosan együtt dolgozzanak nagyjából ugyanazon. A pénztáros példa pont abban különbözik, hogy a pénztárgépek, meg a pénztáros munka kb. mindenütt egyforma. Ott ha kiesik egy, felveszel egy másikat. De ha egy komplex komponenst csak egy ember ismer egy több M$-os projectben, vagy valakinek el kell olvasnia 150 oldalt, hogy egyáltalán felvegye a fonalat valahogy, az már rég rossz.
    Mutasd a teljes hozzászólást!
  • Oké.

    Továbbra is ez a kérdésem:

    Létezik-e a világon az, hogy egy adott problémára a megoldást hamarabb megtalálja két v. több ember, egymással folyamatosan ötleteket cserélve és egymást katalizálva, vagy ilyen nem létezik, mindent egyénileg könnyebb fel- és kitalálni?
    Mutasd a teljes hozzászólást!
  • Van egy vezető fejlesztő, és van alatta mondjuk 3-4-5 fejlesztő. Ők egy csapat. Ilyen csapatból több is lehet egy cégnél.
    Szerintem azért nem látod át a többiek kérdéseinek a lényegét, mert a fejedben egy csőlátás-szerű, predesztinált felállás van. Ez egy lehetséges felállás egy csapatnál, de nem az egyetlen lehetőség.

    akkor összeül mondjuk a 2 vezető fejlesztő és megpróbálja kitalálni hogy egy számla lekönyveléséhez milyen adatokat kell előállítani és ezt milyen formában lenne jó átadni és mi lesz a válasz és az milyen formában jön. A csapattagoknak, a beosztottaknak van ebbe beleszólásuk? Szerintem nincs.

    Először is hadd dícsérjelek meg, hogy itt legalább már látunk példát arra is, hogy szerinted is létezik csapatmunka. Még a végén sikerül legalább az alapvető dolgokban egy platformra helyeződni, hogy az értelmes különbözőségekről beszéljetek te és akik most veled vitáznak

    Másodorban szerintem ez igen veszélyes ilyen formában - még ha elméletben jól is hangzik az eddig leírt két elképzelés. A valóságban® azonban van egy olyan probléma, amit összefoglalva fluktuációnak, vagy még általánosabban változásnak hívhatunk: Az IT szakmában elég erős mind a személyi, mind a projekt, mind pedig a cégen belüli erőforrás-fluktuáció.

    Szerintem nem titulus kell, hanem szerepkör: tehát legyen (vagy inkább lehet) egy architekt-szerű szerepkör a projekten, de ez inkább hasonlít egy sapkához, mint egy névhez, amihez a hozzátartozó névjegyen azt is rá sikerült még biggyeszteni, hogy "vezető fejlesztő". Aki tapasztalt, vagy csak ügyes ne azért keressen sokat, mert formálisan ezt csinálja, hanem mert tevőlegesen ügyes és tapasztalt - vagy épp mert tevőlegesen ezt csinálja.

    Szóval nem mindegy, hogy az ember a csapatban vezető fejlesztő, vagy "úgy általában mindig ő kell ezt ellássa más új projekten is". Ha jön a projekt, amihez gőze sincs - de másnak van - akkor szakmaiatlan, hogy titulus alapján ő vezesse a szakmai oldalt...

    Mindenesetre a világ nem fekete és fehér: én azt szeretem jobban, ha a csapat önszerveződő és a tisztelet, illetve a bizalom nem a titulusból, vagy korból, hanem tényleg magából a tapasztalt dolgokból, vagy a sokat látásból származik - vagy ha fiatal valaki akkor a készségekből, egyedi skillekből és specializációból stb.

    Tehát ilyen példából eddig egy ilyen esetet olvastam tőletek, vagyis hogy két fejlesztő egymás mellett ülve debugol egy kódot, hogy megtaláljanak egy hibát, mert egyedül nem értik meg olyan hamar.

    Itt akkor most pontosítok (a fentiek alapján szükséges), azokra a seniorokra gondolok, akik egy csapaton belül vannak beosztottként és nem a cégnek nevezett csapatról beszélek, tehát két vezető fejlesztő továbbra is összedughatja a fejét.

    2.) Mondjuk az egyik ért a linalghoz, geometriai algoritmusokhoz, transzformációkhoz, kvaterniókhoz, de egyébként pure matek előképzettsége miatt és egyébként üzleti kódot ír Javában - a másik pedig ért az OpenCL-hez, Vulkanhoz és a GPU architektúrákhoz és átlátja az engine technológiai oldalát. Valószínűleg ha egy projekten dolgoznak, akkor el fogják egymástól x% sikerességgel tanulni legalább az alap dolgokat és közben beszélgetni fognak egymással - ha van felettük vezető fejleszt, ha nincs ez most etekintetben lényegtelen és csak másban fontos.

    3.) Mondjuk az egyik jól ért a JavaEE-hez összességében és ezen belül Websphere expert, aminek tudja a csínját-bínját, mert az évek alatt látta. A másik ember ahhoz ért, hogy közvetlenül hogyan kell szálakat kezelni és hogyan működnek a dinamikus plugin rendszerek. Kell csinálni egy rendszert websphere alatt, ami masszívan párhuzamos is és elosztott is (általános task végrehajtási engine). Általában websphere alatt nem kell annyira törődni a szálakkal, de ez esetben igen - aki a cégnél a memory modell minden csínját-bínját ismeri az lehet hogy attól tanul, aki a maven, a websphere és a hybernate dolgait ismeri és fordítva is kérdezősködik a másik szakember a szálas felé. Persze megtehetik, hogy csöndben ülnek és generálják a hibákat, amik nem egyszerre jönnek ki.

    Megj.: Egyébként ez egy plusz érv amellett, hogy a commithoz tartozó code review mindenki számára legyen nyitott: ne egy "vezető fejlesztő" nézegethesse csak (még ha főként ő is csinálja), hanem bárki kommentelgethessen rá.

    én az vitatom, hogy a szalag munkát úgy lehet gyorsabban elvégezni, ha ugyanarra a feladatra 2 embert állítok ugyanazon a poszton. Például 2 pénztárost raksz 1 pénztárhoz. Valóban gyorsabbak lehetnek, sőt biztos vagyok benne, hogy gyorsabban is szolgálnának ki. Mégis sokkal gyorsabb, ha külön dolgoznak.

    Ez projektfüggő dolog, de "szalagmunkát" szerintem sem gyorsít ha tele lesz nyomva a projekt seniorokkal. Vagyis kb. mint a példádban: gyorsítja, csak a cégnek nem ez az optimális ebben az esetben.

    Viszont elég sok nem-szalagmunka jellegű munka is van és pont az ilyen érdekesebb feladatok kivitelezését rongálja az, ha management szinten ezt a "egy kiemelt és 5-6 szalagmunkás" csapatot próbálják ráallokálni mondjuk egy olyan projektre is, ahol ilyen helyzetben az egy ember szimplán meg fog pusztulni - főleg ha egyébként ő a saját elképzelése szerint inkább effektívebb a tényleg király emberek effektív munkakörnyezetének, munkaütemének és teljesítményének a garantálására, illetve arra, hogy még éppen elég jó ahhoz, hogy legalább szót értsen velük technikailag és hidat képezzen mondjuk köztük és a top management között.

    Nálunk pl. komoly gondok fajultak abból, hogy másként értékelték a speciális projekteket - de már tanul a cég is.
    Mutasd a teljes hozzászólást!
  • Most akkor mi az állítás?

    Nyilván bele lehet kötni az én szavaimba is. Mint ahogy egy viszonylag jól dokumentált feladat esetében is lehet kérdezni, illetve pontosítást kérni. Ez viszont pont nem ilyen eset, csak simán trollkodsz. Én nyilván és szerintem érthetően a vezető fejlesztő beosztottjairól írok, a jómunkásemberekről. Van egy vezető fejlesztő, és van alatta mondjuk 3-4-5 fejlesztő. Ők egy csapat. Ilyen csapatból több is lehet egy cégnél. Egyáltalán nem kötelező minden csapatnak mindennel foglalkozni. Az egyik mondjuk a főkönyvet viszi, a másik a számlázót, a harmadik a raktárkezelő programot. Ha mondjuk lesz a számlázásból egy feladás a főkönyvbe, mert kitalálta a vezetőség, hogy kell ilyen, mert akkor lehet eladni a komplett rendszert, akkor összeül mondjuk a 2 vezető fejlesztő és megpróbálja kitalálni hogy egy számla lekönyveléséhez milyen adatokat kell előállítani és ezt milyen formában lenne jó átadni és mi lesz a válasz és az milyen formában jön. A csapattagoknak, a beosztottaknak van ebbe beleszólásuk? Szerintem nincs. Kikérhetik a beosztottak tanácsát, de ez a vezetők felada. Ők fogják kitalálni azt is hogy az egyes szolgáltatások mostantól kezdve egy közösen elérhető táblában kell lenniük, ha eddig nem voltak, hiszen majd főkönyvi számot is kell rendelni hozzájuk. Partnerek ugyanúgy. De az is elképzelhető hogy egy projekt kódot is fel kell/lehet rögzíteni egy számlához ezentúl, ami eddig szükségtelen volt. Ez az ő megbeszélésük, döntésük. Hol jön képbe a beosztott fejlesztő? Viszi magával mindenki az egyik/mindegyik beosztottját, mert hátha valamelyiküknek okosabb/jobb ötlete támad? Támadhat, ezt nem vitatom. Ha nem mennek el a megbeszélésre, akkor biztosan nem tudnak beleszólni, ezt sem vitatom. De ennek ellenére sem viszik el az egész csapatot, mert ez a 2 vezető dolga kitalálni. Mert akár az egész cég ott ülhetne a megbeszélésen, hátha valamelyik titkárnőnek, vagy akár az egyik könyvelőnek lenne jobb ötlete (nem elég ha a főkönyvelő lenne ott, mert akkor a könyvelő csapatból is mindenki legyen ott) .

    De te itt vagy és szerinted nem úgy van, elmondtunk egy rakás érvet, de nem érted.

    Te itt olyat tulajdonítasz nekem, amit én nem állítottam. Vagy legalábbis nem szándékosan. Ha félre érthető voltam, mint az előző példa is mutatja, akkor pontosíthatok, és pontosítok ha felvilágosítasz hogy hol értesz félre. Én már az elején kikötöttem valamit (idézem magam):

    Én olyan esetet szeretnék hallani, olvasni, amikor egy senior kolléga egy másik senior kollégával csapatban dolgozik, de nem azért mert valamelyikük épp azt kompenzálja, hogy nem végezte el a saját feladatát (pl: dokumentáció hiánya miatti bemutató)

    Itt akkor most pontosítok (a fentiek alapján szükséges), azokra a seniorokra gondolok, aki egy csapaton belül vannak beosztottként és nem a cégnek nevezett csapatról beszélek, tehát két vezető fejlesztő továbbra is összedughatja a fejét. Tehát ilyen példából eddig egy ilyen esetet olvastam tőletek, vagyis hogy két fejlesztő egymás mellett ülve debugol egy kódot, hogy megtaláljanak egy hibát, mert egyedül nem értik meg olyan hamar. Ehhez jön a következő: 

    Az egész tudomány- és technikatörténet áll most veled szemben a vitában. Te annak jelenségeit és tényeit tagadod.

    Nem, én az vitatom, hogy a szalag munkát úgy lehet gyorsabban elvégezni, ha ugyanarra a feladatra 2 embert állítok ugyanazon a poszton. Például 2 pénztárost raksz 1 pénztárhoz. Valóban gyorsabbak lehetnek, sőt biztos vagyok benne, hogy gyorsabban is szolgálnának ki. Mégis sokkal gyorsabb, ha külön dolgoznak. Tehát a fejlesztőkre átvetítve, lehet hogy gyorsabban találják meg ők is a hibát, de ha már 2 hibát kell keresni, vajon akkor is gyorsabbak ha együtt vannak? Mert akkor minden hibát úgy érdemes keresni és javítani hogy mindenki azon dolgozik és együtt. A hiba minőségétől teljesen függetlenül, hiszen az majd csak közben derül ki úgyis. Ezt akarjátok állítani? Vagy mi alapján dől el hogy a hibát 1 vagy 2 vagy még több fejlesztő (?) debugolja együtt?
    Mutasd a teljes hozzászólást!
  •  És ha előtte volt már egy másik kolléga aki dolgozott a kódnak ezen a részén, akkor esetleg el tudja mondani hogy az adott ponton anno mire gondolt a költő

    És hogyan indulsz el ebbe az irányba? Amikor megkapod a feladatod elkiáltod magad hogy "ki dolgozott ezen a fileon utolsóként"? Ekkor mindnki odafut hozzád és önként jelentkezik aki piszkálta azt a filet? Vagy megkeresed a verziókezelővel hogy ki dolgozott a fileokon? Ja igen, akkor már az is ott van mit csinált, mit módosított, sőt azt is meg tudod nézni a PM programotokban, hogy miért nyúlt hozzá és mi volt a szándéka. Ja, nem, mert lusta vagy és megkérdezed, úgy egyszerűbb, vagy nincs se verziókövető, se PM program?

    Vagy, ha van egy hiba amit esetleg egy másik módosítással lehet összefüggésbe amit az adott kolléga csinált két hónappal ezelőtt, akkor hasznos lehet beszélni vele hogy mit is csinált ők akkor és ott

    Ugyanúgy mint az új feladatnál.

    Tehát akkor jól írtam hogy a dokumentáció teljes hiánya miatt egymást okítjátok, sokkal több időt töltve ezzel, mint a dokumentálás elkészítésével töltenétek? Ez lehet az oka annak is hogy mindig más kapja az ugyanahhoz a programrészlethez kapcsolódó feladatot. Mert ha meg már/még nincs ott, mert ahogy próbáltad félremagyarázni, külföldről jött programról, vagy elment kollégáról van szó, akkor meg úgy sincs ott senki aki már/még látta volna.

    Ez így addig működik, amíg viszonylag kicsi a projekt - kb. az a nagyságrend amit amúgy egy ember is le tudna fejleszteni nem sokkal több idő alatt. Egy nagy projektet viszont már a vezető fejlesztő sem lát át - minél nagyobb a projekt, annál kevésbé.

    ne haragudj, de az én cerkám akkor is nagyobb...    

    És erre egyedül az egy szem vezető fejlesztőnek esélye sem lenne, annál is inkább mert neki közben funkcionális kérdésekben kell egyezkedni a felhasználóval.

    Nem, az a Support. Esetleg a Projekt Manager az ügyfél cég Projekt vezetőjével egyezkedhet. A vezető fejlesztőnek még csak ismernie sem kell egyetlen felhasználót/ügyfelet sem. Fura hogy hatalmas projektekről regéltek, és még ilyen egyszerű titulusok sincsenek szétválasztva nálatok, hanem mindenki mindent csinál. Hol a vezető fejlesztő munkáját a beosztotja végzi el, mert ő meg a PM munkáját végzi. A fejlesztő meg közben supoortol, hibákat és feladatokat egyeztet az ügyfelekkel ls címszavak alapján fejlesztetek. Hát, nem kicsi lehet a káosz, de legalább biztos izgalmas
    Mutasd a teljes hozzászólást!
  • nem arról van szó, hogy két tapasztalt azonos beosztású senior összedugja a fejét

    vö.:

    Én nem állítottam hogy a vezető fejlesztőknek nincs kommunikációjuk egymással.

    Most akkor mi az állítás?

    Az ő ideje se pótolható, ráadásul hogyan és hol fogja menedzselni ezt az időt? És szinte biztos hogy ugyanazon utakat végigjárja amit én már végigjártam.

    Guess what: Agile-ban igazából és első rendűen a csapat összteljesítménye számít, nem az, hogy xy egyéni teljesítménye egy adott időszakban mi volt. Épp ezért sokszor tökmindegy, hogy ketten dolgoztok valamin fele annyi ideig, majd másvalamin megint fele annyi ideig, vagy külön-külön mindketten egységnyi ideig. Amúgy miután az agile-ban minden transzparens, így az is látszik, ha valakinek nincs feladata, vagy nem csinált semmit. Mert sokáig nem lehet ám kamuzni a standupokon (napi "státusz" meetingek), 4+ ember szemébe kell mondanod élőben a kamut és hazudnod és mellébeszélned. Ez utóbbi csak a pszichopatáknak megy sokáig, de tartalmilag ők sem tudnak sokáig hazudni.

    Az több évtizedes tapasztalat és rogyásig tele van a net case study-kkal, könyvtárnyi irodalma van annak, hogy mi működik és hogyan jól ha van egy csapatod, mintha nincs. De te itt vagy és szerinted nem úgy van, elmondtunk egy rakás érvet, de nem érted.

    Tényleg egyetlen dologra fut ki a dolog: hogy létezik-e a világon az, hogy egy adott problémára a megoldást hamarabb megtalálja két v. több ember, egymással folyamatosan ötleteket cserélve és egymást katalizálva, vagy ilyen nem létezik, mindent egyénileg könnyebb fel- és kitalálni. Az egész tudomány- és technikatörténet áll most veled szemben a vitában. Te annak jelenségeit és tényeit tagadod.
    Mutasd a teljes hozzászólást!
  • Van a senior / vezető / akármilyen fejlesztő, aki a cégnél dolgozik és ért az OpenCl-hez és van az a másik öreg muksó, aki töviről hegyire átlátja a legacy szabályalapú motorból hogyan kell kiszedni az eseteket, illetve hogyan van az felépítve.

    Nem állítottam hogy nem lehet kérdezni a vezető fejlesztőnek a beosztottjától semmit se. De ügye itt még mindig nem arról van szó, hogy két tapasztalt azonos beosztású senior összedugja a fejét? És ügye még mindig kell egy írott dokumentáció/terv ahhoz hogy a feladat elkészülhessen? A senior hozzáértő beosztott fejlesztő nem fogja tudni kitalálni a megoldást valamire, aminek csak a címe van meg:

    WCF kommunikációs interfész kialakítása a szervíz és a főprogram között


    Mi történhet? A vezető fejlesztő leírja hogy milyen adatokat akar átküldeni és vissza, esetleg hogy ez mire kell. Ezután megkéri a beosztottját hogy egyáltalán megvalósítható-e, van-e valami észrevétele és tervezze meg, majd becsüljön időt. Ez tökéletesen megvalósítható írásban is. Semmiképp sem jó, hogy a vezető fejlesztő a hasára üt és mond valami időt, amit mi alapján mondana? A beosztott fejlesztőtől meg nem elvárható hogy kompetens legyen ebben, hagyni kell időt hogy átgondolja, nem? Tehát ebben az esetben az azonnali válasz, ajánlat időbecslése bizonytalan, felmerülhet egy későbbi kötbér 
     Hirtelen tegyük fel, hogy lehetőség nyílik valami, az eddigi volumenhez képest 10x akkor business-t elnyerni, de ehhez a két rendszer együttműködő elemeiből álló harmadik nagy rendszert kell felépíteni. 


    Én nem állítottam hogy a vezető fejlesztőknek nincs kommunikációjuk egymással. Hogyne lenne, együtt kell eldönteniük hogy a saját belső fejlesztéseik milyen irányban menjenek, vagy ami példát Te is felhoztál, az is lehet egy belső kényszer/ötlet következménye. Én még mindig a beosztott fejlesztők csapatmunkájáról vitázom. Hogy ők mitől végeznek 'csapatmunkát'.

    Sőt! Kapaszkodj meg, nagyon sokszor megesik, hogy nem a kollégádnak lesz rá azonnal valami ötlete, ha negyed órában előadod neki, hanem miközben megpróbálod átadni a problémát úgy, hogy ő is megértse, te magad találsz valami szoktatlant, valami új irányt - vagy magát a bugot.


    De ezen már túl vagyok (már a stackoverflowon, prog.hu-n, és még a FB-re is felraktam a kérdésem, több nyelven, google fordítóval lektorálva, mert hasznos a pontos fogalmazáshoz ). Vagy Ti gondolkodtok valamin 5 percet és ha úgy gondolod hogy nem megy, akkor máris rohantok a kollégákhoz? Nem küldtek még el a p..a? Az ő ideje se pótolható, ráadásul hogyan és hol fogja menedzselni ezt az időt? És szinte biztos hogy ugyanazon utakat végigjárja amit én már végigjártam.

    Ráadásul megpróbáltok behozni ide egy teljesen más területet. Ez egy normális cégnél (pl: SAP) szét van választva. Mire odajut a fejlesztőhöz a bug, addigra az már azonosítva és 100 helyen dokumentálva van és az időbeosztását ez nem változtatja meg, mert neki az ugyanolyan feladat mint egy új feladat. Ami gyorsban javítható az esetleg a beállításokban elkonfigurált valami.
    Mutasd a teljes hozzászólást!
  • Én azzal a feltételezéssel éltem, hogy mindenképp megpróbálom, hogy legalább nagyságrendileg be tudjam lőni hogy mennyi ideig fog tartani. Ha hasamra ütök, akkor biztosan tévedni fogok. Ki fogja tudni ezt jobban belőni, mint a vezető fejlesztő, akinek nyilván meg van a kellő tapasztalata, remélhetőleg ismeri a cég kódját, tudja mit hol kell változtatni és még így is nyilván megpróbálja lebontani kisebb részekre. Már csak azért is, mert lehet hogy meg tudja osztani a feladatokat több fejlesztő között.

    Ez így addig működik, amíg viszonylag kicsi a projekt - kb. az a nagyságrend amit amúgy egy ember is le tudna fejleszteni nem sokkal több idő alatt. Egy nagy projektet viszont már a vezető fejlesztő sem lát át - minél nagyobb a projekt, annál kevésbé. Egyre inkább az lesz, hogy a vezető fejlesztő csak a nagy képet látja, az egyes részeket pedig az adott résszel már többet foglalkozott seniorok. A feladat szétszedéséhez és a szükséges idők megtippeléséhez viszont már alaposan meg kell nézni a kódnak az adott részét. És erre egyedül az egy szem vezető fejlesztőnek esélye sem lenne, annál is inkább mert neki közben funkcionális kérdésekben kell egyezkedni a felhasználóval.
    Mutasd a teljes hozzászólást!
  • Ezt nagyjából úgy képzeld el, hogy van egy rohadtul nagy kódbázis, és egy rakás ember, akik ezen elvégeznek különféle feladatokat. Ha te megkapsz egy feladatot, akkor azzal kezded, hogy megérted hogy mit csinál a kódnak az a része amit módosítanod kell. És ha előtte volt már egy másik kolléga aki dolgozott a kódnak ezen a részén, akkor esetleg el tudja mondani hogy az adott ponton anno mire gondolt a költő, mert ő már előzőleg egy hetet eltöltött azzal hogy kitalálta. Vagy, ha van egy hiba amit esetleg egy másik módosítással lehet összefüggésbe amit az adott kolléga csinált két hónappal ezelőtt, akkor hasznos lehet beszélni vele hogy mit is csinált ők akkor és ott. Aztán az sem rossz, ha az új fejlesztést végző csapat, és az aktuális verzióban talált hibákat javító társaság beszélget időnként egymással.
    Mutasd a teljes hozzászólást!
  • A feladatok kiosztása azt jelenti, hogy a nekem kiosztott feladatot nekem kell elvégezni. Ha másokkal függőség van, akkor azt is el lehet intézni egy "kész vagy e xy résszel?" "igen/nem" chat sorral. És hozzá természetesen a doksit is megírja az illető.

    Ez szerintem a legkárosabb dolog. Hányszor és hányszor allokálnak mellé embereket míg van aki séróból tudná, csak a rendszer nem teszi lehetővé a gyors haladást?!

    Az, hogy mennyire jó és hatékony a munkakultúra abban is jól mérhető, hogy expert-to-task, vagy team-to-task allokációs módszer van-e működésben. Sok helyen pl. papíron SCRUM-nak, meg KANBAN-nak nevezik a dolgokat, de expert-to-task allokációval dolgozik az egész cég úgy, hogy nincs ember, aki rendesen egy adott projekten van 50+ százalékban (szóval van 5 projekted 20-10-30-15-15% mondjuk). Hát ehhez az "effektivitáshoz" csak "gratulálni" szoktam tudni általában.

    Viszont az ETT allokáció nem csak a multitask hatékonytalanság miatt káros, hanem főként amiatt, mert pazarol: ha van egy feladat, amihez nagyon értesz, tutira tudod, hobbiként is azt űzöd, de nem hozzád, hanem Kispistihez, vagy Nagypetihez van allokálva, akkor nem kezdhetsz neki. Az egy másik probléma, hogy miért így van allokálva, de megesik? Meg. Aztán meg ennek a másik fele az, ha alulterveznek és rászoksz arra, hogy akkor dolgozz csak, ha valaki odajön és feladatot osztogat neked. Az is probléma, ha jön a PM és predesztinálja a dolgokat, mert bár "megbeszélitek", de neki van előre elképzelése - vagy esetleg ami még rosszabb szét van bontva fázisokra úgy, hogy aki "tervezi" az utána részt se vesz benne. Ezt akkor se szeretem, ha én csinálom, mert így még visszacsatolás se mindig van...

    Ehelyett sokkal normálisabb, hogy van egy team - Lehet hogy több team-ben is benne vagy és multitask-olsz, de legalább van team - és ez a team kap egy folyamatosan változó feladathalmazt. Ott a TODO, ha valamit meg tudsz csinálni, akkor nekiállsz. Ha nem tudod megcsinálni, akkor nem azt csinálod. Ha csak lusta emberek vannak a csapatban, vagy alulképzett a csapat, akkor ez hamar kiderül. Ha 1-2 ember lógni szeretne, akkor a csapat elemi érdeke, hogy ezeket piszkálja - nem kell naponta a PM-nek a nyakára járni, hanem akikkel együtt ül, azokkal sorsközösségben van. Nyilván lehetséges, hogy több is kitaposható az emberből egyébként, de azért hosszú távon nem akarsz olyan csapatban lenni, ahol minden folyton költséges és hosszú, illetve középtávon szépen kiderül minden aminek ki kell derülni.

    Azt a fajta individuális munkavégzést, ahol mindenki kap valami feladatot - tök mindegy mi az - és azt végzi el, de egyébként más nem érdekli, sokkal alacsonyabb rendűnek tartom annál, ahol valódi csapatszellem is ki tud alakulni. Mindegy, hogy ez online, vagy offline alakul ki, de jó ha kialakul. Vannak dolgok, amik offline könnyebbek, de sok fajta munkát online-only is lehet értelmesen és csapatban végezni.

    Sőt! Ahol éppen egészséges a hangulat, ott egyébként nagyobb esély van arra is, hogy a "megbízható, de magányos-farkas" jellegű arcokat a csapat ne is akarja piszkálni. Mármint biztos lesz néha 1-2 szó és közeledési kísérlet, de jellemzően nem a jól működő és önszervezett csapat fogja rádtukmálni, hogy akkor is menj el csapatépítésre, ha egyébként te kertet akarsz otthon kapálni, vagy pihenni szeretnél és egy filmet megnézni az ágyból.
    Mutasd a teljes hozzászólást!
  • És akkor odamegy a másikhoz, aki azonnal átlátja és máris mondja a tuti frankót? Tehát belemásztam, rajta vagyok több órája a témán, nem egy egyszerű problémáról van szó, amit a google simán kidob (valószínűleg a fejlesztők krémjétől a prog.hu-n sem kaptam rá választ , a stackowerflowon is hallgat mindenki mint a sír), hanem valami nagyon összetettről és a kollégámnak azonnal lesz rá valami ötlete, miután én negyed órában előadom neki?

    Nem feltétlenül azonnal, de megesik. Sőt! Kapaszkodj meg, nagyon sokszor megesik, hogy nem a kollégádnak lesz rá azonnal valami ötlete, ha negyed órában előadod neki, hanem miközben megpróbálod átadni a problémát úgy, hogy ő is megértse, te magad találsz valami szoktatlant, valami új irányt - vagy magát a bugot.

    Ez pl. annyira gyakran előfordul, hogy amolyan Murphy-törvénynek is veszik páran, hogy "mire elmondom, pont rájövök" - miközben csak azért történik meg ez a heuréka-effektus talán, mert hirtelen más mentális állapotban, nem begyöpösödve a problémára meredve, hanem azt átadandó információnak tekinted éppen. Ez megtörténhet, ha elmész sétálni, de sokkal valószínűbb, hogy hamarabb kizökkensz, ha átadni akarod az infót, mintha csak a helyedet változtatod meg. Régi trükk már ez és mindenki csinálja, csak nem veszi észre miért működik

    Egyébként meg próbálj meg egy olyan többszálú legacy rendszert debug-olni, amiben időnként starvation van, de soha nem jön elő a saját környezetedben. Hidd el: sokkal jobb ketten olvasni azt a kódot sorról sorra megbeszélve - sőt ilyenkor felkommentezve is - hogy kiderüljön hol lehetnek a rejtett bugtengerek. Anno volt olyan kód, amit ketten nézve, olyan kb. 5sor / sec sebességgel tudtunk csak értelmezni, mert annyira hulladék volt az egész és az volt a stratégia, hogy a folyamatot végignézzük minden érintettségével - kilőve azt ahol hülyeségek vannak. Előtte már próbálták ezt sokszor megoldani és csak így lehetett...
    Mutasd a teljes hozzászólást!
  • Pontosan mit fog megtervezni 2 senior fejlesztő, amit 1 senior fejlesztő nem tud, de a vezető fejlesztő rá bízta ennek a tervezését?

    Egyszerű kérdéseket teszel fel: Legyen mondjuk a születő megoldás egy kémiai szimuláció, ami valami legacy szabályalapú adatbázismotort használ és OpenCL-ben számolgat. Van a senior / vezető / akármilyen fejlesztő, aki a cégnél dolgozik és ért az OpenCl-hez és van az a másik öreg muksó, aki töviről hegyire átlátja a legacy szabályalapú motorból hogyan kell kiszedni az eseteket, illetve hogyan van az felépítve.

    Az állítás az, hogy jobban járunk, ha ez a két ember az elképzelésed ellenére mégis együtt dolgozik. Sőt: ha ők "csak" senior emberek, de értenek a két releváns szakterülethez, akkor nem kell egy harmadik "lead developer" aki csak azért áll ott, hogy megmondja a frankót - vagyis az hogy kell-e, az már emberi és nem szakmai kérdés s esete válogatja mondjuk atekintetben hogyan jönnek ki az emberek egymással, milyen a dinamika.

    "Sem akkor, amikor meg kell állapodni két komplex komponens közötti interfészben."-Most akkor ebben a két fejlesztő fog dönteni és nem a vezető fejlesztő? Miért is hagyjuk ki őt ebből?

    Másik példa: a cégen belül mondjuk két teljesen külön üzletág a saját rendszereit fejlesztgeti, melyek még alaptechnológiájukat tekintve is mások. Mind a ketten mondjuk foglalkoznak telekommunikációval és történelmi okokból más szegmenseit fedik le területnek. Hirtelen tegyük fel, hogy lehetőség nyílik valami, az eddigi volumenhez képest 10x akkor business-t elnyerni, de ehhez a két rendszer együttműködő elemeiből álló harmadik nagy rendszert kell felépíteni. Más üzletágak is vannak, más komponensek is vannak. Felmerül egyáltalán, hogy itt most kit akarsz "vezető fejlesztőnek" nevezni? Aki csak az egyiket, vagy csak a másikat ismeri? Esetleg valami kinevezett céges architektet? Valószínű, hogy pontosan azok fognak együtt dolgozni és együtt tervezni, akik - titulustól, kortól, mindentől függetlenül - a leginkább ismerik azt a két dolgot, amit mostantól össze kell mergelni...
    Mutasd a teljes hozzászólást!
  • Ami nálad a lényeg, az az, hogy szerinted nem létezik olyan, hogy csapatmunka. Csak olyan van, hogy mindenki egyedül dolgozik, maximum feladatokat delegál lefelé további egyedül dolgozóknak. Mindent a szoftvervilágban úgy terveznek, implementálnak, analizálnak, hogy mindenki mindent egyedül csinál és egyszer sem kell leülni és megbeszélni dolgokat, hiszen mindig van a megbeszélő fölött valaki, aki a megbeszélni valót már eleve tudja. Tehát a CTO mindent tud, ha kell, az utolsó csavarig. A többi hosszú okfejtésben, meg nem nagyon látszik a hozzáadott érték.

    "Miért is hagyjuk ki őt ebből? De akkor a vezető fejlesztő egyáltalán mit csinál?"

    Ki mondta, hogy kihagyjuk? Az a te működési elved, hogy nincs semmi, amit közösen lehetne/kellene csinálni. Te hagyod ki.

    "Hasra ütésszerűen ráírja az órát mindenre?"

    Bonyolult esetben szerinted látja a jövőt? Vagy valószínűbb, hogy van némi tippelés is a dologban?

    "Pontosan mit fog megtervezni 2 senior fejlesztő, amit 1 senior fejlesztő nem tud, de a vezető fejlesztő rá bízta ennek a tervezését? Nekem már eleve a szó sem tetszik, hogy a fejlesztő tervez."

    Most már értem. A fejedben él egy konkrét fajta szervezeti struktúra és azt gondolod, hogy csak az létezik (mindenhol).

    "Tehát belemásztam, rajta vagyok több órája a témán, nem egy egyszerű problémáról van szó, amit a google simán kidob"

    Nem, többen másztatok bele. Nem túl valószínű, hogy egy multinál a kódbázisra bármilyen google találatot kapnál. Pláne nem a konkrét bugokra abban a kódban, amit a cég ír. Vagy esetleg van egy rakás algoritmus, amit a cég maga talált föl, kevés esélyed van arra, hogy a google-ben találsz rá választ, ha esetleg közvetve igen, akkor is 5 cikket kellene elolvasnod és megértened, ahelyett, hogy megkérdeznéd a szomszéd szobában ülőt, hogy magyarázza el.

    "valószínűleg a fejlesztők krémjétől a prog.hu-n sem kaptam rá választ , a stackowerflowon is hallgat mindenki mint a sír"

    Egyértelműen látszik, hogy nem igazán érted, hogy nagy projectek hogy működnek. Vagy legalább is az látszik, hogy te a projectek adott fajtáit láttad eddig és elképzelni nem tudod, hogy a világon van más is, ami abban az esetben nem is működhetne úgy, ahogy a te esetedben működik.

    "hanem valami nagyon összetettről és a kollégámnak azonnal lesz rá valami ötlete, miután én negyed órában előadom neki?"

    Ez napi szinten történik meg cégek százaiban. Csak ma ketten jöttek hozzám kérdéssel és kaptak is választ. De én sem láttam előre (meg senki más), hogy a probléma jelentkezni fog, tehát sem a designba nem kerülhetett volna bele, sem előre tervezni nem lehetett ezt a kérdést és a választ.

    "Mert amúgy neki semmi dolga, mert ráér."

    De, van dolga, de mivel csapat vagytok, nem tilos egymást segíteni és együtt dolgozni. Ettől csapat a csapat. Csak te soha, vagy ritkán dolgoztál csapatban, vagy ha igen, akkor sem jó csapatban, így nincs tapasztalatod ebben.
    Mutasd a teljes hozzászólást!
  • Sem akkor, amikor meg kell állapodni két komplex komponens közötti interfészben.

    Most akkor ebben a két fejlesztő fog dönteni és nem a vezető fejlesztő? Miért is hagyjuk ki őt ebből? De akkor a vezető fejlesztő egyáltalán mit csinál? Nem tervez (lásd következő felvetésed), nem dönt, nem dokumentál. Hasra ütésszerűen ráírja az órát mindenre? Legalább tartja a hátát nekünk fejlesztőknek a vezetőség felé? Vagy úgy kommunikálja, hogy ilyen kutyaütő bandával nem lehet dolgozni?

     sem akkor, amikor meg kell tervezni valami bonyolult dolgot

    Pontosan mit fog megtervezni 2 senior fejlesztő, amit 1 senior fejlesztő nem tud, de a vezető fejlesztő rá bízta ennek a tervezését? Nekem már eleve a szó sem tetszik, hogy a fejlesztő tervez. De legalább hozzunk fel egy olyan példát és ne csak handabandázzunk, hogy elvileg hol lehet ilyen.

    mikor valami, addig abban a formában nem létező algoritmust kell kitalálni és mondjuk elakad benne az, aki gondolkodik rajta

    És akkor odamegy a másikhoz, aki azonnal átlátja és máris mondja a tuti frankót? Tehát belemásztam, rajta vagyok több órája a témán, nem egy egyszerű problémáról van szó, amit a google simán kidob (valószínűleg a fejlesztők krémjétől a prog.hu-n sem kaptam rá választ , a stackowerflowon is hallgat mindenki mint a sír), hanem valami nagyon összetettről és a kollégámnak azonnal lesz rá valami ötlete, miután én negyed órában előadom neki? Mert amúgy neki semmi dolga, mert ráér. Ezt úgy tudom elképzelni hogy a vezető fejlesztő a másik kollégát is ráuszítja a problémára (mert ő sem látott még ilyet), de ez innentől kezdve nem tervezhető, és a kimenetele is kétséges. Viszont szerintem erre is van megfelelő személy/titulus: architect?
    Mutasd a teljes hozzászólást!
  • De olyan pl. létezik, hogy egész Kínából online begyűjtött napi több tera adatot 5%-kal gyorsabban kellene kiszámolni, mert azt kéri az ügyfél. Van jó pár tucat egyedi fejlesztésű komponensed egy nagy klaszteren, mondjuk 80 ember munkája. Becsüld akkor meg, hogy hol milyen taszkot kell csinálni hozzá.

    Tehát akkor ezekre rá se nézel, csak kosztod, hogy:

    (Új Task)
    Kínából online begyűjtött napi több tera adatot 5%-kal gyorsabban kell kiszámolni - 12 óra - M.Seal  

    Ha nem tudja megcsinálni, majd feltarthatja a kollégáját, mert ott ül vele szemben és neki nyilván sokkal egyszerűbb és jól dokumentált feladatot osztottál ki, ráér. Ja, nem.

    Ugyanebben a szcenárióban jön a ticket, hogy az egyik grafikonon 12 helyett 17 lenne a helyes válasz az egyik ponton (mert egy másik táblázatból ez jön ki), plusz ketyeg is a support szerződésben vállalt response time. Becsüld meg, hogy mennyi idő kijavítani. 

    Hibakeresésre elég abszurdnak hangzik az időbecslés. De a task/ticket managerben fel szokták vinni, ez a normális ügymenet és kiosztjuk M.Sealnek ezt is, hátha be tudja fejezni mindkettőt határidőre. De szerinted mikor könnyebb a feladata a hiba megtalálásában, ha ahhoz a taskhoz viszed fel, ahol a grafikont készítettétek el (esetleg összekötve vagy belinkelve a táblázat elkészítésének taskjával) és azok össze vannak kötve a verziókezelő szoftverrel, vagy ha mint új task viszed fel, aztán boldoguljon (hiába ne is keresse, mert nincs hozzá task)? Vagy ha segítséget nyújtasz neki hogy hogyan találhatja meg a hibát, melyik menüpont alatt, vagy csak simán kirakod a képét (print screen) a hibának, még a menüpontokat is leszerkesztve a képről. Vagy hogy hogyan tudna a hiba szempontjából értékelhető adatbázishoz jutni, vagy húzza ki a verziókezelőből a sémát és töltse fel a tesztadatok (vannak ilyenek egyáltalán?) mellett valami olyannal, hogy előjöjjön a hiba? Egyáltalán biztos hogy hiba, vagy csak a két adat nem ugyanazt mutatja és nem is kéne neki? Ilyenkor, ilyen hozzáállással szokott az lenni, hogy a végén elrontjuk ami jó.
    Mutasd a teljes hozzászólást!
  • A példa valós egy nagy cégnél.

    Akárhány ilyen példát hozol máshonnan, ahol épp hülyeséget csinálnak, az nem fogja azt igazolni, hogy nem létezik olyan munka, ahol legalább 2 senior együttes munkája kell.

    A feladatok kiosztása azt jelenti, hogy a nekem kiosztott feladatot nekem kell elvégezni. Ha másokkal függőség van, akkor azt is el lehet intézni egy "kész vagy e xy résszel?" "igen/nem" chat sorral.

    Te most egy olyan esetre hivatkozol, ahol ezt meg lehet csinálni, körkörösen érvelsz. Van egy rakás eset, amikor együtt kell kitalálni valamit, mert nincs olyan, hogy kész vagy-e, mert nincs még mivel kész lenni.

    A Scrum szerint nincs "út közben" semmi változtatás, amit a sprintre vonatkozóan, illetve adott napra megbeszéltünk, hogy az lesz, akkor az lesz és kész.

    Bármilyen task, ha csak nem az utolsó betűig mondja meg, hogy mit kell beírni a kódban, tartalmazhat rejtett elemeket és részleteket, amik útközben derülnek ki, az a megbeszélteken belüli, de mégis közös munkát igénylő és változást jelentő események lehetnek. Attól te még a sprint goalt teljesítheted (vagy ha nem tudod teljesíteni az új infó alapján, akkor szólsz a PO-nak, aki akár a sprintet is terminálhatja, ha már nagyon a scrumon rugózunk).
    Mutasd a teljes hozzászólást!
  • Nem, a példa hülyeség

    A példa valós egy nagy cégnél.

    Attól, hogy taskokra vannak osztva feladatok, nem jelenti azt, hogy nem kell másokkal szorosan együttműködni. 

    A feladatok kiosztása azt jelenti, hogy a nekem kiosztott feladatot nekem kell elvégezni. Ha másokkal függőség van, akkor azt is el lehet intézni egy "kész vagy e xy résszel?" "igen/nem" chat sorral. És hozzá természetesen a doksit is megírja az illető.

    Meg azt sem, hogy út közben nem keletkeznek új taszkok az alapján, ami kiderül, akár egy közös brainstorm közben.

    A Scrum szerint nincs "út közben" semmi változtatás, amit a sprintre vonatkozóan, illetve adott napra megbeszéltünk, hogy az lesz, akkor az lesz és kész.
    Mutasd a teljes hozzászólást!
  • Szóval szerinted az kifizetődő, ha egy nagy csarnokban nekiálltok és közösen elkezdtek fejleszteni? Erre szokták mondani, hogy kilenc nő se szül meg egy hónap alatt egy gyereket.

    Ha hülyeséget akartál írni, akkor sikerült. Meg ha szándékosan nem akarod érteni a problémát, az is sikerült. Attól, hogy taskokra vannak osztva feladatok, nem jelenti azt, hogy nem kell másokkal szorosan együttműködni. Meg azt sem, hogy út közben nem keletkeznek új taszkok az alapján, ami kiderül, akár egy közös brainstorm közben.
    Mutasd a teljes hozzászólást!
  • Vagy szerinted az teljesen rendben van, hogy ez szerepel a taskmanagerben:

    Nem, a példa hülyeség. De olyan pl. létezik, hogy egész Kínából online begyűjtött napi több tera adatot 5%-kal gyorsabban kellene kiszámolni, mert azt kéri az ügyfél. Van jó pár tucat egyedi fejlesztésű komponensed egy nagy klaszteren, mondjuk 80 ember munkája. Becsüld akkor meg, hogy hol milyen taszkot kell csinálni hozzá.

    Ugyanebben a szcenárióban jön a ticket, hogy az egyik grafikonon 12 helyett 17 lenne a helyes válasz az egyik ponton (mert egy másik táblázatból ez jön ki), plusz ketyeg is a support szerződésben vállalt response time. Becsüld meg, hogy mennyi idő kijavítani. Meg persze ha 5 komponenst kell átírni, akkor először írtok 60 oldal dokumentációt külön-külön otthon előtte, hogy hogyan lehetne nekiállni megtalálni a hibát, majd kiosztjátok, megcsináljátok, végül szintén ledokumentáljátok pár hét alatt, hogy épp mit bugfixeltetek, ahelyett, hogy először két-három ember helyben, egymás mellett ülve megtalálná a hibát, aztán a komponenseket párprogramozás keretében kijavítják és a lényeget lejegyzik három mondatban. Szerinted ez működne doksikkal, meg skype-pal. Mondd ki.
    Mutasd a teljes hozzászólást!
  • Szóval szerinted az kifizetődő, ha egy nagy csarnokban nekiálltok és közösen elkezdtek fejleszteni? Erre szokták mondani, hogy kilenc nő se szül meg egy hónap alatt egy gyereket. Nem véletlenül vannak taskokra szeparálva a project fejlesztési részei és ezeket önállóan végzik el az emberek (jobb helyeken persze).

    Milyen dokumentáció? Arról, amiről azt sem tudod, hogy működik-e és hogyan?

    Ha semmiről se tudok semmit, akkor bármi kifizetődő és semmi sem.
    Mutasd a teljes hozzászólást!
  • Mert itt nem az elvi része az érdekes, hanem hogy mi a kifizetődő. Mert hát villával is meg tudsz enni egy levest mert valamennyi leves mindig tapad a villára, csak épp nem villával hatékony. Milyen dokumentáció? Arról, amiről azt sem tudod, hogy működik-e és hogyan?
    Mutasd a teljes hozzászólást!
  • Te azzal a feltételezéssel élsz itt, hogy a szoftvervilágban minden feladatot előre le lehet bontani biztosan megcsinálható lépésekre. Hát nem. Van, amiről akkor derül csak ki, hogy nem működik, amikor megcsinálod és nincs ember, aki előre meg tudta volna mondani, hogy nem működik.

    Ezzel a feltételezéssel nem éltem. Én azzal a feltételezéssel éltem, hogy mindenképp megpróbálom, hogy legalább nagyságrendileg be tudjam lőni hogy mennyi ideig fog tartani. Ha hasamra ütök, akkor biztosan tévedni fogok. Ki fogja tudni ezt jobban belőni, mint a vezető fejlesztő, akinek nyilván meg van a kellő tapasztalata, remélhetőleg ismeri a cég kódját, tudja mit hol kell változtatni és még így is nyilván megpróbálja lebontani kisebb részekre. Már csak azért is, mert lehet hogy meg tudja osztani a feladatokat több fejlesztő között. Vagy szerinted az teljesen rendben van, hogy ez szerepel a taskmanagerben:

    WCF kommunikációs interfész kialakítása a szervíz és a főprogram között


    És mellé van írva hogy 12 óra, meg hogy M.Seal? És ha kész, akkor ez megy a gitbe, mint hivatkozás is, ügye? Maga a kód a dokumentáció, nem? Elvileg hiba sem lehet benne, ha van WCF interface közöttük, hiszen ez a feladat mitől lehetne hibás? Csak nehogy utólag derüljön ki, hogy valójában nem is létezik "a szervíz", mert akkor szegény M.Seal még azt is el kell készítse.
    Mutasd a teljes hozzászólást!
  • a scrum nem mond semmit arról, hogy a fejlesztést mennyire választod le a tesztelésről

    "A csapattagok különféle képességei lehetővé teszik hogy a feladatot közösen megoldják (fejlesztő, dizájner, tesztelő, ...)"
    E szerint a "fejlesztő" és "tesztelő" külön képesség és azt külön csapattagok végzik. forrás

    a csapatoknak nem kell együtt dolgozniuk

    Amennyiben egy projecten dolgoznak persze, hogy együtt dolgoznak, de ez nem azt jelenti, hogy fizikailag egy légtérben kell lenniük és azt sem, hogy önállóan nem tudnak dolgozni a taskok és dokumentációk alapján.
    Mutasd a teljes hozzászólást!
  • Még mindig nem hallottam egy olyan esetet sem tőletek, ahol egy senior kolléga segíthet egy másik senioron, de nem azért hogy a másik munkáját elvégezze helyette.

    Példa nélkül nézzük logikailag ezt. Nyilván arra akarod kifuttatni, hogy nincs is ilyen, más különben nem kérnéd rá a példát. Viszont ha nincs ilyen, akkor az ekvivalens azzal az állítással, hogy sehol, soha nincs olyan probléma, amihez legalább két senior kolléga együttműködése kell. Sem akkor, amikor meg kell állapodni két komplex komponens közötti interfészben, sem akkor, amikor meg kell tervezni valami bonyolult dolgot, sem akkor, amikor valami, addig abban a formában nem létező algoritmust kell kitalálni és mondjuk elakad benne az, aki gondolkodik rajta, stb. Ezt szeretnéd állítani?
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd