mi az extrém programozás? Az XP szabályainak és értékeinek áttekintése
Az 1990-es években az Internet növekedése szükségessé tette a szoftverfejlesztés megváltoztatását. Ha egy vállalat sikere attól függött, hogy a vállalat milyen gyorsan tud növekedni és piacra hozni termékeket, a vállalkozásoknak drasztikusan csökkenteniük kellett a szoftverfejlesztési életciklust.,
ez volt az a környezet, hogy Kent Beck létre extrém programozás (XP), egy agilis projektmenedzsment módszertan, amely támogatja a gyakori kiadások a rövid fejlesztési ciklusok javítása, szoftver minőség, valamint lehetővé teszi a fejlesztők számára, hogy reagál a változó vevői igények.
bár ezeket a gyakorlatokat és értékeket más projektmenedzsment módszertanokból is felismerheti, az XP ezeket a gyakorlatokat “extrém” szintekre viszi, ahogy a módszer neve is sugallja., Egy interjúban Informit, Kent magyarázza:
” Az első alkalommal, amikor felkértek, hogy vezessen egy csapatot, megkértem őket, hogy csináljanak egy kicsit a dolgokat, azt hittem, ésszerű, mint a tesztelés és a vélemények. A második alkalommal sokkal több volt a vonalon. Megkértem a csapatot, hogy hajtson fel 10-re minden olyan dolgot, amit fontosnak tartottam, és hagyjon ki minden mást.”
Ha Önnek és csapatának gyorsan ki kell engednie és reagálnia kell az ügyfél kérésére, vessen egy pillantást az extrém programozás értékeire és szabályaira—ez tökéletesen illeszkedik.,
az extrém programozási módszer értékei
XP több, mint egy sor lépés a projektek kezelése—olyan értékkészletet követ, amely segít a csapatnak gyorsabban dolgozni, és hatékonyabban együttműködni.
egyszerűség
a csapatok teljesítik azt, amit kértek, és semmi több. XP lebontja minden lépés egy nagy folyamat kisebb, elérhető célok csapat tagjai elérni.,
egyszerűsített kommunikáció
a csapatok a projekt minden részén együttműködnek, a követelmények összegyűjtésétől a kódex végrehajtásáig, valamint napi standup találkozókon vesznek részt, hogy minden csapattag naprakész legyen. Minden aggodalom vagy probléma azonnal megoldódik.
következetes, konstruktív visszajelzés
XP-ben a csapatok a folyamatot a projekthez és az ügyfelek igényeihez igazítják, nem fordítva. A csapatnak Korán és gyakran be kell mutatnia a szoftverét, hogy visszajelzést tudjon gyűjteni az ügyféltől, és elvégezze a szükséges változtatásokat.,
Respect
Az Extreme programming “all for one and one for all” mentalitást ösztönöz. A csapat minden tagját, a hierarchiától függetlenül, tiszteletben tartják a hozzájárulásukért. A csapat tiszteletben tartja az ügyfelek véleményét, és fordítva.
Courage
a csapat tagjai alkalmazkodnak a változásokhoz, amikor azok felmerülnek, és felelősséget vállalnak munkájukért. Elmondják az igazságot a fejlődésükről—nincsenek “fehér hazugságok” vagy kifogások arra, hogy az emberek jobban érezzék magukat. Nincs ok a félelemre, mert senki sem dolgozik egyedül.,
az extrém programozási módszertan szabályai
Don Wells 1999-ben közzétette az első XP szabályokat, hogy ellensúlyozza azt az állítást, hogy az extrém programozás nem támogatja a szoftverfejlesztéshez szükséges tevékenységeket, például a tervezést, az irányítást és a tervezést. A tervezéstől a szoftver teszteléséig kövesse az alábbi alapvető lépéseket minden iterációhoz.
tervezés
Ez a szakasz az, ahol az UX magic történik., A hosszadalmas követelménydokumentum helyett az ügyfél felhasználói történeteket ír, amelyek meghatározzák az ügyfél által látni kívánt funkcionalitást, valamint az egyes funkciók üzleti értékét és prioritását. A felhasználói történeteknek nem kell kimerítőnek vagy túlságosan technikai jellegűnek lenniük—csak annyi részletre van szükségük, hogy segítsék a csapatot annak meghatározásában, hogy mennyi ideig tart ezeknek a funkcióknak a végrehajtása.
A Lucidchart segítségével az ügyfelek létrehozhatnak egy alapvető folyamatábra, amely könnyen rögzítheti és megoszthatja a kívánt funkciókat.,
innen a csapat létrehoz egy kiadási ütemtervet, és a projektet iterációkra osztja (egy-három hétig). Előfordulhat, hogy a projektmenedzserek létre akarnak hozni egy idővonalat vagy egy egyszerűsített Gantt diagramot, hogy megosszák az ütemtervet a csapattal.
kezelése
ebben a szakaszban a projektmenedzser beállítja a csapatot, hogy sikeres legyen ebben a módszertanban. Mindenkinek együtt kell dolgoznia és hatékonyan kommunikálnia, hogy elkerülje a csúszásokat. Ez a szakasz a következőket foglalja magában:
- nyitott munkaterület létrehozása csapata számára
- fenntartható tempó beállítása (azaz, annak meghatározása, a megfelelő hosszúságú ismétlés)
- megcsináljuk a napi rendes ülés
- Mérési projekt sebesség (a munka mennyiségét készül el a projekt)
- Átcsoportosításával dolgozni, hogy elkerüljék, akadályokat, illetve a tudás elvesztése
- Megváltoztatja a szabályokat, ha XP nem működik tökéletesen a csapat
Tervezése
Ez a szabály megy vissza, hogy az érték az egyszerűség: Kezdjük a legegyszerűbb design, mert kevesebb időt vesz igénybe, hogy teljes, mint a komplex megoldás. Ne adjon hozzá funkciókat Korán. Refactor gyakran tartani a kódot tiszta, tömör., Hozzon létre spike megoldásokat a lehetséges problémák megoldásainak feltárására, mielőtt hátráltatnák a csapatot.
Kent Beck és Ward Cunningham az XP módszertan részeként osztály-felelősség-együttműködés (CRC) kártyákat is létrehozott. Ezek a kártyák lehetővé teszik az egész projektcsapat számára, hogy megtervezze a rendszert, és megnézze, hogyan hatnak egymásra az objektumok. Ha szeretné kipróbálni ezt brainstorming eszköz magad, kezdje a mi Lucidchart sablon.,
Coding
akkor végre eljön az idő a kód végrehajtására. XP gyakorolja a kollektív kód tulajdonjogát: mindenki felülvizsgálja a kódot, minden fejlesztő hozzáadhat funkcionalitást, kijavíthatja a hibákat, vagy refactor. A kollektív kód tulajdonjogának működéséhez a csapatnak:
- válasszon egy rendszer metaforát (szabványosított elnevezési rendszer).
- gyakorlat pár programozás., A csapat tagjai párban, egyetlen számítógépen dolgoznak, hogy kódokat hozzanak létre, és gyártásba küldjék. Egyszerre csak egy pár integrálja a kódot.
- integrálja és kötelezze el a kódot a tárolóba néhány óránként.
az ügyfélnek a teljes folyamat során-lehetőleg a helyszínen-elérhetőnek kell lennie, hogy megválaszolhassa a kérdéseket, és követelményeket állapítson meg.
tesztelés
a csapat egységteszteket végez, és kijavítja a hibákat, mielőtt a kód felszabadulna. Gyakran végeznek elfogadási teszteket is.,
mikor kell használni az extrém programozást
még mindig nem biztos abban, hogy az XP megfelel-e a csapat igényeinek, még a szabályok és értékek elolvasása után is? Az extrém programozás jól működik azon csapatok számára, amelyek:
- elvárják, hogy a rendszer funkcionalitása néhány havonta megváltozzon.
- tapasztalja meg a folyamatosan változó követelményeket, vagy dolgozzon olyan ügyfelekkel, akik nem tudják, mit akarnak a rendszertől.
- csökkenteni szeretné a projekt kockázatát, különösen a szűk határidők körül.
- tartalmaz egy kis számú programozó (2 és 12 között előnyös).
- képesek szorosan együttműködni az ügyfelekkel.,a
- képes automatizált egység-és funkcionális teszteket készíteni.
Ha az együttműködés és a folyamatos fejlesztés prioritás a csapat számára, az extrém programozás érdemes lehet kipróbálni. Mivel ez a rendkívül adaptálható modell folyamatos visszajelzést igényel az ügyfelektől, előre látja a hibákat az út mentén, és megköveteli a fejlesztőktől, hogy együtt dolgozzanak, az XP nemcsak biztosítja az egészségügyi termék kiadását, hanem véletlenül is javította a termelékenységet a fejlesztőcsapatok számára mindenhol.,
Ha úgy dönt, hogy XP-t használ, próbálja meg vizuálisan dokumentálni felhasználói történeteit, kiadási ütemterveit, CRC kártyáit, valamint a rendszer dokumentációját a Lucidchart alkalmazásban. Iratkozzon fel ingyenes fiókjába ma.