Minden, amit a modern szoftvertesztelésről tudnod kell

Minden, amit a modern szoftvertesztelésről tudnod kell
2016-03-18T08:26:11+01:00
2016-03-22T08:02:09+01:00
2022-10-20T14:10:35+02:00
  • Az előadás projekt menedzselésről szól és nem szoftver fejlesztésről.

    A szerepkörök a modern világban nem mindig köthetők emberekhez - sokkal inkább felvehető "sapkák". Ez egészséges is, hiszen így lényegében evolúciós jellegű kiválasztódással az kerül a megfelelő szerepkörbe, aki tényleg oda való és nem az aki címe szerint való oda. Én például nagyon szívesen folyok bele minden területbe és ha valaki a vezetésben nem az optimális úton jár, akkor "beszólok" - na nem kocsmai hangvétellel, hanem azért az alternatívát felmutatva és ha nem érzékelek elmozdulást és ez valamit már elkezd veszélyeztetni akkor más is szóba jöhet. Ezt mondjuk nem érdemes túlzásba vinni.

    Visszacsatolásra, tesztre szükség van, de projekt szinten nem a szoftver fejlesztő feladata.

    Ez egy tipikusan olyan dolog, hogy konkrétan mindegy ki veszi észre a bajokat. Szerintem az is mindegy, hogy ki képviseli azt a szerepkört, hogy "na jó, ez szép de az ügyfélnek nem kell/kell" - csak az a lényeg, hogy a képviselet jól el legyen látva. Egyébként pedig nekem az a véleményem, hogy nem mindegy a fejlesztő világa vajon odáig terjed-e ki ami egy papíron van leírva specifikációként, vagy azon túlmenően a világának része a célközeg is valamilyen módon. Biztos mindenki ismeri azt a mondatot, hogy "a királynőt megölni nem kell félnetek jó lesz ha mindenki egyetért én nem ellenzem" - ami persze sarkított példázata annak, hogy nem mindig minden egyértelmű amit leírsz. Na mármost ha így szeparálod a dolgokat éles határokkal, akkor a félreértések feloldásának a módja, hogy észlelik valami nem világos és megkérdik tőled. Ezzel akkor van baj, amikor valami világos megfogalmazású másnak is - csak épp más jelentéssel. Az agilis módszerek esetén például azért szokás a teljes csapattal kivonulni demózni, közösen összerakni a sprintet és közvetlenül érintkezni a fejlesztőknek az ügyféllel akár, mert így ez a káros szeparáció nem jön létre és a fejlesztő mentális modellalkotása is valóságon - nem pedig másodkézbeli információkon alapszik.

    nem tudom feltűnt-e valakinek a 40 milla, 3 hó 5-6 szoftver fejlesztő kijelentés. Szerintetek valós a havi ~2.6 millás / fő munkaerő költség?

    Nem mindenhol nettó 200k-val számolnak fejlesztői bért, de én nem úgy értettem, mintha munkaerő-költséget mondott volna, hanem teljes projekt-költséget. Ha a teljes költséget nézed, akkor abban van az esetleges AAA iroda, a projektindítás / zárás / elnyerési folyamat és a cég is nyerni akar a dolgon. Szerintem egyébként ez így is túl sok, de mondjuk el tudom képzelni, hogy a fele ennyi az sok helyen már gyakori és hogy van aki meg ilyennel dolgozik. Attól függ milyen közegben mozogsz, mert nem mindegy, hogy php-projektek körül, vagy mondjuk exportképes, de egyedi technológiát igénylő projektek körül nézel szét. Mondjuk ettől függetlenül szerintem is túl sok és ezen lehetne faragni elég rendesen

    Pisti kőműves segédmunkás, kőműves (= fejlesztő(k)) pedig NEM azzal foglalkoznak, hogy módosítják a terveket...

    Látom nem sikerült elolvasni amit ezzel kapcsolatban fő mondanivalóként megfogalmaztam. Persze az is lehet hogy csak nem akartad tudomásul venni, mert zavar maga a gondolat, hogy nem ez a felosztás és egy szoftverprojekten nincs is kőműves

    Egyébként persze értem hogy más irányból közelíted és emiatt könnyen félre lehet siklani, de ettől még ez a félreértés sok gondot okoz.
    Mutasd a teljes hozzászólást!
  • van két fejlesztőcsapatod:

    az egyik nem tesztel sikert és profitot és nem is menedzseli ezt, hanem a megrendelőre tolja

    a másik menedzseli őket, és hatáskörön belül optimalizál, az olyan kérdésekben, ami pedig nem rá tartozik, eszkalál

    megrendelőként szerinted melyikük munkája az értékesebb?

    ha csak arról van szó hogy pár dolgot megtanulsz és csinálsz hogy értékesebb legyen a munkád, mi az érved a fejlődés ellen?

    vajon az érveid a konkurenciádra is vonatkoznak, ő sem fog fejlődni?
    Mutasd a teljes hozzászólást!
  • Elkanyarodunk a lényegről.
    A jelen előadással van problémám, azaz az elhangzottakkal. Az előadás projekt menedzselésről szól és nem szoftver fejlesztésről. Olyan szerepköröket tol a szoftver fejlesztő(k)re ami szerintem nem az ő feladatuk. Visszacsatolásra, tesztre szükség van, de projekt szinten nem a szoftver fejlesztő feladata.

    Piramis 2 felső szintje, cél és siker, projekt szinten nem a szoftver fejlesztő kompetenciája. A projekt gazdáé, a befektetőé. Aztán a projekt sikere NEM a profitot jelenti mint ahogy elhangzott. Lentebb már írtam a lizinges példáról ami szintén problémás. De nem tudom feltűnt-e valakinek a 40 milla, 3 hó 5-6 szoftver fejlesztő kijelentés. Szerintetek valós a havi ~2.6 millás / fő munkaerő költség?
    Ezekért bírálom ezt az előadást. Az én véleményem szerint 30 % hasznos a többi töltelék, egyes részei még félrevezetők akár károsak is.

    Építkezésnél van műszaki ellenőr, építés vezető. Az Ő feladatuk az ellenőrzés úgymond ők látják el a tesztelői feladatokat. (+ az építési hatóság is) Természetesen akkor ha mindenki rendesen végzi a munkáját. A Pisti kőműves segédmunkás, kőműves (= fejlesztő(k)) pedig NEM azzal foglalkoznak, hogy módosítják a terveket...

    Szerepkörök mások. Szoftver fejlesztő NEM tesztel sikert és profitot hogy sarkosan írjam.
    Mutasd a teljes hozzászólást!
  • Ha egy szoftverfejlesztőt vagy csapatot megbízok mint főnök, projekt gazda egy specifikáció szerinti fejlesztéssel Ő(k) meg megváltoztatják és nem azt készítik el hát úgy penderíteném ki őket hogy na...

    Egy egyszerű kérdést teszek fel: Neked az a fontos, hogy a szerződés pontra teljesüljön, vagy az, hogy a készülő termék valós igényeket elégítsen ki és valós problémákat oldjon meg? A véleményem szerint a szerződést optimális esetben senki meg se nézi, csak ha a termékkel nem elégedett.

    Ha viszont nem folyamatában kerülnek a dolgok átadásra iteratív módon, akkor megértem persze, hogy checklist-et akarsz csinálni "nehogy valami kimaradjon ami mégis kell" - de pont az ilyen felhalmozódó verifikációs gyöngyöleg az, amit a folyamatos szállítás kellene feloldjon.

    Én vagyok a befektető, az aki fizeti a munkát és kockáztatja a pénzét.

    Ha ez megnyugtat, amilyen hozzáállással megpróbálod a dolgokat intézni szerintem tényleg kockáztatsz

    Ha egy csoportot azzal bízok meg hogy vizsgálja meg, tesztelje a specifikációt és azt hozzák ki hogy hibás, vagy javítható akkor elfogadom, hisz ezt kértem, ezért fizetek.

    A specifikáció egy elvi leképezése a szoftvernek és elméletben jó hidat képez a feladat és a technikai szintek között, a tervek elméletben tartalmazzák a felmerülő kockázatokat, nem fog kiderülni, hogy valami így nem optimálisan valósítható meg mert ezek elemezve lettek és olyan se fog kiderülni, hogy egy másik, de egyenértékű megoldás előállítási költsége 1000HUF és 10 perc, amit meg leírtál annak pedig 1000 emberóra és.... Na a lényeg, hogy bizonyára akik a specifikációt alakítják szakemberek és ezeket számításba veszik.

    Ez szép és jó, de ismered remélem a mondást:
    - Mi a különbség az elmélet és a gyakorlat között?
    - Hát elméletileg semmi...


    A szoftverfejlesztő kapja a pénzt és nem kockáztat.

    Hogyan mondjam... ugyanúgy ahogy sértő dolgoknál emlegetik, hogy akinek nem inge ne vegye magára, úgy ilyen esetben is azt tudom tanácsolni, hogy ha "fáj" a kockázat, akkor inkább oszd meg a fejlesztővel. A fejlesztőnek mi a kockázatosabb: ha három hetente letesz valamit és bármikor azt mondhatod "köszönjük a megtisztelő munkát, de nem vagyunk megelégedve" - vagy ha írsz egy nagy tervet, a fejlesztőknek adsz egy zsák pénzt, elmennek vele egy évig dolgozgatni aztán megjönnek valamivel aminél a fizetés ahhoz van kötve, hogy checklist-szerűen megvan-e a funkciókör? Hallottál már arról a két fogalomról, hogy "a kilóra történő szállítás" meg a "rendes szállítás"? Bár persze gondolom ezt az elnevezést nem projektgazdaként fogod hallani, maximum sejteni.


    Még egy kérdés ezzel kapcsolatban - ha már építőipari hasonlatokat emlegettünk:
    - Szerinted ez a felállás pl. az építőiparban is érvényes? Akiket megbízol a ház felépítésével nem vállalnak kockázatot, csak pénzt kapnak? Szerintem egy üzlet esetén sosem optimális úgy osztani a szerepköröket, hogy van aki semmit se kockáztat és van aki mindent. Nyilván nem is homogén a dolog, de ez a fajta szélsőség szinte biztos, hogy káros.

    Illetve:
    - Szerinted ha megrendelsz két házat két véletlenszerűen választott cégtől, a házakhoz pedig ugyanolyan igényeket fogalmazol meg és az egyiket a szomszéd kertben építik, a másikat pedig az alföld közepén mindentől távol és nem tudsz kimenni ellenőrízni a munkafolyamatokat, akkor melyik helyzet tűnik biztonságosabbnak? Tovább menve: Ha megbízol egy ismeretlen építtetőt részletes tervekkel és messze fogja neked megépíteni te pedig nem mehetsz ki a telekre, illetve egy helyi vállalkozót felületesen de úgy, hogy melletted épül az ingatlan és bármikor megnézheted, akkor szerinted hol futsz bele nagyobb eséllyel olyan helyzetbe, hogy bár nem lehetsz elégedett, de jogilag mégis ki kell fizetned a projektet?


    Egyébként van még egy nagyon nagy félreértés, ami valószínűleg a szoftverfejlesztési projektek, üzletkötések balul elsülésének és a félreértéseknek a legfőbb forrása - mégpedig hogy szoftverek esetén a követelményeket és specifikációt, illetve a tervezési fázist az építőipari és egyéb papíros mérnöki tervezéshez hasonlítják - a programkód megírását meg ahhoz a munkafolyamathoz, hogy valaki elkezdi a falat rakni a terveknek megfelelően. Az a nagy koncepcionális probléma, hogy ez szerintem egy fatális tévedés - és szó szerint végzetes tévedés... A szoftverfejlesztésben a téglarakást a környezet, a fordítóprogram és fejlesztőeszköz végzi, a blueprint jellegű tervek reprezentációja ebben a szakmában maga a forráskód és a specifikáció kb. annak feleltethető meg amikor kihívod a szakit és szóban elmondasz neki pár dolgot, hogy "hát szeretnék egy erkélyt és két szintes legyen". Egy ház építésénél nem áll rendelkezésre "fordítóprogram" ami a blueprint-ből előállítja a házat, mert még nem járunk asimov robottörténeteinek a kellős közepén, de attól függetlenül, hogy ezt a transzformációt emberi erőforrás végzi el még nagyjából erről van szó. A zavart az okozza, hogy ezt a lépést a puha-áru világában már a kezdetektől automatizálják, így azzal aki a téglát rakja te sose találkozol, mivel egy "robot" végzi már ezt a feladatot.

    A zavar másik oka abból származik, hogy mivel más területeken a blueprint nem így néz ki ezt az emberek - főleg a projektgazdák - általában nem ismerik fel, attól a pár szerencsés kivételtől eltekintve, akik képesek nem csak közepes, de optimális döntéseket is hozni és ténylegesen vezetni. Szerintem ezt sokan szakmán belül sem ismerik mindig fel
    Mutasd a teljes hozzászólást!
  • Sikeres fejlesztés miközben sikertelen a projekt ?
    A műtét sikerült, a beteg maghalt.
    Mutasd a teljes hozzászólást!
  • Ha egy szoftverfejlesztőt vagy csapatot megbízok mint főnök, projekt gazda egy specifikáció szerinti fejlesztéssel Ő(k) meg megváltoztatják és nem azt készítik el hát úgy penderíteném ki őket hogy na...
    Én vagyok a befektető, az aki fizeti a munkát és kockáztatja a pénzét. A szoftverfejlesztő kapja a pénzt és nem kockáztat.

    Ha egy csoportot azzal bízok meg hogy vizsgálja meg, tesztelje a specifikációt és azt hozzák ki hogy hibás, vagy javítható akkor elfogadom, hisz ezt kértem, ezért fizetek.

    Lényeg: NEM a szoftver fejlesztő(k) feladata hogy a specifikációt változtassák!
    Mutasd a teljes hozzászólást!
  • Energetikai, tavkozlesi, urkutatasi, vasuti, katonai, banyaszati, stb. giga projektek igy keszulnek es ez igy JO. Nem is lehet ez maskepp.

    Egy közlekedési projekten voltam nem is olyan régen. Eredetileg hozzáálltak vízeséssel, elherdáltak 70% pénzt és időt és az egyetlen materiális dolog ami megmaradt a munkájukból egy gigantikus rendszerterv, ami többször hátráltatott mint használt, mert már rá volt nyomva a pecsét. A kód mind az illeszkedő interfészek, mind az igények tekintetében használhatatlan volt. A mostani se gyönyörű - sőt kifejezetten rezeg a léc, de ahhoz képest, hogy nulláról újra lett dolgozva.... Ha alapból így történnek a dolgok, nem lett volna baj. A legtöbbször úgy érzem a "hagyományos" utak leginkább azért kerülnek csak követésre, mert valamilyen külső kényszer, vagy megszokás bebetonozza a dolgot.

    Amikor pl. a New York-i metro utkozes elkerulo berendezeseit modositani kellett 1,5-2 evet szantak(unk) csak a feladat definialasara es a magas szintu dekompoziciora.

    Egyébként mi pedig a technológiai ismerkedére szántunk közel egy negyedévet / fél évet, mert speciális technológiát használtunk. Viszont gondolom ti sem azzal töltöttétek az időt, hogy a mérföldköveket tologattátok és üzleti igényeket irogattatok, hanem ez a folyamat már technikai munkát takart - még akkor is, ha az nem volt kódolás. Szóval itt a különbséget én nem az optimális hozzáállásokban, hanem abban látom, hogy bizonyos feladatoknál a tervezés nem is tervezés hanem már a konkrét munka. Mellesleg nem is a tervezésről van itt igazán szó (az agilis vs. vízesés vitában), hanem a specifikálásról, ami inkább a követelmények meghatározása. Röviden a kérdésem ezzel kapcsolatban a következő: Mennyi időt töltöttetek a "plan" fázisban azzal, hogy meghatározzátok a rendszernek mit is kell tudnia és mennyit a "hogyan fogja ezt tudni" kérdésével? Tudsz-e három példát mondani olyan követelményre, ami az első 3 hónap után nem volt nyílvánvaló (nem a megvalósulás tekintetében, hanem atekintetben, hogy az egy követelmény!). Természetesen lehet hogy több ilyen is történt, mint azt én gondolom, de az arány érzésem szerint inkább a "hogyan" megtervezése felé megy el az ilyen projekteknél, ahol pedig nem afelé megy el ott ezt nem tudod csinálni. Azt, hogy papíron egy algoritmust bizonyítasz nem kavarnám bele a vízesés fázisai vs. agilis folyamatok vitába, mert ha olyan a feladat, akkor ezt a task-ot mindkét esetben megcsinálod.

    Egyébként én is tudok olyan esetről, amikor az agilitás nem mindig tökéletes: mostanában kutatás-fejlesztési projekteket állítunk össze és egyrészt a pályázat miatt kell előre megmondani mit fogsz csinálni (ez mondjuk nagyon káros!), másrészt viszont ilyen esetekben jellemzően természetszerűleg nincs is sokszor követelmény, igény stb. mert azt éppen most teremted meg, nincs kinek demózni három hetente csak belsőleg stb.  Ezeket persze úgy kezelheted, hogy nem szó szerint veszed a dolgokat, hanem józan paraszti ésszel átgondolva a helyzetet. Például ugyanúgy lehetnek user story megfogalmazások, de egy brainstorming-ból jönnek ki és nem az megrendelő üzleti értéke szerint, hanem más szerint priorizálod őket... az is fontos, hogy a "minden iterációban üzleti érték készül" ilyen esetben tök mást jelent, mert nem feltétlen terméket csinálsz az iterációban, hanem akár tanulsz, prototipizálsz, mérsz. A lightweight szervezési módszerek jó dolgok ilyen közegben is, de persze a csapatnak érteni és érezni kell a dolgokat. Egy ideig azt gondoltam, hogy a scrum master, meg ilyen-olyan coach szerepkörök szinte feleslegesek, hiszen minden nagyon tiszta és intuitív (legalábbis akiket még nem fertőzött meg a vízesésben töltött sok évtized azok szinte azonnal mindent jól csináltak) és persze rájöttem, hogy ez egy kimondottan fontos, ha nem a legfontosabb vezetői tulajdonság kellene legyen. Érdekes hogy sok helyen még mindig inkább kiemelt szerepköröket és "managereket" keresnek ahelyett hogy coach vezesse a csapatokat. Ez szerintem fura.

    Egyebkent oriasi tevedes az gondolni, hogy a vizeses modelben nem lehet visszacstolasok alkalmazni. Meg a PMBOK is benne van Nem vacuum-ban uldogelnek a fejlesztok.

    Egyébként óriási tévedés azt gondolni, hogy az agilis modellben nem lehet tervezést, prototpizálást, mérést alkalmazni. Még a kimondottan agilis oktatási anyagokban is benne van, hogy minden híresztelés ellenére a tervezés és szervezettség az agilitás egy alapvető vonása - bocs a kihagyhatatlan kontra miatt, ami megszüli a rekontrát hogy na de mégis neked az a benyomásod, hogy ez nincs így és a szubkontrát, hogy nekem meg az, hogy a vízesésben is az a benyomásom amit te mondasz nincs úgy.

    Egyébként sokan azért ódzkodnak az agilitástól, mert kicsit attól tartanak, hogy megszűnteti azt a szerepkört, amiben pont ők tevékenykednek. Valószínűsítem, hogy ha megszűnteti, akkor tényleg valami feleslegeset csinálnak ezek az emberek, de még ennél is jobban valószínűsítem, hogy inkább csak a tényleg megfelelő role-ba kerülnek így az emberek.

    HMK-nak:

    A szoftver fejlesztő(k) utasításra, terv szerint azaz specifikáció szerint dolgoznak, ha attól eltérnek az azt jelenti hogy hibáznak.

    Gratulálok, mert ezzel a mondattal szerintem bizonyára megnyerted a nap anti-agilis hőse díjat. Na de viccet félretéve én reménykedek abban, hogy ezt vagy a témával ellenszenves hév mondatta veled, vagy személyes vágy az antiszociális lét felé vezető ösvényen... Ha már nyilvánvaló is hogy a specifikáció helytelen, de azért te megcsinálod, akkor vajon attól az ügyfél/felhasználó/saját cég/főnök/csapat/ki a fene lesz boldog?

    Lizinges példa sántít. Teljesen más eredményt hoz egyetlen kísérleti helyen gyorsítani az ügyintézést, mint cégszinten.....

    Az így kezdődö gondolatmenettel teljesen egyetértek, ez bennem is felmerült. Egyébként mindent túlzásba lehet vinni és az analízis is szükséges folyamat sokszor de a vízesés vs. agilitás változások nem azért álltak be, hogy a tervezést és a követelményelemzést megszűntessék, hanem hogy a visszacsatolás és a tényleges haladás folyamatos legyen, ne lehessen semmibe érő légvárakat építeni kártyavárként... Nyilván mindent lehet rosszul csinálni, de ha eleve nem azt látja valaki rossznak, amiről ezek az irányok szólnak, akkor nem is az irányokat kritizálja, hanem a kivitelezését itt, vagy éppen ott.
    Mutasd a teljes hozzászólást!
  • Alapvetően problémás az egész. Szoftver fejlesztés nem egyenlő projekt megvalósítás. A szoftverfejlesztéssel foglalkozók az ötletgazda (projekt gazda) elképzeléseit valósítják meg, semmi közük a sikerességhez azaz az előadás szerinti piramis két felső szintjéhez. Ezt csak a projekt gazdát érdekli és az ő felelőssége. A szoftver fejlesztő(k) utasításra, terv szerint azaz specifikáció szerint dolgoznak, ha attól eltérnek az azt jelenti hogy hibáznak. Aztán siker, az nem csak azt jelentheti hogy anyagilag megtérül, azaz profitot termel. Ha így gondolkodnánk már rég kipusztult volna az emberiség. Szóval ez a megközelítés a siker definiálására téves. Lizinges példa sántít. Teljesen más eredményt hoz egyetlen kísérleti helyen gyorsítani az ügyintézést, mint cégszinten. Nem magában a gyorsításban van a lehetősége a több ügyfélnek, hanem a gyorsítás tényének reklám erejében. Cégszintű bevezetése esetén annak megismertetése hoz több ügyfelet. Logikus is hisz a kliens azt válassza a piacon ahol előbb megoldják gondját. Szóval csúsztatás, és generált konferencia témát látok...
    Mutasd a teljes hozzászólást!
  • "Jellemzően a vízesésesen tervezett dolgok az alapján amit látok eléggé silányak szoktak lenni"
    Persze nem tudom pontosan mire gondolsz, de hosszutavu, maradando dolgokat ma is 
    a vizeses model alapjan ill. ennek kiterjesztett valtozataival terveznek ma is (V-W stb. abra) Energetikai, tavkozlesi, urkutatasi, vasuti, katonai, banyaszati, stb. giga projektek igy keszulnek es ez igy JO. Nem is lehet ez maskepp. Amikor pl. a New York-i metro utkozes elkerulo berendezeseit modositani kellett 1,5-2 evet szantak(unk) csak a feladat definialasara es a magas szintu dekompoziciora. Ezeknel a projekteknel 80-20-80 szabaly az ervenyes (plan-dev-test) . Amig a hozzaertok fejeben 100-szor nem fut le az uj rendszer viselkedese, addig nem szabad hozzafogni a realizalashoz. Oriasi kockazatokrol van itt szo. Aztan a developing soran mar lehet alkalmazni agilitast, megfelelo ellonerzes mellett.
    Egyebkent oriasi tevedes az gondolni, hogy a vizeses modelben nem lehet visszacstolasok alkalmazni. Meg a PMBOK is benne van Nem vacuum-ban uldogelnek a fejlesztok.
    Mutasd a teljes hozzászólást!
  • Ez a scrumban sok esetben úgy csapódik le, hogy a bonyolultabb storykat a po hátrasorolja mert egész egyszerűen a business fázik attól, hogy átgondolja őket. "Majd foglalkozunk ezzel ha már megoldottuk ezt meg azt" hozzáállás megy, ami ugye azzal jár, hogy szépen közeledik az éles indulás és a legkritikusabb funkcionalitásokról a csapat még azt sem tudja, hogy tulajdonképpen mit kellene csinálnia.

    A másik ami nagyon szokott tetszeni, az az MVP koncepció, ilyenkor általában automatikusan kihajítanak mindent a scope-ból amivel nem akarnak foglalkozni, a végeredmény az meg olyan is lesz, azaz nem lesz jó semmire.
    Mutasd a teljes hozzászólást!
  • Szerintem ez csak a marketingjében lehetett agilis fejlesztés, valójában svindli volt.

    Szerintem nagyon-nagyon sok helyen találkozni azzal, hogy valakik névleg scrum-ot, vagy más agilis módszert használnak, de igazából semmi köze a folyamatoknak az agilitáshoz. Ilyen dolgokkal főleg olyan közegben találkozni, ahol egyébként is mindenki csak vízesés módszerben képes gondolkozni és persze attól, hogy átnevezik a dolgokat, szerepköröket, de ugyanazt az elfuserált hozzáállást követik nem lesz valami agilis - cserébe legalább a terminológiai kavarás miatt káosz tud kialakulni.

    Egy korábbi projekten megpróbáltam pár baráti kollégával elkormányozni a hajót az agilitás felé és akkor az volt a hozzáállásom, hogy "hú ezt vgy azt a folyamatot be se vezessük, mert ezt tuti nem értik / furán fognak nézni és csak azokat a részeit, parciálisan vezessük be, ami nagyon fontos". Így visszatekintve ez a lehető legnagyobb hiba volt! A lightweight módszertanoknak és eszközöknek pont az lenne az egyik nagyon jó hozadéka, hogy mivel nagyon kevés és megengedő szabály van, azokat akár be is lehet tényleg tartani - míg mondjuk egy RUP-ot szerintem soha senki nem tart be pontosan, mivelhogy lehetetlen.

    Ez olyan mintha elmennel egy epitesz ceghez hogy tervezzen neked hazat, megkerdzi hogy embernek, hany szobas, stb? es erre az a valasz hogy majd kesobb kitalaljuk, ha felpult a haz es latom magam elott.

    Ezzel a hasonlattal az a probléma, hogy ha kell akkor én is fel tudok építeni egy házat (de architekturálisan mindenképpen én is átlátom), míg egy szoftverrendszer pár szerencsés kivételtől eltekintve a felhasználó nem tud összehozni. Ez egy nagyon nagy különbség, mert emiatt a felhasználók sok esetben tényleg nem tudják a követelményeiket megfogalmazni. Ismerek egy nagyon régi programot, amit még clipper-ben írt egy orvos - elavult, dos-os és mégis mindenki szívesebben használja, mint bármely más rendszert. Szerintem azért, mert aki ezt a programot írta - sőt! Tovább megyek és azt mondom, hogy lényegében aki a követelményeket gyűjtögette - az értett nem csak a szakterületéhez, de az informatikához is és nem homályos elképzelései voltak, hanem lehetőségeket látott. Látta, hogy a napi munkát hogyan lehet leképezni az informatika eszközeivel. Én azt tapasztalom, hogy ha valakinek nincsen legalább reál-tanulmány a háta mögött, vagy akár egy nagyon régi / korábbi IT háttér, akkor ezt így nem látja és tényleg csak akkor tudja a saját munkáját számítógéppel támogatva jól elképzelni, ha már egy részlegesen kész terméket lát maga előtt.

    Az, hogy le tudja esetleg írni, hogy ő emberileg miben érzi hátráltatottnak magát, ezeket pedig minden drótváz, papír-prototípus és hasonlók nélkül összegyűjtögeted egy nagy könyvbe amit utána 6-10 hónapig elkezdesz lefejleszteni egyáltalán nem garantálja, hogy bármi hasznosat fog csinálni a fejlesztő - akkor sem, ha a legprofibb programozói vannak.

    Szerintem az előadás legfontosabb pontja egyébként az, amikor az érték/bizonytalanság koordinátarendszerben a szerinte optimális haladást mutatja. A nagyon értékes, de problémás az amit előre kell venni, utána minden ami nagyon értékes és aztán lehet az, amit könnyű megcsinálni, de nincs sok hozadéka - ez persze csak optimális bejárásnál van így és ettől szerintem is el lehet térni, de az egész fejlesztési folyamat benyomásának szerintem is ezt kell tükrözni.

    Néha azt érzem, hogy így is túl sokat vagyok olyan közegben, ahol ezekre nem figyelnek és valamiért a CSS passzentolása a preferencia amikor még vannak kötelezően megvalósítandó bizonytalan dolgok is, de annyi a szerencsém, hogy egyébként is sokkal fontosabb másik projekten is vagyok, így igazából már nem is annyira érdekel az egész - ott úgyis csak beugrós vagyok de azért a lelkem néha felsír :D

    Egyébként ha nem minőségi dolgokat csinál valaki, azt én nem kedvelem, de ennek semmi köze az agilitáshoz, vagy nem-agilitáshoz. Jellemzően a vízesésesen tervezett dolgok az alapján amit látok eléggé silányak szoktak lenni, mert olyan dolgokkal töltenek az emberek időt, ami a projekt eredményének minőségét alig befolyásolja - míg azokkal amik pedig tényleg befolyásolják kapkodás-szerűen foglalkoznak. Ha nagy tervekbe van foglalva minden, annak az a hátránya, hogy a leghosszabb tervezés mellett is egy szintre szokott kerülni egy input mezők nem azonosos szélességei és a kommunikációs protokoll kialakítása - ha pedig a szerződés is bejátszik a tervekre vonatkoztatva az sokszor katasztrófa, mert az egész elmegy húzd-meg, ereszd-meg játékba hogy a projekt el legyen fogadva akkor is, ha ratyi az egész. Ez a véleményem.
    Mutasd a teljes hozzászólást!
  • Az biztos, hogy a régi projekt alapú modellben borzasztó nagy hiba, hogy az ügyfél még nem tudja, hogy mit szeretne, mert neki üzleti problémája van

    Ezt sokan mondogatjak a scrum melleti ervkent, regebben meg en is elhittem. A valosag pedig azt mutatja hogy az a megrendelo aki nem erti a sajat uzleti problemajat, scrummal sem erti. A legtobb kerdesre az a valsz hogy "halasszuk el a valaszt", az eldontendo kerdesekbol meg  akkora fejvakarasok szoktak lenni hogy heteket kell varni mire azt mondja az ugyfel hogy "hat nem tudom, nem lehet ezt elhalasztani?".

    Ez olyan mintha elmennel egy epitesz ceghez hogy tervezzen neked hazat, megkerdzi hogy embernek, hany szobas, stb? es erre az a valasz hogy majd kesobb kitalaljuk, ha felpult a haz es latom magam elott.

    Az en tapasztalataim szerint amikor a megrendelo nem erti a sajat problemajat azon nem segit semmi, halalra van itelve az egesz.

    A gyakori bemutatok, abban tudnak segiteni hogy gyorsabban kideruljon, ha a fejlesztok nem jol ertik a feladatot. Ehez persze nem kell scrum.
    Mutasd a teljes hozzászólást!
  • Szerintem a projektek 99%-a nem sikeres, és nem hasznos.
    A piramis felső két pontjában nem értek egyet. (legalábbis a videóban elhangzott magyarázattal)

    Pont az a baj, hogy ha már rövid távon sem akarnak anyagilag"sikertelenek" lenni, akkor inkább egy igénytelen megoldást adnak át a projekt végén a budget miatt.
    Szerintem egy igazán sikeres, és hasznos szoftver akkor alakul ki, amikor nem az anyagiak az elsődlegesek, és az anyagi siker != a sikeresség definíciójával. 
    A videóban már a hasznos vizsgálatnál is  az anyagiakat belekeverte (mennyire lehet eladni) az előadó.
    Mutasd a teljes hozzászólást!
  • Az biztos, hogy a régi projekt alapú modellben borzasztó nagy hiba, hogy az ügyfél még nem tudja, hogy mit szeretne, mert neki üzleti problémája van. Ez alapján leraknak neki egy tervet, amit ő megrendel aztán 1 év múlva leszállítják neki azt az izét, ami "használhatatlan".
    Az, hogy mennyire lett használható az eredmény csak azon múlik, hogy a fejlesztők és porjektmanagerek mennyire tudták a valódi feladatot megtalálni/megoldani a specifikáció alapján. Az agilis megközelítés szerintem létezett a projektes megközelítésben is csak nem volt formális.

    Ha egy cég folyamatosan el tud adni rossz fejlesztést is jó pénzért, akkor tényleg nincs szüksége a minőségre. A minőség a visszatérő vevőhöz kell. Ha jó a marketing, vagy komoly a kapcsolati tőke, akkor még a mockupot is lehet adni termékként. A kérdés inkább az, hogy akkor minek szórakoznak  egyáltalán a fejlesztéssel.
    Mutasd a teljes hozzászólást!
  • "Az agilis módszertan nem a tervezés eltörléséről szól. "

    Hat pedig a tapasztalat azt mutatja, hogy EZ az egyik legnagyobb gyengesege a agilis fejlesztesnek. 
    Vannak buvos kifejezesek pl.: TimeBox, ugye mindent timebox-olni kell mert az ido penz. OK. Hogy zajlik altalaban a turnover:
    Demo:2-5 ora, Retro: 2 ora, PO plain 2ora, Tasking by group 2-4 ora

    Vagyis ahogy a PO megallmodta az AC-t es amit Tasking alatt a csapat ebbol megert es taszkosit annyira lesz jo a tervezes.Masnapra atvinni mar nem, lehet (max kick-off-olni lehet majd draga SP-kert)  
    Ek alakban megy a fejlesztes. Majd refaktoralunk system test elott" -> kulonben is a korai optimaizalas nagyon kerulendo, ordogtol valo dolog. ??

    Es ezek ellen nem ved sem unit test, sem auto test, sem func test, mert ezek csak validalnak es nem verifikalnak.

    Line fonokkent , en mindig kevertettem egy kicsit (SM-kel) az agilitast es linearis fejlesztest. Minde sprint legyen olyan mint egy sulyzo !

    Tovabbra is allitom, hogy ezek a modern fejleszesi metodikak, NEM a minosegre gyurnak, hanem funkcionalitasra, a ketto kozott oriasi a kulonbseg.
    Mutasd a teljes hozzászólást!
  • Amúgy persze igazad van, az agilitás nem azt jelenti, hogy nem tervezünk semmit - a probléma az, hogy viszont az egész agile approach marha jó arra, hogy mindenféle trógerséget be lehessen dugdosni mögé, azzal a felkiáltással, hogy ez most prioirty low, megoldjuk később.
    A story pont alapú estimation detto, jellemzően a business abszolút nem érti, hogy ezt most így hogy, ergo ha egy szimpla checkbox felhelyezést bemondasz 21 sp-re, nem fogják látni, hogy hoppá itt valami el van ****va.

    Az ominózus projekt is zömmel ezért omlott össze, a végén egy-két eszementen kívül senki nem végzett igazi munkát, csak a szart kenegették.
    Meg is lett az eredménye.
    Mutasd a teljes hozzászólást!
  • Hát elvileg elég nagy erőforrást toltak bele, automatizált tesztek, ATDD stb. Az acceptance criteriakat a rendszernek általában persze nem sikerült megütnie, ezt a scrum teamek jellemzően úgy reagálták le, hogy nyitogattak rá spike-okat, hogy ki kéne deríteni miért nem, aztán a vége mindig az lett, hogy a probléma most nem akut, fixáljuk egy későbbi releaseben.

    A product ownerek persze semmit nem értettek az IThoz, és kritika nélkül benyaltak mindent, amit a team mondott.
    Mutasd a teljes hozzászólást!
  • en nem indulnek a holdra egy olyan raketan, amit Agilisan fejlesztettek es teszteltek !

    Több ezer éves, s a célnak megfelel....
    Mutasd a teljes hozzászólást!
  • Akkor te most pont azt mondod, hogy volt egy agilis hívő cég, amelyiknek nem sikerült elsajátítani az első óra anyagát sem.
    Nem az agilis módszertannal volt a baj, hanem szimplán a nem tervezéssel.
    Az agilis módszertan nem a tervezés eltörléséről szól. 
    Mellesleg gyanús, hogy teszteket sem nagyon futtattak a kollégák.
    Szerintem ez csak a marketingjében lehetett agilis fejlesztés, valójában svindli volt.
    Mutasd a teljes hozzászólást!
  • Hehe, a legkatasztrofálisabb projekt amiben valaha részt vettem, egy scrum meló volt egy igazi scrum hívő cégnél... annyira agilisak voltak a szerencsétlenek, hogy egész egyszerűen megfeledkeztek az architektúra normális megtervezéséről illetve a non-functional requirementekről, majd foglalkozunk vele ha gond lesz alapon.

    Na ennek az lett a következménye, hogy a keresőben a legszimplább queryk is timeouttal elszálltak, egy külsős tanácsadó cég kimérte, hogy egy tök szimpla keresés is valami 100k Oracle hívást generált... nekiálltak refaktorálni, de annyira el volt már ****va minden, hogy nem értek el semmit vele, fél év múlva a projektet a cég lehúzta a retyón. (Szerencsére már nem voltam ott)
    Pedig előtte elment rá pár millió chf...
    Mutasd a teljes hozzászólást!
  • Fejlesztenek, a marsjaro projekt - a NASA-hoz kepest - agilisen tortenik. A MCO / MPL balesetek nem a projekt stabilitasa mellett tanuskodnak, de allitolag a Curiosity-t a modszertannak koszonhetoen annyival olcsobban sikerre tudtak vinni, hogy mindennel egyutt sikeresnek itelik az agilis megkozelitest.
    Mutasd a teljes hozzászólást!
  • Egy biztos, en nem indulnek a holdra egy olyan raketan, amit Agilisan fejlesztettek es teszteltek !

    A nasanal is hasznaljak az agilis modszertant, arrol nem lattam infot hogy reketat is fejlesztenek-e igy :)
    Mutasd a teljes hozzászólást!
  • !0 eve foglalkozom agilis fejlesztessel (is). Abszolut nem csodadolog. Sot...
    Egyetelen celja, hogy periodikusan "erteket" szallitson a megrendelonek, aki nem
    a minoseg miatt aggodik foleg, hanem a penze(ido) miatt ,amit porgetni akar.
    Az agalis teszteles meg egy kulon tudomany es NINCS jo megoldas.
    Persze tudom,  agilisan kell tesztelni is, es ebbol bizonyos emberkek oriasit kaszalnak,
    mert konyveket irnak, eloadast tartanak rola, amik semmire sem hasznalhatoak.
    Dokumentacio persze nincs, fejben megy minden, doksi  max a AC es CODE.
    A code minoseget az SA felugyeli es az o szerepe kulcs egy projectben.
    Aztan, ha minoseget is akarunk akkor atmegy minden vizesesbe es akkor (jobb esetben)
    megy a refaktor ki tudja, mennyi story pontert.

    Az ido, eroforras, minoseg ugye bejon a funkcionalitas, aztan a PO vagy tudja tartani a hatat es kiall 
    a csapatert vagy atmegy minden Kanba-ba es dol minden.

    Egyszoval kisse idegbeteg metodika egy idegbeteg korban.... es ehhez tulajdonkeppen meg a legjobb, placebo.

    Egy biztos, en nem indulnek a holdra egy olyan raketan, amit Agilisan fejlesztettek es teszteltek !
    Mutasd a teljes hozzászólást!
  • Ütöttem, vágtam, fából vaskarikát csináltam: a lényeg hogy MEGY. :)

    Az agilis fejlesztesi modszer alkalmazasa a gyakorlatban pont ilyen :D
    Foleg amikor a szigoru szabalyokat betartva, egyik nap a grafikus irja meg a memoria allokator lib-et. A kereszt funkcionalitas a legfontosabb a tobbi legfontosabb kozott.
    Mutasd a teljes hozzászólást!
  • Ez amit elmondott nem a modern szofterfejlesztesrol szol, hanem a kozepszeru atlagos szoftverfejlesztesrol.

    Ha jol ertettem azt az elvet koveti hogy o tudja "a megfelelo" modszertant, aminek a szabalyait szigoruan kovetni kell es elerjuk a maximum teljesitmenyt. 

    Kivancsi vagyok milyen kornyezetben van benne a szigoruan 3-6 emberes csapatban, az az ember is aki a fejlesztes maslow piramisanak felso 3 reszet tudja tesztelni. Ezt persze ugy hogy a csapat keresztunkcionalis egy adott ember egyik nap frontend masik nap, backend vagy sysadmin vagy devops, vagy ux design, vagy grafikai design feladatokat lat el.

    Mi van azokkal a helyekkel ahol kulso megrendelo van, es a fejlesztesi projekt veget er mielott a felso harom reszt tesztelni lehetne?

    Az kulon erdekessek hogy az agile coaching celja az hogy mindent eroltessunk bele ugyan abba a semaba, a life / business / executive coaching celja pedig ezzel ellentetben az hogy az ugyfel jelenlegi erossegeire epitve segitsunk tovabb lepni, teljesen szemelyre szabott modon.

    A masik komikus dolog amikor hipotezis teszteleskent emlegeti azt amikor egy ceg, egy akalommal, egy kis csapata, kis ideig csinal valamit, kis szegmensben es ez alapjan kovetkeztetest vonnak le.

    Az agilis modszertan valoszinuleg tenyleg jo a programozasi szalagmunkaknal, bizonyos korulmenyek kozott. A tobbinek nem kene azt tancsolni hogy csukott szemmel kovessenek egy modszertant, ami nem feltetlenul jo nekik.
    Mutasd a teljes hozzászólást!
  • nagyon jó előadás, hasznos, köszönöm!
    Mutasd a teljes hozzászólást!
  • És akkor hová lesz az orosz módszer?
    Ütöttem, vágtam, fából vaskarikát csináltam: a lényeg hogy MEGY. :)
    Mutasd a teljes hozzászólást!
  • Ha ez lenne az egyetlen videó, amit a prog.hu nélkül sose találtam volna meg, már akkor is 1000 hála és köszönet érte.
    Zseniális előadás, zseniális előadó.
    Ha tudtok olyan céget, ahol így mennek a dolgok, akkor osszátok meg velem.
    Csak ilyen helyre szeretnék menni dolgozni :)
    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