Egy tanulmány szerint az agilis szoftverprojektek 268%-kal nagyobb eséllyel buknak el

Programozás

Egy tanulmány kimutatta, hogy az Agilis gyakorlatokat alkalmazó projektek 268 százalékkal nagyobb valószínűséggel buknak el, mint azok, amelyek nem. [...] A tanulmány alapját képező kutatást május 3. és május 7. között végezték 600 szoftvermérnök részvételével (250 az Egyesült Királyságban és 350 az Egyesült Államokban). Az egyik főbb megállapítás az, hogy azok a projektek, amelyeknél a fejlesztés megkezdése előtt világos követelményeket dokumentáltak, 97 százalékkal nagyobb valószínűséggel voltak sikeresek.

Részletek itt.

( zdesigner | 2024. 06. 05., sze – 17:17 )

Ez így első olvasatra erősen brit tudósok megállapításának hangzik. Brit tudósok megállapították, hogy mindent el lehet baszni (kivéve a Nokia 3310-et), csak elég sok kókler kell hozzá. Brit tudósok megállapították, hogy 4 napnyi kutatás eredményéből bármilyen hülyeség kijöhet.

Nem értem, mit háborogsz. A brit tudósok agilisen álltak hozzá a projekthez és saját kutatásukon mutatták be, hogy az abban megfogalmazott állítás helyes.

Egyébként az agyalágyult cím miatt elsőre alaposan el kellett gondolkodnom az állítás mibenlétén, mert azt hittem, hogy 268% a bukás valószínűsége. Ha jól tudom, ilyesmi a világ egyetlen helyén létezett, a BME Villamosmérnöki Karán, ahol lehetett negatív osztályzatot kapni.

Science for fun...

( duffy v | 2024. 06. 05., sze – 17:23 )

Mert ha még wc-re is agilisan megyünk, akkor előbb utóbb beszarunk....

Az látszik ezen az eredményen (függetlenül a megbízhatóságától), hogy az agilist valamiféle csodaszernek tekintette a sok menáger. Gurított egy jó nagyot pár satrtup (pl Spotify), erre uccu neki! Minden méretben, pl globális multi méretben is nekifut az agilis transzformációnak. 

Nálunk az volt, hogy akkor a cég ez meg ez a része holnaptól agilis szervezetben és módszertannal működik. A bukás kizárt, nem megengedett. Az eredmény?

A. A projekt nem megbukott, csak másra lesz jó

B. Hát, ez halad, de az agilitás kompromisszumos.

Egyszerű gomb és kabát esete. Látni kell, hogy a sikeres agilis működésnek vannak külső feltételei is. Ha azok hiányoznak épp úgy bukik a műsor, mintha a "mindset" nem megfelelő...

( gelei v | 2024. 06. 05., sze – 17:34 )

Szerkesztve: 2024. 06. 05., sze – 17:35

Nincs olyan, hogy "az agilis" modszertan. Van mindenfele implementacio, amit tobb-kevesebb sikerrel probalnak tobbe-kevesbe jo szakemberek alkalmazni ilyen-olyan kornyezetben. Igen, amikor a Spotify-modellt probalja magara huzni egy ultrakonzervativ F500 ceg, az tud vicces pillanatokat okozni minden erintettnek.

Azt sem mondja semmi, hogy "az agilis" modszertannal ne lehetne elore specifikalni kovetelmenyeket. Olyan ajanlasok vannak csak a manifestoban, hogy ha mar valtozas van, akkor ne a tobb evvel korabban megirt specifikaciora mutogassunk, hanem reagaljon a fejlesztocsapat a megvaltozott igenyekre, vagy hogy ticketbasztatas helyett/mellett neha ulj le beszelegtni a megrendelovel, hogy megis mit akar latni.

Hadd tippeljek, aki ezt a kutatast csinalta, az veletlenul nem arul valamilyen projektmenedzsment toolt vagy tanacsadast is?

A követelmények megfelelő specifikálása az éppen a mérnöki szakma csúcsa.

Jól specifikált követelményeket már bármelyik majom tud implementálni.

Az agile lehet hogy részben épp azért terjed, mert hiányoznak azok a tapasztalt szakemberek, akik tudnak specifikálni. De a PM meg elvárja, hogy "haladjon" a projekt. Ezért inkább csinálnak valamit, majd iterálnak. Előbb-utóbb csak jó lesz :)

Amikor 3 évnyi "from scratch" fejlesztés után - amit azért indítottak mert az előző "elejétől el volt baszva más által, azt javítani nem lehet" - azt hallod, hogy "ez architekturálisan el lett baszva, 0-ról újra kéne kezdeni" ...

Újabb 5 évet nyerve .... 😭😭😆😆😄😄🤭😊😁

trey @ gépház

Kérdés, hogy jutnak el ide, amikor prototype-ok vannak és demo-zva a dolgok folyamatosan stakeholdereknek. A waterfallnál inkább érthető miért történik ez meg, mert lespecifikálják, majd még jobban lespecifikálják, megépítik, majd tesztelik, és átadják, és akkor acceptence teszteli a a megrendelő és rájön, hogy vagy nem így akarta, vagy vagy valamit nem látott előre, vagy ha igen is, közben elteltek évek és már ez így nem ok ezért vagy azért.

Az agile elvileg pont arról szól, hogy nagyok korán jöjjenek a visszajelzések, hamar lehessen változtatni, ha valami nem jó irányba megy, nem miután belement már rengeteg erőforrás. És akkor lehet megint számlázni a change requestekért. Az egész motivációja az agile-nak pont az volt, hogy a waterfallnál túl későn derült ki, hogy gond van, miután rengeteg költség belement.

Viccesen mondva, a teljesen waterfall projekt az első change request után agilis lesz :D Amit én tapasztaltam az, hogy igazából mindegyik máshogy rossz. Az utolsó szögig lespecifikáljuk történet tényleg ott szokott elhasalni, amikor a megrendelő benyögi, hogy hát ő nem erre gondolt. Az agilis meg ott szokott elhasalni hogy az elemzés és a tervezés teljes hiánya miatt lokális maximumra fognak törekedni, és a nap végén a rendszer nem fog logikailag összeállni, mert csak ész nélkül csinálják amit a megrendelő mond és sajnos nincs "architektúra" (üzleti, solution, stb.) ami keretbe fogná a fejlesztést. Nem kidolgozott, végiggondolt, sokszor egymásnak ellentmondó követelményeket próbálnak megvalósítani (pláne ha nem csak egy csapat dolgozik) ami egy kiváló recept az idegállapotba kerülésre.

Amit én eddig jól láttam működni, az a 4-6 iterációval előrébb tartó elemzés és 2-3 iterációval előrébb járó tervezés alapján történő fejlesztés. Igy az üzleti részek is normálisan végig vannak gondolva, viszont lehetőség van viszonylag gyorsan váltani ha megváltoznak a prioritások.

Amit én eddig jól láttam működni, az a 4-6 iterációval előrébb tartó elemzés és 2-3 iterációval előrébb járó tervezés alapján történő fejlesztés. Igy az üzleti részek is normálisan végig vannak gondolva, viszont lehetőség van viszonylag gyorsan váltani ha megváltoznak a prioritások.

Na... ezt lopom.... ezt probalom mar regota tolni a  meglevo projektekbe, de nehez a stakeholdereket arra ravenni, hogy ennyire elore gondolkodjanak.

Amit nalunk latunk az az, hogy a business kitalalja, hogy mit akarnak most es akkor ugye azt bele tudjuk majd venni a kovetkezo sprint-be?
(Persze ugy, hogy a frontend, integration, backend es a hozza kapcsolodo adatbazis(ok)-at mind erinti a valtozas/feature es mind kulon csapat :)

Support Slackware: https://paypal.me/volkerdi

Ezért mondom hogy az üzleti elemzést illetve a tervezést el kell végezni, hogy ezt egy személy egyedül vagy pedig egy csoport közösen végzi, illetve hogy van-e erre külön szerepkör (BA, SA) vagy egy fejlesztő/PO/akárki viszi el, az igazából lényegtelen.

Érdemes a business munkáját megtámogatni irányított közös munkával, tervezéssel, fogalmi modellezéssel, folyamat modellezéssel és más egyéb technikákkal, és akkor ők is jobban bevonódnak. Ennek ugyanúgy van módszertana, folyamata, ki van találva már egy ideje, egyszerűen csak alkalmazni kell. Hamarosan megjelenik a második magyar nyelvű üzleti elemzéssel foglalkozó könyv is, szóval a nyelv sem lehet akadály. (A jól hangolt business analyst könyvet pedig különösen javaslom olvasásra.)

nehez a stakeholdereket arra ravenni, hogy ennyire elore gondolkodjanak

+1

Es ugye akkor arrol szol a "kutatas", hogy ugyanezeket az embereket kellene ravenni arra, hogy ne 2 honapra tervezzenek elore, hanem 2 evre, mert akkor varazslatosan haromezer szazalekkal csokkenne a sikertelen projektek aranya, hagyjuk mar.

Az agilis meg ott szokott elhasalni hogy az elemzés és a tervezés teljes hiánya miatt lokális maximumra fognak törekedni, és a nap végén a rendszer nem fog logikailag összeállni, mert csak ész nélkül csinálják amit a megrendelő mond és sajnos nincs "architektúra" (üzleti, solution, stb.) ami keretbe fogná a fejlesztést.

principle 8 erről (is) szól.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Az agilis meg ott szokott elhasalni hogy az elemzés és a tervezés teljes hiánya miatt lokális maximumra fognak törekedni

Igazabol ez nem is az agilis fejlesztes hozadeka, hanem azoknak a felresikerult absztrakcios retegeknek, amit mindenfele "agilis modszertan" cimen a felbolond kuruzslok implementalnak.

Az agile sehol nem irja, hogy tilos elore gondolkodni. Az ajanlas csak annyi, hogy ennek a gondolkodasnak a vegtermeke ne egy immutable valami legyen, hanem kovesse a valos igenyeket. En nem tudom, ki milyen teruleten dolgozik, de olyat meg nem lattam, hogy 2-3 evre meg lehetne tervezni valamit az utolso bitre lebontva, hogy azt ne verje telibe egy ceges strategiavaltas, jogszabalyi kornyezet valtozasa, versenytarsak tevekenysege, a piac valtozasa, vagy akarmi.

Amit én eddig jól láttam működni, az a 4-6 iterációval előrébb tartó elemzés és 2-3 iterációval előrébb járó tervezés alapján történő fejlesztés. Igy az üzleti részek is normálisan végig vannak gondolva, viszont lehetőség van viszonylag gyorsan váltani ha megváltoznak a prioritások.

+1

És pont ez az egyik érv szintén az agile mellett, hogy az az erőforrás, ami bele van téve ebben a külön létrehozott szuper cizellált, díszes specifikáció építménybe(ami lényegében egy nyelven történik), ez a teljes kirészletezés legyen elvégezve egy másik nyelven a kód szintjén. Ami nem azt jelenti, hogy nincs specifikáció, csak nem ezen az előre megépített módon.

De amúgy innen nézve érdekes lesz a GenAI történet, mert ez a kettő lehet közelebb kerül egymáshoz. És lehet ha megépül a specifikáció katedrális, akkor megépül a kód is, mert a GenAI fordítja és tesztekkel lesz védve a specifikáció.

A követlemény specifikálás nekem is kiütötte a szememet. Nekem is úgy tűnik, hogy nem csinálni kell a valamit, nem úgy "agilis", hogy össze-vissza kókányolnak és csináljanak úgy, mintha dolgoznának. Hanem az oda vezető úton lehet úgy választani a lépéseket, hogy az a körülményektől függően előrébb vigyen. Minden ciklusban visszatekintés, tervezés, becslés és döntéshozás. Az egész lényege, hogy kommunikáljanak szervezett formában és ne a véletlenen múljon az, hogy valami fontos kiderül-e.

( prion | 2024. 06. 05., sze – 17:54 )

Fura ez a cikk. Amiket említ konkrét dolgokat azok inkább a rosszul csinált agile-ból jönnek és nem magából az agile-ból.

pl "One Agile developer criticized the daily stand-up element, describing it to The Register as "a feast of regurgitation."

Én is láttam rossz standupokat. De láttam jót is. Szóval lehet ezt jól is és rosszul is csinálni. Most pl tök fontosnak tartom a stand-up-ot abban, hogy tudjuk szállítani, ami commited a sprint alatt és ne legyenek elakadások, később jövünk rá, hogy nem halad valami. Meg online munkában szerintem nagyon fontos szerepe van, hogy a csapat ismerje egymást, felépüljön bizalom, meg az a légkör, ahol lehet kérdezni, megkérdőjelezni stb.

Eleve szerintem agile mellett nagyon nagyon fontos az egész céges kultúra ami a munka körül felépül. Ha az emberek telibeszarják és nem akarnak dolgozni, akkor itt nagyobb gond lehet, mert a klasszikus parancsok és a végrehajtás keresztülverése helyett jóval nagyobb súly van a csapat szereplőin.

Ezt a specifikáció nélküliséget sem értem. Vannak olyan agile projektek ahol specifikáció nélkül kezdenek el építeni valamit? Ami jót én láttam ott ugyanúgy specifikálva van minden. Csak nem az történik, hogy hamarabb van felépítve ez teljes egészében az utolsó szögig, minthogy bármi történne. A tesztelés is ugyanúgy van. Nehéz mit kezdeni a cikkel.

utolsó bekezdésre: lehet olyan startupra gondolnak, ami azért jött létre, hogy elkezdjen valami hűdeizgi dolgot csinálni, és abban bíznak, hogy azelőtt felvásárolja őket egy nagy cég, mielőtt még kiborul a bili, hogy semmi sem működik és nem megy... addig meg elfoglaltnak és pörgésnek kell látszódni, legyen mivel szédítani a befektetőket.

Nem vagyok befektető, de ha egy cég csak az ötlet szintjén leledzik, akkor annak az ötletnek veszett jónak kell lennie, hogy fizessek érte. Persze, ha nagy cég vagyok, akkor lehet, hogy megéri 1-2 évig finanszírozni a startupot, hogy lássa, mi sül ki belőle - és ha bukik, el lehet engedni anélkül, hogy az egész piac rajtam röhögjön.

( bazso | 2024. 06. 05., sze – 20:00 )

Fail fast. Agilis esetben természetes a bukás, bele van számolva, a tanulás része, és ha jól csinálják, akkor kicsik, relatíve fájdalommentesek, nem úgy, mint waterfall esetén 5 év után szembesülni ugyanezzel. Ez kb. olyan, mint hogy a Tesla a visszahívások száma szerint messze a legrosszabb az összes gyártó közül. Csak ezt a felhasználók nem veszik észre, mert ezek távoli szoftver frissítések...

( kruska v | 2024. 06. 05., sze – 21:01 )

Nagyobb SAP upgrade projekteknél is bepróbálkoznak az ügyfelek, hogy ne töltsünk el heteket tervezéssel / teszteléssel, hanem "agilis" módon csináljuk, magyarul ész nélkül durr bele a közepébe. Ilyenkor átadjuk nekik az irányítást, majd amikor már néhányszor álltak a szőnyeg szélén egy rosszul elsült állásidő miatt, akkor visszatérünk a "tervezős" üzemmódba.

( Oregon | 2024. 06. 05., sze – 21:08 )

Mindig kiderül, hogy más mímelni valamit, mint tudni. Nahát.

( n.balazs v | 2024. 06. 05., sze – 21:20 )

Agilis fejlesztés = gyors szállítás = gyors piacra lépés = gyors profit

Ez él a menedzserek fejében. Minő meglepő, hogy a szükséges lépések kihagyása bukást okoz. (irónia gy. k.)

( Elbandi v | 2024. 06. 05., sze – 21:28 )

es ha meg ezt ho-ban teszik akkor foleg!!! :D

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

( golgota | 2024. 06. 06., cs – 07:04 )

de ha' aze' bukik meg mer' a libsik tal'ta'k ki hogy homokozzanak!!!!!!! Mindenki tudhassa....igazi feher kereszteny hetero mernok nem nyul hozzaja!!!! :D

( PDA_FAN | 2024. 06. 06., cs – 10:10 )

Sok-sok éve jött hozzánk egy szakértő, aki több napos fejtágítót tartott az agilis módszertanról. Mikor a módszertan határairól kérdeztük, akkor világosan elmagyarázta, hogy ez elsősorban olyan "zöldmezős" beruházásokhoz alkalmas, ahol világos és egyszerű célkitűzések vannak, jól szakaszolható a fejlesztés, és a fejlesztés keretei is adottak. Nincs vita, hogy honnan hová kell eljutni. Nincs vita, hogy valamilyen meglévő rendszer vajon hogyan működik, és vajon hogyan kellene átalakítani ahhoz, hogy az új elképzeléseknek megfeleljen.

Elmondta továbbá, hogy ehhez a fejlesztésben érintett összes szervezetnek agilis módon kell működnie. Nincs olyan, hogy két hónapig kell várni egy jogi állásfoglalásra, vagy egy vezetői döntésre.

Fentiek alapján a mindenre ész nélkül agilis módszertant ráhúzni kívánó projektek emiatt előbb-utóbb úgy járnak, mint az egyszeri ember a kalapáccsal a kezében, aki mindent szögnek néz. Oda lehet b@szni a kalapáccsal, de ha ott nem szög van, akkor lehet, hogy fájni fog.

Mikor a módszertan határairól kérdeztük, akkor világosan elmagyarázta, hogy ez elsősorban olyan "zöldmezős" beruházásokhoz alkalmas, ahol világos és egyszerű célkitűzések vannak, jól szakaszolható a fejlesztés, és a fejlesztés keretei is adottak. Nincs vita, hogy honnan hová kell eljutni. Nincs vita, hogy valamilyen meglévő rendszer vajon hogyan működik, és vajon hogyan kellene átalakítani ahhoz, hogy az új elképzeléseknek megfeleljen.

Ez kb. pont az ellenkezője a valóságnak.

Ha megnézed a Cynefin modelt, vagy a Stacy modelt, mind a kettőben van egyszerű/egyértelmű (simple/obvious), összetett (complicated), komplex és kaotikus/anarhia terület.

Az egyszerű területen sokszor nincs szükség semmiféle szervezésre, mert hiszen egyszerű.

Az összetett terület az, ahol világos célkitűzések vannak, jól ismert, hogy mit akarunk elkészíteni és tudjuk azt, hogy hogyan kell a munkát elvégezni. Nincs vita, hogy hova akarunk eljutni. Ezen a területen jól működik a tradícionális (waterfall) projekt irányítás, feltéve, hogy menet közben nem történnek váratlan dolgok. Az Agile megközelítés is működik, de ha nincs szükség a váratlan dolgok kezelésére, akkor jellemzően nem éri meg az Agile extra overheadje.

A komplex terület az, ahol a múltban a tradícionális projekt irányítás rendszeresen felsűlt. Ez az a terület, ahol az Agile jól működik, többek között úgy, hogy a nagy és komplex dolgot felszabdalja kisebb részekre, amik már az összetett részre át tudnak így kerülni, és ott már sikeresen el lehet ezeket készíteni (és persze a végén a részekből összeáll az egész). Másfelől, amikor változnak a dolgok (ahogy az a dolgok természete), ezt az Agile megközelítés könnyen le tudja kezelni.

A kaotikusnak vagy anarchiának hívott terület az, ahol nem lehet nekilátni a fejlesztésnek/gyártásnak, mert nagyon kevés dolog tiszta. Ezen a területen is jól működik az Agile megközelítés, de nem úgy, hogy nosza, álljunk neki és készítsünk el a végterméket, hanem úgy, hogy iterálva teszteljük a világot. Ötlet - teszt - visszajelzés - tanulás. Elkészítünk valamit, és körbekérdezünk, hogy ilyesmire gondoltatok-e. Ez működhet-e. És közben tanulunk a technológiáról, a környezetről. Ha elég sokmindent kiderítettünk, akkor egyszer csak már nem a kaotikus területen leszünk, hanem pl. a komplexben. Ekkor kezdődhet annak a valaminek a kifejlesztése, amiről már tudunk egy keveset.

+1: ha a zöldmezős azt jelenti, hogy 0-ról kifejelszetünk valami újat, akkor ez egyáltalán nem követelmény, sőt, nagyon jellemző az, hogy egy Agile csapat egy már létező (mindegy, hogy Agile vagy Waterfall módon készült) dolognak a továbbfejlesztésén vagy BAU üzemeltetésén dolgozik.

Fentiek alapján a mindenre ész nélkül agilis módszertant ráhúzni kívánó projektek emiatt előbb-utóbb úgy járnak, mint az egyszeri ember a kalapáccsal a kezében, aki mindent szögnek néz.

Ez így van, mindig a feladathoz kell választani az eszközt.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

( popacsek | 2024. 06. 06., cs – 11:19 )

Szerkesztve: 2024. 06. 06., cs – 11:21

Rájöttek, hogy ha nem tudod honnan indulsz, és hova akarsz eljutni, akkor abból céltalan bolyongás lesz. Ez drága kutatás nélkül is eléggé nyilvánvaló.

( Chain-Q v | 2024. 06. 06., cs – 12:37 )

Szerkesztve: 2024. 06. 06., cs – 12:37

Az agilis fejlesztésekkel nincs feltétlenül baj, de csak akkor működik, ha minden résztvevő érti és részt vesz benne. Ha meg nem, akkor a legjobb hagyni, mert a két világ találkozásánál kialakuló kultúrclash megöli az egészet. Emiatt van az, hogy amit agilisnak hívnak, az többnyire nem az, hanem valami más. Leginkább ez.

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Az agilis szoftverfejlesztés sose volt "módszertan". Csak azzá tették. Eredetileg egy 4 pontból álló elv-gyűjtemény volt. Ami pont szembe megy a hagyományos "módszertanok" elméletével, de azt nem lehetett corporate-nek eladni, nyilván, meg tanúsítványokat gyártani róla... Ez utóbbi kalap szar, valóban, de nincs is sok köze az eredeti 4 ponthoz a gyakorlatban. :)

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

trey a sajat kis vilagharol beszel, nehez abbol a buborekbol kineznik. Abban a buborekben nincs felho, mert szar, nincs bigdata mert szar, nincs fejlesztes mert szar, nincs agile mert szar, a kozszolgalati egytetem jobb mint a Harvard, de rengeteg homokos libsi gyikember akarja megeroszakolni a nagymamakat. a szerencse, hogy a hos oroszorszag mar elkezdte az agresszoktol megmenteni a vilagat :D

Na az a 10% az a repedes a buborekjan, de hamarosan a hos szovjet hadsereg majd azokat is elintezi :D

Ja es altalaban csak o tud igazi szakmai valaszokat adni meg a nem szakmai kerdesekre is :D (ebbe nem tartozik bele szinte semmi sem a vmware-en kivul, plane nem a nem letezo felho, bigdata, ai, agile, stb :D)

Hát még, ha tudnád, hogy én min röhögök e topikkal kapcsolatban. Akkor mekkora vidámság lenne az arcodon :D Azt hiszem, hogy nem nekem kell kínos magyarázkodásokba kezdenem hamarosan 🤷‍♂️

BTW: hogy is szól a HUP-száj mondása? Nem kell ahhoz szart enni, hogy megállapítsam róla, hogy az nem finom :D

trey @ gépház

szégyellenünk kellene magunkat azért a szoftverekért

Nem tudom, hogy hallottál-e már erről vagy még nem, de egyébként Agile megközelítést nem csak szoftverfejlesztésben használnak.

Pl. az előző munkahelyemen egy autó márka újragondolásán dolgozott a csapat, és agilis módon pl. logót terveztek, bemutatóteremnek telket vásároltak, építkeztek, berendeztek + autót fejlesztettek.

Az azt megelőző munkahelyemen meg már létező telephelyeken (pl. tengeri olajfúró torony, olajfinomító, vagy csővezeték-tartály-tartályhajó átfejtő terminál) új igényeket építő csapatok dolgoztak agilisan. A sprint review meetingen pl. a sprint során megépített új csőről vagy pumpáról beszéltek, és annak a fényképét mutatták a résztvevőknek).

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Volt pár mókás és tanulságos beszélgetésem amúgy "Certified Agile Coach"-okkal, ami többnyire azt jelenti h. agymosták Scrum-ból, többnyire valami régi verzíóból, amiről már mindenki rájött h. baromság, vagy ami még rosszabb, SAFe-ből vagy ilyesmiből, de a 4 pontból álló Agile manifesto egyik pontját sem tudja fejből, de azért ő agilis. Elmélkedik a processzek és a JIRA fontosságáről ("Individuals and Interactions over Tools and Processes" az vajon mi), meg hogy nem baj ha bugos a szoftver, csak megfelelően dokumentálva legyen ("Working software over comprehensive documentation" meg sose volt). És akkor jön nekem és meg akar győzni hogy ez most nagyszerű lesz. Mert jaj de agilisek leszünk. Hát így nem. És amúgy is:

Do not cite the deep magic to me, Witch, I was there when it was written.

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

( KGer | 2024. 06. 07., p – 17:51 )

amikor beírják hogy pontosan 268%, akkor ott már gyanús hogy vmi nem oké a cikkel