Agilis fejlesztési módszertan

Az agilis fejlesztési módszertan ( angolul  agile software development , agile development ) egy általános kifejezés számos megközelítésre és gyakorlatra, amelyek az Agilis Szoftverfejlesztési Kiáltvány értékein és az azt megalapozó 12 alapelven alapulnak [1] .

Az agilis módszertanok közé tartozik különösen az extrém programozás , a DSDM , a Scrum , az FDD , a BDD és mások.

A legtöbb agilis módszertan célja a kockázat minimalizálása azáltal, hogy a fejlesztést rövid ciklusokra, úgynevezett iterációkra csökkenti, amelyek általában két-három hétig tartanak. Minden iteráció úgy néz ki, mint egy miniatűr szoftverprojekt, és magában foglalja az összes olyan feladatot, amely a funkcionalitás mini-növekedéséhez szükséges: tervezés, követelményelemzés , tervezés , programozás , tesztelés és dokumentáció . Bár egyetlen iteráció általában nem elegendő egy termék új verziójának kiadásához, feltételezzük, hogy egy agilis szoftverprojekt minden iteráció végén készen áll a kiadásra. Minden iteráció végén a csapat újraértékeli a fejlesztési prioritásokat.

Az agilis módszerek a szemtől szembeni kommunikációt hangsúlyozzák. A legtöbb agilis csapat ugyanabban az irodában található, amelyet néha mérnöknek is neveznek .  bullpen . Minimum magában foglalja a „vevőket” is ( angol  terméktulajdonos  - a vevő vagy meghatalmazott képviselője, aki meghatározza a termék követelményeit; ezt a szerepet projektmenedzser, üzleti elemző vagy ügyfél is elláthatja). Az irodában tesztelők, felülettervezők, műszaki írók és vezetők is lehetnek.

Az agilis módszerek fő mérőszáma a munkatermék. A személyes kommunikáció előtérbe helyezésével az agilis módszerek csökkentik az írásos dokumentáció mennyiségét más módszerekhez képest. Ez oda vezetett, hogy ezeket a módszereket fegyelmezetlennek minősítették.

Történelem

Az 1990-es években számos könnyű szoftverfejlesztési módszer fejlődött ki, válaszul az uralkodó nehéz módszerekre, amelyeket a kritikusok túlszabályozottnak, tervezettnek és mikromenedzseltnek neveztek. Ezek a következők: Rapid Application Development (RAD) 1991 óta [2] [3] ; egységes folyamat és módszer a dinamikus rendszerek fejlesztésére 1994 óta; Scrum, 1995 óta; Crystal Clear és Extreme Programming (XP), mindkettő 1996 óta; és funkció-orientált fejlesztés 1997 óta. Bár mindegyik az Agilis Kiáltvány megjelenése előtt keletkezett, manapság összefoglalóan agilis szoftverfejlesztésnek nevezik őket.

2001 februárjában Utah államban (USA) adták ki az " Agile Software Development Manifesto "-t . Alternatívát jelentett a dokumentumvezérelt „nehézsúlyú” szoftverfejlesztési gyakorlatokkal szemben, mint például a „ vízesés módszer ”, amely akkoriban a fejlesztés aranystandardja volt. Ezt a kiáltványt a következő módszerek képviselői hagyták jóvá és írták alá: Extreme Programing , Crystal Clear , DSDM , Feature driven development , Scrum , Adaptív szoftverfejlesztés , Pragmatic Programming . Az agilis fejlesztési módszertant már a kiáltvány elfogadása előtt is sok cég alkalmazta, azonban az Agilis fejlesztés tömegekbe való betörése pontosan ezt követően következett be.

Alapelvek

Az agilis fejlesztési folyamatok családja, nem egyetlen megközelítés a szoftverfejlesztésben, és az Agile Manifesto [4] határozza meg . Az agilis nem gyakorlatokat foglal magában, hanem meghatározza azokat az értékeket és elveket, amelyek irányítják a csapatokat.

Az Agile Manifesto -t 2001. február 11-13-án dolgozták ki és fogadták el a The Lodge at Snowbird síközpontban, a Utah-hegységben. Az Agilis Kiáltvány 4 fő gondolatot és 12 elvet tartalmaz. Figyelemre méltó, hogy az Agilis Kiáltvány nem tartalmaz gyakorlati tanácsokat.

Főbb ötletek:

• az emberek és az interakció fontosabbak, mint a folyamatok és az eszközök;
• a működő termék fontosabb, mint az átfogó dokumentáció;
• az ügyféllel való együttműködés fontosabb, mint a szerződés feltételeiben való megegyezés;
• a változásra való készenlét fontosabb, mint az eredeti terv követése.

Az Agilis Kiáltvány [6] alapelvei :

• a vásárlók elégedettsége az értékes szoftverek korai és megszakítás nélküli szállítása révén a legmagasabb prioritás;
• a változó igények már a fejlesztés végén is örvendetesek (ez növelheti a keletkező termék versenyképességét);
• működő szoftverek gyakori szállítása (párhetente vagy pár havonta, rövidebb időszak előnyben);
• az üzleti élet képviselői és a fejlesztők közötti kommunikációnak napi szintűnek kell lennie a projekt során;
• a projekteket érdeklődők köré kell építeni, akiknek megfelelő munkakörülményeket, támogatást és bizalmat kell biztosítani;
• a csapaton belüli információmegosztás leghatékonyabb módja a személyes találkozás;
• a működő szoftver a fejlődés legjobb mércéje;
• a szponzoroknak, a fejlesztőknek és a felhasználóknak a végtelenségig állandó tempót kell tartaniuk;
• a műszaki kiválóságra való állandó figyelem és a jó tervezés növeli a rugalmasságot;
• nagyon fontos az egyszerűség, akárcsak a felesleges munkavégzés művészete;
• a legjobb követelmények, építészeti és tervezési megoldások önszerveződő csapatoktól származnak;
• a csapat rendszeresen gondolkodik azon, hogyan javíthatná hatékonyságát, és ennek megfelelően módosítja a munkafolyamatot.

Kritika

A kritikák egyik visszatérő pontja: az agilis megközelítés gyakran figyelmen kívül hagyja a termékfejlesztési terv („roadmap”) elkészítését, valamint a követelménykezelést , amelynek során egy ilyen „térkép” kialakul. A követelménykezelés rugalmas megközelítése nem jelent messzemenő terveket (sőt, a követelménykezelés egyszerűen nem létezik ebben a módszertanban), hanem magában foglalja az ügyfél azon képességét, hogy minden iteráció végén hirtelen és váratlanul új követelményeket állítson fel, gyakran ellentmond egy már megalkotott és leszállított termék architektúrájának. Ez időnként katasztrofális „munkavégzéshez” vezet, amely szinte minden következő iterációnál hatalmas átalakítást és átdolgozást jelent .

Emellett úgy gondolják, hogy az agilis munkavégzés arra ösztönzi a fejlesztőket, hogy minden bejövő feladatot a lehető legegyszerűbb és leggyorsabb módon oldjanak meg, miközben gyakran nem figyelnek a kód helyességére a mögöttes platform követelményei szempontjából (a „működik, ill. mindent” megközelítés), ugyanakkor nem veszi figyelembe, hogy a kód további módosítása esetén leállhat. Ez a termék minőségének romlását és a hibák felhalmozódását eredményezi (lásd " Műszaki tartozás ").

Módszertanok

Vannak olyan módszerek, amelyek megfelelnek az Agilis Kiáltványban megfogalmazott értékeknek és elveknek, ezek közül néhány:

• Az Agile Modeling  olyan fogalmak, elvek és technikák (gyakorlatok) összessége, amely lehetővé teszi a szoftverfejlesztési projektekben történő modellezés és dokumentáció gyors és egyszerű végrehajtását. Nem tartalmaz részletes tervezési utasításokat, nem tartalmaz leírást az UML diagramok felépítéséről. Fő cél: hatékony modellezés és dokumentálás; de nem terjed ki a programozásra és tesztelésre, nem foglalja magában a projektmenedzsmentet, a rendszer telepítését és karbantartását. Ez azonban magában foglalja a modell ellenőrzését a [7] kóddal .
• Az Agile Unified Process (AUP) a Scott Ambler által kifejlesztett IBM Rational Unified Process ( RUP ) egyszerűsített változata, amely egy egyszerű és érthető közelítést (modellt) ír le az üzleti alkalmazásokhoz szükséges szoftverek készítéséhez.
• Az Agile Data Method  iteratív szoftverfejlesztési módszerek csoportja, amelyben a követelmények és a megoldások különböző, többfunkciós csapatok együttműködésével érhetők el.
• A DSDM a Rapid Application Development (RAD) koncepcióján alapul. Ez egy iteratív és inkrementális megközelítés, amely hangsúlyozza a felhasználó/fogyasztó folyamatos részvételét a folyamatban.
• Essential Unified Process (EssUP).
• Extrém programozás ( Extreme programozás , XP) . 
• Funkcióvezérelt fejlesztés (FDD) – szolgáltatásorientált fejlesztés. Az FDD-ben használt rendszerfunkció vagy tulajdonság fogalma meglehetősen  közel áll a RUP-ban használt használati eset fogalmához, a jelentős különbség egy további megszorítás: „minden funkciónak legfeljebb két hét alatt kell megvalósítania”. Vagyis, ha egy használati eset elég kicsi, akkor az jellemzőnek tekinthető. Ha nagy, akkor több, viszonylag független funkcióra kell osztani.
• A Getting Real  egy iteratív, nem funkcionális specifikációs megközelítés, amelyet webes alkalmazásokhoz használnak. Ennél a módszernél először a program interfészét, majd annak funkcionális részét fejlesztik ki.
• Az OpenUP  egy iteratív-növekményes szoftverfejlesztési módszer. A RUP könnyű és rugalmas változataként van elhelyezve . Az OpenUP a projekt életciklusát négy szakaszra osztja: kezdet, finomítás, építés és átadás. A projekt életciklusa referenciapontokat és döntéshozatali lehetőségeket biztosít az érdekelt feleknek és a csapattagoknak a projekt során. Ez lehetővé teszi a helyzet hatékony ellenőrzését és időben történő döntések meghozatalát az eredmények elfogadhatóságáról. A projektterv meghatározza az életciklust, és a végeredmény a végső alkalmazás.
• A Scrum szabályokat állapít meg a fejlesztési folyamat kezelésére, és lehetővé teszi a meglévő kódolási gyakorlatok használatát a követelmények módosításával vagy taktikai változtatásokkal. Ennek a módszernek a használata lehetővé teszi a kívánt eredménytől való eltérések azonosítását és kiküszöbölését a szoftvertermékfejlesztés korábbi szakaszaiban.
• A karcsú szoftverfejlesztés ( angolul  lean software development ) a karcsú gyártás koncepciójából származó megközelítéseket alkalmazza .

Jegyzetek

1. ↑ Mi az agilis szoftverfejlesztés? . Agilis Szövetség. - "Az agilis szoftverfejlesztés egy gyűjtőfogalom olyan keretrendszerekre és gyakorlatokra, amelyek az Agilis Szoftverfejlesztési Kiáltványban és a mögötte meghúzódó 12 alapelvben megfogalmazott értékeken és elveken alapulnak." Letöltve: 2019. június 29. Az eredetiből archiválva : 2018. július 31. (határozatlan)
2. ↑ Martin, James. Gyors alkalmazásfejlesztés . - Macmillan, 1991. - ISBN 978-0-02-376775-3 .
3. ↑ Kerr, James M.; Hunter, Richard. Inside RAD: Hogyan építsünk fel egy teljesen működőképes rendszert 90 nap vagy kevesebb alatt ? - McGraw-Hil, 1993. - ISBN 978-0-07-034223-1 .
4. ↑ Az Agile Manifesto archiválva : 2011. február 23. a Wayback Machine -nél 
5. ↑ Az Agilis Kiáltvány alapelvei . agilemanifesto.org. Hozzáférés dátuma: 2016. december 8. Az eredetiből archiválva : 2014. december 25. (határozatlan)
6. ↑ Agilis modellezés . Kezelés időpontja: 2011. december 25. Az eredetiből archiválva : 2008. december 31.. (határozatlan)

Irodalom

• Mike Cohn. Scrum: Agilis szoftverfejlesztés = Siker az Agile segítségével: Szoftverfejlesztés Scrum használatával (Addison-Wesley Signature Series). - M. : "Williams" , 2011. - S. 576. - ISBN 978-5-8459-1731-7 .
• Robert S. Martin, James W. Newkirk, Robert S. Koss. Gyors szoftverfejlesztés. Alapelvek, példák, gyakorlat = Agilis szoftverfejlesztés. elvek, minták és gyakorlatok. - Williams, 2004. - 752 p. — ISBN 0-13-597444-5 .
• James A. Highsmith. Agilis szoftverfejlesztési ökoszisztémák . - Addison-Wesley Professional, 2002. - ISBN 978-0-201-76043-9 .