Agilis szoftverfejlesztés
Az agilis szoftverfejlesztés a szoftverfejlesztési módszerek egy csoportja, ahol a szoftverkövetelmények és a megoldások együttműködésen keresztül együtt fejlődnek az önszerveződő és keresztfunkcioná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 a változásokra adható gyors és rugalmas válaszokra.

A Kiáltvány az agilis szoftverfejlesztésért, 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 és James Kerr et al. definiálta.

Története

Elődök
A növekményes szoftverfejlesztési módszerek egészen 1957-ig vezethetők vissza. 1974-ben E. A. Edmonds írt egy dolgozatot, amelyben bevezetett egy alkalmazkodó szoftverfejlesztési folyamatot. Ezzel párhuzamosan, és teljesen függetlenül ugyanazt a módszert fejlesztette ki és alkalmazta a 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. 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-orientá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. Ezek a pehelysúlyú módszerek a következők voltak: 1994-ből a Unified Process és a dinamikus rendszerfejlesztési 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 az adaptív szoftverfejlesztés és a funkcióvezérelt fejlesztés. Habár ezek a Kiáltvány az agilis szoftverfejlesztésért 2001-es közzététele előttről származnak, mostanra együttesen hivatkoznak rájuk, mint agilis módszerekre; és gyakran rövidítik egyszerűen Agilisnek, nagy kezdő A-val.

Érdemes megjegyezni, hogy az agilis jelző csak részben fedi a Kiáltvány az agilis szoftverfejlesztésért-ben megfogalmazottakat, az adaptív, alkalmazkodóképes jelzők pontosabban jellemzik az alapvető értékeket. Ezért is szoktuk inkább nagy kezdőbetűvel írni, ha a Kiáltványra és annak értelmezésére gondolunk.

Kiáltvány az agilis szoftverfejlesztésért
2001 februárjában 17 szoftverfejlesztési szakértő (lásd alább) találkozott Snowbird Üdülőközpontban Utah-ban, hogy megbeszéljék a tapasztalataikat a pehelysúlyú szoftverfejlesztési módszerekkel kapcsolatban. Megfogalmazták és kiadták az alábbi kiáltványt: Kiáltvány az agilis szoftverfejlesztésért

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

Agilis szoftverfejlesztés elvei
A S.O.L.I.D. alapelvek adják az agilis szoftverfejlesztés alapját.

Áttekintés

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

A legtöbb agilis módszer lebontja a feladatot kisebb feladatokra. Egy fejlesztési ciklus (azaz iteráció vagy sprint) maximum 4 hétig tart. Ezt az időtartamot idődoboznak hívjuk. Minden iterációban lévő feladat elkészítése egy keresztfunkcionális 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 az elkészült feladatokat a megrendelőnek. Így minimalizálhatóak a hosszú fejlesztésből fakadó kockázatok, és a projekt gyorsan alkalmazkodhat a változásokhoz. A növekmény talán nem alkalmas az értékesítésre önmagában, azonban cél, hogy minden fejlesztési ciklus végén potenciálisan szállítható termék készüljön el. A módszer ismétlődésen (iteráción) alapul (minden alkalommal azonos szakaszokon megy végig a fejlesztőcsoport), és növekményes (inkrementális), mert mindig a már elkészült növekményt egészítik ki.

Eredményes és szemtől-szembe való kommunikáció

Az agilis módszerek nagyobb hangsúlyt fektetnek a közvetlen, mint az írásbeli kommunikációra. A csapatok mérete ezért 3-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 kereszt-funkcionálisak, ami azt jelenti, hogy a csapat rendelkezik azokkal a készségekkel, amelyek szükségesek a feladat, munka vagy projekt elvégzéséhez.

Minden csapatban van egy delegált a megrendelő részéről, a Scrum keretrendszerben ő a Terméktulajdonos (angolul Product Owner). A fejlesztés egész ideje alatt rendelkezésre áll, hogy a felmerülő kérdéseket megválaszolja. Az iterációs szakasz végén a fejlesztők és a megbízó delegáltja együtt kiértékelik a növekményt. 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.

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. A kifejezést Alistair Cockburn alkotta meg és írta le 2002-es könyvében, az Agilis szoftverfejlesztésben. 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

Összpontosítás a minőségre
Speciális eszközöket és technikákat, mint pl. a folyamatos integráció, automatikus egységtesztelés, páros programozás, tesztvezérelt fejlesztés, tervezési minták, domainvezérelt tervezés, kódrefaktorálás és másokat gyakran használnak a minőség javítására és a projektagilitás fokozására.

Filozófia
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.

Iterációs kontra vízesésmodell 

Az agilis és a vízeséses módszertanok közötti egyik fő különbség az, hogy hogyan tekintenek a minőség és a tesztelés kérdéskörére. A vízesésmodell mindig külön-külön tesztelési és építési (build) szakaszt definiál; ezzel szemben az agilis szoftverfejlesztés során a tesztelés rendszerint a tényleges fejlesztési (programozási) munkával egyidejűleg, vagy legalábbis ugyanazon iterációban zajlik.

Mivel a tesztelés minden, a szoftver egy-egy kicsiny részét előállító iterációnak része, a felhasználóknak sűrűbben lesz lehetőségük az új részeket használatba venni, és megismerni azok működését.

Miután a felhasználók pontos képet kapnak a továbbfejlesztett szoftver működéséről, jobb döntéseket tudnak hozni a szoftver jövőjéről. Azzal, hogy minden iterációban visszatekintő (retrospektív) és tervezési megbeszéléseket tartunk — a scrum módszertan szerint például általában kéthetente —, segítjük a fejlesztőket abban, hogy a terveket a lehető legcélszerűbb, leghasznosabb módon valósíthassák meg.

Ez az iteratív gyakorlat a vízesésmodell projektalapú szemléletmódjával szemben a terméket helyezi előtérbe. A szoftverre, mintegy élő szervezetként tekint, amely a környezet változásaira maga is változásokkal reagál. A szoftver teljes életútján, különösen pedig versenyhelyzetekben jelentkeznek változási igények; az iteratív szoftverfejlesztés ezen változások megvalósításának a kulcsa. Ugyanezért érdemi módosítások nélkül korlátozottan alkalmazható olyan környezetben (pl. orvostechnika), ahol a fejlesztési folyamatra, valamint a termékre vonatkozóan nagy számú változatlan, sőt megváltoztathatatlan – a projekt szervezet szempontjából – külső (pl. hatósági) követelmény van jelen.

Agilis szoftverfejlesztési módszerek 

Az agilis szoftverfejlesztési módszerek a szoftverfejlesztési életciklus széles körét támogatják.  Néhányuk a gyakorlatokra összpontosít (pl. XP, pragmatikus programozás, agilis modellezés), míg mások a munkafolyamat menedzsmentjére összpontosítanak (pl. Scrum, Kanban). Néhány támogató tevékenység a követelmények meghatározásához és fejlesztéséhez (például FDD), míg mások a teljes fejlesztési életciklus lefedésére törekszenek (például DSDM,  RUP).

A főbb agilis szoftverfejlesztési keretrendszerek, módszerek az alábbiak:

Agilis szoftverfejlesztési gyakorlatok 

Az agilis szoftverfejlesztést számos konkrét gyakorlat támogatja, amelyek olyan területeket ölelnek fel, mint a követelmények, a tervezés, modellezés, kódolás, tesztelés, tervezés, kockázatkezelés, folyamat, minőség stb. Néhány figyelemre méltó agilis szoftverfejlesztési gyakorlat a következőket foglalja magában:

Az agilis módszertan terjedése más területeken

Az agilis megközelítést már nem csak a szoftver-, de a szervezetfejlesztés is alkalmazza. Terjedését az indokolja, hogy a módszertan jó választ ad a mai korra jellemző bizonytalanságra és komplexitásra. A módszertan használatával ugyanis általánosságban is gyorsabb a termékfejlesztés, nem csak a szoftver esetében. Gyorsabban lehet választ találni a piaci változásokra és magasabb termelékenység érhető el, mint hagyományos módon.
  
Ezért a legkülönfélébb ágazatokban vannak már példák a szervezet agilissá való alakítására, vagyis agilis transzformációra. Ilyenkor az alapoktól átgondolják a folyamatokat és kultúraváltásra is szükség van. Nem véletlen, hogy elsősorban olyan szervezetek vállalkoznak erre, ahol már az IT fejlesztés is agilis módon történik.

Jegyzetek

További olvasnivaló
 Abrahamsson, P., Salo, O., Ronkainen, J., & Warsta, J. (2002). Agile Software Development Methods: Review and Analysis. VTT Publications 478.
 Cohen, D., Lindvall, M., & Costa, P. (2004). An introduction to agile methods. In Advances in Computers (pp. 1–66). New York: Elsevier Science.
 Dingsøyr, Torgeir, Dybå, Tore and Moe, Nils Brede (ed.): Agile Software Development: Current Research and Future Directions, Springer, Berlin Heidelberg, 2010.
 Fowler, Martin. Is Design Dead?. Appeared in Extreme Programming Explained, G. Succi and M. Marchesi, ed., Addison-Wesley, Boston. 2001.
 Larman, Craig and Basili, Victor R. Iterative and Incremental Development: A Brief History  IEEE Computer, June 2003
 Riehle, Dirk. A Comparison of the Value Systems of Adaptive Software Development and Extreme Programming: How Methodologies May Learn From Each Other. Appeared in Extreme Programming Explained, G. Succi and M. Marchesi, ed., Addison-Wesley, Boston. 2001.
 M. Stephens, D. Rosenberg. Extreme Programming Refactored: The Case Against XP. Apress L.P., Berkeley, California. 2003. ()
 Shore, J., & Warden S. (2008). The Art of Agile Development. O'Reilly Media, Inc.
 Willison, Brian (2008). Iterative Milestone Engineering Model. New York, NY.
 Willison, Brian (2008). Visualization Driven Rapid Prototyping. Parsons Institute for Information Mapping.
Csaba Zoltán, Mizsei Szabolcs (2019): Kiáltvány az agilis módszertani zaklatás ellen 

 Two Ways to Build a Pyramid , John Mayo-Smith (VP Of Technology At R/GA), October 22, 2001
 The New Methodology Martin Fowler's description of the background to agile methods
 Ten Authors of The Agile Manifesto Celebrate its Tenth Anniversary
https://www.horvath-partners.com/hu/media-center/cikkek/12-jo-tanacs-agilis-transzformaciohoz/
https://hu.asystems.as/konferencia-ne-legyen-az-agile-fragile/
https://www.pmi.org/learning/library/agile-problems-challenges-failures-5869
https://www.infoq.com/articles/agile-agile-blah-blah/
https://ronjeffries.com/articles/018-01ff/abandon-1/

További információk

 Agile Manifesto
 Agnostic Agile alapelvek
 Heart of Agile
 Agile Rapid Website Development
 https://age-of-product.com/sprint-anti-patterns/
 

 agilepatterns.org

Szoftverfejlesztés
Szoftverfejlesztési módszertanok
Az agilis szoftverfejlesztés a szoftverfejlesztési módszerek egy csoportja , ahol a szoftverkövetelmények és a megoldások együttműködésen keresztül együtt fejlődnek az önszerveződő és keresztfunkcioná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 a változásokra adható gyors és rugalmas válaszokra . A Kiáltvány az agilis szoftverfejlesztésért , előszörben vezette be az agilis kifejezést a szoftverfejlesztés keretében . Habár mindez ez a DuPont-nál aas évek közepén fejlesztett technikákból fejlődött ki és később James Martin és James Kerr et al. definiálta . Története Elődök A növekményes szoftverfejlesztési módszerek egészenig vezethetők vissza.ben E. A . Edmonds írt egy dolgozatot , amelyben bevezetett egy alkalmazkodó szoftverfejlesztési folyamatot . Ezzel párhuzamosan , és teljesen függetlenül ugyanazt a módszert fejlesztette ki és alkalmazta a New York Telefon Társaság Rendszerfejlesztési Központja Dan Gielan igazgatása alatt . A koraies években Tom Gilb elkezdte publikálni az evolúciós projektmenedzsment ( EVO ) koncepcióját , amely a competitive engineering-é nőtte ki magát . Azes é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 azes évek közepén válaszul a nehézsúlyú vízesés-orientá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 . Ezek a pehelysúlyú módszerek a következők voltak: ből a Unified Process és a dinamikus rendszerfejlesztési módszer ( angol rövidítéssel DSDM) ;ből a Scrum;ból a crystal clear és az extrém programozás ( angol rövidítéssel XP ) ésből az adaptív szoftverfejlesztés és a funkcióvezérelt fejlesztés . Habár ezek a Kiáltvány az agilis szoftverfejlesztésértes közzététele előttről származnak , mostanra együttesen hivatkoznak rájuk , mint agilis módszerekre ; és gyakran rövidítik egyszerűen Agilisnek , nagy kezdő A-val . Érdemes megjegyezni , hogy az agilis jelző csak részben fedi a Kiáltvány az agilis szoftverfejlesztésért-ben megfogalmazottakat , az adaptív , alkalmazkodóképes jelzők pontosabban jellemzik az alapvető értékeket . Ezért is szoktuk inkább nagy kezdőbetűvel írni , ha a Kiáltványra és annak értelmezésére gondolunk . Kiáltvány az agilis szoftverfejlesztésért 2001 februárjábanszoftverfejlesztési szakértő ( lásd alább ) találkozott Snowbird Üdülőközpontban Utah-ban , hogy megbeszéljék a tapasztalataikat a pehelysúlyú szoftverfejlesztési módszerekkel kapcsolatban . Megfogalmazták és kiadták az alábbi kiáltványt : Kiáltvány az agilis szoftverfejlesztésért Néhány szerző megalakította az Agilis Szövetséget ( angolul Agile Alliance ) , egy nonprofit szervezetet , amely segíti a szoftverfejlesztést a kiáltvány értékei és alapelvei szerint . Agilis szoftverfejlesztés elvei A S.O.L.I.D. alapelvek adják az agilis szoftverfejlesztés alapját . Áttekintés 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 A legtöbb agilis módszer lebontja a feladatot kisebb feladatokra . Egy fejlesztési ciklus ( azaz iteráció vagy sprint ) maximumhétig tart . Ezt az időtartamot idődoboznak hívjuk . Minden iterációban lévő feladat elkészítése egy keresztfunkcionális 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 az elkészült feladatokat a megrendelőnek . Így minimalizálhatóak a hosszú fejlesztésből fakadó kockázatok , és a projekt gyorsan alkalmazkodhat a változásokhoz . A növekmény talán nem alkalmas az értékesítésre önmagában , azonban cél , hogy minden fejlesztési ciklus végén potenciálisan szállítható termék készüljön el . A módszer ismétlődésen ( iteráción ) alapul ( minden alkalommal azonos szakaszokon megy végig a fejlesztőcsoport ) , és növekményes ( inkrementális ) , mert mindig a már elkészült növekményt egészítik ki . Eredményes és szemtől-szembe való kommunikáció Az agilis módszerek nagyobb hangsúlyt fektetnek a közvetlen , mint az írásbeli kommunikációra . A csapatok mérete ezértfő 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 kereszt-funkcionálisak , ami azt jelenti , hogy a csapat rendelkezik azokkal a készségekkel , amelyek szükségesek a feladat , munka vagy projekt elvégzéséhez . Minden csapatban van egy delegált a megrendelő részéről , a Scrum keretrendszerben ő a Terméktulajdonos ( angolul Product Owner ) . A fejlesztés egész ideje alatt rendelkezésre áll , hogy a felmerülő kérdéseket megválaszolja . Az iterációs szakasz végén a fejlesztők és a megbízó delegáltja együtt kiértékelik a növekményt . 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 . 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 . A kifejezést Alistair Cockburn alkotta meg és írta lees könyvében , az Agilis szoftverfejlesztésben . 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 Összpontosítás a minőségre Speciális eszközöket és technikákat , mint pl. a folyamatos integráció , automatikus egységtesztelés , páros programozás , tesztvezérelt fejlesztés , tervezési minták , domainvezérelt tervezés , kódrefaktorálás és másokat gyakran használnak a minőség javítására és a projektagilitás fokozására . Filozófia 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 . Iterációs kontra vízesésmodell Az agilis és a vízeséses módszertanok közötti egyik fő különbség az , hogy hogyan tekintenek a minőség és a tesztelés kérdéskörére . A vízesésmodell mindig külön-külön tesztelési és építési ( build ) szakaszt definiál ; ezzel szemben az agilis szoftverfejlesztés során a tesztelés rendszerint a tényleges fejlesztési ( programozási ) munkával egyidejűleg , vagy legalábbis ugyanazon iterációban zajlik . Mivel a tesztelés minden , a szoftver egy-egy kicsiny részét előállító iterációnak része , a felhasználóknak sűrűbben lesz lehetőségük az új részeket használatba venni , és megismerni azok működését . Miután a felhasználók pontos képet kapnak a továbbfejlesztett szoftver működéséről , jobb döntéseket tudnak hozni a szoftver jövőjéről . Azzal , hogy minden iterációban visszatekintő ( retrospektív ) és tervezési megbeszéléseket tartunk — a scrum módszertan szerint például általában kéthetente — , segítjük a fejlesztőket abban , hogy a terveket a lehető legcélszerűbb , leghasznosabb módon valósíthassák meg . Ez az iteratív gyakorlat a vízesésmodell projektalapú szemléletmódjával szemben a terméket helyezi előtérbe . A szoftverre , mintegy élő szervezetként tekint , amely a környezet változásaira maga is változásokkal reagál . A szoftver teljes életútján , különösen pedig versenyhelyzetekben jelentkeznek változási igények ; az iteratív szoftverfejlesztés ezen változások megvalósításának a kulcsa . Ugyanezért érdemi módosítások nélkül korlátozottan alkalmazható olyan környezetben ( pl. orvostechnika ) , ahol a fejlesztési folyamatra , valamint a termékre vonatkozóan nagy számú változatlan , sőt megváltoztathatatlan – a projekt szervezet szempontjából – külső ( pl . hatósági ) követelmény van jelen . Agilis szoftverfejlesztési módszerek Az agilis szoftverfejlesztési módszerek a szoftverfejlesztési életciklus széles körét támogatják . Néhányuk a gyakorlatokra összpontosít ( pl. XP , pragmatikus programozás , agilis modellezés ) , míg mások a munkafolyamat menedzsmentjére összpontosítanak ( pl . Scrum , Kanban ) . Néhány támogató tevékenység a követelmények meghatározásához és fejlesztéséhez ( például FDD ) , míg mások a teljes fejlesztési életciklus lefedésére törekszenek ( például DSDM , RUP ) . A főbb agilis szoftverfejlesztési keretrendszerek , módszerek az alábbiak : Agilis szoftverfejlesztési gyakorlatok Az agilis szoftverfejlesztést számos konkrét gyakorlat támogatja , amelyek olyan területeket ölelnek fel , mint a követelmények , a tervezés , modellezés , kódolás , tesztelés , tervezés , kockázatkezelés , folyamat , minőség stb . Néhány figyelemre méltó agilis szoftverfejlesztési gyakorlat a következőket foglalja magában : Az agilis módszertan terjedése más területeken Az agilis megközelítést már nem csak a szoftver- , de a szervezetfejlesztés is alkalmazza . Terjedését az indokolja , hogy a módszertan jó választ ad a mai korra jellemző bizonytalanságra és komplexitásra . A módszertan használatával ugyanis általánosságban is gyorsabb a termékfejlesztés , nem csak a szoftver esetében . Gyorsabban lehet választ találni a piaci változásokra és magasabb termelékenység érhető el , mint hagyományos módon . Ezért a legkülönfélébb ágazatokban vannak már példák a szervezet agilissá való alakítására , vagyis agilis transzformációra . Ilyenkor az alapoktól átgondolják a folyamatokat és kultúraváltásra is szükség van . Nem véletlen , hogy elsősorban olyan szervezetek vállalkoznak erre , ahol már az IT fejlesztés is agilis módon történik . Jegyzetek További olvasnivaló Abrahamsson , P. , Salo , O. , Ronkainen , J. , & Warsta , J. Agile Software Development Methods : Review and Analysis . VTT Publications Cohen , D. , Lindvall , M. , & Costa , P. An introduction to agile methods . In Advances in Computers ( pp . 1–66 ) . New York : Elsevier Science . Dingsøyr , Torgeir , Dybå , Tore and Moe , Nils Brede ( ed . ) : Agile Software Development : Current Research and Future Directions , Springer , Berlin Heidelberg , Fowler , Martin . Is Design Dead ? . Appeared in Extreme Programming Explained , G. Succi and M. Marchesi , ed . , Addison-Wesley , Boston . Larman , Craig and Basili , Victor R. Iterative and Incremental Development : A Brief History IEEE Computer , June Riehle , Dirk . A Comparison of the Value Systems of Adaptive Software Development and Extreme Programming : How Methodologies May Learn From Each Other . Appeared in Extreme Programming Explained , G. Succi and M. Marchesi , ed . , Addison-Wesley , Boston . M. Stephens , D. Rosenberg . Extreme Programming Refactored : The Case Against XP. Apress L.P. , Berkeley , California . ( ) Shore , J. , & Warden S. The Art of Agile Development . O'Reilly Media , Inc . Willison , Brian Iterative Milestone Engineering Model . New York , NY. Willison , Brian Visualization Driven Rapid Prototyping . Parsons Institute for Information Mapping . Csaba Zoltán , Mizsei Szabolcs Kiáltvány az agilis módszertani zaklatás ellen Two Ways to Build a Pyramid , John Mayo-Smith ( VP Of Technology At R/GA ) , October The New Methodology Martin Fowler's description of the background to agile methods Ten Authors of The Agile Manifesto Celebrate its Tenth Anniversary https://www.horvath-partners.com/hu/media-center/cikkek/12-jo-tanacs-agilis-transzformaciohoz/ https://hu.asystems.as/konferencia-ne-legyen-az-agile-fragile/ https://www.pmi.org/learning/library/agile-problems-challenges-failures-5869 https://www.infoq.com/articles/agile-agile-blah-blah/ https://ronjeffries.com/articles/018-01ff/abandon-1/ További információk Agile Manifesto Agnostic Agile alapelvek Heart of Agile Agile Rapid Website Development https://age-of-product.com/sprint-anti-patterns/ agilepatterns.org Szoftverfejlesztés Szoftverfejlesztési módszertanok