Nem agile fejlesztünk, mert

Az, hogy nem tervezHETŐ, azt nem mondanám. Legfeljebb mi nem tudjuk megtervezni.

Ezt megint könnyen rá tudom húzni az emberek gyenge képességeire. És nyilván igaz is. De azért azt látni kell, hogy a szoftverek komplexitása mondjuk az 1980-as évekhez képest rendkívül megnőtt, a time-to-market és feature verseny egyre csak fokozódik. Szörnyű nagy nyomás van az embereken és még az Agile, Scrum, Lean, CI, XP, TDD stb varázsszavak, valamint az egyre hatékonyabb nyelvi eszközök, IDE-k, frameworkök és egyebek sem feltétlenül tudnak hosszú távon segíteni azon, hogy ki ne csússzon a lábunk alól a talaj.

Ez egy egyre gyorsabban pörgő mókuskerék, viszont a pofára esés egyszerű jelekből megjósolható. Ha csak hányják be az új dolgokat, refaktorálásra, esetleg már tesztelésre sem jut rendesen idő, akkor ideje lassítani és valami új utat találni vagy végleg befellegzett. Mondhatnám úgy is, hogy a refaktorálás vagy tesztlés akár pillanatnyi elmaradása is egy piramisjáték kezdete, így kérlelhetetlenül meg kell akadályozni.

Sajnos ez nem jelenti azt, hogy a gyorsítást követelő menedzsmentet figyelmen kívül lehet hagyni. Ha összeomlik egy cég és az utcára kerülsz, mindegy, hogy a kód rohadt rád vagy a cég maradt alul a feature versenyben. Technikailag kell folyamatosan fejlődni, és ezek megbeszélése pl. a Retrospective meeting.

Szerintem az egesz agile tema valahol annak besimerese, hogy a megrendelő sosem tudja mit akar. Ezért leírni sem tudja, hogy mit akar. Ehelyett adjunk neki valamit hamar, és ő közben talán rájön, hogy mit is akar, és addig szállítunk neki, amíg nem lesz a termék elég jó. Az agile arról szól, hogy e helyzet ellen ne küzdjünk, hanem fogadjuk el, és e szerint dolgozzunk

Szia,
Szerintem meg pont nem. Kis cégnél dolgozok ( Sophos ) , ahol <sarcasm> apró termékeket fejlesztünk</sarcasm>, és tapasztalatból mondom, hogy az Agile módszer hasznosabb, mint a klasszikus waterfall.
2-3 termék párhuzamos maintainelése és közben feature development esetén meglepően kellemes tud lenni. Főleg amiatt, mivel egyértelműen elmagyarázható ezzel a managementnek, hogy az instant fixnek ára van, válasszanak, hogy mit cserélünk rá ( Mondjuk, mi tartunk fent tartalék időt a kisebb fixekre, de amikor valami nagyobb gond fut be, akkor jön a trade-off value: feature vagy fix. Management pedig szépen elmazsolázhat rajta, hogy megéri-e nekik a 2 napon belüli fix, vagy sem. )
Mondjuk, a mi módszertanunk inkább pseudo-agile, mivel Business cycle-t is alkalmazunk, illetve stabil releasek vannak, előretervezett main featurekkel. De ezen belül fixek, minor feature-ök jönnek mennek sprintenként. A major feature-t pedig tudjuk stabilabban ütemezni.
Ha csúszás várható, mert valaminek a lefejlesztése több időt követel, rövid időn belül kiderül, és a cycle-re kiható részek már hetekkel, hónapokkal előre láthatóak így ( mivel XY dolognak meg kell lenni, hogy Z implementálva legyen, és XY fejlesztője hiába akarna trükközni, egyértelműen látszani fog, hogy meg van csúszva, legkésőbb 2 héten belül. Ez kicsit nyakatekert példa, de talán elég érzékletes...)
Persze, ahol rosszul alkalmazzák, ott minden fejlesztési modell átok, és csak "játékra jó"...
Üdv,
LuiseX

"Jó öreg kőkemény szerződés és emailes trac vagy bugzilla" Agilis fejlesztes elso szabalya: Legyen Agilis a szerzodes! Ezzel nem mondtam neked ellent, sot, ha a multi ceg, vagy az allami szervezet nem ert az agilis fejleszteshez, es nem kotsz veluk agilis szerzodest (miert is kotnel, hiszen azt se tudjak mi az), addig ongyilkossag agilisen fejleszteni. De ez meg nem az agilis modszertant minositi.

-
Big Data trendek 2016

kevered az agile-t a scrum módszertannal...

Szerintem meg pont ezért olyan gagyi minőségűek az államnak vagy multinak szállított szoftverek nagy része. :)

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

Most ezt nézem, nagyon érdekes...

Köszi, majd megnézem!

A témában én ezt találtam nagyon hasznosnak: Kanban és Scrum mindkettőből a legjobbat.

Pedig a panaszkodás a scrum része. Legalábbis a folyamatban résztvevő szereplőké. Erre van a retrospective.
Ha meg mások panaszkodnak, vagy hiába van panasz, mert totál leszarják, hát akkor visszakanyarodtunk oda, hogy nem tudják, hogy hogyan működik.
Meg vannak ugye a disznók és a csirkék (nem tudom magyarra is így fordították-e): A disznók olyan résztvevők, akik bőrüket viszik a vásárra, tehát nekik húsba vágóan fontos, hogy mi történik és hogyan döntenek. A csirkék azok, akik viszont csak a tojást adják a történetbe: ők nem annyira fogják a saját bőrükön érezni a meetingen megszülető döntéseket. Na most ha egy csirkének van olyan hatásköre, vagy akkora szava, hogy az jut érvényre a disznóé helyett, akkor megint csak nem lettek betartva a szabályok.
Bocsánat, hogy nem tudom pontosabban és szebben elmondani, nem vagyok scrum ninja.

> a kitalálója is rózsaszín ködben volt

Pont ellenkezőleg. Az Agile kitalálói láttak sok bedőlt projectet, mert pl. a különböző komponensek fejlesztői nem kommunikáltak direktben, hanem főosztályvezetőkön keresztül, határidőkor derült ki, hogy egyik csapat sincs ott, ahol kéne, amikor végre kész lettek, akkor derült ki, hogy a komponensek nem működtek együtt és mire végre együttműködtek, jött a megrendelő és szörnyülködött, hogy nem ezt akarta.

> Pár dolgot ugyan kihagyott a scrum

Azt nem hiszem. Vagy ha igen (pl. process over individuals), akkor esetleg rosszul csinálják a gyakorlatban.

"Ebbe a körbe tartoznak a különféle metodológiák, amik semmi másra nem alkalmasak, mint a befektetők pénzének értelmetlen elpazarlására kitalált kifogások"
Persze de errol nem a metodologiak tehetnek ;)

Elso szabaly!

-
Big Data trendek 2016

Jelenleg nincs meg a Szoftverfejlesztés Szent Grálja: megbízhatóan olyan szoftvert előállítani, ami megbízható.

Nyugodtan kövezzetek meg érte, de én úgy látom, hogy egy szoftvercég értéke és valódi terméke nem az a szoftver, amit előállít, hanem az a módszertan, az a folyamat, az a rendszer, amivel előállítja a szoftvereket.
Ha egy cégnél van egy kialakult, jól működő módszertan arra, amely a cég által alkalmazott mérnökökkel, üzleti elemzőkkel, tesztelőkkel, szoftvereszközökkel megbízatóan tud szoftvert előállítani, akkor mindegy, hogy ők mobilalkalmazást, motorvezérlő szoftvert, operációs rendszert, vagy éppen webshopot csinálnak. Nem ez az igazi lényeg, hanem maga az a mód, ahogyan ezek a webshopok, kernelek vagy mobil appok elkészülnek. Ez az igazán nagy kincs minden szoftvercégnél, és nem az, hogy mindenáron működő szoftvert hozzunk létre.
Nem, a módszertan majd előállítja a szoftvert megbízhatóan, az egy melléktermék nagy távlatból és koncepcionálisan nézve.
Az egyik kedvenc (már régi ugyan) cikkem a témában:
http://www.fastcompany.com/28121/they-write-right-stuff

"The process is so pervasive, it gets the blame for any error — if there is a flaw in the software, there must be something wrong with the way its being written, something that can be corrected. Any error not found at the planning stage has slipped through at least some checks. Why? Is there something wrong with the inspection process? Does a question need to be added to a checklist?

Importantly, the group avoids blaming people for errors. The process assumes blame - and it's the process that is analyzed to discover why and how an error got through. At the same time, accountability is a team concept: no one person is ever solely responsible for writing or inspecting code. "You don't get punished for making errors," says Marjorie Seiter, a senior member of the technical staff. "If I make a mistake, and others reviewed my work, then I'm not alone. I'm not being blamed for this.""

Szia,
Igazából, az a gond itt szerintem, hogy te egy-egy sprintre, és fejlesztési szakasznál a teljes termékre gondolsz. Inkább nézz erre a módszertanra úgy, mintha épp házat építettnél, és 2 hetente hívnak a szakik, hogy mi a véleményed.
Először látod majd az alapozás nyomait, általában pár gödör, és semmi izgalmas, de feltűnhet az egyből, hogy eggyel több támfal helyét látod. Ekkor szólhatsz, hogy el lett rontva, mert neked bizony ott nincs támfal... A szakikkal összeültök, megbeszélitek, ki-ki megy a maga dolgára.
2 héttel később az alapozás kész van, és az első emeletik jutottak. Ekkor megnézheted, hogy jónak fest-e a földszint beosztása, és szépen megbeszélhetitek, hogy miért nem tetszik az elülső ajtó helye. Ők elfogadják, és javítanak.
Költséges javítani? Igen, de még mindig egyszerűbb az első emeletet lebontani, mint majd a fél házat lebontani egy hídért... ( Tudom erős példa, de jobb nem ugrott be :) ).
Kb. ugyanez az agilis fejlesztés, csak annyi különbséggel, hogy - a korábbi hasonlattal élve - te korábban elmondtad, mit szeretnél, mit nem. Annak vagy volt értelme, vagy nem. A szakik talán el is árulták, és megtudtátok beszélni. Legközelebb akkor mehettél oda, amikor szépen le volt vakolva minden.
Itt a gyors szállítás inkább arra vonatkozik, hogy 2 hetente legyen valami, amit fel lehet mutatni az ügyfélnek. Nem kell, hogy menjen és tökéletes legyen, de még mielőtt minden összeillesztenéd, az ügyfél láthatja , hogy valami félre fog sikerülni, vagy a fejlesztők szólhatnak még időben, hogy egy-egy komponens csúszni fog.
Persze, ha úgy kezeled, hogy 1 sprint alatt kellene egy linux kernelt írni from scratch, bukott a projekt, mielőtt elkezdenéd. De ez esélyesen Waterfallal is így jár. Ellenben, ha úgy indulsz neki, hogy kell egy kernel, és ehhez első héten legyen egy bootloader, akkor már is könnyebb abszolválni a problémát. ( Persze, kiderülhet itt is, hogy valójában arm-re kell x86 helyett, és ciki, de még mindig csak egy bootloader van kész: a projekt mehet tovább, immár arm-re célozva).

És, akkor rendre a reagálnék a felvetéseid egy részére:
1., Az ügyfél előbb látja, mit fog kapni, vagyis, még időben szólhat, mit értettél félre/volt képtelen elmagyarázni. Nem a kész terméket kapja előbb, csak látképet arról, mi is lesz ebből.
2., Változtatni azért tudsz, mivel elvileg a korábbi dolgok már fixáltak, az előtted állók pedig épp formálódnak ( nem az egész szerkezetet módosítod ilyenkor, jól tervezve a korábbi alapok maradhatnak stabilan. Ha minden jól vezényeltek, legfeljebb egy sprint munkája mehet kárba. Ez is költség, de még mindig jobb, mint azt látni, hogy az ügyfél képtelen volt elmondani, hogy a beléptető rendszer alatt nem MS alapú SSO-ra LDAP alapokon, hanem egy szimpla user/password jellegű auth-ra gondolt MySQL-ből... )
5., Motiválhatja az is a fejlesztőt ám, ha annak, amit csinál, van nyoma. Azért, nem mindegy, hogy 200 kicsit feladatot old meg, mindegyikről látja, hogy szépen készen vannak, vagy egy baromi nagyot, aminek a felénél sem jár, de legalább az sem biztos, hogy jól csinálja. Ez utóbbi erősen demotiváló tud lenni például.
7., A tervezési hibák időben kiszűrése miatt iterálunk. Ideális esetben a tervezési hibákat lehet minimalizálni, és igazolható, hogy a korábbi munkában nem volt eddig. Itt megint gondolj arra, hogy a sprintek alatt a teljes feladat részleteit értelmezzük, és azokkal haladunk, nem az egész feladatot mérlegeljük mindig újra. A működés itt is azt fedi, hogy amit abban a két hétben csináltatok, a _saját_ specifikációinak megfelelően üzemel, és ezáltal illeszkedik a korábbi munkára.
9., Mindenben van némi bullshit, és... managerek is olvassák ezeket :D Bár tény, inkább arra utal, hogy a kis részletekre való fókuszálás miatt előbb meglátszanak a nagyobb hibák :)
10., Pontosan :) Csak, megint arra kell gondolni itt, hogy jelenleg kis feladatokkal dolgozol, és pl. ha az auth-ot már leimplementálta egy másik csoport, neked ezen felesleges erőlködni. Integrálhatjátok az ő megoldásukat is, arra törekedve, hogy az auth fejlesztéseket simán behúzzátok a saját kódotokhoz is.
11., Az önszerveződő csapat kicsit bullshit, kicsit nem. A lényege az, hogy magától tudja mindenki, mi a dolga és a többiek is tudják róla, mi a feladata pontosan. Ha valaki kiesik, kétségbe esés helyett maguktól szerveződnek a pótlására - ez vagy effektív lesz, vagy kevésbé - így a csoport nem hal meg nélküle. És.. itt ne csak egy 1 devre gondolj, lehet a QA-s, a lead dev, vagy a PO... Igazából, azt nem fogom megérteni soha, hogy ez a kitétel miért nem alap mindenhol...
12., Itt arra gondolj, hogy pl., kéthetente újratervezés, vagy a csoportba a felmerülő töblet időígény miatt 2 plusz fejlesztőt beraknak a következő sprintre.
Remélem ,sikerült érthetően megfogalmaznom :)
Üdv,
LuiseX
U.i: Fejlesztő vagyok, és nem lelkes agile fan. Személy szerint tetszik a módszer, de ez is csak egy módszer :) Lehet kis baltával is assembly-t írni, de úgyis maga a feladat mondja meg, hogy érdemes-e :)

https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it
https://en.wikipedia.org/wiki/Continuous_integration
https://en.wikipedia.org/wiki/Acceptance_testing
https://en.wikipedia.org/wiki/Functional_testing
https://en.wikipedia.org/wiki/Code_refactoring

Ezeket nezd at, erdemes. Ha ezek megvannak, maris tobb ertelme lesz az agilis modszertanoknak.

Először is érdemes elolvasni a magyarra ferdített változat helyett az angol verziót, aminek több értelme van:

1, Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2, Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

3, Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

4, Business people and developers must work together daily throughout the project.

5, Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6, The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

7, Working software is the primary measure of progress.

8, Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

9, Continuous attention to technical excellence and good design enhances agility.

10, Simplicity--the art of maximizing the amount of work not done--is essential.

11, The best architectures, requirements, and designs emerge from self-organizing teams.

12, At regular intervals, the team reflects on how to become more effective, then tunes and adjusts ts behavior accordingly.

Illetve ezt javaslom olvasásra:

https://www.linkedin.com/pulse/12-agile-manifesto-principles-simply-exp…

1-es pont: ezt szokták nagy sokan szigorúan venni, és akkor be is bukik minden. Amikor elindul egy projekt, akkor a hagyományos modellben van egy speckó, lefejleszted,
fél év múlva a megrendelő kap egy sw-t, tehát a kezdeti specifikáció és a végső termék közötti olló baromi nagy. Egy alternatíva erre, hogy gyorsan kap release-eket valami
pl. egy teszt szerverre, ahol szépen meg tudjátok mutogatni, hogy ez így meg úgy fog működni. Ennek az előnye az, hogy a felhasználó vissza tud jelezni, hogy bocsi, bár
ebben egyeztünk meg, de rájöttem, hogy ez így ebben a formában nem lesz jó, nem-e lehetne másképp? A szoftver tehát időben konvergál ahhoz, amit a felhasználó valóban szeretne,
nem pedig egy "specifikációhoz" ami teljesen biztosan hiányos, hibás, és nem végiggondolt.

2-es pont: ez nem azt jelenti, hogy kávédarálónak indult, és űrhajó lesz belőle. Ez azt jelenti, hogy lehetőséget adunk a felhasználónak a fent említett változtatásokra ésszerű keretek között.

5-ös pont, az emberek azért lesznek motiváltak (mert ha nem fizeted meg őket, akkor nem fognak nálad dolgozni) mert hagyják őket békén dolgozni, nem pedig végtelen mennyiségű szükségtelen adminisztrációs baromsággal kell foglalkozniuk, illetve nem fentről valaki kiosztja a melót hogy ki mit csináljon, hanem a csoport önszerveződik. Igy önállóan egymás között el tudják dönteni, hogy ki mit szeretne csinálni a következő sprintben.

7-es pont: az eredetiben egyébként az van, hogy "emphasis on working software over comprehensive documentation". Tehát fontosabb a működő program, mint hogy le legyen dokumentálva, amit egyébként a kutya sem fog elolvasni.

9-es pont: Continuous attention to technical excellence and good design enhances agility. Igy máris van értelme...

10-es pont: 80-20 szabály. Az eredményeid 80%-a a melód 20%-ából fog jönni. Ezt kell jól megcsinálni. Csinálj jó, ügyes könyvtárakat, toolokat, stb. amik segítik a munkád.

11-es pont: annyi, hogy bízzuk a fejlesztőkre, hogy ők hogyan szervezik meg magukat, mert ők tudják. A PM ne ugasson bele, a felsővezetés meg végképp. Én már találkoztam olyannal, hogy a felsőbb vezetésből valaki, aki korábban fejlesztő volt, osztotta az észt olyanokról, amikhez nem értett. Finoman helyre kellett rakni, hogy ad.1. ez nem az ő dolga, ad 2. hülyeséget beszél.

12-es pont: angolul megint értelmes.

---

magamról: 2001 óta java fejlesztő vagyok...

1: Az ügyfél nem attól elégedett, hogy hamar kapja, hanem attól, hogy azt kapja..

Szerintem ne próbáld meg kitalálni, hogy mi a jó az ügyfélnek, hanem bízd rá!

Nem tudom, nálatok hogyan működik, nálunk nem az van, hogy mi kitaláljuk, hogy majd agile módszertan szerint szállítunk az ügyfél meg szívjon, hanem az ügyfél kéri ezt.

Statisztika szerint az ügyfelek nagy része azért igényel agilis fejlesztést, mert a legfonosabb számukra a piacra kerülés sebessége. Vagyis de, attól elégedett, hogy hamar kapja, még akkor is, ha esetleg hitványabb megoldás kerül bele.

Persze itt felmerül a kérdés: mi az, hogy hitványabb megoldás. Ha működik a szoftver és azt csinálja, amit az ügyfél kért, akkor mi a gond? Ha a hitványabb megoldás helyett a jobb megoldás kerül bele, de tovább tart kifejleszteni = drágább + később kezd hasznot hajtani, akkor az most jó az ügyfélnek?

És légyszi ne írd azt, hogy hitvány = majd három hónap múlva az egész szarból készített vár összeomlik és nagy költséggel újra kell az egészet írni, mert annyira hitvány kódot nem szabad beletenni a rendszerbe, akár agile akár nem.

Agile esetén a 8-as pont, amit nem értettél, az pont arról szól, hogy fenntartható fejlődést kell elérni, tehát ha az első story 1 hét volt, a második hasonló story 2 hét, a következő 2 hónap, akkor rosszul csinálják. A 8-as pont a technical debt szintentartásáról, refaktorálásról, a kódbázis folyamatos javításáról és karbantarthatóságáról szól.

Kifejezetten rossz, ha a határidő miatt kerül a rendszerbe egy hitványabb megoldás. Márpedig ennek garantáltan ez a vége

A leggyakrabban használt Agile módszertanok esetén nincs olyan, hogy határidő. Olyan van, hogy becslés, hogy kb. mi lesz kész, és ami kész van addig, az mehet ki. Ha valami nincs kész "határidőre", akkor majd megy legközelebb. Vagy nem megy egyáltalán.

DSDM esetén van szoros határidő, ott máshogyan van megoldva az, hogy ebből ne legyen gond. A határidőre betervezett feladat 60%-a a kötelező, a maradék az pont azért van, hogy ne jelentsen a határidő nyomása ilyen problémát, mint amit írsz.

Illetve: az Agile nem jó mindenre. Simán el tudok képzelni olyan feladatot, ahol nincs előnye Agile-t használni, és van olyan projekt is, ahol nem is működne. Ha pl. a projektben a scope és az idő is fix, jó eséllyel nem lesz jó Agile módon fejleszteni (mondjuk waterfallal se). Ha még a pénz is fix, akkor meg végképp, mert akkor ahogy írod, a minőség az egyetlen, amivel játszani lehet. Agile esetén meg pont a minőség a fix és a scope + idő a változó.

2: Ez kész. Ez önmagában csődbe vihet egy céget.

Melyik céget? A megrendelőt? Hát ők had döntsék már el, hogy mire szeretnének pénzt költeni, és megengedhetik-e maguknak!
A fejlesztőt nem, hiszen a megrendelő az időért fizet. Vagy rugalmas az idő és addig fejlesztenek az emberek, amíg a megrendelő azt nem mondja, hogy köszönöm elég, vagy fix az idő, és akkor addig fejlesztenek, amíg el nem fogy a keret.

Az agilis fejlesztés alapelvei szerint fix költséggel és szigorú határidőkkel dolgozunk. Ebből az fog következni, hogy sok lesz azoknak az óráknak a száma, amit a fejlesztők ugyan ledolgoznak, de nem lehet elismerni, mert az a költségeket megdobná. Ez szívás lesz a fejlesztőknek. Ha a 2-es pontot komolyan vesszük, akkor a fejlesztő lesz a kisebb ellenállás, hiszen a megrendelőt - az alapelvek szerint - kifejezetten nem lehet önmérsékletre bírni.

Szerintem féleérted. A tipikus Agile projektnek sem a költsége sem a határideje nem fix. Ami fix, az a csapat költsége, mondjuk havonta x pénz.
Lehet fix költséget és ebből következő szigorú határidőt szabni, pl. van fix 6x pénzem, akkor ha havonta x a csapat, akkor 6 hónap a határidő, ott vége a projektnek, akármi is van.
Nincs olyan, hogy a fejlesztő ledolgozik egy órát de nem ismerjük el. A költségeket nem dobja meg, mert bele volt eredetileg kalkulálva, hogy napi 8 órával ennyibe kerül.

A 7-es pontra amit írsz, azzal nem vitatkozom, de az Agile Manifesztó 7-es pontja igazából nem erről szól, amit írsz, hanem arról, hogy a projekt előrehaladásának mérésére az elkészült szoftvert kell nézni. Szóval ha mondjuk kész a UX terv, az még 0. Ha kész a szoftver 90%-ig, az még 0. Ha megcsináltunk mindent, ami a definition of done-ban le van írva és a szoftver komponens fel van telepítve élesben és működik, akkor lehet számolni vele.

9. Bullshit. Mi ez? :) A jó tervezést már az elején elbuktuk. Miről beszél ez? Pont azt akarja megspórolni.

Miért buktuk el az elején? Miért akarná megspórolni?
Elméletileg arról szól ez, hogy minden egyes alkalommal, amikor valamit megtervez a csapat, akkor tessék jól megtervezni. (Nem akarja megspórolni, pont az ellenkezője).
Gyakorlatban persze lehet rosszul tervezni, de ez nem azért van, mert az Agile Manifesztó ezt írja elő.

10. Ez annyit mond, hogy csak annyit dolgoz, amennyit nagyon szükséges. Spórolj meg minden erőfeszítést, amit az ügyfél úgysem venne észre. Na, ebből is minőségi meló lesz... :D Agyam eldobom!

Igen, kb. ezt mondja. Csak annyit dolgozz, amennyit szükséges. Ha az ügyfél nem vesz észre különbséget abban, hogy te két napig reszelgetted a kódot, akkor az feleslegesen eltöltött két nap volt. Ez olyasmikre vonatkozik, ami 'felesleges' munka. Nem tudok hirtelen jobb példát mondani, mint mondjuk ne implementálj egy osztályba olyan függvényeket, amiket nem használ jelenleg senki és semmi csak azért, mert úgy lesz 'teljes' az osztály. Majd ha valamikor a jövőben szükség lesz ezek egy részére, majd akkor implementáljátok. Ha soha nem lesz rá szükség, akkor sosem.
De megint csak: itt nem arról van szó, hogy engedjünk a minőségből vagy a karbantarthatóságból.

11: ez egy koncepció. Ki lehet fejteni bővebben, a manifesztó nem megy részletekbe. Ha érdekel, utána tudsz nézni.

Egyébként pedig, ha szabályos időközönként alkalmazkodsz a szabálytalan időközönként változó valósághoz, akkor ez azt jelenti, hogy egy ideig felesleges dolgokkal foglalkozol, de legalábbis rossz irányba halad a fejlesztés. Ez pénzkidobás.

Ezt jól látod. Ha a valóság változik, mindig lesz ilyen. Agile esetén legalább hamarabb alkalmazkodsz, tehát kevesebb pénzt dobsz ki.

Ha jól tudom, akkor az SDM, az a tipikus waterfall, SDM2 annyival több, hogy iterálja, ami meg már az agilis módszertanok előfutára.

"Miért nem mondjuk ki, hogy ez egy vacak és jobb kell?"

Épp ez ellen lázadozol. Kimondták, hogy vacak a hagyományos és most az újak keresése zajlik. Az agilis az nem egy módszertan, az módszertanok halmaza, csak az alapelvek vannak lefektetve.

Van rengeteg praktikája, gyakorlata (practice), - pl. unit teszt, folyamatos integráció (CI), páros programozás, refaktorálás, - amik nélkül nem igazán beszélhetünk agilis fejlesztésekről, amiket már átvettek többé kevésbé a hagyományos fejlesztéseknél is, mivel már ezek használatával is jelentősen növelhető a rendszerfejlesztés minősége.

A legfőbb gond, az agilis módszerek használatával, hogy nagyon nehéz jól csinálni. Ha az alapelvek közül egy-kettő is hiányzik, vagy nem jól érvényesül, akkor megy a levesbe az egész. Vannak viszont részei, amiket önmagukban is lehet használni és nem jelentenek kockázatot, pl. amiket korábban is kiemeltem.
Ha a buktatókat szeretnénk elkerülni, akkor érdemes elolvasni ezt a minikönyvet: Kanban és Scrum mindkettőből a legjobbat, rengeteg hasznos tanácsot ad!

"az agilis módszertan attól működik, ami nincs benne" nem, nem ezt mondtam, tobb van benne, es attol mukodik, hogy kitalaljuk adott szituacioban mit erdemes alkalmazni. Ehhez kell az az ember, aki jartas tobb modszertanban, es vitt sikerre tobb projektet.

"sikerért képesek többet dolgozni" azert kepesek tobbet dolgozni, mert a sprint elejen kozos volt a vallalas, es nem egy olyan celelrt dolgoztunk, amit valaki kituzott, hanem a sajat vallalasunk betartasaert, a csapatert. "és a végeredmény minőségéből engedni" nem engedunk a vegeredmeny minosegebol, sot javitjuk a minoseget, hogy ha valami nem jo/nem felel meg az ugyfelnek/whatever, akkor szepen betervezzuk a kovetkezo iteracioba, hogy azt is meg kell javitani/at kell alalkitani, es nem csak a vegen derul ki, amikor mar 30 masik featurat epitettunk ra.

"SDM - ahol a módszertanban eleve szerepel a hangolás" csak az SDM az egy modszertan, az agile meg egy szemlelet (8-10 modszertan gyujto neve). ne keverd mar a szezont a fazonnal legyszi.

"Nem neked kell kitalálni." hat konyorgom ki tudja kitalalni, ha nem en?? ki ismeri a csapatot?? ki ismeri a fejlesztendo cuccot?? ki ismeri a megrendelo igenyeit?? ki ismeri a managementet?? ki ismeri a ... Nincs ultimate modszertan, nem lehet taviranyitani. Vannak projektek, ahol mukodik a reggeli standup vannak ahol nem (fugg attol, hogy tipikusan mindenki beer-e reggel, mennyien home officolnak, hany orszagban zajlik a fejlesztes, mekkor az idoeltolodas, stb). Es masik 40 dologrol ugyanez elmondhato.

"A jobb módszertanoknál a hangolás nem úgy megy, hogy kitalálsz a módszertanban nem létező dolgokat, hanem úgy, hogy adott esetben a projektnél, miket hagyhatsz el a készletből úgy, hogy nem okoz gondot" az a nagy bajod neked, hogy azt hiszed az agilis fejlesztes az egy modszertan. Persze vannak alapelvek, de az egyes implementaciok elternek egymastol, vagy egyes implementaciok nem fedik le a teljes fejlesztesi folyamatot, ezert masokkal szimbiozisban mukodnek.

"hogy ez egy vacak és jobb kell" ha lesz jobb kidobjuk, addig meg toljuk ;) Egyenlore nekem/nalunk sokkal jobban bevalt mint az elodjei, es ennel fogva beszelgethetunk itt az elmeletrol, a gyakorlatban sokkal stresszmentesebben tudom vegezni a munkamat alkalmazva az agilis elveket, es a termek is jobb lett mindig. Nekem csak ez a 2 dolog szamit.

-
Big Data trendek 2016