Agilis kiáltvány, agilis módszertanok

MEGOSZTÁS

Ha tetszett a cikk, akkor nyugodtan oszd meg ismerőseiddel, valószínű ők is örülni fognak neki.

Az Agilis Fejlesztés egy módszertan-család, és nem egy konkrét megközelítése a szoftverfejlesztésnek. 2001-ben 17 ember, az akkor ‘pehelysúlyú módszertanok’ néven futó módszertanok jelentős képviselői, összeültek, hogy megbeszéljék, mi a közös a módszertanaikban. Megalkották az Agilis Kiáltványt, amit széles körben elfogadtak, mint az agilis fejlesztés kanonikus meghatározását.

Az Agilis Kiáltvány

A szoftverfejlesztés jobb módjait fedezzük fel azáltal, hogy csináljuk, és segítünk másoknak is csinálni. Ennek során az alábbi hangsúly-eltolódásokat találtuk:

Egyének és interakcióik, szemben az eljárásokkal és eszközökkel.
Működő szoftver, szemben a teljeskörű dokumentációval.
Együttműködés az ügyféllel, szemben a szerződésről való alkudozással.
Változásokra való reagálás, szemben a terv követésével.

Ez azt jelenti, hogy a jobb oldalon szereplő értékek is fontosak, de a bal oldalon lévőket fontosabbnak tartjuk.

Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas

© 2001, a fenti szerzők
Ezt a nyilatkozatot szabadon lehet másolni, de csak egyben, ezzel a jognyilatkozattal együtt.

Összehasonlítás más típusú módszertanokkal

Az Agilis módszertanokat a ‘terv-vezérelt’ vagy ‘fegyelmezett’ módszertanok ellentétének szokták nevezni. Ez félrevezető, mert úgy hangzik, mintha az Agilis módszertanok ‘tervezetlenek’ vagy ‘fegyelmezetlenek’ lennének. Szerencsésebb megkülönböztetés, ha a számegyenes két végpontjának az ‘adaptív’ és a ‘kiszámítható’ módszertanokat tekintjük.

Agilis (agilis)  «-»  Iteratív  «-»  Vízesés (Kiszámítható)

Az adaptív módszertanok arra fókuszálnak, hogy a gyakran változó követelményekhez tudjanak alkalmazkodni. Ha egy projektben megváltoznak az igények, akkor egy adaptív csapat képes alkalmazkodni a változásokhoz. Egy adaptív csapat nehezen tudja megmondani, hogy mi fog történni a jövőben. Minél távolabbi pontról van szó a jövőben, annál bizonytalanabb lesz az adaptív módszertan elképzelése arról, hogy mi is fog akkor történni. Egy adaptív csapat hajszálpontosan meg tudja mondani, mit fognak csinálni a jövő héten, de a következő hónapról már csak azt, hogy milyen feature-öket terveztek arra a hónapra. Ha egy hat hónappal későbbi release a kérdés, a csapat már csak a vállalat célkitűzéséről, vagy a tervezett költség-érték arányról tud beszámolni.

A kiszámítható módszertanok ennek ellenkezőjeként, arra fókuszálnak, hogy minél részletesebben megtervezzék a jövőt. Egy kiszámítható csapat pontosan meg tudja mondani bármelyik pillanatban, hogy mikor milyen feladatok és feature-ök lesznek készen a projektben. A prediktív csapatok nehezen váltanak irányt. A terv általában az eredetileg meghatározott cél elérésére van optimizálva, és az irányváltoztatás könnyen azzal a következménnyel járhat, hogy az elkészült munkát el kell dobni, és újrakezdeni. A kiszámítható csapatok gyakran változáskezelő bizottságot állítanak fel (change control board), hogy biztosítsák, hogy csak a legszükségesebb változások érintsék a projektet.

A legtöbb Agilis módszertan egyetért az iteratív fejlesztéssel abban, hogy a szoftvert rövid időközönként ki kell adni. Az Agilis fejlesztésben azonban ez a rövid időköz inkább hetekben mérhető, mintsem hónapokban. A legtöbb Agilis módszertan továbbá szigorú időkeretként tekinti ezt az időközt, és nem pedig tervezett célként. Az időkeret azt jelenti, hogy a határidő kőbe van vésve, és nem változhat. Ha a csapat kicsúszik a határidőből, akkor a feladatot nem sikerült megoldani, és vagy vissza kell vonni, vagy új feladatot csinálni belőle. Van olyan is, hogy a feladatot lehet egyszerűsíteni, hogy a csapat beleférjen a határidőbe.

A vízesés-modellel már kevesebb közös vonása van az Agilis technikáknak. A vízesés a legkiszámíthatóbb modell (elvileg), olyan lépésekből szokott állni, hogy a követelmények kigyűjtése, elemzése, tervezés, kódolás, tesztelés, szigorúan egymás után. A haladást általában eredményként felmutatható dolgok formájában mérik – követelmény-specifikáció, terv-dokumentumok, teszttervek, kódellenőrzési jegyzőkönyvek, és effélék. A vízesés modell néha azon csúszik meg, hogy a ciklus végén komoly integrálási és tesztelési problémák jelentkeznek, és ez a munka eltarthat néhány hónapig vagy évig is. Ez gyakran okozza a modell bukását. Az Agilis módszertanok ellenben teljesen integrált és tesztelt programokat eredményeznek, de mindig csak egy lépést tesznek előre, hétről hétre. A hangsúly egy elnagyolt, de működő rendszer korai kifejlesztésén van, amit aztán lehet finomítgatni.
Vannak olyan Agilis módszertanok is, amelyek a vízesés-modellt használják, de kicsinyítve, minden kis lépésben a teljes lépéssorozatot végrehajtva. Más módszertanok, például az Extrém Programozás, egyszerre több dologgal is haladnak.

Sokan használják a ‘cowboyos’ kódolás nevű ‘módszert’ is. A cowboyos kódolás lényege, hogy nincs semmiféle módszer meghatározva, mindenki azt csinálja, amit jónak lát. Az Agilis módszertanok gyakori újratervezése, szemtől-szembe kommunikációja, és viszonylag laza dokumentumkezelése miatt sokan azt hiszik, hogy ez is cowboyos kódolás. Az Agilis csapatok azonban nagyon is használják a maguk jól meghatározott (gyakran fegyelmezett és rigorózus) módszertanját, tehát éles különbség van az Agilis kódolás és a cowboyos kódolás között.

Kritikák

Rengeteg kritika olvasható ezekről a módszertanokról, aminek részben az az oka, hogy ezek többségükben még nem kiforrott, lezárt módszertanok, ráadásul mindenki a maga szája íze szerint értelmezi őket. A jogosnak elismert kritikák három központi érv köré gyűlnek:

  • Csak gyakorlott, szenior fejlesztőkkel működik
  • Nincs eléggé megtervezve a szoftver
  • Túl sok kulturális változás kell ahhoz, hogy jól működjön

Az itt bemutatott Agilis módszertanok

  • eXtrém Programozás (XP)
  • Scrum 
  • Cristal/Kristály módszertanok
  • DSDM
  • Feature Driven Development, vagyis Funkcionalitáson Alapuló Fejlesztés (FDD)
  • Test Driven Development, vagyis Tesztelésen Alapuló Fejlesztés (TDD)

Forrás: http://valodi.hu/agile

Letölthető e-könyvek: Agilis adatbázisok Debreceni Egyetem – Pap Béla 2011 

Agile manifesto: http://agilemanifesto.org/principles.html

MEGOSZTÁS

Ha tetszett a cikk, akkor nyugodtan oszd meg ismerőseiddel, valószínű ők is örülni fognak neki.

HOZZÁSZÓLÁS

Ha nem hagy nyugodni az, amit a cikkben olvastál, akkor nyugodtan írd meg kérdésed vagy észrevételed kommentbe. Így szerzőnk könnyen tud neked válaszolni.

Vélemény, hozzászólás?