Az Agile Manifesto (vagy magyarul a kiáltvány az agilis
szoftverfejlesztésért) valójában azoknak az elveknek az összefoglalója, amik vezérelnek bennünket akkor amikor a fejlesztés közben egy-egy döntést kell hoznunk. Vagyis ez nem más mint az alap axiómák összefoglalója, vagy sorvezető a gondolkodáshoz – kinek hogy tetszik. Az első négy alapelv itt következik:
A szoftverfejlesztés hatékonyabb módját tárjuk fel saját tevékenységünk és a másoknak nyújtott segítség útján. E munka eredményeképpen megtanultuk értékelni:
Az egyéneket és a személyes kommunikációt a módszertanokkal és eszközökkel szemben
A működő szoftvert az átfogó dokumentációval szemben
A megrendelővel történő együttműködést a szerződéses egyeztetéssel szemben
A változás iránti készséget a tervek szolgai követésével szemben
Azaz, annak ellenére, hogy a jobb oldalon szereplő tételek is értékkel bírnak, mi többre tartjuk a bal oldalon feltüntetetteket.
Ezen felül érdemes sorra vennünk a kiáltvány alapjául szolgáló többi elvet is ami kicsit bővebben leírja azt, amihez később érdemes visszanyúlnunk, ha tudni szeretnénk egy-egy dologról, hogy jó irányba viszi-e a fejlesztésünk menetét. Lássuk ezeket egyenként
Legfontosabbnak azt tartjuk, hogy az ügyfél elégedettségét a működő szoftver mielőbbi és folyamatos szállításával vívjuk ki.
Elfogadjuk, hogy a követelmények változhatnak akár a fejlesztés vége felé is. Az agilis eljárások a változásból versenyelőnyt kovácsolnak az ügyfél számára.
Nagyon fontos, hogy megértsük és megértessük a fejlesztőkkel a változás fontos része az üzletnek és aki nem képes adaptálódni a környezethez elbukik. A szoftvernek képesnek kell lennie a változó üzleti környezetet nagyon gyorsan követve kielégíteni az ügyfeleink elvárásait. Ez azt jelenti, hogy olyan kódot kell írni ami jól karbantartható és könnyű megváltoztatni.
Szállíts működő szoftvert gyakran, azaz néhány hetenként vagy havonként, lehetőség szerint a gyakoribb szállítást választva.
Nem elég, hogy gyorsan tudunk reagálni ezeket a változásokat minél gyorsabban el kell juttatni a megrendelőhöz. Ennek a hozzáállásnak nem csak az az előnye, hogy gyorsan láthatóvá válnak a változások, hanem az is, hogy a megrendelő vagy szponzor mindig látja a fejlődést és sokkal hamarabb kaphatunk visszajelzést a program működéséről
Az üzleti szakértők és a szoftverfejlesztők dolgozzanak együtt minden nap, a projekt teljes időtartamában.
Minél többet beszélnek egymással az egyes részek szakértői, annál kisebb az esélye, hogy bizonyos elvárások (amikről valamelyik fél úgy gondolja, hogy egyértelmű a másik meg nem is halott róla azért még csak számításba se tudja venni) rejtve maradnak. Ezen felül a fejlesztés során felmerülő kérdésekre is azonnal választ kaphatnak így a fejlesztők és minimalizálható a specifikáció tisztázása fordított várakozási idő.
Építsd a projektet sikerorientált egyénekre. Biztosítsd számukra a szükséges környezetet és támogatást, és bízz meg bennük, hogy elvégzik a munkát.
A jó főnök önmagánál okosabb emberekkel veszi körül magát, ráadásul fejlesztők általában okos emberek, nagy szaktudással és jó problémamegoldó képességgel. Kár volna nem kihasználni ezen adottságaikat és letörni a kreativitásukat.
A leghatásosabb és leghatékonyabb módszer az információ átadásának a fejlesztési csapaton belül, a személyes beszélgetés.
Gondolj csak bele, milyen kínosan lassú egy kérdést feltenni e-mailben, megvárni a választ, írásban elmagyarázni, hogy mire gondoltál, mivel a válasz köszönő viszonyban sincs a kérdéseddel, majd ismét várni a válaszra. Egyszerűbb és gyorsabb ha felemeled a feneked és odamész megkérdezni. Ezen kívül a személyes beszélgetés nagy előnye, hogy látod a partner reakcióit, metakommunikációját, ami sokat segít a probléma gyors kezelésében, mert azonnal látszik, hogy mit ért és nem ért a másik, mire nem kell szót vesztegetni, mit kell jobban megmagyarázni.
A működő szoftver az elsődleges mércéje az előrehaladásnak.
Tulajdonképpen senkit se érdekel, hogy hány oldal specifikációt vagy dokumentációt gyártottál, hány fejlesztő hány órát dolgozott egy funkción. Az egyetlen dolog ami fontos, hogy mit tud a program.
Az agilis eljárások a fenntartható fejlesztést pártolják. Fontos, hogy a szponzorok, a fejlesztők és a felhasználók folytonosan képesek legyenek tartani egy állandó ütemet.
A műszaki kiválóság és a jó terv folyamatos szem előtt tartása fokozza az agilitást
Elengedhetetlen az egyszerűség, azaz az elvégezetlen munkamennyiség maximalizálásának művészete.
Ez valószínűleg furán hangzik elsőre, gondolj bele: minden olyan kódsor ami szükségtelen bonyolultságot visz a rendszerbe egyrészt felesleges időbefektetés, másrészt feleslegesen bonyolítja a programot vagyis nehezíti a kód karbantartását. Soha, de soha ne csinálj meg olyan dolgot amire nincs szükség!
A legjobb architektúrák, követelmények és rendszertervek az önszerveződő csapatoktól származnak.
Minden csapatban különféle emberek dolgoznak különféle ismeretek birtokában, így összességében valószínűleg szélesebb körű ismeretek birtokában tudják elvégezni a feladatokat mint egyedül bármelyikük.
A csapat rendszeresen mérlegeli, hogy miképpen lehet emelni a hatékonyságot, és ehhez hangolja és igazítja az működését.
Ez nagyon fontos része az agilis fejlesztésnek, amiről a résztvevők hajlamosak elfelejtkezni, pedig rengeteg lehetőség van a fejlődésre. Lehet a hatékonyságot növelő eszközöket (segédprogramokat) készíteni, lehet a személyes csapatok közötti kommunikáción, kapcsolatokon javítani, motiválni és még egy sor dologgal növelni a kibocsátás sebességét.
