Ismeri a programozást, de az Extreme Programming (röviden XP) még mindig rejtély az Ön számára.
Ne hagyja, hogy a név eltántorítsa Önt, mert fennáll a veszélye, hogy kimarad egy hasznos információról.
Ebben a cikkben mindent bemutatunk, amit az extrém programozásról tudnia kell, hogy előnyére fordíthassa.
Az extrém programozás egy szoftverfejlesztési módszertan, amely része az úgynevezett agilis módszertanoknak. Az XP értékekre, elvekre és gyakorlatokra épül, és célja, hogy a kis- és közepes méretű csapatok kiváló minőségű szoftvereket gyárthassanak, és alkalmazkodjanak a folyamatosan változó és változó követelményekhez.
Az XP-t az különbözteti meg a többi agilis módszertől, hogy az XP a szoftverfejlesztés technikai szempontjait hangsúlyozza. Az extrém programozás pontosan meghatározza a mérnökök munkáját, mivel a mérnöki gyakorlatok követése lehetővé teszi a csapatok számára, hogy kiváló minőségű kódokat készítsenek fenntartható ütemben.
Az extrém programozás dióhéjban a szélsőségekig terjedő jó gyakorlatok. Mivel a páros programozás jó, csináljuk folyamatosan. Mivel az előzetes tesztelés jó, teszteljük a gyártási kód megírása előtt.
Az XP a többi módszertől eltérően olyan értékeken és elveken alapul, amelyek fontosak és relevánsak a mérnöki gyakorlat szempontjából.
Az értékek célt adnak a csapatoknak. "Északi csillagként" működnek, hogy magas szinten irányítsák döntéseit. Az értékek azonban absztraktak és túl homályosak a konkrét útmutatáshoz. Például: Ha azt mondod, hogy értékeled a kommunikációt, az sokféle eredményhez vezethet.
A gyakorlatok bizonyos értelemben az értékek ellentétei. Konkrétak és földhözragadtak, defimeghatározza, hogy mit kell tenni. A gyakorlatok segítenek a csapatoknak abban, hogy felelősséget vállaljanak az értékekért. Például az információs munkaterek gyakorlata elősegíti az átlátható és egyszerű kommunikációt.
Az alapelvek terület-specifikus irányelvek, amelyek áthidalják a gyakorlatok és az értékek közötti szakadékot.
XP értékei: kommunikáció, egyszerűség, visszajelzés, bátorság és tisztelet. Nézzük mindegyiket részletesebben.
Szerkesztési BlogInnovazione.azt a képről alexsoft.com
közlés: A kommunikáció hiánya megakadályozza a tudás áramlását egy csapaton belül. Gyakran, ha probléma adódik, valaki már tudja, hogyan kell megoldani. A kommunikáció hiánya azonban megakadályozza őket abban, hogy megismerjék a problémát vagy hozzájáruljanak annak megoldásához. Így a probléma végül kétszer is megoldódik, hulladék keletkezik.
Egyszerűség: Az egyszerűség azt mondja, hogy mindig a legegyszerűbb dologra törekszel, ami működik. Gyakran félreértik, és a legegyszerűbb dolognak tekintik, figyelmen kívül hagyva a „működő” részt.
Azt is fontos megjegyezni, hogy az egyszerűség erősen kontextusfüggő. Ami az egyik csapatnak egyszerű, az a másiknak bonyolult, és teljes mértékben az egyes csapatok készségeitől, tapasztalatától és tudásától függ.
Visszacsatolás: A hagyományosabb, lépcsőzetes szoftverfejlesztési módszereknél gyakran „túl kevés, túl későn” érkezik visszajelzés.
Az XP azonban elfogadja a változást, és az XP-csapatok időszerű és állandó visszajelzésekre törekednek. Ha kurzuskorrekcióra van szükség, az XP-sek a lehető leghamarabb tudni akarják.
Szerkesztési BlogInnovazione.azt a képről alexsoft.com
A visszajelzés többféle formában és méretben érkezik. Ha partnerprogramozást végez, a kollégái megjegyzései létfontosságú visszajelzést jelentenek. Ugyanígy a csapat többi tagjának véleménye is egy ötletről, beleértve a vevőt is, aki ideális esetben a csapat tagja.
A tesztek egy másik forrása az értékes visszajelzéseknek, amelyek túlmutatnak a teszteredményeken. Függetlenül attól, hogy a tesztek írása könnyű vagy nehéz, a visszajelzés is az. Ha problémái vannak a tesztek írásával, akkor valószínűleg túl bonyolult a projektje. Hallgassa meg a visszajelzéseket, és korszerűsítse a tervezést.
Valami, ami nagyszerű ötletnek tűnik, nem biztos, hogy olyan jól működik a gyakorlatban. Ezért a kész kód is visszacsatolás forrása, csakúgy, mint az elosztott termék.
Végül ne feledje, hogy túl sok a visszajelzés. Ha egy csapat több visszajelzést generál, mint amennyit képes kezelni, fontos visszajelzések eshetnek ki a radarról. Ezért elengedhetetlen, hogy lassítson, és kitalálja, mi okozza a túlzott visszacsatolást, és javítsa ki.
coraggio: Kent Beck defia bátorság mint „hatékony cselekvés a félelemmel szemben” jelenik meg. Szoftvermérnökként sok félnivalója van, ezért rengeteg lehetősége van a bátorság kimutatására.
Bátorság kell ahhoz, hogy kimondjuk az igazat, különösen a kellemetleneket, például az őszinte becsléseket. A visszajelzés adása és fogadása is bátorságot igényel. És bátorságra van szükség ahhoz, hogy elkerüljük az elsüllyedt költségek tévedését, és elvetjük a hibás megoldást, amely jelentős befektetéssel járt.
Tisztelet: Az XP alapvető előfeltétele, hogy mindenki törődik a munkájával. Semmiféle technikai kiválóság nem mentheti meg a projektet, ha nincs odafigyelés és tisztelet.
Minden ember méltó a méltóságra és a tiszteletre, és ebbe természetesen beletartoznak a szoftverfejlesztési projektekben résztvevők is. Ha Ön és a csapattagok tisztelik és törődnek egymással, az ügyféllel, a projekttel és a jövőbeli felhasználókkal, akkor mindenki profitál
Az elvek konkrétabb útmutatást adnak, mint az értékek. Olyan iránymutatások, amelyek megvilágítják az értékeket, egyértelműbbé és kevésbé kétértelművé teszik azokat.
Szerkesztési BlogInnovazione.azt a képről alexsoft.com
Például pusztán a bátorság értéke alapján arra a következtetésre juthat, hogy tanácsos azonnal nagy változtatásokat végrehajtani az időbeosztáson. A Baby Steps elv azonban azt mondja nekünk, hogy a nagy változások kockázatosak. Tehát inkább a kicsiket részesítsd előnyben.
Emberiség: Az emberek szoftvereket hoznak létre az emberek számára, ezt gyakran figyelmen kívül hagyják. De az alapvető emberi szükségletek, erősségek és gyengeségek figyelembevételével olyan termékek jönnek létre, amelyeket az emberek használni akarnak. A kiteljesedés és növekedés lehetőségét, az összetartozás érzését és az alapvető biztonságot kínáló munkakörnyezet pedig egy olyan hely, ahol könnyebben figyelembe veheted mások igényeit.
gazdaság: Az XP-ben a csapatok mindig odafigyelnek a szoftverfejlesztés gazdasági realitásaira, folyamatosan értékelik a gazdasági kockázatokat és a projektigényeket.
Például a felhasználói történeteket üzleti értékük, nem pedig technikai szempontok alapján valósítanák meg.
Kölcsönös haszon: XP után kerüli az olyan megoldásokat, amelyek az egyik fél hasznára válnak a másik rovására. Például a kibővített specifikációk segíthetnek másoknak megérteni, de elvonják a figyelmet a megvalósításról, és késleltetik a felhasználók számára.
Kölcsönösen előnyös megoldás az automatizált átvételi tesztek alkalmazása. Azonnali visszajelzést kaphat a megvalósításról, társai pontos specifikációkat kapnak a kódban, a felhasználók pedig elsőként ismerik meg a funkciókat. Ráadásul mindannyian rendelkezik egy biztonsági hálóval a regresszió ellen.
Előny (kölcsönös haszon): Ha egy adott megoldás egy szinten működik, akkor magasabb vagy alacsonyabb szinten is működhet. Például a korai és állandó visszajelzések megszerzése különböző mértékben forog kockán az XP-ben.
Javulás: A fejlesztés elve szerint a csapatok nem a tökéletességre törekednek egy kezdeti implementációban, hanem egy kellően jó implementációra, majd azt folyamatosan tanulják, fejlesztik valódi felhasználók visszajelzései alapján.
Sokféleség: Ön és kollégái a nézőpontok, készségek és attitűdök sokféleségéből profitálnak. Az ilyen sokszínűség gyakran konfliktusokhoz vezet, de ez így van rendjén.
A konfliktusok és a nézeteltérések lehetőséget kínálnak a jobb ötletek megjelenésére, amikor mindenki a bátorság és a tisztelet értékei szerint játszik. Bátorság az ellentétes álláspontok kifejezésére, tisztelet ezek civil és empatikus kifejezésére. És mindez egy hatékony kommunikációs gyakorlat.
Visszaverődés: Nagyszerű csapatok reflektálnak a munkájukra, és elemzik, hogyan lehetnek jobbak. Az XP számos lehetőséget kínál erre. Nem csak a heti és negyedéves ciklusokban, hanem minden gyakorlatban, amit hirdet.
A logikai elemzés mellett fontos figyelembe venni az érzéseket is. A bélrendszere tájékoztathat, mielőtt bármit is okoskodni kezdene. És így tud beszélgetni nem műszaki emberekkel, olyan kérdéseket tehetnek fel, amelyek teljesen új lehetőségeket nyitnak meg.
Folyam: A hagyományos szoftverfejlesztési módszereknek külön fázisai vannak, amelyek hosszú ideig tartanak, és kevés lehetőségük van visszajelzésre és kurzuskorrekcióra. Ehelyett az XP-ben a szoftverfejlesztés olyan tevékenységekben történik, amelyek folyamatosan, következetes értékfolyamban zajlanak.
Véletlen: A szoftverfejlesztésben elkerülhetetlenek a problémák. Azonban minden probléma egy lehetőség a fejlődésre. Tanulj meg így tekinteni rájuk, és sokkal nagyobb valószínűséggel találsz olyan kreatív és célorientált megoldásokat, amelyek egyben arra is szolgálnak, hogy ne ismétlődhessenek meg.
Redundancia: A redundancia elve azt mondja, hogy ha egy adott probléma kritikus, akkor sokféle taktikát kell alkalmaznia annak leküzdésére.
Fogadd el a hibákat. Nincs egyetlen taktika, amely megakadályozná, hogy minden hiba kikerüljön a gyártásból.
Tehát az XP megoldása egy sor minőségi mérőszám halmozása. Páros programozás, tesztelés, folyamatos integráció. Mindegyik egyetlen védelmi vonal, együtt gyakorlatilag áthatolhatatlan fal.
Kudarc: a kudarc nem pazarlás, ha tudássá válik. Cselekedni és gyorsan megtanulni azt, ami nem működik, sokkal eredményesebb, mint a tétlenség, amelyet a sok lehetőség közötti választási határozatlanság okoz.
qualità: Az emberek gyakran azt gondolják, hogy dilemma van a minőség és a sebesség között.
Ez fordítva is igaz: a minőség javítására való törekvés az, ami gyorsabbá tesz.
Például az újrafaktorálás – a kód szerkezetének megváltoztatása a viselkedés megváltoztatása nélkül – olyan gyakorlat, amely megkönnyíti a kód megértését és megváltoztatását. Ennek eredményeként kevésbé valószínű, hogy kódhibákat vezet be, ami lehetővé teszi, hogy először több értéket biztosítson azáltal, hogy nem kell hibákat javítania.
Kis lépések: A nagy változások kockázatosak. Az XP csökkenti ezt a kockázatot azáltal, hogy minden szinten kis lépésekben hajt végre változtatásokat.
A programozók kis lépésekben írnak kódot tesztvezérelt fejlesztés segítségével. A kódjukat naponta többször integrálják a fővonalba, nem pedig néhány hetente vagy akár havonta. Maga a projekt rövid ciklusokban zajlik, nem pedig hosszú távú szakaszokban.
Felelősség vállalva: XP-ben a felelősséget vállalni kell, nem kiosztani.
Az elszámoltathatóságnak együtt kell járnia azzal a felhatalmazással, hogy döntéseket hozzon arról, hogy miért felelős. Ennek az ellenkezője is igaz. Nem akarod, hogy az emberek döntéseket hozzanak, ha nem kell együtt élniük a következményeikkel.
Az extrém programozás, mint agilis módszertan, merev tervek betartása nélkül is elfogadható és elkezdhető átvenni. Ez egy iteratív tervezés, nem pedig egy nagy kezdeti projekt.
Az XP jelentősen eltér a hagyományos módszertanoktól, azaz a kaszkádolástól, elkerülve a hosszan tartó fázisokat.
Miben különbözik az XP a többi agilis módszertől?
Az extrém programozás természeténél fogva sok hasonlóságot mutat a többi agilis módszertannal, de ezek között is egyedülálló.
A legtöbb egyéb fejlesztési módszer nem mond sokat, ha egyáltalán nem, arról, hogyan kell elvégezni a munkát. Az XP viszont nagyon elgondolkodtató, ha erről van szó, és nagy hangsúlyt fektet a szoftverfejlesztési gyakorlatra.
A Scrum egy olyan keretrendszer, amely segíti a csapatokat komplex projektek adaptív kidolgozásában. A Scrum nem határozza meg, hogy a fejlesztők hogyan végezzék munkájukat. Az XP, mint említettük, nagy hangsúlyt fektet a jó programozási gyakorlatokra.
Szerkesztési BlogInnovazione.hu Kép netes megoldások
Emellett az XP nyilvánvalóan a programozásról szól. Ezzel szemben a Scrum minden olyan projektre alkalmazható, amely az iteratív megközelítés előnyeit élvezi.
Az XP elfogadja az összetevőinek módosításait. A csapatok felhatalmazást kapnak, sőt arra is ösztönzik, hogy sajátos igényeik alapján módosítsák gyakorlatukat. A Scrum Guide viszont határozottan állítja, hogy „Bár csak a Scrum egyes részeit lehet megvalósítani, az eredmény nem Scrum”.
Ezenkívül a Scrum egy olyan keretrendszer, amelyet módszertanokkal és gyakorlatokkal kell kiegészíteni a munka elvégzéséhez.
Ez azt jelenti, hogy erősen ajánlott az extrém programozás és a Scrum használata.
Kent Beck szerint egy érett XP-csapatnak nem szabad merev szerepeket kiosztania, hanem fel kell ismernie, hogy a szerepek hasznosak lehetnek a kezdő csapatok számára, amíg nem kezdenek lelassulni vagy megnehezíteni az együttműködést.
Lássunk néhány kulcsszerepet:
Ez az XP-ben elfogadott gyakorlat. Három fő csoportra oszthatók: szoftverfejlesztés, munkahelyi és projektmenedzsment.
Páros programozás: XP-ben gépen ülve párban írod a kódot. Te és a párod beszélgetnek egymással, miközben elemzi, implementálja és teszteli a funkciót, amelyen dolgozik. A páros programozás különösen jó abban, hogy kevesebb hibát tartalmazó kódot állítson elő, miközben lebilincselő, szórakoztató és fárasztó.
Tíz perces határ: Kötelező 10 percet tesz lehetővé a teljes projekt felépítéséhez, beleértve az összes automatizált teszt futtatását is, legfeljebb tíz perc alatt. Ez a korlát az egyszerű és hatékony tesztelés érdekében.
Programozás előtti tesztek: implementálja a funkciókat a teszt-first megközelítéssel, más néven tesztvezérelt fejlesztés (TDD). A TDD egy egyszerű iteratív eljárással történő fejlesztésből áll:
A TDD számos előnnyel jár.
Először is, visszajelzés. Ha nehéz megírni egy tesztet, akkor a keresett vagy az örökölt terv valószínűleg túl bonyolult, és egyszerűsíteni kell.
Másodszor, a TDD lehetővé teszi a programozók számára, hogy megbízzanak az általuk írt kódban, és egy szép ciklusos ritmust hoz létre, ahol a következő lépés mindig egyértelmű.
Végül, de nem utolsósorban, a TDD használata a kezdetektől 100%-os kódlefedettséget biztosít. A tesztkészlet ekkor valóban biztonsági hálóvá válik a jövőbeli változtatásokhoz, ösztönzi a kódok újrafeldolgozását és a minőség erényes körét.
Inkrementális tervezés: A növekményes tervezés gyakorlata azt jelenti, hogy minden nap be kell fektetnie az alkalmazástervezésbe, keresve a lehetőségeket a duplikáció eltávolítására és apró fejlesztésekre, hogy a lehető legjobb tervezést érje el, amire a rendszernek ma szüksége van.
Folyamatos integráció: XP-ben naponta többször integrálja a munkáját a fő megosztott tárolóba, ami elindítja a teljes rendszer automatikus felépítését. A lehető legkorábbi és minél gyakoribb integráció drámaian csökkenti az integráció költségeit, mivel csökkenti az összeolvadások és logikai konfliktusok előfordulásának valószínűségét. Környezeti és függőségi problémákat is feltár.
Megosztott kód (kollektív tulajdon): Az XP a megosztott kódot vagy a kollektív tulajdonjogot hirdeti: minden fejlesztő felelős az összes kódért. Bátorítja az információcserét, csökkenti a csapatbusz-tényezőt és növeli az egyes modulok általános minőségét, ha figyelembe vesszük a sokszínűség elvét.
Egyetlen CodeBase: Az egységes kódbázist „törzs alapú fejlesztésnek” is nevezik. Ez azt jelenti, hogy az igazságnak csak egy forrása van. Tehát ahelyett, hogy hosszú ideig elszigetelten fejlődne, korán és gyakran egyesítse hozzájárulásait egyetlen adatfolyamba. A funkciójelzők segítenek korlátozni a funkciók használatát, amíg azok be nem fejeződnek.
Napi elosztás: a napi legalább egyszeri üzembe helyezés a termelésben a folyamatos integráció logikus következménye:. Valójában manapság sok csapat még ennél is tovább megy, és gyakorolja a folyamatos megvalósítást. Ez azt jelenti, hogy amikor valaki csatlakozik a fővonalhoz, az alkalmazás üzembe kerül a termelésben.
Kód és tesztek: Ez a gyakorlat azt jelenti, hogy a forráskód, beleértve a teszteket is, a szoftverprojekt egyetlen állandó mellékterméke. Más típusú műtermékek, köztük a dokumentáció létrehozásában való részvétel gyakran pazarló, mert nem termel valódi értéket az ügyfél számára.
Ha más műtermékekre vagy dokumentumokra van szüksége, próbálja meg előállítani azokat gyártási kódból és tesztekből.
Kiváltó okok elemzése: Amikor egy hiba gyártásba kerül, ne csak javítsa ki a hibát. Győződjön meg róla, hogy először is kitalálja, mi okozta, miért nem sikerült Ön és csapattársai megakadályozni a megcsúszást. Ezután tegyen lépéseket annak biztosítására, hogy ez többé ne fordulhasson elő.
Üljetek együtt: XP-ben a csapatok szívesebben dolgoznak együtt nyílt térben. Ez a gyakorlat elősegíti a kommunikációt és a csapathoz tartozás érzését.
Az egész csapat: Mindenki az XP csapat tagja, akire szükség van a projekt sikeréhez. Ez erősen kontextusfüggő – csapatonként eltérő – és dinamikus, csapaton belül változhat.
Információs munkaterületek: Az információs munkaterület a csapat fizikai terét használja olyan információk megjelenítésére, amelyek lehetővé teszik, hogy bárki egy pillantással megismerhesse a projekt előrehaladását. Ennek módja eltérő lehet, a fizikai jegyzetektől és grafikonoktól a projektmenedzsment szoftverből származó Kanban-táblákat és műszerfalakat bemutató képernyőképekig.
Energikus munka: XP-ben csak addig dolgozol, amíg energikus munkát tudsz végezni. A munkaórát legfeljebb heti 40-re kell korlátozni.
Anaiisi- Írja meg a felhasználói követelményeket felhasználói elemzésként ismert formátumban. A felhasználói elemzésnek van egy rövid, leíró neve és egy rövid leírása arról, hogy mit kell megvalósítani.
Laza: Ciklus tervezésekor adjon hozzá olyan kisebb feladatokat, amelyeket a csapat elhagyhat, ha szükséges. Ha a csapat túl sokat teljesít, mindig hozzáadhat további történeteket.
Ciklusok (havi és heti): Az XP fejlesztése két fő ciklusban történik: a heti és a havi ciklusban.
Találkozók, ciklusok, tervezett kiadások: Az XP-ben a fejlesztés két fő ciklusban működik: a heti és a negyedéves ciklusban. Kezdetben Kent Beck kéthetes ciklust javasolt, de könyve második kiadásában ezt megváltoztatta.
Heti ciklus: a heti ciklus egy XP projekt "pulzusa". A ciklus egy találkozóval kezdődik, amelyben a kliens kiválasztja, hogy a hét folyamán mely történeteket szeretné elkészíteni. Ezenkívül a csapat áttekinti munkájukat, beleértve a múlt heti előrehaladást is, és azon gondolkodik, hogyan lehetne javítani a folyamaton.
Havi ciklus: A csapat minden hónapban átgondolja és azonosítja a fejlesztési lehetőségeket a folyamatában. Az ügyfél kiválaszt egy vagy több témát az adott hónapra, az ezekben a témákban végzett elemzésekkel együtt.
Hogyan kezdjünk el extrém programozással dolgozni?
A technikai készségek és az XP-szokások nehezen tanulhatók meg. Néhány gyakorlat idegennek tűnhet a hozzá nem szokott programozók számára.
Ercole Palmeri
Szemplasztikai műtétet végeztek az Apple Vision Pro reklámmegjelenítővel a Catania Poliklinikán…
A finom motoros készségek színezéssel történő fejlesztése felkészíti a gyerekeket olyan összetettebb készségekre, mint az írás. Kiszínezni…
A haditengerészeti szektor igazi világgazdasági hatalom, amely egy 150 milliárdos piac felé navigált...
Múlt hétfőn a Financial Times bejelentette, hogy megállapodást köt az OpenAI-val. Az FT engedélyezi világszínvonalú újságírását…
