Extrém programozási gyakorlatok

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.

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

Mivel az XP doktrínája csak azt javasolja, hogy programozzuk azt, amire ma szükség van, és a lehető legegyszerűbb megvalósítást, ez időnként a rendszer elakadását eredményezheti. Ennek egyik tünete a kettős (vagy többszörös) karbantartás szükségessége: a funkcionális változások megkezdik ugyanazon (vagy hasonló) kód több példányának módosítását. Egy másik tünet, hogy a kód egy részének változásai sok más részt is érintenek. Az XP doktrínája azt mondja, hogy amikor ez megtörténik, a rendszer azt kéri, hogy az architektúra megváltoztatásával alakítsa újra a kódot, egyszerűbbé és általánosabbá téve azt.

Kis kiadások

A szoftver szállítása a konkrét értéket teremtő, éles funkciók gyakori kiadásán keresztül történik. A kisebb kiadások segítenek az ügyfélnek abban, hogy bizalmat kapjon a projekt előrehaladásával kapcsolatban. Ez segít fenntartani az egész csapat koncepcióját, mivel az ügyfél most már a valós tapasztalatokon alapuló javaslatokat tehet a projektre vonatkozóan.

Közös megértés

Kódolási szabvány

A kódolási szabvány megegyezett szabályrendszer, amelyet a teljes fejlesztőcsapat betart a projekt során. A szabvány meghatározza a forráskód egységes stílusát és formátumát a választott programozási nyelven belül, valamint különböző programozási konstrukciókat és mintákat, amelyeket a hibák valószínűségének csökkentése érdekében kerülni kell. A kódolási szabvány lehet a nyelv szállítója által meghatározott szabványos konvenciók (pl. a Sun által ajánlott The Code Conventions for the Java Programming Language), vagy a fejlesztőcsapat által meghatározott egyedi konvenciók.

Extreme Programming támogatókat szószólója kódot, amely önmagát dokumentálja, hogy a legtávolabbi mértékben lehetséges. Ez csökkenti a kódhoz fűzött megjegyzések szükségességét, amelyek kieshetnek magával a kóddal.

Kollektív kódtulajdonlás

A kollektív kódtulajdonlás (más néven "csapatkód tulajdonjog" és "megosztott kód") azt jelenti, hogy mindenki felelős a kódért; ezért mindenki megváltoztathatja a kód bármely részét. A kollektív kódtulajdonlás nemcsak szervezeti politika, hanem érzés is. "A fejlesztők jobban érzik a csapatkód tulajdonjogát, ha megértik a rendszerkörnyezetet, hozzájárultak a szóban forgó kódhoz, jónak ítélik meg a kód minőségét, hiszik, hogy a termék kielégíti a felhasználói igényeket, és nagyfokú csapatkohéziót észlelnek." A páros programozás, különösen az átfedő párok forgatása hozzájárul ehhez a gyakorlathoz: a különböző párokban végzett munka révén a programozók jobban megértik a rendszer kontextusát, és a kódbázis több területéhez járulnak hozzá.

A közös kódtulajdonlás felgyorsíthatja a fejlesztést, mivel a hibát észlelő fejlesztő azonnal kijavíthatja azt, ami összességében csökkentheti a hibák számát. A programozók azonban olyan kód megváltoztatásakor, amelyet nem értenek jól, hibákat is bevihetnek. A kellően jól definiált egységteszteknek enyhíteniük kell ezt a problémát: ha az előre nem látható függőségek hibákat okoznak, akkor az egységtesztek futtatásakor hibákat fognak mutatni.

A kollektív kódtulajdonlás a tagok jobb biztonsági mentését, a tudás és a tanulás nagyobb elosztását, a kód közös felelősségét, jobb kódminőséget és kevesebb kódjavítást eredményezhet. De ez a tagok gyakoribb konfliktusához, a hibák növekedéséhez, a fejlesztők szellemi teljesítményének megváltozásához, az érvelésük akadályozásához, megnövekedett fejlesztési időhöz vagy a kód nehezebb megértéséhez is vezethet.

Egyszerű kialakítás

A programozóknak a "legjobb az egyszerű" megközelítést kell alkalmazniuk a szoftvertervezésben. Amikor egy új kódrészletet írnak, a szerzőnek fel kell tennie magának a kérdést, hogy "van-e egyszerűbb módja ugyanannak a funkciónak a bevezetésére?". Ha a válasz igen, akkor az egyszerűbb megoldást kell választani. Az összetett kód egyszerűbbé tételéhez a refaktorálást is alkalmazni kell.

Rendszermetafora

A rendszermetafora egy történet, amelyet minden – vásárló, programozó és menedzser – elmondhat a rendszer működéséről. Ez az osztályok és metódusok elnevezési koncepciója, amely megkönnyíti a csapattagok számára, hogy kitalálják egy adott osztály/metódus funkcionalitását, pusztán a nevéből. Például egy könyvtári rendszer létrehozhat loan_records(class) a borrowers(class), és ha a tétel késedelmessé válna, akkor elvégezhet egy make_overdue műveletet egy catalogue(class)-on . Minden egyes osztály vagy művelet esetében a funkcionalitás nyilvánvaló az egész csapat számára..

Programozói jólét

Fenntartható tempó

A koncepció az, hogy a programozók vagy szoftverfejlesztők ne dolgozzanak többet heti 40 óránál, és ha egy héten van túlóra, akkor a következő héten ne legyen egyáltalán. Mivel a fejlesztési ciklusok a folyamatos integráció rövid ciklusaiból állnak, és a teljes fejlesztési (kiadási) ciklusok gyakoribbak, az XP-ben lévő projektek nem követik azt a tipikus időt, amelyet más projektek túlórában igényelnek.

Ebbe a koncepcióba az is beletartozik, hogy az emberek akkor teljesítenek a legjobban és legkreatívabban, ha teljesen kipihentek.

A fenntartható munkasebesség elérésének kulcsfontosságú eleme a gyakori kódegyesítés, valamint a folyamatosan végrehajtható, tesztelhető, kiváló minőségű kód. A folyamatosan alakuló munkamódszer friss és éber elméjűvé teszi a csapattagokat. A csapaton belüli intenzív együttműködés arra késztet, hogy a hétvégéken pihenéssel újra feltöltődjünk.

A jól tesztelt, folyamatosan integrált, gyakran telepített kódok és környezetek szintén minimálisra csökkentik a váratlan fejlesztési problémákat és a leállások gyakoriságát, valamint a szükséges munkaidőn túli éjszakába nyúló és hétvégi munkát.

Fordítás

Ez a szócikk részben vagy egészben az Extreme programming practices című angol Wikipédia-szócikk ezen változatának fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.

További információk

• XP-gyakorlatok
• Kent Beck XP-gyakorlatok
• Ron Jeffries XP-gyakorlatok

Kapcsolódó szócikkek

• Extrém programozás
• Folyamatos integráció
• Többlépcsős folyamatos egyesítés
• Osztály-felelősség-együttműködés kártya