Az extrém programozás (XP) talán a legismertebb és legszélesebb körben használt agilis módszer. A nevet Beck [16] adta, mert a megközelítés úgy fejlődött ki, hogy elismert gyakorlati alkalmazásokat erőltetett, mint például az iteratív fejlesztés és az ügyfél "extrém" részvételének használata [1,20].
A hagyományos rendszerfejlesztési módszertanokban, a rendszerrel szemben támasztott követelmények adottak a projekt elején, és gyakran nem is változnak meg. Ez azzal jár, hogy minél később kell változtatni a követelményeken, ami pedig szoftverfejlesztési projektekben a legvégén sem szokatlan, annál magasabbak lesznek a költségek.
Az XP arra törekszik, hogy ezeket a költségeket csökkentse azáltal, hogy más elveket, és gyakorlatot vezet be. Egy XP-t használó rendszerfejlesztési projekt sokkal rugalmasabb lesz a váratlanul bekövetkező változásokkal szemben. Az XP módszertana a következő alapvető értékek köré épül:
− Kommunikáció
− Egyszerűség
− Visszajelzés
− Bátorság
− Tisztelet Kommunikáció
Az egyik alapvető fontosságú feladat a szoftverrendszer készítése során, hogy a fejlesztők tudják, hogy mi lesz a fejlesztési projektben elvégzendő feladatuk. A hagyományos módszertanok során ez főként dokumentumok gyártásával történt meg. Az
39
XP módszertan egyik fő célkitűzése, hogy a fejlesztőcsapat minél gyorsabban szerezze meg a munkájához szükséges tudást és információkat. A cél az, hogy minden fejlesztő ugyanúgy lássa a rendszert, ahogy a majdani felhasználók is látni fogják. Ezért az XP előtérbe helyezi az egyszerű terveket, a majdani felhasználók, a megrendelők és a fejlesztők együttműködését, a gyakori szóbeli kommunikációt, és a visszajelzéseket. Ezt kielégítve a megrendelő a fejlesztőcsapat tagja is lehet akár napi, teljes munkaidőben.
Egyszerűség
Az XP azt a megközelítést támogatja, hogy a programfejlesztést a lehető legegyszerűbben kezdjük el, és folyamatosan dolgozzuk át a programot, hogy egyre jobb és jobb legyen. A különbség e megközelítés, és a hagyományos megközelítések között, hogy a mai követelményeknek megfelelő programot tervezünk és írunk, nem pedig a jövőbeli igényeknek megfelelőt. Az XP ellenzői ezt hátrányként fogják fel, mondván, hogy így megeshet, hogy a következő hónapban több munkába fog kerülni átdolgozni a rendszert, ha nem készültünk fel előre új követelményekre. Az egyszerűség elve viszont pontosan azt mondja, hogy a program túlbonyolódhat, ha tele lesz olyan funkciókkal, amelyekről már rég mindenki elfelejtette, hogy mire való, és a bonyolultság okozta többletmunka sokszorosan meg fogja haladni a folyamatos átdolgozás által generált munkát. Az egyszerűség megkönnyíti és elősegíti a kommunikációt, mert egy egyszerű tervet és a hozzátartozó egyszerű kódot a csapat minden programozója könnyen megért.
Visszacsatolás
Az XP módszertanban a visszacsatolás a fejlesztés több területére is vonatkozik:
− Visszajelzés a rendszertől. a részegység tesztek készítésével a programozók közvetlen visszajelzést kapnak arról, hogy milyen állapotban van a rendszer egy-egy módosítás után.
− Visszajelzés az ügyféltől. a funkcionális teszteket a programozók együtt készítik az ügyféllel, így mindketten konkrét visszajelzést kapnak arról, hogy milyen állapotban van a rendszer funkcionalitása. Ilyenfajta közös tesztelést 2-3 hetente célszerű végezni, így az ügyfélnek megvan a lehetősége a fejlesztés irányítására.
− Visszajelzés a fejlesztőktől. amikor az ügyfél új igényekkel áll elő, a fejlesztőcsapat rögtön tud rá reagálni, és visszajelzést tud adni, hogy mennyi ideig fog tartani a fejlesztés, és mennyibe fog kerülni.
Bátorság
Az XP módszertanában mindig a mai igények kielégítésére kell a programot tervezni és megírni. Ez az erőfeszítés azért szükséges, hogy ne bonyolódjunk bele a tervezésbe, és nehezítsük meg saját magunk számára a hosszú távú munkát. Bátorság kell ahhoz, hogy ne ijedjünk meg attól, hogy a kódot folyton át kell dolgozni. Az átdolgozás azt jelenti, hogy átnézzük a kódot, és olyan változtatásokat eszközölünk rajta, amik egyszerűbbé és átláthatóbbá teszik. Bátorság kell továbbá ahhoz is, hogy eldobjunk egy már megírt kódot.
Tisztelet
Az XP-ben a tiszteletnek többféle aspektusa van. Tiszteljük emberileg a fejlesztőcsapat tagjait. Tiszteljük őket azáltal is, hogy olyan minőségű munkát adunk ki a kezünkből, amely nem hátráltatja a többiek munkáját.
Az extrém programozásban minden követelményt forgatókönyvként állítanak össze, amely közvetlenül feladatok egy soraként kerül implementálásra. A programozók
40
párokban dolgoznak és minden feladatra teszteket készítenek, még mielőtt a kódot megírnák. Minden tesztnek sikeresen le kell futnia, mielőtt az új kódot elhelyeznék a rendszerben. A rendszer kiadásai között csak kis idő telik el. A 4.3. ábra az XP folyamatát mutatja be, amint a fejlesztés alatt álló rendszer egy új inkremensét állítja elő.
4.3. ábra. Az extrém programozás kiadási ciklusa
Az extrém programozásban alkalmazott gyakorlatokról a 4.1. táblázat nyújt összefoglalást.
4.1. táblázat. Extrém programozási gyakorlatok.
Fogalom Definíció
Inkrementális tervezés A követelményeket történetkártyákra jegyzik, a történeteknek egy kiadásba történő bekerülése a rendelkezésre álló időtől és a relatív prioritásuktól függ. A fejlesztők ezeket a történeteket fejlesztési feladatokra osztják.
Kisméretű kiadások Azokat a funkcionalitásokat fejlesztik először, amelyek minimálisak, hasznosak és üzleti hasznot hozhatnak. A rendszer kiadásai gyakoriak, és lépésenként adnak új funkcionalitásokat a legelső kiadáshoz.
Egyszerű tervezés Az egyszerű tervezés megvalósítja a követelményekben leírtakat, de nem többet.
Fejlesztés előrehozott teszteléssel
Automatikus, egységes tesztrendszert használnak, hogy teszteket írjanak egy új funkcionalitás ellenőrzésére, még mielőtt az implementálásra kerülne.
Újraírás, átdolgozás Minden fejlesztővel szemben elvárás, hogy folyamatosan tökéletesítse a kódot, amint arra lehetőséget lát. Ez egyszerűen kezelhetővé teszi a kódot.
Páros programozás A fejlesztők párokban dolgoznak, egymás munkáját ellenőrzik, és biztosítják a támogatást, hogy mindig jó munkát végezzenek.
Közös tulajdonjog A fejlesztőpárok a rendszer minden területén dolgoznak, ezért nincsenek fejlesztési szakterületek, és a fejlesztők közösen birtokolják az egész kódot. Bárki bármit megváltoztathat.
Folyamatos integrálás
Amint egy feladat elkészül, azt beintegrálják a teljes rendszerbe. Minden ilyen integrálás után a rendszernek az összes egységteszten meg kell felelnie.
Fenntartható iram A sok túlóra nem megfelelő, mert ez gyakran ronthatja a kód 41
minőségét és a középtávú termelékenységet.
Helyszíni ügyfél A rendszer végfelhasználója egy képviselőjének (az ügyfél) teljes munkaidőben az XP csapat rendelkezésére kell állnia. Ezért az extrém programozási folyamatban az ügyfél a fejlesztőcsapat tagja, és felelős azért, hogy a csapatot ellássa az implementációhoz szükséges rendszerkövetelményekkel.
Az XP folyamatban az ügyfél fontos szerepet játszik a rendszerkövetelmények specifikációjában és azok prioritásának meghatározásában. A rendszer megrendelője a fejlesztőcsapat tagjaként megbeszéli a forgatókönyvet a csapat többi tagjával. Közösen kifejlesztenek egy történetkártyát, ami magában foglalja az ügyfél kéréseit. A fejlesztőcsapat ezután megpróbálja implementálni a forgatókönyvet a szoftver egy jövőbeli kiadásában.
Amikor a történetkártyák elkészültek, a fejlesztőcsapat ezt feladatokra bontja, és megbecsüli az implementáláshoz szükséges időt és erőforrásokat. Az ügyfél ezután rangsorolja az implementálandó történeteket, kiválasztva azokat, amelyek azonnal felhasználhatók üzleti célok támogatására.
Az extrém programozás az iteratív fejlesztés extrém megközelítését használja.
Naponta többször is megjelenhet a szoftver egy új verziója, de az inkremensek nagyjából kéthetente kerülnek csak az ügyfélhez. Amikor a fejlesztő létrehozza a rendszer következő verzióját, minden létező automatizált teszten végig kell futtatnia, beleértve az új funkcionalitásokhoz készült teszteket is. Az új verziót pedig csak akkor lehet elfogadni, ha minden teszt sikeresen lefutott.
5.1.1 Tesztelés az XP-ben
Az iteratív fejlesztés esetén nincs rendszer-specifikáció, amit egy külső tesztelő használhatna a rendszer tesztjeinek fejlesztéséhez. Ezért az iteratív fejlesztés különböző megközelítése csak informális tesztelési folyamatokat használnak. A teszteléssel és a rendszer validálásával kapcsolatos problémák elkerülésére az XP nagyobb hangsúlyt fektet a tesztelés folyamatára, mint a többi agilis módszer. Az XP-ben történő tesztelés fő jellemzői a következők:
1. Előrehozott teszteléssel történő fejlesztés.
2. Inkrementális tesztfejlesztés a forgatókönyvek alapján.
3. Felhasználók bevonása a tesztek fejlesztésébe és a validálásba.
4. Automatizált tesztelő eszközök használata.
Az előrehozott teszteléssel történő fejlesztés az XP egyik legfontosabb eleme. Az előre elkészített tesztek meghatározzák a viselkedési specifikációt a fejlesztendő funkcionalitás számára. Az XP-ben a felhasználói követelmények forgatókönyvekként vagy történetekként jelennek meg, és a felhasználó rangsorolja ezeket a fejlesztéshez. Az ügyfél szerepe a tesztelési folyamatban az, hogy a történetekhez segítsen elfogadási teszteket fejleszteni, amelyeket a rendszer következő kiadásában implementálni kell. Az elfogadási tesztelés az a folyamat, amikor a rendszert az ügyfél adataival ellenőrizzük, hogy megfelel-e az ügyfél valódi elvárásainak.
Az XP módszertanban a teszteket hamarabb megírjuk, mint a kódot. A tesztet, mint 42
futtatható komponenst előbb írjuk meg, mint ahogy a feladatot implementálnánk. Amint a szoftver implementációja kész, rögtön futtatható rajta a teszt. Ennek a tesztelő komponensnek ellenőriznie kell, hogy a végeredmény megfelel-e a kimenet specifikációjának.
Az automatikus teszteszköz egy olyan rendszer, ami elküldi ezeket az automatikus teszteket végrehajtásra.
Az előrehozott teszteléssel történő fejlesztés esetében mindig vannak olyan előkészített tesztek, amelyek gyorsan és könnyedén futtathatók. Ez azt jelenti, hogy ahányszor egy új funkcionalitás kerül a rendszerbe, a tesztek már le is futtathatók rajta, és rögtön előjönnek azok a problémák, amelyeket az új kód okozott.
5.1.2 Páros programozás
Az XP módszertanban az egyik legfontosabb gyakorlati alkalmazás az, hogy a programozók párban dolgoznak a szoftverfejlesztés alatt. A munkatársak együtt dolgoznak egy közös munkaállomás mellett. A fejlesztés nem mindig vonja magával, hogy ugyanazok a párok dolgozzanak együtt. Az alapötlet a párok dinamikus választása, így a fejlesztési folyamat során a csapat minden tagja dolgozik párban a többi taggal. A párban való programozásnak a következő előnyei vannak:
− Támogatja a fejlesztendő rendszerre vonatkozó közös tulajdonlást és felelősségtudatot.
− Jobb kódminőséget eredményez, mert a kódot legalább két ember átnézi, amely nagyon eredményes lehet a szoftverhibák nagy százalékának a felderítésében.
− Megnövekedett fegyelemérzet
− Rugalmas munkafolyamatok, megszakítástűrés
− Több tervező, a párok cserélődhetnek
− Élvezetesebb munka egyes programozók számára
− Mentorszellem, tudás és tapasztalatterjesztés
− A munkatársak gyorsabban megismerik egymást
− Kevesebb megszakítás
− Feleannyi munkaállomás