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.