NEW
Font size
WorksheetsAgilis módszertan és szoftverfejlesztés – kérdések
Total questions: 40
Worksheet time: 20hrs 0mins
Melyik igaz az alábbi állítások közül?
Minden korábbi folyamat-modellt képes helyettesíteni az érték-alapú megközelítés, mint amilyen az agilis módszertan.
Nincs olyan fejlesztési modell megközelítés, ami az agilis módszertanoknál magasabb minőségű szoftvert eredményezne.
A terv-alapú fejlesztési modellek (pl. vízesés) robosztus végeredményt eredményezhetnek, ami fontos a kritikus alkalmazások esetében.
Az adaptív modellek, mint amilyen az agilis módszertan, garantálják, hogy nem lesz műszaki tartozás a rendszerben.
Az alábbiak közül melyik nem egy érték-alapú eleme az agilis kiáltványnak?
Folyamatos minőségbiztosítás a pusztán fejlesztéssel szemben.
Működő szoftver az átfogó dokumentációval szemben.
Együttműködés a megrendelővel a szerződéses egyeztetéssel szemben.
Változás iránti készség a tervek szolgai követésével szemben.
Mi nem a szoftverkrízis tünete?
Túl sok alkalmazás használata.
Költségvetés és/vagy határidő túllépése.
Rossz "külső" minőség (pl. hatékonyság, követelmények nem teljesítése).
Rossz "belső" minőség (pl. karbantarthatóság).
Melyik nem iteratív inkrementális módszer?
Vízesés.
Agilis.
Evolúciós.
Spirális.
Mi nem tartozik a lineáris fejlesztés hátrányai közé?
Ritkán teljesíthetők az előfeltételei (pl. teljes specifikáció).
Túl gyakori egyeztetés a megrendelővel.
Nem képes reagálni a változásokra.
A használható termék túl későn áll elő.
Mi nem jellemző a Kanban-ra?
Célja az igények és a kapacitás egyensúlyban tartása.
Minden feladathoz egyből hozzá van rendelve a felelőse.
Fokozatos, evolúciós kis, de gyakori változások.
Korlátozások a folyamatban lévő munkák számát illetően.
Kik nem szereplői a Scrum-nak?
Scrum Master.
Product Owner.
Vezérigazgató.
Scrum csapat.
Mit nem értékel többre az Agilis Kiáltvány?
A módszertanokat és eszközöket az egyénekkel és személyes kommunikációval szemben.
A működő szoftvert az átfogó dokumentációval szemben.
Az ügyféllel való együttműködést a szerződéses egyeztetéssel szemben.
A változásokra való reagálást a terv követésével szemben.
Melyik nem a dinamikus rendszerfejlesztési módszer (DSDM) alapelve?
Koncentrálj az üzleti igényre.
Szállíts időben.
Projekttervezés funkciónként.
Folyamatos és világos kommunikáció.
Mit nem értékel többre az Agilis Kiáltvány?
Az egyéneket és interakciókat a módszertanokkal és eszközökkel szemben.
Az átfogó dokumentációt a működő szoftverrel szemben.
Az ügyféllel való együttműködést a szerződéses egyeztetéssel szemben.
A változásokra való reagálást a terv követésével szemben.
Mik a virtuális csapatok legnagyobb kihívásai? Válaszd ki az állítást, amely nem kihívásként jelenik meg.
A vezető a személyes jelenlét hiányában nem képes a munkavégzést megfelelő mértékben ellenőrizni, ezáltal a hatékonyság csökkenhet.
Az információáramlás nehézkesebb. A csoportfejlődés viharzási (storming) fázisa elmarad, ezáltal valódi csapatmunka nehezebben alakul ki.
A csapattagok komfortérzete csökken a magányos munkavégzés miatt, ez pedig kihat a motivációjukra, ami heves konfliktusokhoz vezet.
Az online kapcsolat okozta kommunikációs problémák miatt sok a félreértés.
Mit jelent az, hogy egy csapat keresztfunkcionális (cross-functional)?
A csapat tagjai egymással felcserélhetőek, mindenki ért mindenhez.
A csapat munkája úgy van megszervezve, hogy ezzel nem akadályozza más csapatok munkáját.
Minden olyan kompetencia és erőforrás, amely szükséges ahhoz, hogy a csapat a rábízott feladatot elvégezze, vagy megtalálható a csapaton belül, vagy szabadon hozzáférhető a csapat számára.
A csapat tagjai között van tesztelő és üzleti érdekeltségű személy is.
Mely szempontok alapján szervezünk csapatokat agilis módszertan szerint? Válaszd ki a helytelen elvet.
A csapatok egy munkafázisra specializálódnak (pl. tesztelés, fejlesztés), és az erre szakosodott kollégákat szervezzük tematikus csapatokba (fejlesztő csapat, tesztelő csapat).
A csapatokat a személyes szimpátiát figyelembe véve formáljuk, hogy a személyes konfliktusokat minimalizáljuk.
A csapatok egy feladat minden munkafázisáért felelnek, ezért a csapatokat úgy alakítjuk ki, hogy ehhez minden kompetencia képviselve legyen (pl. minimum egy fejlesztő, és minimum egy tesztelő) a csapatban.
A csapatok önszerveződők, így ebbe nem szabad beleszólni, elegendő a célt kitűzni, a többit a szakemberek megoldják maguktól.
Miért nem különítünk el fejlesztői szerepköröket (pl. fejlesztő, tesztelő) egy agilis csapatban?
Mivel minden csapattagnak egyformán jártasnak kell lennie a munkamenet minden lépésében, így ennek nincs értelme.
Mivel feladattól függően mások lehetnek a szerepkörök, így időfecsérlés lenne ezek definiálásával foglalkozni.
Az elhatárolt szerepek arra motiválnák a csapattagokat, hogy elsősorban a saját feladatukra koncentráljanak. Mivel azonban a cél elérése és az ehhez legmegfelelőbb szerep vállalása minden csapattagnak egyformán felelőssége, nem teszünk különbséget.
A különböző szerepek jelenléte azt éreztetheti, hogy a csapat tagjai nem egyformán fontosak, ami féltékenységhez és versengéshez vezethet.
Egy hagyományos csoporthoz viszonyítva egy agilis csapatban az egyén felelőssége és motivációja hogyan változik? Válaszd ki a helyes állítást.
Felelőssége kisebb, mivel az megoszlik a csapat tagjai között.
Motivációja nagyobb, mivel nincs egyéni felelősségre vonás.
Felelőssége nagyobb, mivel nincs vezető, aki egy személyben felelősséget vállaljon és döntést hozzon, ezt a szerepet a csapat tagjai veszik magukra.
Motivációja kisebb, mivel egy csapatban gyakran kell alkalmazkodni és kompromisszumot kötni a siker érdekében.
Mely 5 szintből épül fel az agilis tervezés folyamata?
Elemzés, előkészítés, tervezés, validáció, végrehajtás.
Refinement, sprint planning, daily standup, sprint review, retrospektív.
Termék vízió, termék roadmap, aktuális release, aktuális iteráció, napi tervezés.
Szervezeti szint, menedzsment szint, műszaki megvalósítás szint, csapat szint, egyéni szint.
Mit jelent az evolúciós tervezés?
Mivel vízió nélkül működni nem lehet, ugyanakkor nagy a bizonytalanság a jövőt illetően, a távlati célokat csak vázlatosan, a közeli, biztosan látszó teendőket ellenben nagyon is részletesen tervezzük.
Mivel a jövőt nem látjuk biztosan, a hosszútávú tervekbe pazarlás energiát fektetni, így csakis rövid távra tervezünk.
A tervezés elengedhetetlen, ezért ugyanúgy tervezünk, mint bármikor. Ha változás történik, elölről kezdjük a tervalkotási folyamatot.
A tervezés részletességét mindig a projekt aktuális igényeinek megfelelően állapítjuk meg.
Mi a backlog refinement?
A folyamat, ahogyan a product owner priorizálja a product backlog elemeit.
A backlog azon részhalmaza, amelyet a csapat az adott sprintben megvalósít.
Az a folyamat, amely során a csapat a product backlog elemein dolgozik, azokat finomítja, kisebb darabokra bontja, becslést ad rá.
Értekezlet, ahol a product owner a product backlog elemeit egyezteti az ügyfelekkel.
Mik a product backlog priorizálásának fő szempontjai?
Befektetés-megtérülés különbsége.
Érték, kockázat, költség.
Határidők, feladatok egymástól való függősége.
A megrendelő igényei.
Milyen elemek találhatók a product backlogban?
Kis méretű technikai feladatok, amelyeket csak implementálni kell.
Pontosan specifikált üzleti követelmények, amelyekre a technikai megvalósítást a csapat szállítja.
Minél kisebb méretű felhasználó esettanulmányok, amelyekre a teljes koncepciót és technikai megvalósítást is a csapat szállítja.
Bármi, ami a projekt időtartama során feladatként felmerül.
Melyik kérdésre nem kell kitérni a napi scrum megbeszélésen?
Mit csináltam a tegnapi megbeszélés óta?
Mit tervezek a mai napon csinálni?
Vannak-e akadályok, amik gátolnak?
Mi tetszett az előző sprintben?
Mi a helyes sorrend a tartalmazás szempontjából?
epic, user story, task, subtask
user story, epic, task, subtask
epic, task, user story, subtask
task, epic, user story, subtask
Mi a Product Owner feladata?
A folyamatokért felelős
Akadályokat hárít el
Megrendelőt képviseli, látja a végcélt
Implementáció
Mi jellemző az agilis dokumentációra?
Minimális mennyiségű, de még érthető, csak az aktuális szükséges elemeket tartalmazó dokumentáció.
A szerződéskötéskor lefektetett specifikációt tartalmazza.
A tesztesetek és a forráskód nem szolgálhat dokumentációként.
A környezetvédelem érdekében tilos kinyomtatni.
Mi a Scrum Master feladata?
A folyamatokért felelős, akadályokat hárít el.
A megrendelőt képviseli
Vízióval kell rendelkezzen
Implementáció
Mi a célja a sprint retrospektívnek?
A rosszul sikerült dolgok felelőseinek elmarasztalása.
A rossz dolgokon javítani, a jó dolgokat fenntartani, erősíteni.
A jól dolgozó munkatársak dicsérete.
Nosztalgia.
Ki van jelen a démón?
A scrum csapat, a scrum master, a management és a stakeholderek
A scrum csapat
A scrum csapat és a scrum master
A scrum csapat, a scrum master és a management
Milyen sűrűn van hardening sprint?
Csak a projekt kezdetén.
Csak a projekt végén.
Néhány sprintenként.
Kivételes helyzetekben.
Mi nem igaz a hardening sprintről?
End-to-end tesztek végrehajtását tartalmazza.
Nem ajánlott / Bad practice.
Ajánlott időnként különösebb indok nélkül is.
Más, befejezetlen sprintek lezárásához szükséges.
Milyen tesztelés az átvételi tesztelés?
Black-box tesztelés.
White-box tesztelés.
Regressziós tesztelés.
Smoke tesztelés.
Az alábbiak közül melyik funkcionális teszt?
Stressz teszt.
Használhatósági teszt.
Biztonsági teszt.
Integrációs teszt.
Az Isolate Change refaktorálási technika szerint:
Két kódrészlet lépésenként addig módosítunk, míg azonos kódot nem kapunk.
Először válasszuk le a módosítandó kódot, refaktoráljunk, majd helyezzük vissza.
Ideiglenesen duplikáljunk egy algoritmust, majd a hívókat egyesével kössük át.
Az adatok reprezentációjának módosításakor ideiglenesen duplikáljuk a struktúrát.
Mi a gyors fejlesztés és a kódminőség kapcsolata?
Gyors fejlesztés következménye a kódminőség romlása.
Agilis módszertan egyik alapelve a gyors és minőségi fejlesztés.
Magas kódminőség garancia a gyors fejlesztésre.
Nincs kapcsolat.
Az alábbiak közül mi nem igaz a statikus kódelemzésre?
Jelzi a hibákat és hiba lehetőségeket, de nem a pontos helyen.
A használt szabályrendszer testreszabható.
A teljes kódbázist lefedi.
Könnyen bevezethető.
Tesztelhető-e automata tesztekkel a felhasználók számára nem látható funkcionalitás?
Igen, API hívások révén.
Igen, kódelemzés segítségével.
Nem, mert csak az tesztelhető, ami a felületre ki van vezetve.
Nem, mert az nem is lényeges funkcionalitás.
Melyik BDD sablon?
Red Green - Refactor.
Given - When - Then.
Role - Function - Reason.
Spec Flow.
Melyik fejlesztési technika célja a követelmények megértése?
TDD.
BDD.
ATDD.
DDD.
Mi a TDD első lépése?
Új funkcionalitás implementálása.
Új tesztek létrehozása a később létrehozandó funkcióhoz.
Tesztek létrehozása korábban létrehozott funkciókhoz.
Refaktorálni a már meglévő kódot.
Mit nem céla kideríteni a User Acceptance Test-nek?
Az alkalmazás automatikus tesztelhetőségének mértéke
Az alkalmazás az elvárásoknak megfelelő módon működik üzleti igények szempontjából
Az alkalmazás használható a végfelhasználó szempontjából
Az alkalmazás működése megfelel a jogi/szabályozási követelményeknek
Melyik nem része a Gherkin nyelven írt BDD sablonnak?
Given
When
Then
Except
