Az extrém programozás (XP) egy agilis szoftverfejlesztési módszer, amelyet szoftverprojektek megvalósítására használnak. Ez a cikk részletezi az ebben a módszertanban alkalmazott gyakorlatokat. Az extrém programozásnak 12 gyakorlata van, négy területre csoportosítva, amelyek a szoftverfejlesztés legjobb gyakorlataiból származnak.Beck, K. Extreme Programming Explained: Embrace Change 2nd. ed. Addison-Wesley, 2000 pp. 54

Finom léptékű visszajelzés

Páros programozás A páros programozás azt jelenti, hogy az összes kódot két ember állítja elő, akik egy feladatra programoznak egy munkaállomáson. Az egyik programozó irányítja a munkaállomást, és leginkább a kódoláson gondolkodik részletesen. A másik programozó jobban összpontosít a teljes képre, és folyamatosan felülvizsgálja az első programozó által előállított kódot. A programozók akár percenként, vagy óránként cserélnek szerepet.

A párok nem állandóak; A programozók gyakran cserélnek partnereket, így mindenki tudja, mit csinál, és mindenki ismeri az egész rendszert, még a képességeiken kívül eső részeket is. Ily módon a páros programozás javíthatja a csapatszintű kommunikációt is. (Ez együtt jár a kollektív tulajdon fogalmával is).

Tervezési játék Az extrém programozáson belüli fő tervezési folyamatot Tervezési Játéknak nevezik. A játék egy találkozó, amelyre ismétlésenként egyszer kerül sor, jellemzően hetente egyszer. A tervezési folyamat két részre oszlik:

Kiadás tervezése: Ez arra összpontosít, hogy meghatározza, milyen követelményeket tartalmaznak az adott rövid távú kiadások, és mikor kell azokat teljesíteni. Az ügyfelek és a fejlesztők egyaránt részesei ennek. A kiadás tervezése három szakaszból áll: Felfedező szakasz: Ebben a fázisban az ügyfél megadja a rendszerrel szemben támasztott nagy értékű követelmények rövid listáját. Ezeket a felhasználói történet kártyákra írják fel. Kötelezettségvállalási szakasz: A kötelezettségvállalási szakaszban a vállalkozások és a fejlesztők elkötelezik magukat a benne foglalt funkciók és a következő kiadás dátuma mellett. Kormányzási szakasz: Az irányítási fázisban a terv módosítható, új követelményekkel egészíthető ki és/vagy a meglévő követelmények módosíthatók vagy törölhetők. Iterációs tervezés: a fejlesztők tevékenységeit és feladatait tervezi. Ebben a folyamatban az ügyfél nem vesz részt. Az iterációs tervezés is három szakaszból áll: Feltárási fázis: Ebben a fázisban a követelményt különböző feladatokra fordítják. A feladatokat feladatkártyákon rögzítjük. Elköteleződési szakasz: A feladatokat a programozók osztják ki, és a végrehajtáshoz szükséges időt becsülik. Irányítási fázis: A feladatok végrehajtása megtörténik, és a végeredmény illeszkedik az eredeti felhasználói történethez.

A tervezési játék célja, hogy a terméket a szállításba vezesse. Ahelyett, hogy megjósolná a pontos dátumokat, hogy mikor lesz szükség a teljesítményekre, és mikor kell azokat előállítani, ami nehezen kivitelezhető, a cél az, hogy a projektet egy egyszerű megközelítéssel "irányítsa" a teljesítés felé. A Planning Game megközelítést a nem szoftveres projektek és csapatok is átvették az üzleti agilitással összefüggésben.

A kiadás tervezése

Feltárási szakasz Ez egy iteratív folyamat a követelmények összegyűjtésére és az egyes követelmények munkára gyakorolt hatásának becslésére.

Írjon egy történetet: Az üzletnek amikor problémája van; egy értekezlet során a fejlesztés megpróbálja meghatározni ezt a problémát és követelményeket kérni. Az üzleti probléma alapján egy történetet (user story) kell írni. Ezt az üzlet végzi, ahol rámutatnak arra, hogy mit szeretnének a rendszer egy részétől. Fontos, hogy a fejlődés ne legyen hatással erre a történetre. A történet egy felhasználói történetkártyára van írva. Becsüljön meg egy történetet: A fejlesztés megbecsüli, hogy mennyi időbe telik a történetkártya által feltételezett munka végrehajtása. A fejlesztés tüskés megoldásokat is létrehozhat a probléma elemzésére vagy megoldására. Ezeket a megoldásokat a becsléshez használják, és elvetik, amint mindenki világos képet kap a problémáról. Ez megint csak nem befolyásolhatja az üzleti követelményeket. Történet felosztása: Minden tervezési kritikus összetettséggel foglalkozni kell az iterációs tervezés megkezdése előtt. Ha a fejlesztés nem képes megbecsülni a történetet, fel kell osztani és újra meg kell írni.

Ha az üzlet nem tud több követelményt felmutatni, akkor az ember az elkötelezettségi szakaszba lép.

Elköteleződési szakasz Ez a fázis magában foglalja a költségek, hasznok és az ütemterv hatásának meghatározását. Négy összetevője van:

Rendezés érték szerint: A vállalkozás az üzleti érték szerint rendezi a felhasználói történeteket. Rendezés kockázat szerint: A fejlesztés kockázat szerint rendezi a történeteket. Sebesség beállítása: A fejlesztés határozza meg, hogy milyen sebességgel tudják végrehajtani a projektet. Hatókör kiválasztása: A következő kiadásban befejeződő felhasználói történetek kerülnek kiválasztásra. A felhasználói történetek alapján kerül meghatározásra a megjelenés dátuma.

Rendezés érték szerint Az üzleti oldal üzleti érték szerint rendezi a felhasználói történeteket. Három kupacba rendezik őket:

Kritikus: olyan történetek, amelyek nélkül a rendszer nem tud működni, vagy nincs értelme. Jelentős üzleti érték: Nem kritikus felhasználói történetek, amelyek jelentős üzleti értékkel rendelkeznek. Jó, ha van: olyan felhasználói történetek, amelyeknek nincs jelentős üzleti értéke.

Rendezés kockázat szerint A fejlesztők kockázat szerint rendezik a felhasználói történeteket. Három csoportba is sorolhatók: alacsony, közepes és magas kockázatú felhasználói történetek. A következő egy példa erre a megközelítésre:

Határozza meg a kockázati indexet: Adjon minden felhasználói történetnek egy indexet 0-tól 2-ig a következő tényezők mindegyikéhez: Teljesség (tudjuk a történet összes részletét?) Teljes (0) Hiányos (1) Ismeretlen (2) Volatilitás (valószínű, hogy megváltozik?) alacsony (0) közepes (1) magas (2) Bonyolultság (mennyire nehéz felépíteni?) egyszerű (0) szabvány (1) komplex (2)

Minden indexek a felhasználó történetet adunk, hozzárendeljük a felhasználói történetek a kockázati index alacsony – közepes (2 – 4), vagy magas –

Irányítási fázis Az irányítási fázison belül a programozók és az üzletemberek "irányíthatják" a folyamatot. Vagyis változtatásokat eszközölhetnek. Az egyes felhasználói történetek vagy a különböző felhasználói történetek relatív prioritásai változhatnak; a becslések tévesnek bizonyulhatnak. Ez a lehetőség a terv megfelelő kiigazítására.

Iterációs tervezés Figyelembe véve a tervezendő csapatsebesség-történetpontokat. Az iteráció időtartama 1-3 hét lehet.

Feltárási szakasz Az iterációs tervezés feltáró szakasza a feladatok létrehozásáról és azok megvalósítási idejének becsléséről szól.

A követelmény fordítása feladatokra: Helyezze el a feladatkártyákra. Feladat egyesítése/felosztása: Ha a programozó nem tudja megbecsülni a feladatot, mert az túl kicsi vagy túl nagy, akkor a programozónak kombinálnia vagy fel kell osztania a feladatot. Feladat becslése: Becsülje meg a feladat végrehajtásához szükséges időt.

Elköteleződési szakasz Az iterációs tervezés kötelezettségvállalási szakaszában a programozók olyan feladatokat kapnak, amelyek a különböző felhasználói történetekre hivatkoznak.

A programozó elfogad egy feladatot: Minden programozó kiválaszt egy feladatot, amelyért felelősséget vállal. A programozó megbecsüli a feladatot: Mivel most a programozó felelős a feladatért, neki kell megadnia a feladat végső becslését. Beállított terhelési tényező: A terhelési tényező az ideális gyakorlati fejlesztési időt programozónként egy iteráción belül. Például egy 40 órás hétben, ahol 5 órát szentelnek az értekezleteknek, ez nem több 35 óránál. Kiegyenlítés: Amikor a csapat összes programozója megkapta a feladatokat, összehasonlítjuk a feladatok becsült idejét és a terhelési tényezőt. Ezután a feladatokat kiegyensúlyozzák a programozók között. Ha egy programozó túlterhelt, más programozóknak át kell venniük a feladatai egy részét, és fordítva.

Irányítási fázis A feladatok végrehajtása az iteráció irányító szakaszában történik.

Szerezzen feladatkártyát: A programozó megkapja a feladatkártyát az egyik feladathoz, amelyre elkötelezte magát. Partner keresése: A programozó egy másik programozóval együtt hajtja végre ezt a feladatot. Erről bővebben a Páros programozás gyakorlatban van szó. A feladat megtervezése: Ha szükséges, a programozók megtervezik a feladat funkcionalitását. Végezze el a feladatot tesztvezérelt fejlesztéssel (TDD) (lásd alább) Funkcionális teszt futtatása: Funkcionális tesztek futnak (a kapcsolódó felhasználói történet és feladatkártya követelményei alapján).

Tesztvezérelt fejlesztés Az egységtesztek olyan automatizált tesztek, amelyek a kód egyes részei (pl. osztályok, metódusok) működőképességét tesztelik. Az XP-n belül az egységtesztek az esetleges kód kódolása előtt íródnak. Ennek a megközelítésnek az a célja, hogy arra ösztönözze a programozót, hogy gondolkodjon olyan körülményeken, amelyek között a kódja meghibásodhat. Az XP azt mondja, hogy a programozó befejez egy bizonyos kódrészletet, amikor nem tud további feltételeket felhozni, amelyek esetén a kód meghibásodhat.

A tesztvezérelt fejlesztés a következő lépések gyors átfutásával megy végbe, és minden lépés legfeljebb percet vesz igénybe, lehetőleg sokkal kevesebbet. Mivel minden felhasználói történet általában egy-két napos munkát igényel, nagyon sok ilyen ciklusra lesz szükség történetenként.

Írjon egységtesztet: A programozók levelet minimális tesztet kell nem azért, mert a funkcionalitás nem hajtották végre maradéktalanul a gyártási kód. Nézze meg az új teszt kudarcát: A programozók ellenőrzik, hogy a teszt valóban sikertelen. Bár időpocsékolásnak tűnhet, ez a lépés kritikus fontosságú, mert igazolja, hogy a gyártási kód állapotáról alkotott meggyőződésed helyes. Ha a teszt nem bukik meg, a programozóknak meg kell állapítaniuk, hogy a tesztkódban van-e hiba, vagy a gyártói kód valóban támogatja az új teszt által leírt funkciókat. Kód írása: A programozók csak annyi gyártási kódot írnak le, hogy az új teszt sikeres legyen. Teszt futtatása: Az egységtesztek végrehajtása annak ellenőrzésére történik, hogy az új gyártási kód megfelel-e az új tesztnek, és más tesztek sem hibáznak-e. Refaktor: Távolítson el minden kódszagot mind a gyártási, mind a tesztkódból.

A fenti folyamat intenzívebb változatát lásd Bob bácsi három TDD szabályában.

Egész csapat XP-n belül nem az a "vevő" aki fizeti a számlát, hanem aki tényleg használja a rendszert. Az XP azt mondja, hogy az ügyfélnek mindig kéznél kell lennie, és elérhetőnek kell lennie a kérdések megválaszolására. Például a pénzügyi adminisztrációs rendszert fejlesztő csapatnak tartalmaznia kell egy pénzügyi adminisztrátort.

Folyamatos feldolgozás

Folyamatos integráció A fejlesztőcsapatnak mindig a szoftver legújabb verzióján kell dolgoznia. Mivel a különböző csapattagok különböző változtatásokkal és javításokat tartalmazó verziókkal rendelkezhetnek helyben elmentve, meg kell próbálniuk néhány óránként, vagy amikor egy jelentős törés jelentkezik, feltölteni az aktuális verziót a kódtárba. A folyamatos integráció elkerüli a projektciklus későbbi szakaszában az integrációs problémák okozta késéseket.

Tervezési fejlesztés