A számítástechnika és különösen a szoftverfejlesztés , extrém programozás ( XP ) egy agilis módszer különösen orientált végrehajtásáról aspektusa egy alkalmazás, nem elhanyagolva a projekt menedzsment szempont . Az XP alkalmas változó igényű kis csapatok számára. Az XP az egyszerű elveket a végletekig kitolja.
Az extrém programozást Kent Beck , Ward Cunningham és Ron Jeffries találta fel , miközben a „C3” bérszámfejtési projekten dolgozott a Chryslernél. Kent Beck, projektmenedzser1996. március, elkezdte finomítani a projekt során alkalmazott fejlesztési módszert. Ezt hivatalosan októberben született 1999-ben a könyv Extreme Programming magyarázata szerint Kent Beck .
Az Extreme Programming Explained című könyvben a módszert a következőképpen határozzák meg:
Fő célja a változás költségeinek csökkentése. A hagyományos módszerekben az igényeket meghatározzák és gyakran rögzítik az informatikai projekt kezdetekor, ami megnöveli a módosítások későbbi költségeit. Az XP arra törekszik, hogy az alapértékek, elvek és gyakorlatok bevezetésével rugalmasabbá és nyitottabbá váljon a projekt számára.
Ennek a módszernek az alapelvei nem új keletűek: a szoftveriparban évtizedek óta, a menedzsment módszerekben pedig még hosszabb ideig léteznek. A módszer eredetisége az, hogy a végsőkig nyomja őket:
Az extrém programozás gyors fejlesztési ciklusokon alapul (néhány hetes iterációk), amelyek szakaszai a következők:
A ciklus addig ismétlődik, amíg az ügyfél forgatókönyveket tud nyújtani a teljesítéshez. Az első kézbesítést megelőző ciklust általában annak időtartama és a fedélzeti funkciók nagy mennyisége jellemzi. Az első kiadás után az iterációk rövidebbé válhatnak (például egy hét).
A jó programozási gyakorlatok hangsúlyozása mellett az XP azt javasolja, hogy rövid ismétlésekkel és együttesen, az ügyfél folyamatos bevonásával kezelje a kibontakozást. Az eredmény a vevő és a szállító közötti kapcsolat újradefiniálása , meglepő eredménnyel a kód minősége, a határidők és a vevői elégedettség szempontjából .
Az extrém programozás alapján öt alapvető értékeit.
KommunikációEz a problémák elkerülésének alapvető módja. Az XP által ajánlott gyakorlatok intenzív kommunikációt igényelnek. A tesztelés, a páros programozás és a tervező játék kommunikációra kényszeríti a fejlesztőket, a döntéshozókat és az ügyfeleket. Ha minden ellenére megjelenik egy hiány, akkor az edző felelős annak azonosításáért és ezeknek az embereknek a kapcsolatfelvételéért.
EgyszerűségAz eredmény elérésének legegyszerűbb módja a legjobb. A jövőbeni meghosszabbítások előrejelzése időpazarlás. Egy egyszerű alkalmazást könnyebb frissíteni.
VisszacsatolásA visszajelzés elengedhetetlen a programozó és az ügyfél számára. Az egységtesztek jelzik, hogy a kód működik-e. A funkcionális tesztek megadják a projekt előrehaladását. A gyakori szállítások lehetővé teszik a funkcionalitás gyors tesztelését.
BátorságNéhány változás nagy bátorságot igényel. Néha meg kell változtatnia egy projekt architektúráját, el kell dobnia a kódot a jobb előállításához, vagy új technikát kell kipróbálnia. A bátorság a kiút egy alkalmatlan helyzetből. Nehéz, de az egyszerűség, a visszajelzés és a kommunikáció hozzáférhetővé teszi ezeket a feladatokat.
TiszteletEzt az értéket adta hozzá az Extreme Programming második kiadása, magyarázata : K. Beck. Ez az érték magában foglalja a mások iránti tiszteletet, valamint az önbecsülést. A programozóknak soha nem szabad olyan változtatásokat végrehajtaniuk, amelyek megszakítják az összeállítást, a meglévő egységtesztek kudarcot okoznak, vagy késleltetik társaik munkáját. A tagok tiszteletben tartják a saját munkáját mindig keresi a minőség és a legjobb design a megoldás, és ezt át újraszervezi .
Ezt az öt értéket tizenhárom egymást erősítő gyakorlatra bontják:
Ügyfél a helyszínenAz ügyfél képviselőjének lehetőség szerint a projekt időtartama alatt jelen kell lennie. Rendelkeznie kell a végfelhasználó ismereteivel és globális jövőképpel kell rendelkeznie az elérendő eredményről. A szokásos munkáját végzi, miközben rendelkezésre áll a csapat kérdéseire.
Játék tervezés vagy póker tervezésAz ügyfél forgatókönyveket készít az elérni kívánt funkcionalitásról. A csapat felméri a megvalósításukhoz szükséges időt. Ezután az ügyfél kiválasztja a forgatókönyveket a prioritások és a rendelkezésre álló idő szerint.
Folyamatos integrációAmikor egy feladat befejeződik, a módosítások azonnal beépülnek a teljes termékbe. Ezzel elkerülhető a munka túlterhelése az összes elem szállítás előtti integrálásával kapcsolatban. A tesztelés nagyban megkönnyíti ezt az integrációt: amikor az összes teszt sikeresen teljesül, az integráció befejeződik.
Kis szállításokA szállításnak a lehető leggyakoribbnak kell lennie. A folyamatos integráció és tesztelés drámai módon csökkenti a szállítás költségeit.
Fenntartható tempóA csapat nem dolgozik túlórát. Ha ez felmerül, felül kell vizsgálni az ütemtervet. Egy fáradt fejlesztő rosszul működik.
Elfogadási tesztek (vagy funkcionális tesztek)Az ügyfél által meghatározott forgatókönyvekből a csapat teszteljárásokat hoz létre, amelyek lehetővé teszik a fejlesztés előrehaladásának ellenőrzését. Amikor az összes funkcionális teszt sikeres, az iteráció befejeződött. Ezek a tesztek gyakran automatizáltak, de ez nem mindig lehetséges.
Valójában csak a nem regressziós tesztek automatizálhatók megismétlődésük miatt.
Egy alkalmazás funkcionális receptjét egyre gyakrabban a fejlesztőktől független tesztelő szakértőkre bízzák.
EgységvizsgálatokA funkció bevezetése előtt a fejlesztő tesztet ír, amely ellenőrzi, hogy programja a várt módon viselkedik-e. Ez a teszt a projekt végéig megmarad, mindaddig, amíg a funkcionalitás szükséges. Minden alkalommal, amikor a kód módosul, lefuttatjuk az összes fejlesztő által írt tesztet, és azonnal tudjuk, ha valami már nem működik.
Egyszerű kialakításAz iteráció célja az ügyfél által kiválasztott forgatókönyvek megvalósítása, és csak ez. A következő fejlemények elképzelése időveszteséget okozna anélkül, hogy garantálná a későbbi nyereséget. A tesztek lehetővé teszik az architektúra későbbi megváltoztatását, ha szükséges. Minél egyszerűbb az alkalmazás, annál könnyebb lesz a következő iterációkban fejleszteni.
A metaforák használataA rendszer és annak működésének leírására metaforákat és analógiákat használnak. A funkcionális és a műszaki megértése sokkal jobb, ha megegyeznek az általuk használt feltételekben.
Refaktorálás (vagy a kód átdolgozása )A kód minőségének rendszeres javítása a viselkedés módosítása nélkül. Átdolgozzuk a kódot, hogy jobb alapon indulhassunk újra, ugyanazon funkciók megtartása mellett. A refaktorálási fázisok nem hoznak semmit az ügyfél számára, de lehetővé teszik a fejlesztők számára, hogy jobb körülmények között, tehát gyorsabban haladjanak előre.
A kód kollektív tulajdonjogaA csapat kollektíven felelős az alkalmazásért. Minden fejlesztő módosíthatja a kód bármely részét, még azokat is, amelyeket nem ő írt. A tesztek megmondják, ha valami már nem működik.
ElnevezésiMivel minden fejlesztő részt vesz az összes kódban, elengedhetetlen a változók, módszerek, objektumok, osztályok, fájlok stb.
Páros programozásA programozás párban történik. Az első hívott illesztőprogram (vagy pilóta ) tartja a billentyűzetet. Ő fog dolgozni a kód azon részén, amelyet írni kell. A második hívott partner (vagy másodpilóta ) segít abban, hogy új lehetőségeket javasoljon vagy felderítse a lehetséges problémákat. A fejlesztők gyakran cserélnek partnereket és szerepeket, ami javítja az alkalmazás kollektív ismeretét és javítja a csapaton belüli kommunikációt.
Ez a módszer a következőkön alapul:
A módszer hátránya helyett könnyebben olyan kedvezőtlen környezetekről fogunk beszélni, amelyekben az XP módszer nem alkalmazható.
Ebben az esetben a gyakorlatoknak csak egy része hajtható végre. A fő kedvezőtlen összefüggések a következők: