70 otázok na pohovor o agilnej metodológii

V súčasnosti je agilná metodika široko používanou metodikou v riadení softvéru a v agilných projektoch je vysoký dopyt po scrum mastroch, vývojároch a testeroch. V tomto článku sme zostavili zoznam najlepších otázok na pohovore o agilnej metóde.

Otázky na pohovor o agilných metódach

Otázky.1. Čo je to agilná metodika?

Odpoveď: Agilná metodika sa používa pri vývoji softvéru. Zameriava sa na metódy inkrementálneho vývoja, kde cieľom metodiky je rýchle dodanie produktu. 

Otázka.2. Čím sa agilná metodika líši od tradičných metodík?

Odpoveď: Hlavný rozdiel medzi agilnou metodikou a ostatnými tradičnými metodikami je v tom, že agilná metodika sa riadi modelom inkrementálneho vývoja, zatiaľ čo tradičné metodiky sa riadia sekvenčným modelom.

V agilnej metodike prebieha vývojová fáza a fáza testovania súčasne. V tradičnej metodike sa fáza testovania začína po skončení fázy vývoja.

Agilná metodika poskytuje flexibilitu, pretože zavádzanie zmien je jednoduchšie. V tradičnej metodike je začlenenie zmien ťažké, pretože pred začatím vývojových prác sú požiadavky zmrazené.

Agilná metodika potrebuje menej dokumentácie. Vďaka rýchlemu dodaniu vývojári vykonávajú zmeny v kóde na základe potreby. Zatiaľ čo v tradičnej metodike sa proces vývoja začína až po tom, čo má tím k dispozícii hotové zdokumentované požiadavky.

Zákazníci sú zapojení do každej fázy životného cyklu agilného softvéru, kontrolujú produkt a v prípade potreby navrhujú zmeny. V tradičnej metodike sú zákazníci zapojení najmä do fázy zhromažďovania požiadaviek. Hotový produkt zvyčajne vidia v posledných fázach životného cyklu vývoja.

Otázka.3. Môžete vymenovať niektoré agilné frameworky?

Odpoveď: 

• Scrum
• Crystal
• Metóda dynamického vývoja systémov (DSDM)
• Feature Driven Development (FDD)
• Kanban
• Adaptívny vývoj softvéru (ASD)
• Lean Software Development (LSD)

Otázka.4. Čo je to agilný manifest?

Odpoveď: Agilný manifest je dokument pre agilný vývoj softvéru, ktorý pripravilo 17 podobne zmýšľajúcich odborníkov na vývoj softvéru a ktorý bol uverejnený vo februári 2001. Je postavený na 4 základných hodnotách a 12 podporných princípoch.

Otázka.5. Aké sú štyri hodnoty agilného manifestu?

Odpoveď: Štyri základné hodnoty agilného manifestu sú tieto:

• Jednotlivci a interakcie nad procesmi a nástrojmi.
• Pracovný softvér nad komplexnou dokumentáciou.
• Spolupráca so zákazníkom nad zmluvnými rokovaniami.
• Reakcia na zmenu namiesto dodržiavania plánu.

Otázka.6. Ktorých 12 princípov obsahuje manifest agilného prístupu?

Odpoveď: Nasleduje 12 zásad agilného manifestu:

• Našou najvyššou prioritou je uspokojiť zákazníka prostredníctvom včasného a nepretržitého dodávania hodnotného softvéru.
• Vítajte meniace sa požiadavky, a to aj v neskorej fáze vývoja. Agilné procesy využívajú zmeny v prospech konkurenčnej výhody zákazníka.
• Dodávať funkčný softvér často, od niekoľkých týždňov do niekoľkých mesiacov, pričom uprednostňujeme kratšie časové horizonty.
• Obchodníci a vývojári musia spolupracovať denne počas celého projektu.
• Projekty budujte okolo motivovaných jednotlivcov. Poskytnite im prostredie a podporu, ktorú potrebujú, a dôverujte im, že svoju prácu zvládnu.
• Najefektívnejšou a najúčinnejšou metódou odovzdávania informácií vývojovému tímu a v rámci neho je osobný rozhovor.
• Pracujúci softvér je hlavným meradlom pokroku.
• Agilné procesy podporujú udržateľný vývoj. Sponzori, vývojári a používatelia by mali byť schopní udržiavať konštantné tempo neobmedzene dlho.
• Neustála pozornosť venovaná technickej dokonalosti a dobrému návrhu zvyšuje agilitu.
• Jednoduchosť – umenie maximalizovať množstvo nevykonanej práce – je nevyhnutná.
• Najlepšie architektúry, požiadavky a návrhy vznikajú v samoorganizujúcich sa tímoch.
• V pravidelných intervaloch tím uvažuje o tom, ako sa stať efektívnejším, a potom podľa toho ladí a upravuje svoje správanie.

Otázka. 7. Čo je to extrémne programovanie (extreme programming)?

Odpoveď: Extrémne programovanie alebo XP je jeden z populárnych prístupov k agilnému vývoju softvéru. Používa objektovo orientovaný prístup a riadi sa rovnakými postupmi, ktoré sú zahrnuté v agilnom manifeste. 

Extrémne programovanie je zodpovedné za zavedenie konceptov, ktoré sa teraz široko používajú ako štandardné postupy, ako sú používateľské príbehy, nepretržitá integrácia a vývoj riadený testovaním. Jednou z výhod extrémneho programovania je, že poskytuje flexibilitu pri začleňovaní meniacich sa požiadaviek v ktoromkoľvek bode životného cyklu vývoja. 

Otázka. 8. Ktorých je päť základných zásad extrémneho programovania?

Odpoveď: Nasleduje päť hodnôt alebo základných princípov extrémneho programovania:

• Komunikácia – táto zásada sa zameriava na včasnú a úzku komunikáciu medzi príslušnými stranami (najmä vývojármi a zainteresovanými stranami).
• Jednoduchosť – Základnou myšlienkou tejto zásady je pracovať najprv na bezprostredných funkciách a zachovať jednoduchosť. Kód by mal byť taký, aby sa dal ľahko implementovať a v prípade potreby zmien sa mohol refaktorizovať. 
• Spätná väzba – Na získavanie spätnej väzby sa používajú tri zdroje. Vykonávaním unit testovania sa zachytáva spätná väzba systému. Vykonávaním akceptačného testovania sa zachytáva spätná väzba zákazníka a vykonávaním plánovacej hry sa zhromažďuje spätná väzba ostatných členov softvérového tímu.
• Odvaha – tento princíp sa zameriava na odvahu potrebnú na navrhovanie okamžitých funkcií, pričom sa zameriava len na prítomnosť. Agilný tím by mal mať odvahu uznať aj skutočnosť, že požiadavky sa môžu v budúcnosti zmeniť a bude ich potrebné zapracovať do kódu.
• Rešpekt – Tento princíp sa zameriava na sebaúctu, rešpekt získaný od ostatných a rešpekt poskytnutý ostatným členom tímu.

Otázka.9. Aké sú štyri frameworkové činnosti extrémneho programovania?

Odpoveď: 

• Plánovanie
• Návrh
• Programovanie
• Testovanie

Otázka.10. Čo je to refaktoring?

Odpoveď: Refaktoring je proces zmeny existujúceho zdrojového kódu bez zmeny jeho funkčnosti.

Otázka.11. Čo je párové programovanie?

Odpoveď: Párové programovanie je technika používaná pri agilnom vývoji softvéru, pri ktorej dvaja vývojári pracujú ako tím. Jeden z dvoch vývojárov píše kód a je známy ako „driver“, zatiaľ čo druhý kód kontroluje a je známy ako pozorovateľ. V prípade potreby si môžu svoje úlohy vymeniť.

Otázka.12. Aké sú výhody párového programovania?

Odpoveď: 

• Výsledkom párového programovania je vyššia kvalita kódu a menej chýb v kóde, pretože druhý vývojár neustále kontroluje kód v priebehu jeho písania.
• Párové programovanie uľahčuje hľadanie riešení akéhokoľvek problému, ktorý sa vyskytne počas kódovania, pretože druhý partner môže pomôcť.
• Umožňuje jednoduchý prenos znalostí, pretože ak je jeden z partnerov skúsenejší, môže druhého vývojára učiť.

Otázka.13. Aké sú rôzne techniky odhadu v agilnom prostredí?

Odpoveď: Agilné techniky odhadu sa používajú na odhadnutie pracovného úsilia. Nasledujú niektoré z agilných techník odhadu:

Planning Poker 

T-shirt sizes 

Affinity Estimation

Sorting Method

The Bucket System

Three-Point Method

Dot Vote

Otázka. 14. Čo je to planning poker technika?

• Odpoveď: Planning poker je technika odhadu, ktorá zahŕňa spoluprácu medzi členmi tímu. Vykonáva sa pred začiatkom iterácie s pomocou vývojárov. 
• Každý člen dostane balíček plánovacích pokerových kariet. Hodnoty kariet sú podobné Fibonacciho číslam. Tieto čísla predstavujú story points alebo dni. 
• Vlastník produktu (PO – Product Owner) prečíta a vysvetlí tímu používateľský príbeh (user story). Vývojári môžu ďalej diskutovať, ak majú nejaké otázky.
• Po diskusii každý člen odhadne úsilie pri vývoji danej story a súkromne vyberie ľubovoľnú kartu, ktorá predstavuje úsilie. 
• Všetky karty sa odhalia súčasne a ak sú všetky rovnaké, príbeh sa odhadne na základe hodnoty karty.
• Ak sa hodnoty kariet líšia, prebieha ďalšia diskusia, ktorá pokračuje dovtedy, kým sa všetci členovia tímu nedohodnú na rovnakom čísle.

Otázka. 15. Čo je to t-shirt sizing technika?

Odpoveď: T-shirt sizing je technika odhadu používaná na meranie veľkosti user story a používa sa najmä vtedy, keď je potrebné odhadnúť relatívne veľké položky backlogu. Pri t-shirt sizing sa na odhad príbehu používajú veľkosti tričiek (XS, S, M, L, XL). Rozhodnutie o veľkosti si vyžaduje otvorenú diskusiu. 

Otázka .16. Čo je to Lean Software Development (LSD)?

Odpoveď: Lean Software Development je iteratívna agilná metodika, ktorá prevzala princípy z ‚lean manufacturing process‘ a implementovala ich do procesu vývoja softvéru. 

Niektoré z prevzatých princípov sú rýchle dodanie, eliminácia plytvania, optimalizácia času a zdrojov vývoja, budovanie kvality produktu atď. 

Otázka.17. Čo je to Kanban?

Odpoveď: Podobne ako Scrum, aj Kanban je jedným z populárnych frameworkov používaných pri agilnom vývoji softvéru. Kanban je japonský výraz pre tabule. V tomto rámci sa pracovné položky alebo používateľské príbehy zobrazujú na tabuli Kanban, tím môže na tabuli vidieť stav každého používateľského príbehu (user story). Kanban umožňuje, aby sa produkt vyvíjal v jednom veľkom vývojovom cykle namiesto toho, aby mal iterácie (ako Scrum). Kanban je inkrementálny, nie iteračný.  

Otázka.18. Čo je to Scrumban?

Odpoveď: Scrumban je agilná metodika vývoja, ktorá je kombináciou scrumu a kanbanu.

Scrumban sa používa najmä pri projektoch údržby, kde sa scrumové procesy vylepšujú pomocou princípov Kanban. Pomáha projektovému tímu pri optimalizácii procesov.

Súčasťou scrumbanu je rozhodovanie o množstve práce, ktorú možno vykonať v šprinte, a určenie priorít úloh.

Kanban časť scrumbanu sa používa na zlepšenie procesov a vizualizáciu pracovného postupu. Scrumban využíva pull systém Kanban; pri ktorom sa položky priebežne vyťahujú z backlogu.

Otázka.19. Čo je to vývoj riadený testami (TDD)?

Odpoveď: Test-Driven Development (TDD) je proces vývoja softvéru, pri ktorom sa najprv napíšu testovacie prípady a až potom sa kóduje. Testovacie prípady sa píšu na overenie toho, čo má kód robiť.

Nasledujú základné pravidlá procesu vývoja TDD:

• Najprv sa napíše unit test, ktorý opisuje funkciu systému.
• Ďalším krokom je spustenie testu. Zlyhá, pretože funkcia v systéme neexistuje.
• Napíšte kód, ktorý bude funkciu v systéme obsahovať. Základnou myšlienkou je napísať jednoduchý test tak, aby testovací prípad prešiel.
• Prepracovať kód podľa potreby.
• Zopakujte vyššie uvedené kroky pre ďalšie funkcie systému.

Otázka.20. Čo je DevOps?

Odpoveď: DevOps je súbor myšlienok a postupov, ktoré spájajú vývoj softvéru (Dev) a prevádzku informačných technológií (Ops). DevOps spája vývojový a prevádzkový tím s cieľom poskytovať vysokokvalitný a spoľahlivý softvér a skrátiť čas vývoja.

Otázka.21. Aké sú rozdiely a podobnosti medzi scrumom a agilným prístupom?

Agilná metodika sa používa pri vývoji softvéru. Zameriava sa na metódy inkrementálneho vývoja, kde cieľom metodiky je rýchle dodanie produktu. Zatiaľ čo scrum je jedným z frameworkov agilnej metodiky, ktorý spadá pod agilné riadenie projektov. Používa sa aj pri vývoji softvéru. 

Agile sa pri dokončovaní projektov riadi inkrementálnym a iteračným prístupom. Scrum má tiež inkrementálny a iteratívny charakter.

Otázka.22. Môžete stručne vysvetliť agilné testovanie?

Odpoveď: Agilné testovanie je proces testovania softvéru, ktorý sa riadi zásadami agilného vývoja softvéru. Agilný vývojový proces je iteračný proces, v ktorom sa požiadavky neustále menia podľa potrieb zákazníka. Agilné testovanie je nepretržitý proces, ktorý sa vykonáva súčasne s procesom vývoja. Agilné testovanie zahŕňa priebežné testovanie systému, kým sa nedosiahne požadovaná kvalita softvéru. 

Otázka. 23. Aký prístup by ste mali ako agilný tester uplatňovať, keď sa požiadavky priebežne menia?

Po prvé, pri vytváraní testovacích prípadov by sa mal agilný testovací tím zamerať na písanie všeobecných testovacích prípadov, ktoré môžu byť užitočné pri zmene testovacích prípadov v budúcnosti.

Agilný tester by mal spolupracovať s vlastníkom produktu a biznis analytikom, aby pochopil zmenené požiadavky a riziká spojené so zmenou, aby mohol upraviť testovacie prípady. 

Testovací tím by mal pristúpiť k automatizovanému testovaniu až po zmrazení požiadaviek.

Otázka .24. Aké sú niektoré vlastnosti dobrého agilného testera?

Odpoveď: Nižšie sú uvedené niektoré dôležité vlastnosti, ktoré by mal mať dobrý agilný tester:

• Agilný tester by mal mať hlboké znalosti agilných princípov a konceptov.
• Agilný tester by mal byť schopný rýchlo a jasne pochopiť požiadavky projektu.
• Mal by byť dobrým komunikátorom, pretože agilný proces podporuje neustálu interakciu s obchodnými analytikmi, vývojármi a ostatnými testermi.
• Agilný tester by mal byť schopný zvládnuť meniace sa požiadavky. Mal by byť schopný pochopiť riziko vyplývajúce zo zmeny a mal by byť schopný upraviť testovacie prípady na základe meniacich sa požiadaviek.

Otázka. 25. Aké sú niektoré agilné metódy testovania?

Odpoveď: 

• Vývoj riadený správaním (BDD – Behaviour Driven Development) 
• Acceptance Test-Driven Development (ATDD)
• Prieskumné testovanie (Exploratory Testing)
• Testovanie založené na reláciách (Session-Based Testing)

Otázka. 26. Aké sú fázy životného cyklu agilného testovania?

Odpoveď: Životný cyklus agilného testovania sa delí na nasledujúce etapy:

• Agilné plánovanie testovania (Agile Test Planning) – V tejto fáze zainteresované strany vytvárajú harmonogramy plánov testovania a výstupy, ktoré sa majú testovať.
• Denné scrum meetingy (Daily Scrums) – Tieto stretnutia zahŕňajú diskusiu o stave testovacích aktivít vykonaných v predchádzajúci deň a stanovenie cieľov testovania na daný deň.
• Test Agility Review – Tieto stretnutia sa uskutočňujú každý týždeň so zainteresovanými stranami s cieľom preskúmať pokrok.
• Pripravenosť na vydanie (Release Readiness) – V tejto fáze sa vykonáva preskúmanie funkcií s cieľom skontrolovať pripravenosť funkcií na spustenie do produkcie.
• Analýza dopadov (Impact Analysis) – V tejto fáze sa zhromažďuje spätná väzba od zainteresovaných strán a pripravujú sa ciele pre ďalší životný cyklus.

Otázka .27. Aký je rozdiel medzi inkrementálnym a iteratívnym vývojom?

Odpoveď: Pri iteratívnej metóde vývoja sa softvér vyvíja a dodáva zákazníkovi. Po získaní spätnej väzby od zákazníka sa táto spätná väzba zohľadní v softvéri a ten sa opäť vyvíja v šprintoch a potom sa dodá zákazníkovi.

Pri inkrementálnej metóde vývoja sa softvér vyvíja v prírastkoch. Každý prírastok obsahuje dokončené vlastnosti niektorých čiastkových funkcií systému.

Otázka .28. Čo je to kandidát na vydanie (release candidate)?

Odpoveď: Release candidate je zostavenie systému, ktoré je funkčné a je uvoľnené interne na účely testovania. Nepoužíva sa na produkčné nasadenie. Na zostave sa vykonáva testovanie, aby sa zabezpečilo, že v systéme nie sú prítomné žiadne kritické problémy.

Release candidate je kód / verzia / zostavenie uvoľnené s cieľom uistiť sa, že počas posledného obdobia vývoja nezostal žiadny kritický problém. Používa sa na testovanie a je rovnocenný s konečným zostavením.

Otázka .29. Čo je to prerušovač buildu (build breaker)?

Odpoveď: Build breaker je situácia, keď chyba v softvéri zastaví kompiláciu a spôsobí varovania alebo zlyhania v automatizovanom testovacom prostredí. Stáva sa to vtedy, keď vývojári omylom zapíšu chyby v softvéri.

Otázka .30. Ako môže QA pridať hodnotu agilnému tímu?

• Testeri sa zúčastňujú na zasadnutiach analýzy rizík s cieľom identifikovať riziká a kroky na ich predchádzanie.
• Testeri študujú používateľské príbehy (user stories), pomáhajú pri tvorbe akceptačných kritérií (acceptance criteria).
• Vykonávajú prieskumné testovanie (exploratory testing) novo vyvinutých funkcií.
• Môžu vývojárom poskytovať priebežnú a rýchlu spätnú väzbu systému, keďže testovali softvér.
• Testeri sa podieľajú na automatizovanom testovaní.
• Tester pomáha pri zisťovaní všetkých chýb, ktoré sa v systéme vyskytnú.
• Testeri sa môžu pokúsiť rozmýšľať inak o rôznych scenároch, ktoré sa majú testovať, aby sa rozšírilo pokrytie testov a našlo sa viac chýb v systéme.

Otázka .31. Aké sú výhody agilného modelu?

• Agilný model podporuje rýchle a kontinuálne dodávanie softvéru.
• Keďže agilný model je flexibilný, pomáha prispôsobiť sa akýmkoľvek zmenám navrhnutým zákazníkmi.
• Agilný proces zahŕňa vysokú interakciu medzi rôznymi členmi tímu, ktorá pomáha rýchlo identifikovať akékoľvek problémy v procese vývoja.
• Agilný model pomáha pri zvyšovaní počtu zákazníkov softvéru, pretože dodávka je rýchla a po každom prírastku je zákazníkovi dodaný funkčný produkt.
• Zákazníci si môžu produkt prezrieť v a po každom inkremente, čo im dáva istotu, že proces vývoja prebieha správnym smerom.

Otázka . 32. Aké sú nevýhody agilného modelu?

• Keďže sa požiadavky často menia, vývojári nemusia byť schopní kvantifikovať plný rozsah úsilia potrebného v procese vývoja.
• Agilná metóda kladie menší dôraz na dokumentáciu, čo môže v budúcnosti spôsobiť problémy najmä novým účastníkom projektu.
• Očakáva sa nepretržité zapojenie tímu klienta, ktoré si vyžaduje, aby bol tím klienta k dispozícii na stretnutiach.
• Ak klientsky tím nie je schopný jasne vysvetliť konečný výsledok systému, projekt sa môže dostať mimo trať.
• Agilný proces vývoja si vyžaduje skúsených vývojárov, ktorí majú zručnosti na vývoj systému so schopnosťou prijímať niektoré rýchle a zásadné rozhodnutia počas procesu.
• Očakáva sa nepretržitá interakcia každého člena tímu, ktorá zvyšuje čas a energiu potrebnú na prácu tímu.

Otázky na pohovore pre Scrum Master

Otázka.33. Môžete v krátkosti vysvetliť pojem Scrum?

Odpoveď: Scrum je jedným z najpoužívanejších frameworkov agilnej metodiky. Činnosti frameworku Scrum sú požiadavky, analýza, návrh, vývoj a dodanie.

V Scrume sa zoznam požiadaviek pridáva do backlogu, ktorý sa nazýva produktový backlog (product backlog). Na dosiahnutie požiadaviek sa vytvárajú pracovné jednotky nazývané šprinty. Každý šprint obsahuje určité požiadavky z produktového backlogu a môže trvať 2 až 4 týždne.

Otázka. 34. Prečo sa scrum nazýva odľahčený procesný framework?

Odpoveď: Agilný framework scrum je odľahčený procesný rámec, pretože má len niekoľko pravidiel a postupov. Tento framework je flexibilný a prispôsobivý a dokáže ľahko zapracovať zmeny v požiadavkách. Vo frameworku scrum je vývoj produktu rozdelený na šprinty, ktoré majú krátke trvanie.

Otázka. 35. Kedy používame agilnú metodiku scrum?

Odpoveď: 

• Keď požiadavky nie sú jasné.
• Keď je vysoká pravdepodobnosť zmien požiadaviek počas vývoja.
• Scrum môžeme použiť aj vtedy, keď existuje požiadavka na rýchle dodanie produktu .
• Keď je vývojový tím samoorganizujúci sa a multifunkčný.

Otázka. 36. Aké sú tri piliere scrumu?

Odpoveď: Nasledujúce sú tri piliere scrumu:

• Transparentnosť – všetky aspekty procesu vývoja produktu by mali byť viditeľné pre príslušné strany, ako je vývojový tím, klient, scrum master atď.
• Kontrola – Účastníci scrumu by mali pravidelne kontrolovať artefakty scrumu a zisťovať, či nie je niečo, čo blokuje pokrok. 
• Prispôsobenie – Ak sa počas kontroly zistia nejaké otázky alebo problémy, mali by sa vykonať úpravy alebo zmeny v procese s cieľom odstrániť problémy.

Otázka. 37. Čo je to šprint?

Odpoveď: V Scrume je šprint krátke a časovo ohraničené obdobie, v ktorom vývojový tím vykoná určitý objem práce s cieľom vytvoriť produkt, ktorý sa dá releasnuť.  Je to základná jednotka vývoja v scrume. 

Otázka. 38. Ako dlho trvá cyklus scrum?

Odpoveď: Scrum cyklus alebo šprint závisí od veľkosti tímu a projektu. Šprint nesmie presiahnuť mesiac, t. j. 4 týždne. Bežne trvá šprint v priemere niekoľko týždňov. 

Otázka. 39. Aké sú primárne artefakty scrum procesu?

Odpoveď: Artefakty procesu Scrum sú zodpovedné za poskytovanie kľúčových informácií vývojovému tímu a klientovi. Pomáhajú pri rovnakom chápaní detailov vývoja produktu.

Existujú najmä tri artefakty:

• Produktový backlog – Produktový backlog je zoznam položiek, ktoré má vlastník produktu (product owner) urobiť. Pozostáva z požiadaviek, vylepšení, funkcií atď. 
• Sprint backlog – Sprint backlog je zoznam položiek úloh vybraných z produktového backlogu, ktoré sa majú dokončiť v konkrétnom šprinte.
• Inkrement – Inkrement pozostáva zo zoznamu všetkých položiek produktového backlogu, ktoré boli dokončené počas šprintov. Je to jeden z výstupov scrumu.

Otázka.40. Môžete povedať o rôznych udalostiach vykonávaných v každom scrum šprinte?

Odpoveď: Scrum sa skladá z nasledujúcich štyroch udalostí, ktoré sa používajú na kontrolu a prispôsobenie:

• Sprint planning – Pri plánovaní šprintu sa uskutočňuje podrobná diskusia o práci na projekte, ktorá sa má vykonať v šprinte. 
• Daily scrum – Daily scrum je časovo vymedzený na 15 minút, počas ktorých sa prediskutujú činnosti vývojového tímu na nasledujúcich 24 hodín. Zahŕňa aj diskusie týkajúce sa práce vykonanej za posledných 24 hodín.
• Sprint Review – Sprint Review sa vykonáva na konci šprintu. Vykonáva sa s cieľom prediskutovať inkrement. 
• Sprint Retrospective (Retrospektíva šprintu) – Sprint Retrospective sa vykonáva preto, aby sa vývojový tím mohol skontrolovať a aby sa prediskutovali zlepšenia alebo zmeny, ktoré sa môžu vykonať v ďalšom šprinte pre vyššiu efektivitu.
• Otázka. 41. Čo je to sprint planning?

Odpoveď: Pri plánovaní šprintov sa vytvára plán práce, ktorú je potrebné vykonať v konkrétnom šprinte. V prípade mesačného šprintu je plánovanie šprintu časovo obmedzené na maximálne 8 hodín. Scrum master je zodpovedný za to, aby účastníci pochopili jeho účel.

Nasledujú dve otázky, na ktoré sa odpovedá pri plánovaní šprintu:

Čo je možné dodať v šprinte? – Product owner prediskutuje cieľ šprintu a vyberú sa položky z produktového backlogu, ktoré sa zahrnú do šprintového backlogu.

Ako sa bude práca vykonávať? – Na základe šprintového backlogu musí vývojový tím rozhodnúť, ako bude pracovať na vývoji použiteľného inkrementu.

Otázka. 42. Čo je to daily scrum?

Odpoveď: Daily scrum je udalosť, na ktorej sa diskutuje o činnostiach vývojového tímu na nasledujúcich 24 hodín. Je časovo obmedzená na maximálne 15 minút. V rámci tejto udalosti sa odpovedá na nasledujúce otázky-

• Čo som robil včera?
• Čo budem robiť dnes?
• Vidím nejaké prekážky, ktoré bránia tímu splniť cieľ šprintu?

Cieľom denného scrumu je skontrolovať pokrok v plnení položiek backlogu šprintu.

Otázka. 43. Čo je to kontrola šprintu?

Odpoveď: Preskúmanie šprintu sa vykonáva na konci šprintu s cieľom skontrolovať prírastok. Na sprint review sa zúčastňujú zainteresované strany a vývojové tímy. V rámci nej účastníci prechádzajú, čo sa v šprinte urobilo, diskutujú o prípadných problémoch, ktorým vývojový tím čelil, poskytujú spätnú väzbu atď. V prípade potreby sa aktualizuje produktový backlog a poskytnú sa vstupy pre plánovanie ďalšieho šprintu. 

Otázka.44. Čo je to retrospektíva šprintu?

Odpoveď: Retrospektíva šprintu sa vykonáva po preskúmaní šprintu a pred plánovaním šprintu. Zahŕňa kontrolu posledného šprintu a prispôsobenie zmien na zlepšenie v nadchádzajúcom šprinte.

Retrospektíva je časovo obmedzená na maximálne 3 hodiny pre mesačný šprint. Za jej vedenie a motiváciu ostatných členov tímu s cieľom zvýšiť efektivitu šprintu zodpovedá scrum master.

Otázka.45. Čo je to produktový backlog?

Odpoveď: Produktový backlog je zoznam položiek na vykonanie. Pozostáva z požiadaviek, funkcií, vylepšení, zmien atď. Vedie ho vlastník produktu, ktorý je zodpovedný za jeho obsah.

Produktový backlog sa neustále vyvíja s postupom vývoja produktu a zmenenými požiadavkami. 

Otázka. 46. Čo je to šprintový backlog?

Odpoveď: Pre konkrétny šprint sa vyberú určité položky produktového backlogu, na ktorých pracuje vývojový tím. Tento zoznam položiek sa nazýva Sprint backlog. Sprint backlog je podmnožinou produktového backlogu.

Otázka. 47. Čo je to nultý šprint?

Odpoveď: Pred začiatkom prvého šprintu je potrebné vykonať určité činnosti, ako je nastavenie vývojového prostredia, príprava produktového backlogu, ďalšie plánovanie súvisiace s nadchádzajúcim šprintom. Táto fáza sa nazýva nultý šprint. Je známa aj ako Inception Sprint, Initial Sprint alebo Sprint Zero.

Otázka. 48. Čo je to story point?

Odpoveď: Story point je merná jednotka na odhad celkového úsilia potrebného na realizáciu položky produktového backlogu alebo akejkoľvek inej práce. Pri výpočte potrebného úsilia možno zohľadniť niekoľko faktorov: množstvo práce, ktorú treba vykonať, zložitosť práce a akékoľvek riziko, ktoré môže vzniknúť počas práce.

Otázka.49. Čo je to burn up chart?

• Odpoveď: Burn up chart sa používa pri riadení projektov na sledovanie postupu prác na projekte.
• Burn up chart znázorňuje, koľko práce na projekte bolo dokončených, a tiež ukazuje celkový objem práce na projekte.
• Zvislá os v grafe vyhorenia predstavuje celkovú prácu a dokončenú prácu. Jednotkou tejto osi môžu byť dejové body, pracovné hodiny alebo pracovné dni. Horizontálna os predstavuje čas, ktorým môžu byť sprits, t. j. iterácie, dni alebo týždne.
• V grafe vyhorenia je jasne vidieť efekt zmeny rozsahu, pretože zobrazuje celkové množstvo práce. 

Otázka.50. Čo je to burn down graf?

Odpoveď: Burn down chart sa používa pri riadení projektov na sledovanie postupu prác na projekte.

• Burn down chart zobrazuje množstvo nevykonaných projektových prác.
• Zvislá os v grafe vyhorenia predstavuje zostávajúce množstvo práce. Jednotkou tejto osi môžu byť dejové body, pracovné hodiny alebo pracovné dni. Vodorovná os predstavuje čas, ktorý sa bude merať v spritoch, t. j. iteráciách.
• V grafe burn down sa efekt zmeny rozsahu zobrazuje ako negatívny pokrok vývojového tímu, pretože nezobrazuje celkové množstvo práce.

Otázka 51. Aké sú rôzne typy burn down diagramov?

Odpoveď: Existujú štyri typy burn down diagramov:

• Defect burn down chart
• Release burn down chart 
• Product burn down chart
• Sprint burn down chart

Otázka.52. Čo si predstavujete pod pojmom defect burn down chart?

Odpovede: Defekt burn down chart je vizuálne znázornenie zostávajúcej práce v rámci defekt backlogu. 

Vertikálna os v grafe vypálenia chýb predstavuje zostávajúce množstvo práce v zozname nevyriešených chýb. Jednotkou tejto osi sú chyby v zozname nevyriešených chýb. Vodorovná os predstavuje čas, ktorý sa bude merať v šprintoch, t. j. iteráciách.

Otázka. 53. Čo si predstavujete pod pojmom release burn down chart?

Odpoveď: Graf vyhorenia vydania sa používa na monitorovanie postupu vydania. Predstavuje zostávajúcu prácu na vydaní. 

Vertikálna os v grafe vyhorenia vydania predstavuje zostávajúce množstvo práce vo vydaní. Jednotkou tejto osi môžu byť hodiny, dni alebo body príbehu. Vodorovná os predstavuje čas, ktorý sa bude merať v šprintoch, t. j. iteráciách.

Otázka .54. Čo predstavuje burn down chart?

Odpoveď: Graf vyhorenia produktu je vizuálne znázornenie zostávajúcej práce na produkte backlog. 

Vertikálna os v grafe vyhorenia produktu predstavuje zostávajúce množstvo práce v produktovom backlogu. Jednotkou tejto osi sú body príbehu. Vodorovná os predstavuje čas, ktorý sa bude merať v šprintoch, t. j. iteráciách.

Otázka .55. Čo predstavuje sprint burn down chart?

Odpoveď: Sprint burn down chart je vizuálne znázornenie zostávajúcej práce konkrétneho šprintu.

Zvislá os v grafe vyhorenia šprintu predstavuje zostávajúce množstvo práce v šprinte. Jednotkou tejto osi môžu byť body príbehu, pracovné hodiny alebo pracovné dni. Vodorovná os predstavuje čas, ktorý sa bude merať v dňoch.

Otázka .56. Čo je to „spike“?

Odpoveď: Termín „spike“ vznikol v súvislosti s extrémnym programovaním. Niekedy sa môže stať, že pri určitom používateľskom príbehu narazia vývojári a ostatní členovia tímu na problém. Nie sú si vedomí riešenia problému a možno budú musieť vykonať výskum alebo experiment, aby našli riešenie.

Spike je experiment alebo investícia, ktorá pomáha vývojovému tímu odhadnúť príbeh. Spike zadáva do backlogu vlastník produktu. Spiky majú dva typy – funkčné spiky a technické spiky.

Napríklad používateľský príbeh obsahuje požiadavky na integráciu so softvérom tretej strany. Vývojári s týmto softvérom nikdy nepracovali a potrebujú určitý čas na jeho pochopenie. Vlastník produktu si môže na tento výskum nechať deň alebo dva a vytvoriť špice v backlogu.

Otázka č. 57. Čo je to tracer bullet?

Odpoveď: Niekedy sa môže stať, že niektoré user stories sú zložité a ťažko odhadnuteľné a obsahujú nový architektonický prvok, ktorý vývojári nepoznajú. V takýchto prípadoch sa môže na preskúmanie uskutočniteľnosti riešenia použiť tracer bullet s pomocou „spike“.

V tracer bullet sa jeden z komponentov používateľského príbehu zabuduje do koncového riešenia s minimálnym množstvom kódu a získa sa spätná väzba. Na základe implementácie jednej zložky sa môžu nakódovať ďalšie zložky príbehu.

Otázka. 58. Čo je to velocity (rýchlosť) v scrume?

Odpoveď: Rýchlosť je kľúčovou metrikou v scrume a používa sa na meranie množstva práce, ktoré môže vývojový tím pokryť v jednom šprinte. Velocity sa môže použiť aj na odhad času dodania ďalších verzií.

Otázka. 59. Ako merať velocity (rýchlosť)  v scrume?

Odpoveď: Existujú dva typy rýchlosti, t. j. skutočná rýchlosť a očakávaná rýchlosť.

• Skutočná rýchlosť sa vypočíta pomocou nasledujúceho vzorca

Skutočná rýchlosť = celkový počet dokončených bodov príbehu / počet šprintov

• Očakávaná rýchlosť sa vypočíta pomocou nasledujúceho vzorca

Očakávaná rýchlosť = celkový počet odhadovaných bodov príbehu / počet šprintov

Otázka.60. Čo je to user story (používateľský príbeh)?

Odpoveď: Používateľské príbehy sú jednoduché opisy používané na reprezentáciu obchodných požiadaviek z pohľadu koncového používateľa. Používateľské príbehy sú ľahšie pochopiteľné v porovnaní s bežnými požiadavkami alebo prípadmi použitia. 

Otázka.61. Čo sa myslí pod skratkou „INVEST“ v programe scrum?

Odpoveď: INVEST znázorňuje kritériá kvality dobrej user story Je to skratka pre –

I –  Independent (nezávislý); User story by mal byť taký, aby nebol závislý od iného príbehu 

N – Negotiable (vyjednávateľný); V každom príbehu by mal byť priestor na vyjednávanie

V – Valuable (hodnotný); Mal by prinášať hodnotu pre koncového používateľa

E – Estimable (odhadnuteľný); User story by mal byť taký, aby sa dal odhadnúť a aby sa dalo správne naplánovať šprint

S – Small (malý); Malo by ísť o malú prácu, ktorá sa dá dokončiť za 3 – 4 dni.

T – Testable (testovateľný); mal by byť testovateľný, t. j. mal by obsahovať akceptačné kritériá

Dobrá user story spĺňa všetky tieto kritériá, a ak ich nespĺňa, tím by mal zvážiť prepracovanie.

Otázka. 62. Aké sú tri zložky user story?

Odpoveď: 

• Card (Karta) – Karta zobrazuje používateľský príbeh v jeho surovej podobe. Užívateľský príbeh je napísaný n a karte vo fyzickej podobe (post-it note). Štandardný formát používateľského príbehu je: Ako [typ používateľa] chcem [cieľ], aby [nejaký dôvod].
• Conversation (Konverzácia) – Konverzácia prebieha medzi zákazníkmi, vlastníkmi produktu, testermi atď. s cieľom prediskutovať detaily karty.
• Confirmation (Potvrdenie) – Potvrdenie znamená odvodenie akceptačných kritérií, aby tím mohol potvrdiť, že príbeh bol úspešne implementovaný.

Otázka 63. Čo je to epic?

Odpoveď: Epic je veľký používateľský príbeh, ktorý možno rozdeliť na viacero malých používateľských príbehov. Jeden epic môže byť rozložený do viacerých šprintov.

Otázka.64. Čo je to task v scrume?

Odpoveď: Task (Úloha) je technická práca, ktorú vývojový tím vykonáva s cieľom dokončiť položku produktového backlogu v stanovenom časovom rámci.

Otázka.65. Aké sú hlavné úlohy v Scrume?

Odpoveď: Nasledujúce úlohy sú hlavné úlohy v scrume:

• Product Owner (Vlastník produktu) – Vlastník produktu je zodpovedný za reprezentáciu požiadaviek tímu. Mal by mať jasnú víziu toho, aký by mal byť produkt, a túto víziu by mal vlastník produktu efektívne komunikovať s tímom. 

Vlastník produktu je tiež zodpovedný za správu produktového backlogu. Zodpovedá za zoznam položiek produktového backlogu, ich zoradenie, zabezpečenie transparentnosti produktového backlogu, zabezpečenie toho, aby vývojový tím položkám produktového backlogu rozumel, a za optimalizáciu práce vývojového tímu. 

• Development Team (Vývojový tím) – Vývojový tím tvoria najmä vývojári, ktorí vykonávajú vývoj produktu kódovaním, testeri, ktorí testujú vyvinutý produkt, a obchodní analytici. Vývojový tím je zodpovedný za dodanie kvalitného softvéru vo forme použiteľného inkrementu na konci šprintu. Vývojový tím by mal byť samoorganizujúci sa a multifunkčný. Je dôležité poznamenať, že Scrum neuznáva žiadne iné tituly pre vývojový tím ako vývojár bez ohľadu na to, aké úlohy daná osoba vykonáva.
• Scrum Master – Scrum Master je vedúci vývojového tímu. Je zodpovedný za to, aby vývojový tím správne vykonával úlohy šprintu. Scrum master je ten, kto je zodpovedný za riadenie šprintu. 

Otázka. 66. Čo je to cieľ šprintu (sprint goal)?

Odpoveď: Cieľ šprintu je cieľ stanovený pre konkrétny šprint. Cieľ šprintu sa vytvára počas plánovania šprintu pred jeho začiatkom. V cieli šprintu sa vyberie zoznam položiek produktového backlogu, ktoré majú dodať primeranú funkčnosť. 

Otázka. 67. Čo je to task board v scrum?

Odpoveď: Task board je nástroj, ktorý sa používa na sledovanie postupu aktuálneho šprintu. Je to vizuálne znázornenie backlogu šprintu, kde tím vidí úlohy, ktoré sú hotové, ktoré prebiehajú a ktoré sa ešte len začnú.

Otázka.68. Čo je to prekážka (impediment) v scrume?

Odpoveď: Prekážka je niečo, čo ovplyvňuje produktivitu tímu a spomaľuje pokrok. 

Otázka.69. Môžete uviesť niekoľko príkladov prekážok?

Odpoveď: V scrume môžu byť prekážky:

• Technické problémy
• Organizačné problémy
• Nekvalifikovaní členovia tímu
• Problémy zainteresovaných strán
• Problémy s infraštruktúrou
• Prírodné katastrofy

Otázka . 70. Čo je scrum scrumov?

Odpoveď: Scrum of scrums je agilná technika na rozšírenie denných stand-up stretnutí, keď na tom istom projekte pracujú veľké tímy. Pri tejto technike sú skupiny rozdelené do agilných tímov po 5 až 10 ľuďoch. Každá podskupina alebo tím určí „ambasádora“ zo svojho tímu. Ambasádor sa zúčastňuje na každodenných stretnutiach s ambasádormi ostatných tímov.