Új hozzászólás Aktív témák
-
bambano
titán
"De mondjuk nem vagyok benne biztos, hogy ilyen sokan használnák, ha annyira rossz lenne.": amióta azok a vasak kimentek a divatból, amit a gazdájuk nem bír felemelni, azóta nem számít, hogy a szoftver milyen minőség.
egyébként ez egy vicc, hogy mindenre vannak minőségi paraméterek, amcsiban szétperlik a gyártót, ha minimálisan is eltér a doksitól, kivéve szoftver. a szoftver mehet as-is. bill egy zseni.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
Pikari
addikt
Én az agilitást - eredeti jelentésében - nagyon fontosnak tartom. Egy terméket legalább annyira nehéz eladni, mint elkészíteni. Ahol az agilitás kifejezést kifogásnak, vagy marketing lózungnak használják, ott persze már eleve bajok vannak.
A Dunning−Kruger-hatás az a pszichológiai jelenség, amikor korlátozott tudású, kompetenciájú vagy képességű emberek rendkívül hozzáértőnek tartják magukat valamiben, amiben nyilvánvalóan nem azok.
-
Jobb helyeken az Agile annyit jelent, hogy nem szarakodunk, hanem csináljuk. Ez nem azt jelenti, hogy nem kellene jól megtervezni, vagy lefejleszteni, csak az aktatologatást kell kihagyni.
Meg annak a felismerése, hogy a megrendelő úgyis 3 percenként mást fog akarni
Amúgy senki nem mondta, hogy ha rosszul csinálod, akkor is jó lesz
A fent említett cégnél megcsinálták ezt a supportra. Eredménye az lett, hogy a managerek átmentették magukat, bürokrácia maradt, de legalább össze lett kutyulva minden. Ez van, ha rosszul csinálják."amcsiban szétperlik a gyártót, ha minimálisan is eltér a doksitól, kivéve szoftver. a szoftver mehet as-is."
Na ez már igaz.
Mondjuk ott is lehetne, hogy megkövetelni a specifikáció betartását[ Szerkesztve ]
Mutogatni való hater díszpinty
-
bambano
titán
más helyeken meg az agilitás azt jelenti, hogy mond valamit a megrendelő, lefejlesztik, nem jó, dobják, kezdik elölről. ehhez kell ez a rilízelj gyakran, gyorsan, sokat történet, ami szülte az összes szemetet, ami mostanában az architektek mániája lett.
rendes helyen meg úgy megy a szoftverfejlesztés, agilitást nagy ívben kerülve, hogy üzleti elemző megnézi a folyamatot, a folyamaton történő fejlesztési igényt, és ezt iterálva elkészít egy rendes, részletes, hitelt érdemlő, elfogadott üzleti specifikációt. utána indul a program tervezés és programozás. na ezt akarja mindenki megspórolni, erre találták ki az agilis módszertanokat.
mifelénk nem használnak külön kifejezést arra, hogy valaki elvégzi a munkáját.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
buherton
őstag
A CICD témakör messzire vezet. Annyival szeretném itt lezárni, hogy egy SW termékfejlesztése elképesztően komplex dolog. Olyanokra kell gondolni, hogy:
- fordítható-e a kód
- statikus kód analízis
- dinamikus kód analízis (nem garbage collected language)
- 3PP check
- unit testing
- fuzzy testing
- kód vulnerability check
- formai követelmény ellenőrzés
- smoke/regression/e2e/integration/component testing
- vulnerability test
- stb.Ezeket pedig szerencsésebb automatikusan futtatni, mint sem kézihabverőzni. Szóval, igen jobb helyeken CICD nélkül nem lehet SW-t fejleszteni.
tely, baly, fojó, mennyél, mingyárt, telyföl, tolyás, malyd, kapú, egyenlőre, ejsd, jáccani, ahoz, fúj, hüje, muszály, alat, álok, lasan, fojtatás, ál, fontós, költsön, eggyüt, lyob (jobb?), mek, mongyak, milyért - !!! Tanúlyunk már meghejjessen irni... !!!
-
Amit a rendes helyről írsz, az a normálisan előadott agilis fejlesztés is, csak nincs közben 20 tonnányi papírmunka, meg több órás meetingek a semmiről, amitől 5x annyi ideig tart az egész
Illetve alfa, bétaverziók vannak a normál fejlesztési módszertanokban is.
" utána indul a program tervezés és programozás."
Meg az idióta igények a megrendelő részéről.[ Szerkesztve ]
Mutogatni való hater díszpinty
-
dabadab
titán
mert cicd nélkül nem lehet élni...
Én azt értem, hogy soha életedben nem volt semmi közöd a szoftverfejlesztéshez, nem dolgoztál komoly projekten se waterfall, se agile, se semmilyen más metodológiával, csak azt nem, hogy ezt miért kell folyamatosan világgá kürtölnöd.
[ Szerkesztve ]
DRM is theft
-
buherton
őstag
Miért fáj, hogy ekkora egy játék? A TB-okat nagyon olcsón adják már ráadásul, így több marad a zsebedben, mintha mondjuk kétszer annyiba kerülne a játék, mert hogy optimalizálni kell ezerrel.
#99 hcl: igen, attól még, hogy külföldi nem lesz rögtön Messiás, ahogy a magyar menedzser sem jelenti azt, hogy nem jó benne. Nekem most magyar menedzserem van és egy szinttel fentebb is magyar van. Értenek hozzá és jók benne.
#100 bambano és a többi hasonló tartalmú hsz-re: azt tapasztalom - legalábbis itthon -, hogy van egy fajta ellenszenv az Agile-al szemben és olyanokat is belelátnak, ami egyébként nem is az Agile része.
Az Agile egy keretet ad a SW fejlesztésnek. Definiál szerepköröket (Product Owner, XFT, stb.), jól definiálja azt, hogyan folyik az információ (Backlog Refinement, Sprint Planning, stb) és leírja az elvárásokat is (DoD, DoR, stb.). Ha mindenki csinálja a dolgát, akkor az ügyfél azt kapja, amit kért és akkorra amikor a cég ígérte.
A jelenlegi környezetben ez a legjobb módszer a SW fejlesztéshez. Vannak hibái, de jelenleg nincs jobb megoldás, majd biztosan lesz.
Az egyszerűen hazugság, hogy nem kell tervezni.
Az Agile - és egyébként minden elképzelésnek - természetszerű gyengesége, hogy emberek működtetik. Hogyan várjuk el az Agile-tól, hogy jól működjön, amikor tipikus mezei fejlesztőből lesz Scrum Master?! A menedzsment sem hajlandó elfogadni, hogy user story-ban kellene gondolkozni, no meg story pointban?! Nem csodálom, hogy sokaknak nincs jó tapasztalata az Agile-al, egyszerűen nincs elég jó szakember Mo-n. Azon sem lepődnék meg, hogy menedzsment sem veszi komolyan az Agile-t, mert hogy máshol sem voltak jó tapasztalataik ezzel, mert hogy szakbarbárok működtették az Agile-t.
Itt egy érdekes beszámoló a fentebbiekről: [link]
ehhez kell ez a rilízelj gyakran, gyorsan, sokat történet,
És ez nagyon jó dolog. Ez jó a fejlesztő cégnek és a vevőnek is. Btw, ez egy jó CICD nélkül nem megy. Emlékszem egy másik multinál óriási erőfeszítés kellett ahhoz, hogy a féléves releseak helyett negyedéve legyen, de úgy hogy 3 hetente már lehessen adni a customernek valamit tesztelésre. De nagyon jó, hogy meglépték, mert a SW quality sokat javult. Nyilván nemcsak azért, mert jóval gyakoribb lett a SW átadás, hanem mert több féle automata teszteket is bevezettek.
rendes helyen meg úgy megy a szoftverfejlesztés, agilitást nagy ívben kerülve, hogy üzleti elemző megnézi a folyamatot, a folyamaton történő fejlesztési igényt, és ezt iterálva elkészít egy rendes, részletes, hitelt érdemlő, elfogadott üzleti specifikációt. utána indul a program tervezés és programozás. na ezt akarja mindenki megspórolni, erre találták ki az agilis módszertanokat.
Itt utalnék vissza arra, amikor valaki olyat lát az Agile-ba, ami nem is
. Az Agile sehol nem mondja azt, hogy ne legyen üzleti/termék/SW terved, sőt! Az iteráció pont az Agile egyik lényeges pontja.tely, baly, fojó, mennyél, mingyárt, telyföl, tolyás, malyd, kapú, egyenlőre, ejsd, jáccani, ahoz, fúj, hüje, muszály, alat, álok, lasan, fojtatás, ál, fontós, költsön, eggyüt, lyob (jobb?), mek, mongyak, milyért - !!! Tanúlyunk már meghejjessen irni... !!!
-
Tasunkó
senior tag
válasz
buherton
#108
üzenetére
kétszer annyiba kerülne a játék, mert hogy optimalizálni kell ezerrel.
Az optimalizált azt is jelenti hogy nem tesz kontrollálatlan köröket a program, amiből csak sejteni lehet mi sül ki, ergó egy kókányolás. Olcsóbb ettől nem lesz, legfeljebb kiszámíthatatlanabb hogy mit gányoltak össze, viszont ha kiszámíthatatlan hogy készült el, akkor azt sem tudják ki készítette. Nem tudni ki készítette és nem tudni mit, az előrejelzi, hogy majd nem lesz kinek.[ Szerkesztve ]
Kérek egy számot a jútútú
-
dabadab
titán
Mi volt a legnagyobb szoftverfejlesztési projekt, amiben részt vettel és ahol ilyen kiválóan megtanultad, hogy hogyan működik az optimalizálás?
Meg mondjuk hogyan érted azt, hogy "azt sem tudják ki készítette" és ez milyen viszonyban van a git commitokkal?Komolyan, miért kell olyanoknak magabiztosan osztaniuk az észt, akik egy helloworldot se tudnának összerakni?
DRM is theft
-
Chrystall
senior tag
Jó, figyelj, nyilván szélsőséges véleményt formáltam. Azt én sem tagadom, hogy vannak pozitív megnyilvánulások, pl bedolgozó programozók, kezdeményezések, projektek, esetleg termékek, de felsővezetés szinten, irányvonal szinten 0. Abban kb. itt tartunk mint az alap probléma a Google-nél, hogy van a magar Heureka meg a Google. És nem arról van szó, hogy ne tudnának jót csinálni. Csak egyszerűen nem tudja, hogy mitől lesz jó. Nem tud gyakorlatiasan gondolkodni. Stb. Meg lehet ezt nézni pl. mikor kimész Londonba, hogy hogy szervezik ott az életet, és nem feltétlen a pénz a kulcsa, hanem a földhözragadtság, az ötletek, a józan paraszti ész kategóriájú dolgok. Azok idehaza teljesen hiányoznak. Szóval emiatt van, hogy az ember az ilyen Google pereket a háta közepére kívánja, mert ha visszajön megint az a világ mint régen, hogy fragmentálódik az információhoz való hozzáférés lehetősége, a megjelenés lehetősége, akkor az nem lesz ám túl jó, legalább is annak, aki nem szereti, hogy az embereken nyerészkedő kormányok vagy cégek legyenek az úr. Magyarországon márpedig ilyen a cégmentalitás általában, mint azoké a kiskereskedőké volt, akik bedőltek mikor az olcsó cuccokkal az online áruházak meg az eBay átvették a piacot. Addig ők voltak a góré meg az úr a városban, annyiért adtak mindent amennyiért nem szégyellték. Csak aztán szembejött a 'jóság' a netről.
-
Chrystall
senior tag
Figyelj már, most tényleg az mlayer-t hasonlítjuk a Google-lel, amivel szakmákat tanultam meg ingyen, Wise-zal amivel több százezreket spóroltam bankköltségeken, eBay-el, amivel szerintem milliókat sporoltam már termékeken (arról nem beszélve, hogy sokmindent máshol meg se találtam volna), Skype-pal, amivel a telefonszámlán spóroltunk? Most komolyan, ez az etalon, hogy na, idehaza is van ám innováció, mplayer, tehát kreatív a magyar IT, van vérkeringés, szántsuk be akkor a Google-t és majd a magyar IT elveiszi a hátán a magyar igényeket. Na kössz de nem. Inkább a monopol Google az adatbányászatával mint az mplayer meg a Heuréka kereső.
[ Szerkesztve ]
-
Tasunkó
senior tag
Az hogy egy részletét felderítik, az nem azt jelenti hogy az a részlet nincs viszonyrendszerben más részekkel , így egy hiba közvetlen okozója sem független.
Ha egy libikókára 2 kacsa ül, vagy 2 víziló, ugyanúgy fog billegni föl le. Az eredmény az egyben optimalizáltság is. Amikor csak 2 mamuttal tudják megoldani, akkor már a vizilovasok nincsenek a projektben. Vagyis nem tudják ki csinálta, ha tudnák nem kéne a mamutokkal bajlódni, pedig nyilván probléma a mamutokat odaterelni. És ezt azért kell nekem elmondanám, mert a leggyorsabb voltam, azok közül akik tudják ezt.Kérek egy számot a jútútú
-
Tasunkó
senior tag
Nyereséget nem csak az optimalizálás kárára lehet. Nem szeretem ezt a szemléletet hallani, mert az optimalizáció hiányán nyerészkedni, az a jól működő programmal szembemegy. Az egyszerűség miatt nevezem optimalizációnak, így szokás, nyilván összetett, ha ...ul van megírva, hiába optimalizálják.
A többi a feltételezéseid, azokon nem segíthetek. HelloWorld, látod hogy megy.Kérek egy számot a jútútú
-
válasz
buherton
#108
üzenetére
Ö, azért ne tapsoljak már a beleszarásnak, hogy á, úgyis olcsó a tárhely, meg a RAM, csapjuk össze, jó'vanazúgy. Ilyen szempontból bambanonek van igaza, egy tisztességesen megírt szoftver nem így működik.
Amúgy vannak olyan helyek, ahol jól sikerül Agile-t csinálni? Gyanítom, hogy kevés.@Chrystall : " Google-lel, amivel szakmákat tanultam meg ingyen, "
Ja, Ok...Mutogatni való hater díszpinty
-
buherton
őstag
Ez már - szerencsére - nagyon régóta igaz, hogy a HW-t olcsóbb venni, mint a SW-t írni. És ez így van jól, mert elég meredek lenne asm-ben vagy C-ben business appokat írni. Ha már játékok, akkor valahol olvastam, hogy az Imperium Galactica tán 10k HUF volt, amikor kiadták és manapság is 20-25k körül megáll egy játék, de közben a fizetések min 10-szerese lett.
Btw, egy tisztességesen megírt SW-t kb. senki nem vesz meg, mert túl drága lenne.
Igen, vannak helyek ahol hellyel-közzel működik az Agile. És igen, tényleg kevés van sajna.
[ Szerkesztve ]
tely, baly, fojó, mennyél, mingyárt, telyföl, tolyás, malyd, kapú, egyenlőre, ejsd, jáccani, ahoz, fúj, hüje, muszály, alat, álok, lasan, fojtatás, ál, fontós, költsön, eggyüt, lyob (jobb?), mek, mongyak, milyért - !!! Tanúlyunk már meghejjessen irni... !!!
-
dabadab
titán
Ö, azért ne tapsoljak már a beleszarásnak, hogy á, úgyis olcsó a tárhely, meg a RAM, csapjuk össze, jó'vanazúgy. Ilyen szempontból bambanonek van igaza, egy tisztességesen megírt szoftver nem így működik.
Ez hogy jön az agile-hoz?... Sehogy.
Ez az a optimalizáció, amit az egyik tisztelt hozzászóló annyira szeretett volna látni
: a fejlesztési időre való optimalizáció és ez eléggé független metodológiától.[ Szerkesztve ]
DRM is theft
-
Bizonyos értelemben ja, de a másik szerint meg az Agile okozza ezt
@buherton :
"Btw, egy tisztességesen megírt SW-t kb. senki nem vesz meg, mert túl drága lenne."
Persze, amikor egy gyártóegység megáll egy idióta Siemens hiba miatt, akkor biztos nem kellett volna normálisan megírni.
Másrészt, szakmai szemmel nézem, mert nem marketinges meg manager vagyok, hanem informatikus.Illetve hát azzal is tele a tök, hogy atomerőművek kellenek a világ kedvenc OS-ének futtatásához, meg hogy egy oszlopdiagramot le lehessen generálni, és még így is lassú szar az egész. Ez kb. nonszensz.
"és manapság is 20-25k körül megáll egy játék, de közben " a fejlesztési költségek csökkentek, a piac meg szélesedett, szóval muszáj olcsóbban adniuk.
Mutogatni való hater díszpinty
-
dabadab
titán
Dolgoztam olyan agile projecten is, ahol a CI/CD része volt egy olyan teszt is, hogy mennyi memóriát/CPU-t eszik a program és milyen válaszidőket produkál - és ezeknek megadott határon belül kellett maradniuk, különben a teszt hibát dobott.
Viszont amikor meg a Javat (C++-t, C-t, operációs rendszereket, amit akarsz) kitalálták, akkor még sehol sem volt az agile és azokat is pontosan az az elképzelés vezette, hogy olcsóbb a vas, mint a fejlesztő.
DRM is theft
-
azbest
félisten
az mplayer és néhány más felsoroltak kapcsán: ami hobbi, nem munka, nem megélhetés, azt nem érdemes ide venni. CV-ben jól mutat munkakereséskor.
A Graphisoft pedig multi, akik sok más országban jelen vannak és látatlanban biztos vagyok benne, hogy nem magyar piacról jön a bevétel jelentősebb része. Más magyar érintettségű multik is vannak, igen.
A hdsentinel, aida és hasonlók kb mikrovállalkozások, bár céginfós stat szerint valsz olyan kevés fővel egész jól elvan, de azért messze a meggazdagodás. Nekik is nagy segítség lehet, hogy nemzetközi piacra dolgoznak, az itthoni forgalom valsz nullához konvergál.A legtöbb magyar kkv csak sokadik alvállalkozó vagy esetleg valamekkora - nem túl fizetőképes - ügyfélkörrel rendelkezik. És ott nincs lóvé túl nagy dolgokra. Max valami pályázatban bíznak, amivel pár évig lélegeztetőgépen lehetnek.
A szarból várat építkezés és a kókányolás a standard itthon. Ez egyébként külföldi startup alvállalkozóként még akár be is jöhez, mert a kezdeti időkben ott is a semmiből kókányolnak gyorsan valamit. Az ott bukik, hogy 4-6 vagy még több közvetítő lántcszem viszi el a hasznot, m,ire a magyar kkv-s kokkolóig eljuk a feladat kicsi pénzzért (minden láncszem vagy 30-50%-ot levesz a felsőbb szint áltlal fizetett pénzből. 4 közvetítő szintem már csak 16oda pénz jut a céghez, amiből még max fele rész jut a dolgozónak. A fizetésed 32x-esét fizeti a tényleges megrendelő).A mikro, kis, középvállalkozás deffinicói nézve is nagyon faramuci a helyzet. A legnagyobb magyar cég, akikkel együtt dolgoztam létszámilag már középvállalkozás, de forgalmilag meg kis. A legtöbb cég létszámilag kis, de forgalmilag mikro. Szóval ilyen pénzszűkös környezetben nehéz nagy dolgokat csinálni. A létszámhoz képes kicsi a forgalom a legtöbb cégnél. De ez nem azt jelenti, hogy könnyű a munka, inkább azt, hogy nem tudnak jól fizető ügyfeleket felhajtani. Ha pedig mindenen spórolni kell...
Na ehhez képest, ha Graphisoftot, NNG-t nézed, náluk máshogy aránylik a létszám és a bevétel.
[ Szerkesztve ]
-
buherton
őstag
Persze, amikor egy gyártóegység megáll egy idióta Siemens hiba miatt, akkor biztos nem kellett volna normálisan megírni.
Nem tudom milyen hibáról van szó, de hibamentes SW nem létezik, maximum olyan, amiben nagy eséllyel nem talál hibát a user. A megtalált hibák/tesztelésre fordított idő arány pedig nyilvánvalóan az idő előre haladtával csökken és aztán már nem éri meg. Ilyenkor jön az, hogy az ügyfél tesztel.
Mintha mondtam volna már, hogy a német cégekről talán még rosszabb véleményem van, mint a magyarról.
a fejlesztési költségek csökkentek,
Pontosan erről beszéltem.
#122 dabadab: "Gálánsan" elfeledkeztem az újkori nyelvekről, úgy mint a go és a rust, amik szemben a korábbi filozófiával hatékonyabban használják fel az erőforrásokat, mint a saját területeiken lévő nyelvek.
tely, baly, fojó, mennyél, mingyárt, telyföl, tolyás, malyd, kapú, egyenlőre, ejsd, jáccani, ahoz, fúj, hüje, muszály, alat, álok, lasan, fojtatás, ál, fontós, költsön, eggyüt, lyob (jobb?), mek, mongyak, milyért - !!! Tanúlyunk már meghejjessen irni... !!!
-
Nagyon messze nem voltak ezek egymástól, de talán a nagyon flexibilis, egyféle dolgokra jó nyelveket találták ki így (Magic).
A Java esetén nem sok ilyet látok, az platformfüggetlennek indult. Az is kb.A Rust a másik véglet, inkább a C biztonsági hibáit és bugjait javítja, de a hatékonysága talán csak annyival rosszabb, amennyiben ezeket nem tudod kreatívan alkalmazni. De különben a C továbbfejlesztése, bevallottan.
@buherton : "Nem tudom milyen hibáról van szó, de hibamentes SW nem létezik, "
Ja, csak a megrendelőt nem fogja érdekelni - ha nem lenne ott is vendor lock-in, akkor...
Van ilyen Siemens Simatic cucc, ami több millió Ft. A szoftver. Annyiért már elvárnám, hogy ne blőd hibákon álljon meg.Mutogatni való hater díszpinty
-
Pikari
addikt
Ami nem "mikro", annak van mondjuk 10 országban fejlesztőirodája, és nem specifikus semmilyen országhoz sem. Magyarán csak kicsiket tudsz vizsgálni. Hogy valami opensource, az nem jelenti azt, hogy nem hoz profitot, meg csak önéletrajzba jó, mert nagyon sokszor azokat is cégek tolják, a fő fejlesztő meg vagy alkalmazott, vagy kapja érte a zsetont máshogy. Szerintem ezeket az aspektusokat, amiket idehoztál, nincs is értelme ebben a kontextusban vizsgálni. Nem is nagyon akartam már reagálni az újabb kommentekre, mert egyre vadabb hülyeségek hangzanak el. De mégegyszer összefoglalva elmondom, bármennyire próbálják is kötni az ebet a karóhoz egyesek: a magyar it kultúra és más országok it kultúrája között nincs különösebb eltérés, semmilyen szempontból sem.
[ Szerkesztve ]
A Dunning−Kruger-hatás az a pszichológiai jelenség, amikor korlátozott tudású, kompetenciájú vagy képességű emberek rendkívül hozzáértőnek tartják magukat valamiben, amiben nyilvánvalóan nem azok.
-
bambano
titán
válasz
buherton
#108
üzenetére
"Btw, ez egy jó CICD nélkül nem megy.": én is ezt mondtam. csak nem értek vele egyet. az agilis módszertan arra jó, hogy hogyan lehet sok hibát nagyon gyorsan elkövetni, és ehhez megalkották a szükséges szoftver infrastruktúrát. Az egész k8, docker, ansible, cicd, stb. infrastruktúrának egyik kulcs tulajdonsága, hogy gyorsan lehet deployolni. csak arra nincs magyarázat, hogy minek?
"Az iteráció pont az Agile egyik lényeges pontja.": értsük meg, hogy ez BAJ! Egy rakás forrást néztem, mindegyikből az jött le, hogy a probléma alapos megismerését helyettesíti az iteráció meg az agile meg a többi. Aminek eredménye, hogy rakás programozói munkát dobnak ki.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
bambano
titán
szerencsére az, hogy mihez volt közöm, nem a te gondolataidtól függ, hanem a karrieremtől.
másrészt azt elég nehéz lenne elvitatni, hogy a szoftveriparban káros folyamatok zajlanak, aminek az eredménye a pocsék szoftver. a pocsék szoftver egyik oka pedig a kapkodás, a szükséges fejlesztés megspórolása.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
dabadab
titán
Az egész k8, docker, ansible, cicd, stb. infrastruktúrának egyik kulcs tulajdonsága, hogy gyorsan lehet deployolni. csak arra nincs magyarázat, hogy minek?
Mert ha az automatizálható dolgokat automatizáljuk, akkor több idő marad a nem automatizálhatókkal foglalkozni, mert egyrészt nem kell megcsinálni, másrészt ha nem kell megcsinálni, akkor elrontani se lehet és a hibakeresést is meg lehet spórolni.
De ezt tényleg magyarázni kell? Legközelebb azt kérdezed meg, hogy minek a copy-paste, amikor kézzel is szépen be lehet pötyögni ugyanazt."Az iteráció pont az Agile egyik lényeges pontja.":
értsük meg, hogy ez BAJ!
vs
üzleti elemző megnézi a folyamatot, a folyamaton történő fejlesztési igényt, és ezt iterálva elkészít egy rendes, részletes, hitelt érdemlő, elfogadott üzleti specifikációt
szerencsére az, hogy mihez volt közöm, nem a te gondolataidtól függ, hanem a karrieremtől.
Azt meg gondosan megismertetted velünk
és elég pontosan lehet tudni, hogy te rendszergazdáskodásban vagy otthon, nem a szoftverfejlesztésben.másrészt azt elég nehéz lenne elvitatni, hogy a szoftveriparban káros folyamatok zajlanak, aminek az eredménye a pocsék szoftver. a pocsék szoftver egyik oka pedig a kapkodás, a szükséges fejlesztés megspórolása.
Ez nem újdonság, mindig is így volt és természetesen ennek nincs köze az agile-hoz.
[ Szerkesztve ]
DRM is theft
-
bambano
titán
ha túltervezed az architektúrát, akkor egy rakás olyan plusz réteg lesz a rendszerben, aminek kézzelfogható eredménye nincs, viszont bugokat hoz be.
A két iteráció között lényeges különbség van: az üzleti elemző NEM PROGRAMOZ. Az üzleti elemző feltárja a folyamatokat, igényeket, folyamatfejlesztési lehetőségeket, célokat, és azt dokumentálja. És igen, EBBEN van és kell iteráció. Odamegy Gizikéhez, kérdez párat, és kap valami benyomást, ami alapján legközelebb megint odamegy, és pontosít. De nem pazarolja a programozási erőforrásokat, mert ekkor még nincs programozás.
Az agilis iteráció meg arról szól, hogy programozzanak már a gyerekek, ne unatkozzanak, mindegy mit, majd iterálunk, eldobjuk és jön a következő kanyar.
Amikor az elemző végez az iterációkkal, akkor keletkezik egy végleges rendszerterv. Utána már nincs iteráció, azt megvalósítják a programozók.
Ez a moving target típusú programfejlesztés nem tetszik, ami az agilis módszertan lényege. Gyakorlatilag még akkor is bőven találgatás folyik a célról, amikor már jelentős lépések történtek a cél akkori állapotban hitt irányába. És pontosan ezért röhögte ki a bankos haverom az agilis módszertant, mert a banki szféra speciális szabályainak nem lehet találgatással megfelelni. Autót sem úgy gyártanak, hogy már elindult a gyártóüzem felszerszámozása, de még nem világosak a célok, a marketing selling pointok, a célközönség meg a hasonló dolgok.
"Azt meg gondosan megismertetted velünk": egyrészt te komolyan hiszed, hogy minden dolgomat közhírré tettem? másrészt én komolyan higgyem el, hogy emlékszel is a dolgaimra akár csak arra a 17 évre visszamenőleg, mióta ezt a regemet használom? bocs, nem hiszem el.
"Ez nem újdonság, mindig is így volt és természetesen ennek nincs köze az agile-hoz.": egy tőről fakad: azért ócska a szoftver, mert meg akarják spórolni a költségek egy részét, és ezért "fejlesztették ki" ezt a bullshit módszertant, hogy ezzel elfedjék a tróger munkát. De a tény az, a szoftver projektek zöme bedől. Tehát a jelenlegi szoftverfejlesztési módszertanok nem jók.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
L.Edit
tag
Vége egy téma ahol mindenkivel egyet értek. Még a trollokkal is!
A napokban jutottam el oda, hogy YT-Google vonalon kicsit is nem specifikusan keresve kizárólag generált tartalmat kapok, igazi tartalom nélkül. Ha hozzá akarok jutni a releváns tartalomhoz el kell jutnom azokhoz az oldalakhoz, emberekhez, akiket NEM generálnak akkora forgalmat, hogy abból ezeken a platformokon keresztül megélhessenek, és ennek a kiszolgálására rendezkedjenek be.
Ami döbbenet, hogy bedobott 3. találatnak olyan short videót, ahol arab munkás vízsugárral vágja le az újját. Valószínű hogy nem fogok ekkora kupac szarnak a közelébe menni, amíg nem képesek arra az apróságra, hogy a "találatok" címe kapcsolódjon az általam használt keresőszavakhoz.
Csíramentes, mosott-szárított belsőség eladó.
-
azbest
félisten
Nálunk nincs minden commit után automatikus deploy, de jobok indításával lehet docker tesztkörnyezetre kitenni bármelyik verzió ügyfélváltozatát. Ott kiderül, hogy ők és a devek is arra gondoltak-e, amit az ügyfél gondolt, ugyanaz jön-e ki. Van, hogy módosítani kell akár üzleti elemzőnek, akár devnek.
Az üzleti elemző nem programoz, de speciális excelekben rakják össze az üzleti elemzőink az adatstruktúrát, amiből job generál kódot, sok esetben nem kell dev segítség sem a bekötéshez, ha már létező képességet használó adatfeldolgozáshoz kell.
A végleges rendszertervről annyit, hogy van, amikor menet közben, van amikor a kiadott verzió tesztelésekor rájön az ügyfél, hogy mégsem arra gondolt, mint ami az általa is elfogadott specifikációban van
Az agilis módszer nem fix, hanem a feladathoz lehet igazítani. Nálunk a valóban hasznos meetingek adják a legnagyobb hozzáadott értéket (napi fél óra, 3 heti 1.5 retro és 1.5 tervezés, van hogy menet közben is becslés, tervezés váratlan új feladatnál). Meg nem úgy agilis, hogy össze vissza gányol mindenki. A csapat a határidők és belső szempontok alapján rak sorrendbe feladatokat, az ütemezés van hogy változik, ahogy az ügyfelek vagy más külső-belső körülmények változnak. Az előfordul, mert 3-4 ügyfél felé is van egyszerre aktivitás, plusz az előre nem látható technikai support problémáik. Nem úgy moving target, hogy minden nap kedv szerint mást csinálunk, hanem alkalmazkodunk a változó környezethez, attól még van terv és prioritás, csak gyakran az élet közbeszól.
Lenne igény több automata tesztre is (CICD egyik kulcseleme), de nagyon régóta fejlesztett nagyon komplex rendszernél, ami ráadásul sok tekintetben paraméterezéstől függően működik, nehéz jól megcsinálni.
Nekem az a benyomásom, hogy amióta "agilis" - jelentsen ez bármit is - nálunk a fejlesztés, azóta hatékonyabban, kevesebb hibával halad a szekér. Üdv banki szférából
-
Z_A_P
addikt
Hála istennek ahol en tolom ott komoly elvarasok vannak, most már sűrűn release - ulnk (dobozos termék, nem lakossági piacra), 6 havonta 1x. Régebben kb évi 1 release. Sűrű, mert ügyfelek átlag 3 évente frissítenek, de van aki 10 év alatt 1x.
mégsem arra gondolt, mint ami az általa is elfogadott specifikációban van
Hála istennek újra, mi készítjük a speckot (igaz figyelembe vesszük az ügyfél igényeket, és ha nem túl egyedi akkor belerakjuk ha illik a koncepciónkba), és az ügyfél azt kapja amit csinálunk.
A fenti példa nem probléma, hanem bevétel: estimation -t becsülni, szorozni, stb, megy ki uj szerződés ügyfélnek, amint itt a pénz neki lehet állni. Ha pechje van, es az egész design bukó, akkor újra fizeti az egészet.De azt értem hogy én kivételezett helyzetben vagyok, nem projectek vannak bizonytalan ügyfelekkel, hanem dobozos terméket csinálunk, és azt kapják amit mi csinálunk.
Jobban kéne értékelnem a jót
[ Szerkesztve ]
OK
-
bambano
titán
" rájön az ügyfél, hogy mégsem arra gondolt" vs "Meg nem úgy agilis, hogy össze vissza gányol mindenki.": vagyis de.
ha a programozó nem lehet biztos benne, hogy azt programozza, ami a valódi igény, akkor de, akkor csak össze-vissza gányol mindenki.
egyébként pedig adatbázist rendes helyen adatbázis szakértő tervez, és nem excelben. szerintem kevés üzleti elemző van, akinek ha azt mondod, hogy csomszki, nem kívánja egészségedre.persze te lehetsz szerencsés (a munkahely-választásod miatt), mert bankban elvileg lenne zseton szakemberre, és lehet, nálatok volt is. meg az is lehet, hogy ti csak névleg vagytok agilisek. ettől még az agilis módszertan sok helyen arról szól, hogy a megrendelőnek fogalma sincs, hogy mit akar, és ezen dolgoznak.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
buherton
őstag
másrészt azt elég nehéz lenne elvitatni, hogy a szoftveriparban káros folyamatok zajlanak, aminek az eredménye a pocsék szoftver. a pocsék szoftver egyik oka pedig a kapkodás, a szükséges fejlesztés megspórolása.
És az is, hogy a fejlesztők jó része megragad egy szinten, nem akar jobbá válni. Ha el is megy tanfolyamra, akkor sem igazán figyel oda és/vagy érti meg az elhangzottakat. Ez nem Agila. Btw, a Scrum Master egyik feladata, hogy a csapat megkapja a szükséges oktatást, amivel a feladatát eltudja végezni.
#126 dabadab: Nagyon nehéz objektíven összemérni két nyelvet, mindenesetre tettek próbát, aminek ez lett az eredménye:
[Rust vs C Clang]
[Rust vs C++]Nekem a fentebbiek alapján azt vontam le, hogy abszolút fej-fej mellett vannak. A Rust-t egyébként nem ismerem jól csak hallottam róla.
A go:
[Go vs Java]
[Go vs C#]
[Go vs C++] (nyilván a C++ gyorsabb, de azért az komoly, hogy a go memória footprintje az több esetben is azonos a C++-al)A go egyébként sokat merített a C-ből, talán azért is, mert az egyik megalkotója Ken Thompson. És abban is hasonlít a C-re, hogy kevés nyelvi elemet használ, de nagyon eltud aztán bonyolódni. Nekem nagyon tetszik ez a nyelv. Többek között ennek hatására tettem le a 10 éves C-s pályafutásomat.
#135 bambano: Az iterációs témakörhöz. Leírva szépen hangzik, hogy majd az üzletért felelős xy szépen megtervez meg leír mindent és alaposan mindenkit kifaggat, hogy wtf. A baj csak ott van, hogy igazából senki nem tudja, hogy mit is akar a customer. A customer maga sem tudja az elején. Azért kell mi hamarabb megmutatni, hogy legyen képe arról, hogy mi ez.
Amikor az elemző végez az iterációkkal, akkor keletkezik egy végleges rendszerterv.
Ilyen természetszerűleg nem létezik.
Amit te szeretnél az a németes waterfall, ami már kb akkor elbukott, amikor elkezdték használni.
És pontosan ezért röhögte ki a bankos haverom az agilis módszertant, mert a banki szféra speciális szabályainak nem lehet találgatással megfelelni.
A szabály az szabály, azt meg kell csinálni és ebben is segít az Agile és a CICD, hogy belegyenek tartva.
Gondolom a banki szabályok nem fedik le maradéktalanul, hogy egy alkalmazásnak hogyan kell működnie, ergo jó ott is az Agile, mert az elején ott sem tudják, hogy mit akarnak.
Autót sem úgy gyártanak, hogy már elindult a gyártóüzem felszerszámozása, de még nem világosak a célok, a marketing selling pointok, a célközönség meg a hasonló dolgok.
Szóval minden gyártónak minden autója sikeres lesz. Ha ez talán mégsem lenne igaz, akkor az Agile itt is segíthet bár ez nem SW és itt a átfutási idők jóval hosszabbak.
"Ez nem újdonság, mindig is így volt és természetesen ennek nincs köze az agile-hoz.": egy tőről fakad: azért ócska a szoftver, mert meg akarják spórolni a költségek egy részét, és ezért "fejlesztették ki" ezt a bullshit módszertant, hogy ezzel elfedjék a tróger munkát. De a tény az, a szoftver projektek zöme bedől. Tehát a jelenlegi szoftverfejlesztési módszertanok nem jók.
A fejlesztői és vezetői kvalitás hiányára nem lehet semmilyen módszertant kitalálni, ami ezeket megoldja.
Érdekes, hogy pl. a Spotifyról nem sok rosszat hallottam senkitől, holott ők aztán nagyon durván tolják az Agile-t.
tely, baly, fojó, mennyél, mingyárt, telyföl, tolyás, malyd, kapú, egyenlőre, ejsd, jáccani, ahoz, fúj, hüje, muszály, alat, álok, lasan, fojtatás, ál, fontós, költsön, eggyüt, lyob (jobb?), mek, mongyak, milyért - !!! Tanúlyunk már meghejjessen irni... !!!
-
buherton
őstag
egyébként pedig adatbázist rendes helyen adatbázis szakértő tervez, és nem excelben.
A XFT fogalma pont azt takarja, hogy a csapat minden olyan kompetenciával rendelkezik, ami a munka elvégzéshez szükséges. Ha kell adatbázis szakértő a feladathoz, akkor az Agile alapján lesz adatbázis szakértő a csapatban.
ettől még az agilis módszertan sok helyen arról szól, hogy a megrendelőnek fogalma sincs, hogy mit akar, és ezen dolgoznak
A megrendelő nem tudja, hogy mit akar és az Agile pont erre ad megoldást, hogy derüljön ki mihamarabb.
tely, baly, fojó, mennyél, mingyárt, telyföl, tolyás, malyd, kapú, egyenlőre, ejsd, jáccani, ahoz, fúj, hüje, muszály, alat, álok, lasan, fojtatás, ál, fontós, költsön, eggyüt, lyob (jobb?), mek, mongyak, milyért - !!! Tanúlyunk már meghejjessen irni... !!!
-
niof
addikt
Ha valami komolyat akar tenni a bíróság, amit egyébként kétlek (kirakatper lesz ez), egy végtelenül egyszerű döntést kellene hozniuk. A Google tegye open source-á a keresési algoritmusát minden vetélytárs számára, és a forrásokhoz való hozzáférést is biztosítsa, valamint oldja meg, hogy az ebből származó bevétele megszűnjön, az ehhez tartozó szerződések pedig váljanak semmissé. Innentől bármelyik böngésző használhatná a Google megoldását szabadon, és bárki eldönthetné, hogy mit használ, amellett, hogy a kereső megszokott hatékonyságából nem vesztene semennyit sem. Mert azért lássuk be, akármilyen mocsok egy cég, ha valamit egyszerűen meg akar az ember találni a "zinterneten", akkor az ő motorjukat fogja igénybe venni. Hiába sír a DuckDuckGo, ha az ő megoldásuk egy hulladék, de még a Bing is elég gyenge muzsika. A többi meg kb. említésre sem méltó.
Egyelőre nem szelem fel az almát egyenlőre.
-
#146
fatpingvin
őstag
niof
#145
fatpingvin
őstag
az algoritmus mostly open-source. nem maga a szoftver a nagy érték itt hanem az a felfoghatatlan méretű (meta)adatbázis amit összeharácsoltak. azt kéne szabadon hozzáférhetővé tenni, nem a keresőalgót.
A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)
-
-
#148
fatpingvin
őstag
azbest
#147
fatpingvin
őstag
oldják meg
viccet félre. oldják meg. igen, tudom, nem így működik a piac. akkor rá kell kényszeríteni. ha meg ettől összeomlik akkor nem kár érte.
[ Szerkesztve ]
A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)
-
niof
addikt
Annyira nem értek hozzá, hogy ez hogyan működik, de nagyjából eltaláltam. Az adatbázis kimaradt. Miből üzemeltessék a szervereiket? Abból, amit rajtad és rajtam megkeresnek. Ha rajtam múlna, már rég kivágtam volna alóluk a fát. Van egy olyan sanda gyanúm, hogy ebből a perből nem lesz semmi, mert már túl nagyra nőttek (nem csak ők), ezt nem lett volna szabad hagyni. Most már későn kapálózik a jog meg a politika. Gyakorlatilag azt csinálnak, amit akarnak. Elhúzódik majd a per 10 évig, és közben milliónyi kiskaput kihasználva máshogy kerülik meg a törvényeket.
Egyelőre nem szelem fel az almát egyenlőre.
. Az Agile sehol nem mondja azt, hogy ne legyen üzleti/termék/SW terved, sőt! Az iteráció pont az Agile egyik lényeges pontja.
Új hozzászólás Aktív témák
it Nagy reményekkel figyelik a keresőriválisok a Google és az USA perét: a Google azt állítja, hogy nem élt vissza az erejével, hogy monopolhelyzetbe kerüljön a keresőpiacon – az USA viszont kemény vádakkal támadja a nagy trösztellenes perben. Állítólag az internet jövője a tét.
- AMD CPU-k jövője - amit tudni vélünk
- Milyen hagyományos (nem okos-) telefont vegyek?
- World of Tanks - MMO
- Elkészült Oroszország első litográfiai berendezése
- BestBuy ruhás topik
- sziku69: Szólánc.
- Luck Dragon: Asszociációs játék. :)
- sziku69: Fűzzük össze a szavakat :)
- DIGI kábel TV
- Cyberpunk 2077
- További aktív témák...
- DJI Avata 2 Fly More Combo (Three Batteries)
- -59% HP EliteBook x360 830 G7:i5 10310U,16GB,256GB,vil.MAGYAR bilI.,IR,13.3" Touch,100%sRGB,WWAN 4G
- Sony PS5 (1116A) + 2TB Samsung SSD bővítés a gyári 825GB mellett, két karral + venom töltőhub
- HP Laptop 15-fd051ne - ÚJ - 15,6" FullHD IPS notebook - Core i5-1335U, 8GB, 512SSD, Win11
- Brother DCP-L2532DW wifis, multifunkciós lézernyomtató
- Intel Core I5-8600
- Akció! Dell Optiplex 3080 Micro / I5-10500T / 16GB DDR4 / 256GB SSD /Windows11 Matrica BESZÁMÍTOK
- ASUS Radeon RX 5700 XT Dual EVO 8GB GDDR6
- Videoton AB 1010 autó hangszóró pár eladó a képeken látható állapotban. Mindegyik hangszóró működik,
- Ultra ritka Sound Blaster 1.5 2.0 klón Anchor Media Concept retró 8 bites ISA PC hangkártya
Állásajánlatok
Cég: Alpha Laptopszerviz Kft.
Város: Pécs
Cég: Ozeki Kft.
Város: Debrecen