| 🇭🇺Elfogadási tesztelés 🇬🇧Acceptance testing | Ez a gyakorlat az agilis szoftverfejlesztésben a user story funkcionális tesztelését jelenti. Vagyis lefejlesztett user storynak valóban olyan működése, funkciója lett, melyet eredetileg ki szerettek volna alaakítani. Ezt a tesztelést a fejlesztő csapat egy tagja végzi el az előre meghatározott elfogadási tesztek alapján. | |
| 🇭🇺Agilis alapelv 🇬🇧Agile principle | Az agilis manifesztóban felsorolt 12 alapelv egyike. | |
| 🇭🇺Agilis manifesztó vagy kiáltvány 🇬🇧Agile manifesto | Az a 2001-ben keletkezett dokumentum, amely a 4 agilis alapértéket és a 12 agilis alapelvet írja le. | |
| 🇭🇺Agilis mindset 🇬🇧Agile mindset | Az agilis munkakörnyezetet támogató viselkedésminták összessége, mint például a tisztelet, kollaboráció, folyamatos tanulás és javulás, a gyakori értékszállításra való törekvés és a gyors változásra, változtatásra való hajlam. | |
| 🇭🇺🇬🇧Antipattern | Olyan gyakorlat, hozzáállás vagy viselkedésminta, mely a helyesnek pontosan az ellentéte. Antipattern például az, ha a daily scrum 40 percen keresztül tart. | |
| 🇭🇺Artifact, munkaanyag 🇬🇧Artifact | A Scrum keretrendszerben a Scrum csapat által elvégzett, elvégzés alatt álló vagy elvégzendő munka megjelenítése. A Scrum három artifactjén (Product Backlog, Sprint Backlog és Increment) elsődleges célja az, hogy teljesen transzparenssé tegye a munkát, ezzel elősegítve az empirizmus másik két pillérét (lásd: inspect and adapt) | |
| 🇭🇺🇬🇧Acceptance Test Driven Development (ATDD) | Az a megrendelő, a fejlesztők és a tesztelők közti kommunikáción alapuló szoftverfejlesztési gyakorlat, amely a fejlesztést megelőzően az elfogadási teszteket rögzíti, és csak akkor fogadja el a szoftvert, ha az az összes elfogadási tesztet sikeresen teljesítette. | |
| 🇭🇺🇬🇧API | Az API (Application Programming Interface) egy olyan interfész, amely lehetővé teszi, hogy a különféle szoftveralkalmazások vagy programon belüli modulok kommunikáljanak és együttműködjenek egymással. Az API-k határozzák meg azokat a szabályokat és protokollokat, amelyeken keresztül az alkalmazások adatokat cserélhetnek, vagy szolgáltatásokat kérhetnek egymástól. | |
| 🇭🇺Automata tesztelés 🇬🇧Automated testing | A szoftverfejlesztés folyamatában alkalmazott tesztelési módszer, amely automatikus eszközök segítségével végzi a tesztelést. Ezzel csökkenti az emberi erőforrás szükségességét a tesztek újrafuttatásakor. Ehhez legtöbb esetben a tesztelő írja a kódot. | |
| 🇭🇺🇬🇧Back-end | A szoftvernek az a része, amely a háttérben futó funkciókat, például az adatbázis-kezelést, a hálózati kommunikációt és az alkalmazás üzleti logikáját kezeli. Ez a rész a felhasználó számára láthatatlan. | |
| 🇭🇺🇬🇧Backlog | Lásd: Product Backlog vagy Sprint Backlog | |
| 🇭🇺🇬🇧Backlog Grooming | Lásd: Backlog Refinement | |
| 🇭🇺🇬🇧Backlog Refinement | Az a folyamat, amely során a fejlesztői csapat tagjai a munkát kisebb user storykra vagy feladatokra bontják le. | |
| 🇭🇺🇬🇧Behaviour-Driven Development (BDD) | Az a szoftverfejlesztési gyakorlat , amely a szoftver viselkedését határozza meg a teszteléshez, és nem a technológiát. Segít abban, hogy a csapat a felhasználóval közösen, konkrét példák segítségével közös megértést alakítson ki arról, hogy hogyan kellene a szoftvernek működnie. | |
| 🇭🇺Becslés, esztimáció 🇬🇧Estimation | Az a folyamat, melynek során a fejlesztők felmérik és megbecsülik az elvégzendő munkaelem komplexitását. Ennek elsődleges célja az, hogy a fejlesztők közmegegyezésre jussanak az adott munkaelem terjedelmével illetve megoldási lehetőségeivel kapcsolatban. A becslés sokféleképpen mehet végbe, az egyik a Fibonacci-számsoron alapuló becslés. | |
| 🇭🇺Akadály 🇬🇧Blocker | Lásd: Impediment | |
| 🇭🇺🇬🇧Board | Egy digitális vagy fizikai felület, ahol a csapat megjeleníti a Sprint Backlogot. A Daily Scrum során a fejlesztők ezt a felület használják fel arra, hogy transzparenssé tegyék a csapat haladását a Sprint goal felé. | |
| 🇭🇺🇬🇧Branch | A szoftverfejlesztési folyamatban használt ág, amely a fejlesztés új funkcióinak elkészítésére vagy javítására szolgál. Sok esetben a fejlesztők ugyanazt a kódbázist használják párhuzamosan. Ehhez egy saját másolatot készítenek a kódbázisról (leágaztatás), majd a funkciók lefejlesztése után megvizsgálják, hogy más addig nem írta-e felül a kód azon részét, ahol ők is dolgoznak. Ha minden rendben zajlott, akkor a kódbázishoz hozzáadják a fejlesztésüket és elhagyják a külön ágat. | |
| 🇭🇺🇬🇧BRS (Business Requirement Specification) | Ez a dokumentum írja le a projekt üzleti követelményeit, céljait és elvárásait, részletesen bemutatva azt, hogy mit kell elérni egy projekt során ahhoz, hogy az üzleti célok teljesüljenek. A BRS általában az érintett üzleti szereplők, például a megrendelők, ügyfelek vagy a vállalat vezetősége által meghatározott elvárásokat tartalmazza. | |
| 🇭🇺🇬🇧Build | A build az a folyamat, mely során a forráskód különböző részei programcsomaggá állnak össze. Ekkor adódnak a kódbázishoz a különféle külső könyvtárak, de a build során konfigurálhatják a fejlesztők az alkalmazást, és akár a véglegesen lefuttatható programcsomagot is létrehozhatják. | |
| 🇭🇺🇬🇧Burndown Chart | Egy olyan grafikon, melyen nyomon követhető, hogy a betervezett feladatokból mennyi valósult meg, mennyi van még vissza, valamint hogy ideális tempóban halad-e a fejlesztés a Sprint alatt. | |
| 🇭🇺Ceremónia (elavult) 🇬🇧Ceremony | Lásd: Esemény | |
| 🇭🇺🇬🇧Commit | A “commit” során a fejlesztő elmenti a forráskód változásait a verziókezelőbe (pl. git). Ekkor az összes módosított fájl aktuális állapotát rögzíti a repositoryban, és a változások mellé egy üzenetet is ír, amely leírja a változtatásokat. Ezáltal visszakövethető és dokumentálható, hogy ki, mikor, és milyen módosításokat végzett a kódon. | |
| 🇭🇺Fordítás 🇬🇧Compilation | Az a folyamat, amikor egy programozási nyelven, pl. Javában meg írt forráskódot egy fordítóprogram (compiler) gépi kódra vagy köztes kódra alakít át. Ez a gépi kód az, amit a számítógép közvetlenül végre tud hajtani. | |
🇭🇺🇬🇧Continuous Integration/Continuous Delivery (CI/CD) | Szoftverfejlesztési gyakorlat, amely a folyamatos integrációt és a folyamatos szállítást egyesíti, minél inkább automatizálttá téve azt. A folyamatos integráció által a kisebb változtatások is gyorsan elérhetővé válnak a csapat többi tagja számára, ezáltal korábban felismerik a problémákat és hamarabb javítják azokat, így elkerülve a költséges későbbi javításokat. A folyamatos szállítás célja, hogy minél előbb visszajelzést kapjunk a munkáról, hogy azt minél tökéletesebben a megrendelő igényeihez lehessen igazítani, ezáltal növelve az ügyfélelégedettséget. | |
| 🇭🇺🇬🇧Confluence | Egy olyan szoftvermegoldás, mely az átlátható dokumentációt segíti elő. Az excelek, word doksik kiváltására használt verziókövető szoftver, mely könnyen összeköthető a Jira-val, lévén a két terméket ugyanaz a cég fejleszti. | |
| 🇭🇺🇬🇧Cycle time | Egy feladat elkezdése és befejezése között eltelt időmennyiség. A lean gyártásban használt hatékonyságnövelést elősegítő mérési indikátor. | |
| 🇭🇺🇬🇧Daily Scrum | A Scrum keretrendszer egyik eseménye, mely minden nap azonos időben, azonos helyen történik. Célja, hogy a fejlesztői csapat ezen a fórumon megtervezze az aznapi munkát, valamint transzparenciát teremtsen a Sprint Goal elérésével kapcsolatban. | |
| 🇭🇺🇬🇧Definition of Ready | Azon feltételek listája, amelyeket a fejlesztés megkezdéséhez a Fejlesztők szerint teljesíteni kell. Ilyen feltétel lehet például, hogy “csak megfelelően előkészített, átbeszélt és közösen megértett User Story-k kerülhetnek be a Sprint Backlogba”. Hosszabb távon ez a gyakorlat kifejezetten hátrányos lehet bizonyos csapatoknál. | |
| 🇭🇺🇬🇧DevOps | Olyan filozófia, eszköz- és gyakorlatkészlet, mely automatizálja és integrálja a folyamatokat a szoftverfejlesztő és IT-üzemeltető csapatok között. A DevOps-mérnökök elsődleges fókuszában a CI/CD-eszközök állnak. | |
| 🇭🇺🇬🇧Definition of Done (DoD) | Azon – elsősorban minőségi és folyamatbeli – követelmények listája, amelyeknek teljesülniük kell ahhoz, hogy a munka befejezettnek minősüljön. A Sprint Backlog elemeit csak akkor lehet az Inkrementum részének tekinteni, ha az a DoD-ben foglaltaknak megfelel. | |
| 🇭🇺Deployolás 🇬🇧Deploy | Az a folyamat, amikor a szoftvercsomagokat és opcionális esetben a rendszer beállításait egy másik rendszerre telepítik | |
| 🇭🇺Élesítés 🇬🇧Release | Amikor a szoftvert éles, a végfelhasználók számára is látható környezetbe telepítik. | |
| 🇭🇺Elfogadási kritérium 🇬🇧Acceptance Criteria | Az a lista, amely leírja, hogy egy adott user storynak pontosan milyen funkciókkal kell rendelkeznie ahhoz, hogy az a Product Owner számára elfogadható legyen. Az Elfogadási kritériumok user storynként változnak, hiszen mindegyik más és más funkciót lát el. | |
| 🇭🇺Empirizmus 🇬🇧Empiricism | A Scrum keretrendszer alapja, amely szerint az ismeret és tudás tapasztalati úton, megfigyelések alapján hozott döntések révén szerezhető. Három oszlopa a transzparencia, a megfigyelés és a változtatás. | |
| 🇭🇺🇬🇧Epic | Egy nagyobb, üzleti értékkel rendelkező fejlesztési feladat, mely túl absztrakt és összetett, hogy a csapat ebben a formájában átlássa. Az epic lebontásából születnek a feladatok és user storyk. | |
| 🇭🇺🇬🇧E2E | Egy teljes folyamat lefedése az elejétől a végéig. Például egy webshopban a termék keresésétől a megrendelésen át egészen a kiszállításig tartó lépések egymásutánisága. | |
| 🇭🇺Esemény 🇬🇧Event | A Scrum keretrendszerben négy esemény szolgál arra, hogy a Scrum artifactokat (és azokon keresztül az elvégzett vagy elvégzendő munkát) megfigyeljük illetve azokon változtassunk. Ezen események révén történik meg az empirizmus a Scrum keretrendszerben. | |
| 🇭🇺Extrém Programming (XP) 🇬🇧Extreme Programming | Egy szoftverfejlesztési keretrendszer, melynek révén javítható a leszállított szoftver minősége, illetve elősegíti azt is, hogy a változó ügyféligényekre gyorsabban reagálhasson a fejlesztőcsapat. Az XP az agilis szoftverfejlesztés egyik típusa, amely az iteratív fejlesztési ciklusokat helyezi előtérbe. | |
| 🇭🇺Facilitálás 🇬🇧Facilitation | A Scrum Master egyik legfontosabb feladata, mellyel olyan környezetet teremt, ahol a csapat bevonódva tud kísérletezni, alkotni, döntést hozni. A facilitálás célja, hogy a csapat kollaboráció révén konszenzusra jusson, és aztán az adott döntés mellett elköteleződjön. Fontos, hogy a facilitátor a témába ne vonódjon be, csak vezesse a gondolatmenetet. | |
🇭🇺🇬🇧Feature-Driven Development (FDD) | Egy agilis szoftverfejlesztési gyakorlat, mely a felhasználó számára értéket nyújtó funkcionalitást helyezi előtérbe. A csapat fókuszáltan, egy teljes funkcionalitást fejleszt le, majd élesít. Célja, hogy rendszeresen “kézzelfogható” szoftvert szállítsanak a segítségével. | |
| 🇭🇺🇬🇧Feature | Funkcionalitás, mely a felhasználó számára értékkel bír. | |
| 🇭🇺Fejlesztők vagy Developerek 🇬🇧Developers | A Scrum csapat egyik szerepköre. Minden olyan szakértő, aki a fejlesztési munkát elvégzi. A Scrum nem különböztet meg tesztelőt, fejlesztőt, designert, architektet, rájuk közösen, mint Fejlesztőkre hivatkozik. | |
| 🇭🇺Fibonacci-sorozat 🇬🇧Fibonacci squence | A Fibonacci-számsorozat az a sorozat, ahol a sorozat következő eleme az előző két szám összege. A szoftverfejlesztésben a csapatok a feladatok komplexitásának jelölésére használják a számsor egyes elemeit: 1, 2, 3, 5, 8, 13, 21, stb. | |
| 🇭🇺🇬🇧Fork, forkolás | Amikor egy meglévő projekt forráskódját lemásolják, és azt az eredeti fejlesztésről leválasztva, külön fejlesztik tovább. | |
| 🇭🇺🇬🇧Front-end | A programoknak, weboldalaknak az a része, melyet a felhasználó lát illetve amelyekkel a felhasználó interakcióba léphet. A front-end feladata, hogy a back-endről érkező adatokat, információkat könnyen befogadható, feldolgozható módon jelenítse meg, és az esetleges változásokat, módosításokat közvetítse a back-end felé. | |
| 🇭🇺🇬🇧Full stack | Minden olyan technológia, mely szükséges egy projekt véghezviteléhez a back-endtől a front-endig. Ha egy fejlesztő ért a front-end és a back-end technológiákhoz, full stack fejlesztőnek hívjuk. | |
| 🇭🇺🇬🇧Git | Olyan ingyenes verziókezelő rendszer, mely a legegyszerűbb projekttől a legnehezebbig a kódbázis menedzselését könnyűvé és hatékonnyá teszi. | |
| 🇭🇺🇬🇧Given When Then | A BDD egyik jól bevált eszköze, mely segítségével könnyen írhatóak tesztesetek. A User Story-k elfogadási kritériumában is használható a módszer, mellyel könnyen átláthatóak a lefedni kívánt funkcionalitás esetei. | |
| 🇭🇺Impediment, akadály 🇬🇧Impediment | Olyan tényező, amely a csapat haladását lassítja vagy teljes mértékben meggátolja. A Scrum Master feladata az, hogy ezt az akadályt igyekezzen megszüntetni illetve a megszüntetéséről gondoskodni, amennyiben ez lehetséges. | |
| 🇭🇺Információradiátorok vagy információsugárzók 🇬🇧Information radiators | Olyan transzparenssé tett adatok, mérőszámok, riportok, grafikonok, melyek felhasználásával a csapat megalapozott döntést tud hozni, hogy milyen irányba haladjon tovább a fejlesztés. A Scrum Master előszeretettel használja ezeket, ezekkel teremt transzparenciát. | |
| 🇭🇺Inkrementális fejlesztés 🇬🇧Incremental development | Olyan fejleszési folyamat, mely minden egyes növekménnyel, inkrementummal egyre jobb és jobb terméket állít elő (több funkció, kevesebb hiba, gyorsaságnövelés, fenntarthatóság, stb.). | |
| 🇭🇺Megfigyelés és adaptáció 🇬🇧Inspect and Adapt | A Scrum keretrendszert fenntartó empiricizmus második és harmadik pillére. A Scrum négy inspect and adapt eseménye (Sprint planning, Daily Scrum, Sprint Review, Sprint Retrospektív) során a Scrum Master feladata az, hogy elősegítse, megtanítsa a ciklus sikeres elsajátítását. | |
| 🇭🇺Integráció 🇬🇧Integration | A szoftver integráció egy folyamat, mely a külön-külön működő rendszereket, funkciókat egy közös szoftverré “gyúrja”. | |
| 🇭🇺Integrációs tesztelés 🇬🇧Integration testing | Az integrációs teszt az integrációs folyamatot hivatott tesztelni, hogy a külön-külön működő rendszerek és funkciók egy közös rendszerré alakítva is megtartják a régi és új funkciójukat is anélkül, hogy egyéb hibát okoznának | |
| 🇭🇺Iteráció 🇬🇧Iteration | Az iteratív fejlesztés egy teljes ciklusa. Scrum esetén a Sprintet nevezzük iterációnak. | |
| 🇭🇺Iteratív fejlesztés 🇬🇧Iterative development | Ciklikus, ismétlődésen alapuló szoftverfejlesztési gyakorlat. | |
| 🇭🇺🇬🇧Jira | A Jira egy nemzetközileg használt és népszerű ticketing szoftver, mely megkönnyíti a munka követését és láthatóvá tételét. | |
| 🇭🇺🇬🇧Kanban | A Kanban egy vizuális rendszer, mely nyomonköveti és menedzseli a munkát a teljes folyamaton keresztül. Ezt legkönnyebben egy Kanban boardon valósíthatjuk meg, ahol az oszlopok a folyamat státuszai és a ticketek/kártyák pedig a feladatok. | |
| 🇭🇺Keresztfunkcionális vagy krosszfunkcionális csapat 🇬🇧cross-functional team | Olyan, különböző kompetenciájú szakértőkből álló csapat, mely önmaga képes E2E leszállítani egy szoftvert. | |
| 🇭🇺🇬🇧Lead time | Az az idő, mely egy feladat, termék ötletének megszületésétől az ötlet végrehajtásáig tart. A Leanben használt hatékonyságnövelést elősegítő indikátor. | |
| 🇭🇺🇬🇧Lean | Vállalatszervezési, vállalatirányítási módszer, amelynek célja, hogy a vállalat minél gazdaságosabban állítsa elő a termékeit, szolgáltatásait. A Lean vállalat a tevékenységeit elsősorban az alapján alakítja ki, hogy a vevő számára mi az érték. Ami a vevő számára nem teremt értéket, amiért a vevő nem fizet, azt a lean veszteségnek (pazarlásnak) tekinti, és a munkafolyamatok hatékonyságát ezeknek a veszteségeknek a megelőzésével, megszüntetésével vagy minimálisra csökkentésével növeli. | |
| 🇭🇺🇬🇧Merge | A leágaztatott szoftverág visszaintegrálása, összefésülése az eredeti, közös kódbázisba. | |
| 🇭🇺🇬🇧Microservice | Egy független, önállóan is működő szoftveralkalmazás, mely egy könnyen elkülöníthető funkciót lát el. Azzal, hogy egy microservice különálló komponensből áll, az integráció gyorsabb és hatékonyabb lesz. | |
| 🇭🇺🇬🇧Minimum Szerethető Termék 🇭🇺🇬🇧Minimum Loveable Product (MLP) | Az MLP az a minimális termék/szolgáltatás ajánlat, melyet a felhasználók már “egyből” szeretnek. Az MVP-nél több funkcionalitást tartalmaz, hogy a felhasználók ne csak megtűrjék és elfogadják a terméket, hanem valóban szeressék használni azt a limitált funkciókészletet, amit tartalmaz.. | |
| 🇭🇺Mobbing, mob programozás 🇬🇧Mobbing | lásd: Swarming | |
| 🇭🇺🇬🇧MVP (Minimum Viable Product) | A termék legelső változata, mely még csak annyi funkciót tartalmaz, amellyel a termék alapszinten működik, viszont már piacra lehet dobni. Ennek a változatnak az a célja, hogy a piacról visszajelzést kapjunk. | |
| 🇭🇺Növekmény, Inkrementum🇬🇧Increment | A Scrum keretrendszer egyik artifact-je, és végtére is a sprint során elvégzett fejlesztés célja. Az inkrementum az a szoftververzió, amit a fejlesztőcsapat a stakeholderekkel együtt megtekint illetve használatba vesz a Sprint review során. | |
| 🇭🇺Tulajdonosi szemlélet 🇬🇧Ownership mindset | Az a szemlélet, amikor az egyén vagy csapat saját magáénak érzi azt a terméket, szolgáltatást, amit fejleszt. | |
| 🇭🇺Páros programozás 🇬🇧Pair programming | Egy Extreme Programming (XP) gyakorlat, mely során a fejlesztők közösen dolgoznak a szoftveren és a négy szem elvét figyelembe véve menet közben beszélik át, vizsgálják felül egymás kódját. Ezzel a gyakorlattal magasabb minőségű, kevesebb hibát tartalmazó, fenntarthatóbb terméket hoznak létre. | |
| 🇭🇺🇬🇧Pairing | lásd Pair Programming | |
| 🇭🇺🇬🇧Peer Review | Az a folyamat, amikor a megírt kódot a fejlesztőcsapat egy vagy több tagja átnézi, arra konstruktív kommenteket ad, majd pedig jóváhagyja a változásokat. | |
| 🇭🇺🇬🇧Planning Poker | Az a konszenzus-alapú “kártyajáték”, amelyet a csapatok a feladatok vagy user storyk becslésére használnak. | |
| 🇭🇺🇬🇧POC vagy Proof of Concept | A POC egy olyan prototípushoz hasonlítható leginkább, melynek elsődleges célja az, hogy bizonyítsa egy ötlet vagy koncepció működőképességét. A POC rendszerint gyorsan és az általános minőségi szabályok figyelembevétele nélkül történik, és nem kerül élesítésre. | |
| 🇭🇺🇬🇧Product Backlog | Ez az emergens, sorrendbe állított lista azokat a munkaelemeket tartalmazza, amelyeket a termék fejlesztése érdekében el lehet/szükséges végezni. | |
| 🇭🇺🇬🇧Product Backlog Item (PBI) | A Product Backlog egy bizonyos eleme. | |
| 🇭🇺Termékcél 🇭🇺🇬🇧Product Goal | A Product Goal a termék jövőbeli formáját, állapotát írja le, ezzel olyan célt biztosít a Scrum csapat számára, amely elérése érdekében a sprintek során lépéseket tehet. | |
| 🇭🇺🇬🇧Product Owner | A Scrum keretrendszer egyik felelősségi köre, amely elsősorban az üzleti stakeholderekkel való kapcsolattartásért, a termék víziójának kifejtéséért és a Product Backlog priorizálásáért felel. | |
| 🇭🇺🇬🇧Pull request | Gyakori szokás, hogy a frissen megírt kódot csak akkor szabad főágra (lásd: Branch) visszamásolni, ha azt más fejlesztők áttekintették (lásd: peer review). A folyamatot az új kód írója egy pull request-tel kezdi a verziókezelőben (git). | |
| 🇭🇺Minőségbiztosítás 🇬🇧Quality Assurance (QA) | Az a teljes tesztelési folyamat, melynek célja, hogy a termék ill. szolgáltatás – teljesítmény, design, megbízhatóság, karbantarthatóság, stb. tekintetében – megfeleljen a vásárló igényeinek. A minőséget szoftverfejlesztés esetében különféle tesztelési módszerek segítségével vizsgálják. | |
| 🇭🇺Refaktorálás 🇬🇧Refactoring | Az a folyamat, amikor a fejlesztők egy már funkcionálisan jól működő programkódot karbantarthatóság, teljesítmény, megbízhatóság, stb szempontjából úgy optimalizálnak, hogy közben az eredeti funkció nem változik. | |
| 🇭🇺Relatív becslés 🇬🇧Relative estimation | Olyan becslési technika, mely arra alapoz, hogy az emberek számára könnyebb az egyes munkaelemek komplexitását egy másik munkaelem komplexitásához hasonlítani. A csapat a korábbi feladatokhoz viszonyítja az újakat, ezzel megközelítőleg azonos méretű kategóriákba tudja azokat sorolni. | |
| 🇭🇺🇬🇧Repository, repó | Egy központi digitális tárhely, amelyet a fejlesztők az alkalmazás forráskódjának módosítására és kezelésére használnak. | |
| 🇭🇺Kiadás, release vagy rilíz 🇬🇧Release | A szoftver release rendszerint az alkalmazás egy új, továbbfejlesztett változata. A Scrum keretrendszer szerint a csapat mindig potenciálisan leszállítható, kiadható Inkrementumot hoz létre, így a kiadás igény szerint valósítható meg, amelyről a Product Owner dönt. | |
| 🇭🇺Sprint retrospektív vagy Retró 🇬🇧Sprint Retrospective | A Scrum keretrendszer utolsó eseménye, mely során a Scrum csapat megvizsgálja, hogy a fejlesztés minőségét, folyamatait, valamint a csapaton belüli és kívüli kollaborációt hogyan tudja javítani. Az esemény célja, hogy a csapat közösen találjon ki olyan apró improvemente(ke)t, amely(ek)et aztán a következő sprintben megpróbálnak megvalósítani. | |
| 🇭🇺🇬🇧Scrum | Az az egyszerű keretrendszer, mely felhasználásával emberek, csapatok és szervezetek komplex problémákra adott adaptív megoldások révén értéket teremthetnek. | |
| 🇭🇺Scrum csapat 🇬🇧Scrum Team | A Scrum keretrendszerben résztvevő három felelősségi kört betöltő csapattagok együttese. Lásd még: Fejlesztők, Scrum Master, Product Owner. | |
| 🇭🇺🇬🇧Scrum Master | A Scrum keretrendszer egyik felelősségi köre. A Scrum Master felelős a Scrum Team eredményességéért, és felel a Scrum keretrendszer helyi implementációjáért. A Scrum Master három területen tesz szolgálatot: szolgálja a csapatát, a Product Ownert és az őt alkalmazó szervezetet. | |
| 🇭🇺🇬🇧Scrumban | Az a hibrid keretrendszer, amely rendszerint úgy ötvözi a Scrum és a Kanban elemeit, hogy a Kanbanra jellemzően (Work-In-Progress) WIP-limitekkel korlátozza a folyamatban lévő feladatok számát, ugyanakkor fenntartja a Scrumra jellemző timeboxokat és eseményeket. | |
| 🇭🇺Skálázás 🇬🇧Scaling | A Scrum keretrendszer egy kis létszámú szoftverfejlesztő csapatra lett kitalálva. Manapság a cégek több Scrum csapatban fejlesztik a szoftvereiket, ezért szükség van a csapatok közötti koordinációra és további szabályok, alapelvek, keretek lefektetésére, melyhez a skálázás segítséget nyújt. Több skálázási módszertan, keretrendszer elfogadott napjainkban (pl.: LeSS, Scrum@Scale, SAFe) | |
| 🇭🇺🇬🇧Smoke testing | Az a szoftvertesztelési gyakorlat, mely biztosítja, hogy a kiadni szánt szoftvercsomag stabil és a folytonos üzletmenetet garantáló legfontosabb funkciói nem lettek hibásak az új funkciók fejlesztése során. | |
| 🇭🇺🇬🇧Spotify-modell | A Spotify svéd zenestreamelő cég 2012-ben bemutatott skálázási modellje, ami azóta bizonyos körökben iparági szabvány lett. A Spotify-modellben a csapatokat squadnak hívják, élükön a squad lead áll. Több, szomszédos területen működő squad pedig tribe-okba tömörül, melynek élén a tribe lead található. A squadokban azonos diszciplínákban dolgozó fejlesztők egy chapterbe tömörülnek, élükön a chapter lead áll.A Spotify-modellt a Spotify már nem alkalmazza. | |
| 🇭🇺🇬🇧Sprint | A Scrum keretrendszer egyik eseménye, amely a másik négy eseményt tartalmazza. A Sprint egy legfeljebb egy hónap hosszúságú timebox, amelynek célja, hogy ezalatt az idő alatt a csapat az üzlet számára értékes, potenciálisan leszállítható Inkrementumot fejlesszen le. | |
| 🇭🇺🇬🇧Sprint Backlog | A Sprintcél, a Product Backlogból a sprintre kiválasztott Product Backlog Itemek, valamint az azok leszállítására vonatkozó terv összefoglaló neve. | |
| 🇭🇺Sprintcél 🇬🇧Sprint Goal | A Sprint planning során közösen meghatározott cél, tulajdonképpen a sprint mozgatórugója, miértje. Sprint során nem változhat, így segítve a csapat fókuszát. | |
| 🇭🇺🇬🇧Sprint Planning | A Scrum keretrendszer kezdőeseménye, mely során a Scrum csapat a Sprint Backlog elkészítése révén megtervezi a sprintet. | |
| 🇭🇺🇬🇧Sprint Review | A Scrum keretrendszer egyik záróeseménye, mely során a Scrum csapat és a stakeholderek megtekintik ill. használatba veszik a Sprint során elkészített Inkrementumot. A Scrum csapat ezt az eseményt arra használja fel, hogy a Stakeholderektől, illetve a felhasználóktól az Inkrementumra vonatkozóan visszajelzést kapjon. | |
| 🇭🇺🇬🇧Stakeholder | Azok az emberek, akik érdekeltek a fejlesztés sikeres megvalósításában. Szervesen nem tartoznak a Scrum csapathoz, de fontos szerepük abban, hogy a fejlesztés során a csapat visszajelzést kapjon. Stakeholderek például a termék vásárlói, a projekt szponzorai, üzleti vezetők, projektmenedzserek, stb.. | |
| 🇭🇺🇬🇧Standup | Napi csapatmeeting, ill. státuszmeeting. A Scrum keretrendszeren belüli jelentését ld.: Daily Scrum bejegyzés alatt. | |
| 🇭🇺🇬🇧Story pontok | A relatív becslés során használt mértékegység, amellyel a csapattagok az adott feladat vagy user story komplexitását mérik. | |
| 🇭🇺🇬🇧Swarming vagy Mobbing | Az a szoftverfejlesztési gyakorlat, amikor az egész fejlesztőcsapat egyetlen feladaton vagy user storyn dolgozik. Vannak olyan fejlesztőcsapatok, melyek napi szinten használják ezt a gyakorlatot, más csapatok csak ritkábban, pl. hackathonok alkalmával dolgoznak így. | |
| 🇭🇺🇬🇧Squad | A Spotify-modellben nevezik így a krosszfunkcionális csapatokat. | |
| 🇭🇺🇬🇧Squad Lead | Az ún. Spotify-modellben a squad vezetője, legtöbbször főnöke ill. line managere. | |
| 🇭🇺Tesztvezérelt fejlesztés 🇬🇧Test-driven development (TDD) | Egy szoftverfejlesztési folyamat, mely során a fejlesztők a szoftver követelményeit még a fejlesztés megkezdése előtt tesztesetekké alakítják. Ennek eredményeképpen a kód íródik a teszthez és nem fordítva, így kizárólag csak az a logika kerül lefejlesztésre, mely az üzleti igényben vagy user storyban megfogalmazódik. | |
| 🇭🇺🇬🇧Team charter | Egy, a csapattagok által kötött megállapodás, amely rendszerint tartalmazza azokat az értékeket és viselkedésmódokat, amit a csapattagok egymás felé közvetíteni szeretnének illetve egymástól elvárnak, és azt is, hogy a csapat miért létezik, mi a célja, valamint azt, hogy a csapat napi szinten hogyan működik együtt. | |
| 🇭🇺Időkeret 🇭🇺🇬🇧Timebox | A Scrum keretrendszerben a timebox az a maximális időmennyiség, amennyit az egyes eseményekre fordítani lehet. A timeboxolás mint gyakorlat elősegíti azt, hogy a Scrum csapat figyelme az esemény céljának elérésére irányuljon. | |
| 🇭🇺🇬🇧Tribe | A Spotify által 2011-ben publikált Spotify-modell egyik egysége, amely több, hasonló területen dolgozó csapatot (squad) foglal magában. | |
| 🇭🇺🇬🇧Unit testing (UT) | Ez a szoftvertesztelési gyakorlat az önálló, modulon belüli, logikailag jól elkülöníthető egységeket teszteli. A tesztelést legtöbbször a fejlesztők végzik. Ezzel a módszerrel lehet “legolcsóbban” megtalálni az esetleges hibákat. | |
| 🇭🇺🇬🇧User Interface (UI) | Az a felület, ahol a szoftver a felhasználóval interakcióba lép. Mobil applikációk esetén például a képernyő, ahol gombok, beviteli mezők, legördülő menük, csúszkák, stb. segítségével lehet irányítani a szoftver működését. A szoftver ezen alkotórészét front-endnek is nevezzük. | |
| 🇭🇺Usability tesztelés 🇬🇧Usability testing | A usability tesztelést valós felhasználókkal valósítják meg, akik a megadott folyamatokat próbálják elejétől a végéig (E2E) kipróbálni. A teszt elvégzése közben a fejlesztőcsapat tagjai folyamatosan figyelik a felhasználó lépéseit és viselkedését. A teszt célja, hogy végfelhasználói szempontból kiderüljön, mennyire elégedettek az adott funkció működésével. | |
| 🇭🇺Felhasználói elfogadási teszt vagy User Acceptance Test 🇬🇧User Acceptance Test (UAT) | Az a tesztelési módszer, melyet egy valós vagy potenciális végfelhasználó végez el a szoftver kiadása előtt. Ha minden, a felhasználók számára fontos funkció a megfelelő minőségben készült el, akkor a felhasználó elfogadja a fejlesztést, más esetben pedig visszautasítja és módosításra tesz javaslatot. Az UAT sokszor a tesztelés egyik utolsó fázisa a funkcionális illetve az integrációs tesztelés után. | |
| 🇭🇺Felhasználói perszóna vagy user persona 🇬🇧User persona | A user personák olyan kitalált személyek, melyeket a fejlesztőcsapatok azért hoznak létre, hogy jobban megismerjék a tipikus meglévő vagy leendő felhasználóikat. Ez a gyakorlat segíthet abban, hogy a fejlesztők a célfelhasználók helyébe képzelhessék magukat, és felfedezhessék a felhasználók termékkel szembeni igényeit, követelményeit. | |
| 🇭🇺Felhasználói történet 🇭🇺🇬🇧User Story | A szoftverfejlesztésben használt feladattípus, amely informális, természetes nyelven írja le, hogy a felhasználó mit szeretne elérni a szoftver funkcióinak használatán keresztül, és hogy azoktól milyen eredményt, felhasználói előnyt vár el. | |
| 🇭🇺🇬🇧User Story Mapping | A szoftverfejlesztés kezdeti fázisában alkalmazott workshop, melynek révén user personák felhasználásával azt térképezik fel, hogy az egyes felhasználók bizonyos célfeladatokat milyen lépéseken keresztül oldanak vagy oldhatnak meg. A workshop célja az, hogy a fejlesztők jobban megértsék a felhasználó gondolkodását, prioritásait. | |
| 🇭🇺User story sablon 🇬🇧User story template | A User Story megfogalmazásához felhasználható formátum, mely egyértelműen kifejti, hogy ki, hogy a felhasználók melyik szegmense pontosan milyen eredményt vár el az adott funkcionalitástól, és az milyen előnyt jelent számára.Sablon: As a…, I want…. so that…Pl.: (As a…) Okosóra felhasználóként (I want…) szeretnék telefonhívást fogadni az órámon, (so that…)hogy ne kelljen elővennem a zsebemből a telefont. | |
| 🇭🇺🇬🇧User Experience (UX) | A felhasználói élmény, melyet a felhasználó “átél” a szoftver használata közben. Ha a folyamat gördülékeny, egyértelmű és könnyű használni, ez az érték magas. Ha bonyolult, a szoftver nem használható könnyen, az érték alacsony és a felhasználók akár el is pártolhatnak a terméktől. | |
| 🇭🇺Velocity vagy velocitás 🇬🇧Velocity | A sprintben elvégzett ill. elvégezhető munka mennyiségét kifejező mérőszám. Bizonyos csapatoknál a sprintben elkezdett és befejezett user story-k és feladatok komplexitását jelző számok összege, más csapatoknál egyszerűen az elvégzett feladatok számának összege, de egyéb módszerekkel is meghatározható. A velocity használatával bizonyos csapatok számára leegyszerűsödhet a Sprint Planning esemény. | |
| 🇭🇺Verziókövetés 🇬🇧Version Control | A verziókövető rendszerek olyan fejlesztéstámogató szoftverek, melyek segítik a kódban történő változások nyomon követését, így a fejlesztők párhuzamosan is dolgozhatnak a kód egy bizonyos részén. A verziókövetésnek köszönhetően a kód tetszőleges verziója állítható vissza, így kisebb a változásokkal járó kockázat. | |
| 🇭🇺Vízesés🇬🇧Waterfall | Egy olyan projektmenedzsment-rendszer, mely előre definiált, jól dokumentált, kevés bizonytalansági tényezővel járó feladatok esetén működik jól. Fix határidőkkel és tartalommal dolgozik. Ebben a rendszerben az egyes fejlesztési fázisok teljes mértékben különválnak egymástól az igények kialakításától kezdve a tesztelésen át az élesítésig és a karbantartásig. | |
| 🇭🇺🇬🇧Work In Progress-limit (WIP, WIP-limit) | Az agilis szoftverfejlesztésben, különösen a kanban rendszerekben használt szám, amely azt határozza meg, hogy a munkafolyamat egy adott státuszában (oszlopában) legfeljebb hány munkaelem lehet. A folyamatban lévő munkaelemek számának megfelelő korlátozásával kiszámíthatóbbá válhat az értékszállítás, és optimalizálható a munka áramlása, a flow. | |
IT-szószedet 100+ hasznos kifejezéssel Scrum Mastereknek
Bittera Gábor
Scrum Master, korábban a Babylon Health, a Vodafone és a LeoTech, jelenleg pedig egy brit konzultánscég, az AND Digital gyakorló Scrum Mastere, a ScrumMasterLab társalapítója.
"Fontos számomra az, hogy az Angliában szerzett tapasztalataimat Magyarországon, magyar szakemberekkel osszam meg, és hogy olyan szakmai környezeteket alakítsak ki, ahova érdemes tanulni járni, és nincsen az egésznek iskolapad-szaga. Több tucat Scrum Masternek segítettem abban, hogy mélyebben, élményszerűen tapasztalják meg a Scrum keretrendszert, és az agilis értékeket és alapelveket. Úgy szeretek tanítani, hogy nem rajtam és a tanítandó anyagon legyen a hangsúly, hanem azon, hogy a résztvevők a saját kontextusukban, a saját tapasztalataikra építve értsék meg a keretrendszert. Ezen kívül folyamatosan képzem magam, vallom, hogy csak így lehet és érdemes ezt a szakmát hivatásként kezelni."
Értékes és megbecsült munkát végeznél?
A ScrumMasterLab tartja az egyetlen Scrum Master képzést, amely All Inclusive szolgáltatást nyújt, ha Scrum Master akarsz lenni. Csatlakozz a legpiacképesebb kezdő Scrum Masterek exkluzív csapatába és hozd ki végre magadból a benned rejlő potenciált!