Hmm...

Az, hogy a minőség magas legyen, legfeljebb a scope kisebb, azt én is szoktam mondani az embereknek, amikor az Iron Triangle-t mutatom meg nekik. De itt a magas minőség nem azt jelenti, hogy magasabb, mint amikor nem agile-lal fejlesztenek, csupán azt, hogy nem akarunk a minőségből lejjebb adni. Vagyis azért, hogy mondjuk az üzlet által vágyott időre az üzlet által vágyott scope-ot késznek lehessen jelenteni, nem fogjuk kihagyni a visszatérő értékek ellenőrzését meg a tesztek írását stb.

Az iron triangle pont a waterfall és az agile megközelítés különbségéről szól, de mindkettő esetben középen a quality az, amihez nem nyúlunk.

A második ponthoz hozzászólva (persze nem tudom, hogy mire gondolt a költő), én úgy gondolom, hogy a product quality az nem feltétlenül azt jelenti, hogy az elkészült kódban kevesebb lesz a hiba, amikor kiadom a kezemből. Én inkább úgy gondolnám, hogy a quality az, hogy a program azt csinálja, amit a felhasználók és a megrendelő szeretne. Amit a rövid iterációk és a gyors feedback loopok segítenek. Ugyanígy, ugyanezek miatt esély van arra, hogy bugokat és rossz minőségű kódot hamarabb észrevesznek (mert egy sprint végére már valamennyi tesztelés és kód review megtörtént), és ezért hamarabb neki lehet állni a javításnak (mondjuk ahhoz képest, hogy mondjuk egy év fejlesztés után kezdődik a tesztelés, és akkor kezdik el felfedezni a bugok garmadáját. Dolgoztam már olyan projekten, ahol egy csóka kb. három hónap alatt lefejlesztett egy számla formázást egy számlázórendszerbe, és amikor elméletileg elkészült, akkor nézték meg mások, és kaptak a fejükhöz, mert egy szemétdomb volt az egész).

Nem azt mondom, hogy nem mennek konzultánsok ügyfelekhez ezzel az üzenettel, igazából fogalmam sincs, hogy a konzultánsok mivel próbáljál eladni az agile megközelítést (nem volt részem ilyenben).

Akikkel én találkoztam, ott az ügyfeleknek jellemzően két vágyuk volt az agile bevezetéssel kapcsolatban: 1) rugalmasság 2) gyorsabb és olcsóbb fejlesztés. Azt nem tudom, hogy valaki ezt így adta el nekik, vagy csak valahol hallottak olyan mendemondákat, hogy ezt jelenti az agile.

Állás interjú során kérdezték már tőlem többször is, hogy hogyan mérném a kód minőséget agile fejlesztés esetén, és erre én általában azt szoktam mondani, hogy a bugok számát ugyanúgy, mint waterfall esetén, de mellette mérek pl. lead time-ot és cycle time-ot.
Aztán fene tudja, hogy ezt akarták-e hallani :-)

"Az agilitással pont ez a megfontoltság veszett el, hiszen két hétre előre felesleges megfontoltnak lenni, utána meg úgyis minden megváltozhat, és a tesztek úgyis lefednek mindent, nem érdekes.
Érdekes helyen dolgozhatsz(dolgozhattál) ha ez a meglátásod. Jobban mondva érdekes emberekkel. Nálunk 2 hetes sprintek vannak és egyik csapat se ilyen hozzáállással megy neki a dolgoknak. (100+ csapat) Ha kell akkor inkább rolled-over de amíg nincs teljesen körüljárva a probléma, fejlesztői és tesztelői tekintetből is. Persze lehet vannak olyan cégek akik sz@rnak a dolgokra és bármit kiadnak a kezükből ami működik. Ellenben visszatértünk oda, hogy maga a minőség a csapattól függ nagyban. A módszertan a buisnessnek segtíség, hogy közelebb kerüljenek a csapathoz, valamint a csapatnak, hogy megmaradjon a motiváltság.

---

return signResponse.getSignForUser("zeletrik").map(SignResolvable::getSign).orElse(StringUtils.EMPTY);

> Ostor folyamatosan van, mert a business mondja meg, mi legyen, changes welcome.

Azert alljon mar meg a menet!

A business _kerhet_ feature-t, a business _prioritizalhat_, de a business technikai kerdesekben nem kompetens. A business se nem esztimalhat, se nem mondhatja meg, hogy technologiailag adott dolgot hogy kellene megvalositani. A feljesztoi csapat nem valami kozgazt, meg 2 ev managementet vegzett emberek rabszolgacsoportja, akiket ide-oda ugraltathat kenyere-kedvere.

Azt persze mondhatja, hogy a fejleszto csapat nem eleg gyors, nem eleg rugalmas, es lecserelheti az egeszet a francba.

Kar, hogy ezek utan, mikor a szarbol epult kartyavar osszedol, az ezen donteseket meghozok mar nincsenek az adott cegnel / pozicioban, hogy szamon lehessen rajtuk kerni a fogalmatlan donteseik kovetkezmenyeit.

Nem, nem, nem és nem! A "Changes welcome" azt jelenti, hogy amint a projekttel előrehaladva jobban látjuk a dolgokat, esetleg rájövünk, hogy más fontosabb. Nem toljuk végig a tervet, ha látjuk, hogy úgy nem lesz jó a végeredmény. De ezek nem eszement váltások.

"Elérheted úgy is, hogy teljes körű tervezésed van előre, és minden rész le van vezetve formálisan."

Igen. Csak az esetek túlnyomó többségében senki nem tudja előre, hogy pontosan mit is akar, vagy ha igen, akkor menet közben rájön, hogy tévedett. Ez igaz az össze résztvevőre a vevőtől a kódolóig. És ekkor jön be az Agile és az olyan alkalmazott eszközök, mint a CI és a tesz automatizálás. Ahol nincs rá szükség, ott ne használjanak Agile-t.

"két hétre előre felesleges megfontoltnak lenni, utána meg úgyis minden megváltozhat"

Hát, az elég nagy baj volna. Az, hogy a cél nem tű éles még nem at jelenti, hogy az M7-esen rájössz, hogy a Balcsi helyett az Alpokba mennél síelni.

"Prototipizálásra kiváló"

Prototipizálásra az Agile nem jó. Lásd "continuous delivery of valuable software".

"kérünk két hónapot, amíg rendesen ledokumentálunk mindent, specifikáljuk, hogy mi hogyan működik"

Az Agile nem mond olyat, hogy terv nélkül dolgozz. Te egyszerűen nem az Agile-ról beszélsz.

Ebben mi az ostor?

Olyan emberre nem emlékszem, aki azért panaszkodott, mert folyamatosan változtak az igények. Olyan embert viszont igen, aki felháborodott azon, hogy amin dolgozott két hónapig, az hirtelen obsolete lett és gyakorlatilag kidobták.

Gondolom, ez kb. ugyanaz pepitában.

De én inkább úgy értettem a kérdést, hogy szerintem a fejlesztő nem igazán vállalják magukra ezt vagy azt. Nem kérdezi meg őket senki, hogy ez vagy az az agile principle mehet-e.

De azt hiszem, értem, hogy mit akartál mondani. Én is találkoztam sok olyan emberrel, akik hallottak agile-ról, dolgoztak scrum projekten, de fogalmuk se volt, hogy igazából mi miért történik.