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 :-)