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