"Az Agilis Kiáltvány 12 alapelven nyugszik:
1. Ügyfél elégedettség fenntartása a használható szoftver gyors szállításaival
2. Változtatás kérések fogadása bármikor még a fejlesztés végén is
3. Működő szoftver gyakori szállítása (hónaponként helyett hetenként)
4. Szoros napi együttműködés az üzleti emberek és a fejlesztők között
5. Projektek motivált, megbízható egyénekből épülnek fel
6. Kommunikáció legjobb formája a szemtől-szembe való információcsere
7. Működő szoftver a haladás legfőbb mérőfoka
8. Fenntartható fejlesztés, állandó mértékben való fenntartás
9. Folyamatos figyelem a technikai kiválóságok és jó tervezés felé
10. Egyszerűség - az el nem végzett munka mennyiségének maximalizálása művészi fokon - elengedhetetlen
11. Önszerveződő csapat
12. Alkalmazkodás szabályos időközönként a változó körülményekhez"
1: Az ügyfél nem attól elégedett, hogy hamar kapja, hanem attól, hogy azt kapja..
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. (Ha nem hiszed, akkor beszélj fejlesztőkkel, vagy néz bele a forráskódba!)
Ha hamar szállítod, akkor jól kib@..tál magaddal, mert ezentúl nem csak a fejlesztéssel kell foglalkoznod, hanem a hibajavításokkal is. Vannak akik erre külön csapatot hoznak létre. (Folyik el a lóvé...) Külön öröm, ha ilyenkor elágazik a fejlesztés. Ha sikerül is kordában tartani, külön meg kell tervezni, hogy az ügyfélnél hogyan lehet áttérni a kint lévő rendszerről az újra. Ez magában iszonyatos pazarlássá válhat. Ezt ismételgetni hétről-hétre? El sem tudom képzelni... Minden ilyen áttérés jó kis kockázat. (Pl. belegondolok, hogy az ügyfél éles adatbázisát hétről-hétre átformáljuk az újonnan felmerült követelmények alapján. Nagy meló, nagy kockázat. Ez öngyilkosság. :) Persze, amíg nem mondtak fel a fejlesztők, addig még lehet csinálni. )
2: Ez kész. Ez önmagában csődbe vihet egy céget.
5: Ez már eldőlt korábban. A cég olyan emberekkel tud dolgozni, amilyeneket sikerült felvennie. Le lehet írni, külön, de ez semmin nem változtat. Ha motivált emberei vannak, akkor felesleges ide írni. Ha nem, akkor meg ez nem változtat semmin.
Tegyük fel, hogy az emberanyag megfelelő. Ebben az esetben is jobb, ha arra számítunk, hogy a projekt során egyre kevésbé motivált fejlesztőink lesznek. 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.
7: Hibás meglátás. Simán működhet egy szoftver, miközben a tervezési hiányosságok miatt zsákutcába navigál a fejlesztés. Ha ennek megoldása végül az alapjaiban való visszabontás, akkor nem jelent semmit, hogy előtte mennyi mindent tudott a szoftver.
9. Bullshit. Mi ez? :) A jó tervezést már az elején elbuktuk. Miről beszél ez? Pont azt akarja megspórolni.
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!
11. Nesze semmi fogd meg jól! :D
12. .... valamint világbéke! :D 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.
Még órákig lehetne boncolgatni ezt is és más Agilis forrásokat is.