Agilis szoftverfejlesztés

A Wikipédiából, a szabad enciklopédiából

A szócikk egy része még lefordítandó. Segíts te is a fordításban!

Az agilis szoftverfejlesztés a szoftverfejlesztési módszerek egy csoportja, ahol a szoftver követelmények és a megoldások együttműködésen keresztül együtt fejlődnek az önszerveződő és multifunkcionális csapatok között. Ez elősegíti az alkalmazkodó tervezést, az evolúciós fejlesztést, korai szállítást, folytonos továbbfejlesztést és bátorít az változásokra adható gyors és rugalmas válaszokra.[1]

Az Agilis Szoftverfejlesztési Kiáltvány,[2] (ismert még Agilis kiáltvány néven is), először 2001-ben vezette be az agilis kifejezést a szoftverfejlesztés keretében. Habár mindez ez a DuPont-nál a 80-as évek közepén fejlesztett technikákból fejlődött ki és később James Martin[3] és James Kerr et al.[4] definiálta.

Története[szerkesztés]

Elődök[szerkesztés]

A növekményes szoftverfejlesztési módszerek egészen 1957-ig vezethetők vissza.[5] 1974-ben E. A. Edmonds írt egy dolgozatot, amelyben bevezette egy alkalmazkodó szoftverfejlesztési folyamatot.[6][7] Ezzel párhuzamosan, és teljesen függetlenül ugyanazt a módszert fejlesztette ki és alkalmazta New York Telefon Társaság Rendszerfejlesztési Központja Dan Gielan igazgatása alatt. A korai 1970-es években Tom Gilb elkezdte publikálni az evolúciós projektmenedzsment (EVO) koncepcióját, amely a competitive engineering-é nőtte ki magát.[8] Az 1970-es évek közepétől a végéig Gielan alapos előadásokat tartott Amerika szerte erről a módszertanról és gyakorlatáról és előnyeiről.

A pehelysúlyú szoftverfejlesztési módszerek egy csoportja kezdett kifejlődni az 1990-es évek közepén válaszul a nehézsúlyú vízesés-orintált módszerekre, amely kritikákat nevezik nehezen szabályozhatónak, nagyszámúnak és mikromenedzseltnek; habár egyes hívei ezen pehelysúlyú módszereknek azt állították, hogy csak visszatértek a korai szoftverfejlesztési gyakorlathoz.[5] Ezek a pehelysúlyú módszerek a következők voltak: 1994-ből a Unified Process és a dinamikus rendszerfejlesztéis módszer (angol rövidítéssel DSDM); 1995-ből a Scrum;1996-ből a crystal clear és az extrém programozás (angol rövidítéssel XP) és 1997-ből a adaptív szoftverfejlesztés és feature-driven fejlesztés. Habár ezek az Agilis Kiáltvány 2001-es közzététele előttről származnak, mostanra együttesen hivatkoznak rájuk, mint agilis módszerekre[9]; és gyakran rövidítik egyszerűen Agilisnek, nagy kezdő A-val, bár ez fokozatosan válik elavulttá.[10]

Az Agilis Kiáltvány[szerkesztés]

2001 februárjában 17 szoftverfejlesztő (lásd alább) találkozott Snowbird Üdülőközpontban Utah-ban, hogy megbeszéljék a pehelysúlyú szoftverfejlesztési módszereket. Kiadták a Kiáltvány az Agilis szoftverfejlesztésért-et:[2]

Azzal leplezzük le a szoftverfejlesztés jobb módjait, hogy csináljuk és segítünk másoknak is csinálni. Ezen a munkán keresztül következő értékekhez jutottunk el:

Egyének és kölcsönhatások előnyben részesítése a folyamatokkal és eszközökkel szemben

Működő szoftver előnyben részesítése az átfogó dokumentációval szemben

Ügyféllel való együttműködés előnyben részesítése a szerződéses megállapodással szemben

Változásokra adandó válasz előnyben részesítése egy terv követésével szemben

Habár a jobb oldali elemekben is van érték, mi sokkal értékesebbnek tartjuk a bal oldali elemeket.[2]
Kent Beck James Grenning Robert C. Martin
Mike Beedle Jim Highsmith Steve Mellor
Arie van Bennekum Andrew Hunt Ken Schwaber
Alistair Cockburn Ron Jeffries Jeff Sutherland
Ward Cunningham Jon Kern Dave Thomas
Martin Fowler Brian Marick

© 2001, a fenti szerzők. Ez a nyilatkozat szabadon másolható bármilyen formában, de csak teljes egészében ezen megjegyzéssel együtt.

A kiáltvány bal oldali elemeinek jelentései:

  • Egyének és kölcsönhatások: önszerveződés és motiváció nagyon fontos: az olyan kölcsönhatások mint szoros egymás melletti elhelyezkedés és páros programozás.
  • Működő szoftver: működő szoftver sokkal hasznosabb és üdvözlendőbb, mint a dokumentációk bemutatása az ügyfélnek a megbeszéléseken
  • Ügyféllel való együttműködés: a követelményeket nem lehet teljesen összegyűjteni a szoftver fejlesztési ciklus elején, így a folyamatos ügyfél vagy érdekeltek bevonása nagyon fontos.
  • Változásokra adandó válasz: az agilis módszerek a változásokra adandó gyors válaszokra és a folyamatos fejlesztésre koncentrálnak.[11]

Néhány szerző megalakította az Agilis Szövetséget (angolul Agile Alliance), amely egy nonprofit szervezet, amely segíti a szoftverfejlesztést a kiáltvány értékei és alapelvei szerint.

Agilis szoftverfejlesztés elvei[szerkesztés]

Az Agilis Kiáltvány 12 alapelven nyugszik:[12]

  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

Fejlődési irányok[szerkesztés]

Áttekintés[szerkesztés]

Páros programozás, egy XP által használt agilis fejlesztési technika.

Számos konkrét agilis fejlesztési módszer létezik. Legtöbbjük elősegíti a fejlesztést, csoportmunkát, együttműködést és folyamat alkalmazkodását a projekt életciklusán keresztül.

Ismétlődő, növekményes és evolúciós[szerkesztés]

A legtöbb agilis módszer lebontja a feladatot kisebb inkrementumokra (részfeladatokra), amelyek minimális tervezést igényelnek, ezért nem szükséges hosszú távú tervek kidolgozása. Egy fejlesztési ciklus (azaz iteráció) általában 1-4 hétig tart. Ezt az időtartamot idődoboznak hívjuk. Minden iteráció egy összetett fejlesztői csoport feladata, amely a tervezéstől, elemzéstől a programozáson át a tesztelésig és átvételi tesztig mindent elvégez. Az iteráció végén bemutatják a futtatható változatot a megrendelőnek. Így minimalizálhatóak a hosszú fejlesztésből fakadó kockázatok, és a projekt gyorsan alkalmazkodhat a változásokhoz. Egy-egy inkrementum talán nem alkalmas az értékesítésre önmagában, azonban cél, hogy minden fejlesztési ciklus végén bug-mentes program készüljön el. A módszer ismétlődésen alapul (minden iterációban azonos szakaszokon megy végig a fejlesztőcsoport), és növekményes, mert mindig a már elkészült prototípust egészítik ki.[13][14]

Hatékony és szemtől-szembe való kommunikáció[szerkesztés]

Az agilis módszerek nagyobb hangsúlyt fektetnek a közvetlen, mint az írásbeli kommunikációra. A csapatok mérete ezért 5-9 fő ideális esetben, ennél nagyobb csapatban nem alakul ki a csapatszellem, vagy több csapatot kell létrehozni, amelyek között kommunikációs problémák léphetnek fel. A csapattagok ideális esetben egy térben dolgoznak, és vegyes összetételűek, pl. programozók és tesztelők.

Minden csapatban van egy delegált a megrendelő részéről, a Scrum módszerben ő a product owner. A fejlesztés egész ideje alatt rendelkezésre áll, hogy a felmerülő kérdéseket megválaszolja.[15] Az iterációs szakasz végén a fejlesztők és a megbízó delegáltja együtt kiértékelik az elkészült prototípust. A megbízótól érkező személy fontos feladata, hogy az elkészítendő funkciókat fontossági sorrendjét felállítsa üzleti szempontból (megtérülési mutató, azaz return of investment - ROI). A fejlesztői csapat a legmagasabb prioritású funkciókat veszi előre.[16]

Az agilis szoftverfejlesztésben általában elhelyeznek az iroda egyik feltűnő pontján egy általában nagyméretű információs táblát (information radiator). Ezen mindenki láthatja a szoftver vagy más termék projektje fejlesztésének naprakész állapotát.[17][18] A kifejezést Alistair Cockburn alkotta meg és írta le 2002-es könyvében, az Agilis szoftverfejlesztésben.[18] Egy úgynevezett build light indicator (a projekt elkészültségi fokára utaló fényjelző) szintén tájékoztathatja a csapat tagjait a feladat állásáról.

Nagyon rövid visszajelzési és alkalmazkodási ciklus[szerkesztés]

Összpontosítás a minőségre[szerkesztés]

Speciális eszközök és technikák, mint pl. a folyamatos integráció, automatikus egység tesztelés, páros programozás, teszt vezérelt fejlesztés, tervezési minták, domain vezérelt tervezés, kód refaktorálás és más technikákat gyakran használják a minőség javítására és a projekt agilitás fokozására.

Filozófia[szerkesztés]

A hagyományos szoftvertervezési filozófiákkal szemben az agilis szoftver fejlesztés a komplex rendszereket és projekteket dinamikus, nemdeterminisztikus és nemlineáris módon célozza, ahol a pontos becslés, a stabil terv és az előrejelzés korai stádiumban gyakran nehezen megvalósítható, ezért a nagyszabású előre elkészített tervek és lebontások valószínűleg hatalmas veszteséggel járnak abban az értelemben, hogy gazdaságilag (üzletileg) nem megalapozottak. Ezek az alapvető érvek, és a korábbi iparági tapasztalatok, éveken át tartó próbálkozások sikerei és kudarcai segítettek kidolgozni az agilis szoftverfejlesztésnek kedvező adaptív, iteratív és evoluciós fejlesztést.[19]

Alkalmazkodás kontra előre jelezhetőség[szerkesztés]

Ismétlődés kontra vízesés modell[szerkesztés]

Kód kontra dokumentáció[szerkesztés]

Agilis módszerek[szerkesztés]

Agilis gyakorlatok[szerkesztés]

Módszer átszabás[szerkesztés]

Comparison with other methods[szerkesztés]

Nagyméretű és elosztott agilis fejlesztés[szerkesztés]

Tapasztalat és átvétel[szerkesztés]

Jegyzetek[szerkesztés]

  1. What is Agile Software Development?. Agile Alliance, 2013. június 8. (Hozzáférés: 2015. április 4.)
  2. ^ a b c Beck, Kent: Manifesto for Agile Software Development. Agile Alliance, 2001. (Hozzáférés: 2010. június 14.)
  3. Martin, James (1991). Rapid Application Development. Macmillan. ISBN 0-02-376775-8.
  4. Kerr, James M.; Hunter, Richard (1993). Inside RAD: How to Build a Fully Functional System in 90 Days or Less. McGraw-Hill. ISBN 0-07-034223-7 p.3
  5. ^ a b Gerald M. Weinberg, as quoted in Larman, Craig (2003. június 1.). „Iterative and Incremental Development: A Brief History”. Computer 36 (6), 47–56. o. DOI:10.1109/MC.2003.1204375. ISSN 0018-9162. „We were doing incremental development as early as 1957, in Los Angeles, under the direction of Bernie Dimsdale at IBM's Service Bureau Corporation. He was a colleague of John von Neumann, so perhaps he learned it there, or assumed it as totally natural. I do remember Herb Jacobs (primarily, though we all participated) developing a large simulation for Motorola, where the technique used was, as far as I can tell ... All of us, as far as I can remember, thought waterfalling of a huge project was rather stupid, or at least ignorant of the realities. I think what the waterfall description did for us was make us realize that we were doing something else, something unnamed except for 'software development.'” 
  6. Edmonds, E. A. (1974). „A Process for the Development of Software for Nontechnical Users as an Adaptive System”. General Systems 19, 215–18. o.  
  7. Note by Edmonds: I presented these ideas in London in 1970 and first submitted the paper to the Journal Computer Aided Design. It was rejected with the comment "If you don't know what you are going to do before you start you shouldn't start"! Only then did I submit it to General Systems.
  8. Evolutionary Project Management. Gilb
  9. Larman, Craig. Agile and Iterative Development: A Manager's Guide. Addison-Wesley, 27. o (2004). ISBN 978-0-13-111155-4 
  10. "a"-vs-agile-lowercase-"a" Agile With a Capital "A" Vs. agile With a Lowercase "a". Rally, 2010. (Hozzáférés: 2015. március 31.)
  11. Ambler, S.W. "Examining the Agile Manifesto". Hozzáférés ideje: 6 April 2011.
  12. Beck, Kent: Principles behind the Agile Manifesto. Agile Alliance, 2001. [2010. június 14-i dátummal az eredetiből archiválva]. (Hozzáférés: 2010. június 6.)
  13. Beck, Kent (1999). „Embracing Change with Extreme Programming”. Computer 32 (10), 70–77. o. DOI:10.1109/2.796139.  
  14. Jegyzet a projekt labor című tárgyhoz. Eger: Eszterházy Károly Főiskola, 46-18.. o (2012. július 15.). Hozzáférés ideje: 2016. április 17. 
  15. Gauthier, Alexandre: What is scrum. Planbox, 2011. augusztus 17.
  16. Jegyzet a projekt labor című tárgyhoz. Eger: Eszterházy Károly Főiskola, 48.. o (2012. július 15.). Hozzáférés ideje: 2016. április 17. 
  17. Cockburn, Alistair: Information radiator
  18. ^ a b Ambler, Scott. Agile Modeling: Effective Practices for EXtreme Programming and the Unified Process. John Wiley & Sons, 12, 164, 363. o (2002. április 12.). ISBN 978-0-471-20282-0 
  19. Larman, Craig (2004): Agile and Iterative Development: A Manager's Guide. Addison-Wesley, p.27.

További olvasnivaló[szerkesztés]

További információk[szerkesztés]

Wikikönyvek
Az angol Wikikönyvekben
további információk találhatók