Dokumentácia k riadeniu

Transcription

1 SLOVENSKÁ TECHNICKÁ UNIVERZITA V BRATISLAVE Fakulta informatiky a informačných technológií Ilkovičova 2, Bratislava 4 Dokumentácia k riadeniu 1. kontrolný bod Tímový projekt 2018/2019 Tím č. 04 : Fastar Bc. Michaela Balážová Bc. Kamil Janeček Bc. Tomáš Jendrejčák Bc. Matúš Kalafut Bc. Matej Končál Bc. Michal Maňak Bc. Ján Vnenčák Vedúci projektu: Ing. Kamil Burda Dátum poslednej úpravy:

2 Obsah 1. Úvod Role členov tímu a podiel práce Aplikácie manažmentov Sumarizácie šprintov Šprint č. 1 ( ) Retrospektíva šprintu č Šprint č. 2 ( ) Retrospektíva šprintu č Šprint č. 3 ( ) Retrospektíva šprintu č Globálna retrospektíva Metodiky Metodika pre prehliadku zdrojového kódu Prostredie Metodika pre písanie zdrojového kódu Všeobecné konvencie Konvencie pre Python Konvencie pre Javascript Metodika pre verziovanie zdrojového kódu Metodika pre nástroj JIRA Úlohy Roly Vytváranie úloh Stavy Akceptovanie user story Product ownerom Metodika ku dokumentácií Formálna úprava Jazyk Tvorba retrospektívy šprintu Dokumenty Metodika Definition of ready Metodika Definition of done Metodika plánovania... 21

3 7. Export evidencie úloh Webové sídlo tímu... 22

4 1. Úvod V dokumentácií riadenia zachytávame ako náš tím funguje, opisujeme samotný tím, rozdelenie úloh medzi členov tímu a celkové riadenie v rámci predmetu Tímový projekt. Významná časť tejto dokumentácie je venovaná aj používaným metodikám, ktoré sme si spoločne vytvorili a ktoré na projekte používame. Opisujeme tiež už realizované šprinty, popis jednotlivých úloh v šprinte, sumarizáciu šprintu a retrospektívu. Ako dôkaz pre našu vykonanú prácu slúžia exporty z nástroja JIRA. 2. Role členov tímu a podiel práce Náš tím sa skladá zo siedmich členov. Každý člen tímu má zodpovednosť za určitú oblasť pri vývoji produktu a pri úlohách týkajúcich sa manažmentu. Bc. Matej Končál server testovanie machine learning Bc. Matúš Kalafut vývojár machine learning Bc. Michal Maňak scrum master machine learning Bc. Kamil Janeček server testovanie kvalita kódu verziovanie Bc. Tomáš Jendrejčák machine learning testovanie 4

5 Bc. Michaela Balážová dokumentácia machine learning Bc. Ján Vnenčák webové sídlo tímu logger V rámci podielu prác pri moduloch rátame celkový strávený čas, či už je to implementácia, návrh, testovanie alebo code review. Taktiež pri práci na moduloch zahŕňame aj technickú dokumentáciu, ktorá sa píše spolu so zdrojovým kódom. Pri stĺpci iné zahŕňame aktivity, ktoré bolo potrebné vykonať buď pre nastavenie nástrojov alebo vytvorenie a správu webové sídla tímu. Meno člena tímu Bc. Matej Končál Bc. Matúš Kalafut Bc. Michal Maňak Bc. Kamil Janeček Bc. Tomáš Jendrejčák Bc. Michaela Balážová server modul machine learning logger modul dokumentácia 25% 24% 5% 6% 20% 8% 19% 5% 8% 5% 8% 24% 5% 6% 10% 35% 5% 5% 8% 25% 8% 19% 5% 6% 5% 8% 9% 5% 60% 5% Bc. Ján Vnenčák 8% 0% 70% 6% 30% iné (webstránka, JIRA) 5

6 3. Aplikácie manažmentov Do procesu tvorby metodík sa zapojil každý člen tímu, každý mal na starosti vypracovanie jednej z nich. Tvorba metodiky spočívala najprv zo spoločnej konverzácie a diskusie ohľadne vzniknutých problémov, až kým sa celý tím nedohodol na spoločných riešeniach a následne bolo realizované jej vypracovanie. Väčšina metodík sa zatiaľ počas práce na projekte nemenili - napr. verziovanie, kde bol dohodnutý formát ako majú vyzerať rôzne vetvy a commit správy v nich. Pri metodike ohľadne dokumentácie bolo dohodnuté, že pre lepšiu prístupnosť širšej verejnosti sa dokumentácia k inžinierskemu dielu bude vypracovávať aj v anglickom jazyku. V metodike ohľadne nástroja JIRA boli upresnené prechody medzi stavmi pre rôzne úrovne (story, sub-task). V niektorých šprintoch sú zaradené samostatne stojace tasky, ktoré nepatria pod žiadnu story a tým pádom nemajú odhadnuté story points. V tomto prípade sa jedná o funkcionalitu, ktorá musí byť realizovaná pre úspešné dokončenie šprintu. Sú to úlohy, ktoré nevieme namapovať pre žiadnu story, resp. neposkytujú priamu funkcionalitu pre používateľa - napr. vytvorenie demo ukážky pre PO alebo naštudovanie problematiky, ktorá sa bude realizovať v nasledujúcom šprinte. Tiež sme si pridali do metodiky plánovania, že každá story, ktorá vstupuje do nového šprintu musí mať priradenú osobu, ktorá je za ňu zodpovedná. 4. Sumarizácie šprintov 4.1. Šprint č. 1 ( ) V prvom šprinte sme sa zamerali na úlohy týkajúce sa manažmentu a vytvorenie prvotného loggera pre počítačovú myš. Vytvorili sme Big Picture projektu, kde sme opísali náš projekt, definovali sme si ciele, ktoré by chceli naplniť na konci zimného semestra a vízie, ktoré by sme chceli realizovať ďalej v letnom semestri. Tento dokument opisuje aj navrhovanú architektúru systému. Určili sme si metodiky, ktoré používame pri manažmente projektu, tiež sú bližšie popísané v kapitole 6. Na metodikách pracoval každý člen tímu. Implementovali sme základný logger a ukladanie dát z myši na webe. Pre udalosti z myši sme zachytávali súradnice (x, y), typ udalosti a časovú známku. Nastavili sme aj databázový server, kde sme ukladali testovacie dáta. Typ Popis úlohy Story points Realizovatelia Story Logovanie surových dát z počítačovej myši 13 Ján Vnenčák, Kamil Janeček 6

7 Story Ukladanie logovaných dát 13 Managment story Big picture 13 Kamil Janeček, Matej Končál Michaela Balážová, Michal Manak Managment story Metodiky 5 všetci členovia tímu Retrospektíva šprintu č. 1 Čo sme urobili dobre? Stihli sme všetko, čo sme mali naplánované Rovnomerné rozdelenie úloh Čo sme mohli urobiť lepšie? Akcie Vylepšiť časové plánovanie Vylepšiť remote komunikáciu o úlohách Zmierniť automatické notifikovanie o činnostiach (JIRA, Confluence) Vyriešiť automatické notifikovanie - spoločné stretnutie a diskusia Pozrieť sa znova na metodiky, po komentároch 4.2. Šprint č. 2 ( ) V druhom šprinte sme prepojili vytvorený logger so serverom, teda loggované dáta boli posielané na priamo na server a ukladané do databázy. Vytvorili sme rozhranie loggera pre možnosť loggovania vlastných (custom) udalostí. Pomocou vytvoreného machine learning modul sme rozdelili používateľské dáta na jednotlivé segmenty a realizovali sme výpočet stĺpcov s rýchlostnými metrikami. V tomto šprinte nám nastala situácia, kedy pri prezentácií demo ukážky PO nebol kompletne spokojný s výsledkom, chyba nastala v komunikácií a v nekompletnej špecifikácií. V tomto prípade sme postupovali podľa postupu, ktorý je opísaný v metodiky pre nástroj JIRA - teda prípad, kedy PO čiastočne akceptuje Story (odpočítanie nového odhadu chýbajúcej funkcionality). Typ Story Popis úlohy Pokročilé logovanie surových dát z počítačovej myši Story points Realizovatelia 2 Ján Vnenčák, Kamil Janeček 7

8 Story Logovanie vlastných eventov 8 Story Story Story Task Rozdelenie surových dát do časových intervalov a segmentov Výpočet rýchlostných stĺpcov zo surových dát Integrácia loggera spolu so serverom Príprava jupyter notebooku pre demo ukážku Retrospektíva šprintu č. 2 Čo sme urobili dobre? Ján Vnenčák, Kamil Janeček, Michal Manak, Matúš Kalafut 12 Matej Končál, Michal Manak Michaela Balážová, Matej Končál, Michal Manak, Tomáš Jendrejčák Matej Končál, Kamil Janeček, Matúš Kalafut, Ján Vnenčák - Matúš Kalafut, Matej Končál Aj napriek študijnému voľnu sme dodržali pracovnú hygienu Pekne vypracovaná demo ukážka Čo sme mohli urobiť lepšie? Akcie Zlepšiť komunikáciu s PO pri definovaní stories Vyhradiť viac času na plánovanie Zlepšiť spôsob spúšťania demo ukážky Zrýchliť ukončenie šprintu (stop diskusie po 5 minútach) Ján Vnenčák Sprístupniť logger modul Stop diskusie po 5 minútach 4.3. Šprint č. 3 ( ) V treťom šprinte sme pridali možnosť sťahovania dát vo formáte.csv, zo stĺpcov s rýchlostnými metrikami sme extrahovali črty, ktoré budú ďalej použité na klasifikáciu. Vytvorili sme prvotný klasifikátor, ktorý bude binárne predikovať, či sa jedná o autentifikovaného používateľa. Pre ďalšiu fázu projektu sme vykonali analýzu prístupných senzorov v mobilných zariadeniach. Typ Popis úlohy Story points Story Extrahovanie čŕt zo segmentov 21 Realizovatelia Matej Končál, Tomáš Jendrejčák, Matúš Kalafut 8

9 Story Story Story Nastavenie dát na jednotný formát Výpočet rýchlostných stĺpcov zo surových dát Generovanie dátovej sady zo získaných dát Story Autentifikácia používateľa 13 3 Michal Manak 3 (21-18) Michal Manak 8 Matej Končál, Matúš Kalafut, Kamil Janeček Matej Končál, Tomáš Jendrejčák, Matúš Kalafut Managment story Vytvorenie dokumentácie 8 Michaela Balážová Task Task Zmena implementácie demo ukážky Prehľad loggovacích možností pre mobilné zariadenia Retrospektíva šprintu č. 3 Čo sme urobili dobre? Implementovaná základná klasifikácia Dobrý code review Čo sme mohli urobiť lepšie? Akcie Pripraviť sa na retrospektívu Stavy v JIRE meniť pred začiatkom akcií Zlepšit odozvu pri komunikácii ohľadom dokumentácie Stories by mohli mať svojích zodpovedných vedúcich Pozrieť videá o retrospektíve Určiť stories vedúcich pri plánovaní Naškálovať vhodne story pointy 5. Globálna retrospektíva - Ján Vnenčák - Ján Vnenčák Do 1. kontrolného bodu sa nám podarilo úspešne dokončiť 3 šprinty. V tomto bode náš projekt poskytuje logger pre udalosti z počítačovej myši, ktoré ukladá do databázy na server, predspracovanie dát a vykonáva jednoduchú klasifikáciu. 9

10 6. Motivačný dokument Predstavenie tímu: Náš tím sa skladá zo siedmich členov, kde každý člen z tímu má skúsenosti v oblasti strojového učenia. Väčšina z nás si vybrala túto oblasť aj pre vypracovanie bakalárskeho projektu a zúčastňovala sa výskumného seminára PeWe, ktorý poskytoval širšie informácie v oblasti a hlavne diskusiu s ostatnými členmi v rámci problémov, ktoré vznikali pri tvorbe bakalárskej práce. Taktiež každý z nás absolvoval bakalársky predmet Inteligentná analýza údajov, ktorý nám poskytol prehľad v metódach dolovania dát a taktiež spracovania surových dát. Zaujíma nás aj oblasť neurónových sietí, v ktorej si niektorí z členov v inžinierskom štúdiu zvolili predmet Neurónové siete. Väčšina tímu je už zohratá (od strednej školy) a doteraz spolu tvorí tím na väčšine školských aj mimoškolských projektov. Ako tím sme sa spoznali v prvom ročníku bakalárskeho štúdia a odvtedy sme súčasťou súdržnej skupiny, ktorá vzájomne spolupracovala a pomáhala si v rámci školských povinností. Príkladom spolupráce je tvorba projektov v rámci predmetov na bakalárskom štúdiu (ako napr. ICP, aj IAU). Okrem školských projektov sme spolupracovali aj na rôznych projektoch v rámci voľného času. Tieto projekty siahali od jednoduchých webových stránok až po rozsiahlejšie systémy. Takto sme získali skúsenosti v oblasti vývoja všetkých častí (mobilná aplikácia, webová aplikácia, serverová časť) takéhoto systému. Počas štúdia sme získali skúsenosti so spracovaním väčšieho množstva dát, ale taktiež aj s návrhom metód strojového učenia alebo aj vizualizácie rôznych typov dát. Aj keď máme spoločné záujmy, každý z nás sa venuje rôznej podoblasti. Je pre nás preto jednoduché rozdeliť si prácu na projekte. Časť tímu preferuje prácu na klientskej a iní členovia na aplikačnej časti. Niektorí členovia uprednostňujú návrh vzhľadu stránky, plánujú úlohy alebo tvoria dokumentáciu. Zaujala nás aj oblasť virtuálnej reality, kde sa niektoré témy umiestnili na vyšších priečkach v našom rebríčku preferovaných tém. Nemáme v tejto oblasti doteraz žiadne skúsenosti, avšak radi sa učíme novým veciam a technológiám. Motivácia pre každú z tém: 1. Podpora výskumu behaviorálnej biometrie [behametrics-learn] (č. 05) Táto téma nás z ponúkaných zaujala najviac, nakoľko sme našli prienik medzi ňou a našimi doterajšími znalosťami - hlavne skúsenosti v oblasti strojového učenia. Väčšina z nás už 10

11 pracovala v rámci bakalárskej práce s programovacím jazykom Python a taktiež s knižnicami na analýzu dát (NumPy, scikit-learn, pandas). Oblasť biometrie je pre nás nová a teda doteraz sme s ňou nepracovali. Považujeme ju však za veľmi zaujímavú, a má podľa nás aj praktické využitie do budúcnosti, čo vnímame ako najväčšiu výhodu. Zaujala nás tiež myšlienka autentifikácie nielen pri začiatku používania zariadenia, ale aj na pozadí počas práce so zariadením. Autentifikácia na pozadí môže priniesť zníženie pravdepodobnosti zneužitia tohto zariadenia cudzou osobou. Existujúce riešenie by sme chceli vylepšiť, prípadne rozšíriť na iné platformy. Ako sme spomínali v charakteristike tímu, sme schopní vytvoriť aplikáciu pre zber biometrických dát s využitím senzorov daného zariadenia. Získané dáta vieme následne vizualizovať prostredníctvom webového rozhrania. Vieme tiež vytvoriť črty pre ďalšie spracovanie modelmi strojového učenia. A prostredníctvom týchto modelov sme schopní odhaliť vzory správania sa používateľa a pomocou týchto údajov následne používateľa identifikovať. 2. Monitoring antisociálneho správania [MonAnt] (č. 15) Tématika falošných správ v dnešnej dobe hýbe celou spoločnosťou. Téma nás zaujala jej potencionálnym výstupom, či už technickým, ale najmä možným prínosom pre spoločnosť. Ako už bolo spomenuté väčšina členov tímu má už skúsenosti so spracovaním dát a spracovaním textu. Taktiež sa vo voľnom čase venujeme aj inému vývoju. Máme skúsenosti so spájaním rôznych dátovych zdrojov a taktiež aj s hromadným získavaním dát z webových zdrojov. Z tohto dôvodu si myslíme, že by sme naplnili vedomosti a schopnosti, ktoré sa požadujú od tohto zadania na tímový projekt. Napriek rôznorodosti nášho tímu nemáme skúsenosti vo všetkých podoblastiach projektu, ktoré nás môžu zasiahnuť. To berieme ako skutočnú výzvu a radi by sme sa s ňou čo najlepšie popasovali. Motiváciou pre nás je pracovať na projekte väčších rozmerov v oblasti strojového učenia, ktorá nás všetkých zaujíma a týmto spôsobom by sme chceli prehĺbiť naše doterajšie znalosti a skúsenosti. Príloha A - Zoradenie tém podľa priority Poradie Názov témy 1. Podpora výskumu behaviorálnej biometrie [behametrics-learn] 2. Monitoring antisociálneho správania [MonAnt] 3. Vyhľadávanie pomocou obrázkov [ImageSearch] 4. Generátor 3D priestoru [3DSpaceGen] 5. Identifikácia entít spracovanie textu [SK-CZ-TEXT] 11

12 6. Vnímanie neviditeľného [Holographic Eyes] 7. Analýza správania sa vozidiel v meste [SmartMobility] 8. Prostredie pre inteligentnú analýzu textov [TxtEnv] 9. Inteligentný importér verejných dát [Importer] 10. Škola hrou vo virtuálnej realite [VREducation] 11. In-memory databáza s využitím GPU [In-memory-DB] 12. WiFi Funtoro [WFuntoro] 13. Databanka otázok a úloh [FIIT - DU] 14. IoT systém monitorovania osôb [Breyslet] 15. Automatické testovanie v prostredí Internetu vecí [IoTesting] 16. 3D simulovaný robotický futbal [3D futbal] 17. Prostredie na vizualizáciu mikrogridu [GridBox] 18. Monitorovanie a vyhodnocovanie fyziologických procesov človeka [BioMonitor] 19. 3D UML, improved version [3D-UML] 20. Vizualizácia softvéru vo virtuálnej a rozšírenej realite (Remake) [VizReal] 7. Metodiky 7.1. Metodika pre prehliadku zdrojového kódu (Tomáš Jendrejčák, Matej Končál) V tíme nemáme dopredu určených reviewerov. Dokončené tasky čakajúce na review sa nachádzajú v stave READY FOR REVIEW. Člen tímu, ktorý svoj task už dokončil, alebo na ňom práve nepracuje, si môže tento task vziať na review presunutím tasku do stavu IN REVIEW. V prípade, že reviewer počas code review neobjavil žiadne nedostatky, presunie task do stavu DONE. V opačnom prípade reviewer pridá komentár k chybnej časti kódu. Vývojár buď zapracuje požadované zmeny alebo reaguje na komentár. Tento proces sa iteruje, kým reviewer neakceptuje kód Prostredie Code review sa vykonáva v prostredí GitLabu. V GitLabe si reviewer zobrazí otvorené merge requesty a zvolí merge request pre reviewovanú story a zobrazí zmeny. V prípade potreby pridania 12

13 komentára pridáva komentár priamo k príslušnému riadku zdrojového kódu. Ak boli všetky pripomienky ku kódu zapracované, reviewer schváli merge request Metodika pre písanie zdrojového kódu (Kamil Janeček, Ján Vnenčák) Pri vyvíjaní nášho produktu využívame niekoľko programovacích jazykov. Konkrétne sa jedná o: Python Javascript Všeobecné konvencie Zdrojový kód píšeme v angličtine Komentáre píšeme v angličtine Kód musí byť pokrytý jednotkovými testami. Za tieto testy zodpovedá dodávateľ funkcionality (osoba, ktorá otvorila merge request) Konvencie pre Python Všetok kód je formátovaný podľa PEP 8 o tento stav je vynútený pomocou nástroja flake8, ktorý sa spúšťa pri každom commite do git repozitára. Ak táto kontrola neskonči úspešne nebude možné tento kód prijať. Dodržiavame best-practices pre použité knižnice a frameworky (Flask, pytest) V prípade potreby rozdelenia riadku s binárnym operátorom (napr. +, -) sa tento riadok delí pred operátorom (operátor sa presúva na ďalší riadok) Konvencie pre Javascript Dodržiavame konvencie písania kódu podľa Google štandardu o na kontrolu konvencií používame nástroj eslint o pri commite do git repozitára sa v rámci pipeline je spustená automatická kontrola dohodnutých konvencií 7.3. Metodika pre verziovanie zdrojového kódu (Michal Maňak, Matúš Kalafut) Na verziovanie používame nástroj git. Používame 4 úrovne vetiev - master, develop, story, subtask. 13

14 Každý repozitár obsahuje 2 hlavné vetvy - master a develop. Master vetva predstavuje produkt v stave po šprinte. Vetva develop slúži na pridávanie funkcionality z user stories počas šprintu. Po uzavretí šprintu sa merguje do master vetvy. Každá story sa vyvíja vo svojej vetve, odvodenej z develop vetvy. Sub-tasky sa vyvíjajú v osobitnej vetve odvodenej od danej story vetvy. Story a sub-task branche pomenuvávame podľa labelu story alebo sub-tasku z Jiry a jeho názvu (napr. BEL-21 - názov). Commit správy musia obsahovať label sub-tasku na začiatku (príklad - BEL-44 - basic mouse events logging works). Po dokončení celého sub-tasku sa otvorí merge request do story branche. Vtedy sa vykonáva code review na merge requeste. Následne sa sub-task branch squashne do jedného commitu a mergne do story vetvy. Ak je celá funkcionalita v rámci story vetvy hotová, merguje sa do develop vetvy. 14

15 Obr. č. 1 : Grafické znázornenie vytvoreného flow-u 15

16 7.4. Metodika pre nástroj JIRA (Matúš Kalafut) V našom projekte používame nástroj JIRA pre agilné zaznamenávanie úloh vykonávaných na projekte. Tento nástroj priamo umožňuje vytváranie backlogu, user stories a šprintov Úlohy Úlohy sú usporiadané v 3-úrovňovej hierarchií: epic story story sub-task Epic story - najväčši celok, ktorý zastrešuje stories tématicky patriace pod danú epic story. User story - jedna z vlastností, ktorú má výsledný produkt obsahovať. Definuje product owner. Managment story - slúži pre interné záležitosti v tíme a nesúvisí priamo s produktom. Sub-task - konkrétna úloha, ktorú je potrebné splniť pre naplnenie user alebo managment story Roly Riešiteľ tvorí riešenie úlohy, ktorú má pridelenú. Recenzent kontroluje správnosť riešenia úlohy, ktorú recenzuje. Watcher osoba, ktorá je akýmkoľvek spôsobom zapojená do riešenia úlohy alebo sa úloha týka tej časti vývoja, na ktorej spolupracujú Vytváranie úloh Práca, ktorá je vykonávaná na projekte, musí mať vytvorený príslušný sub-task. Takto dosiahneme prehľad o celkovej práci a práci jednotlivých členov tímu. Pri vytváraní sub-tasku je potrebné do popisu zadať popis úlohy, zdroje, ktoré by mohli pomôcť pri riešení a postrehy jednotlivých členov tímu. Ďalej sa pre story zadefinujú akceptačné kritéria, 16

17 aby riešiteľ aj následne recenzent presne vedeli, čo má daná úloha spĺňať. Sub-tasku sa nastaví priorita, pridajú sa prílohy, napríklad poznámky k sub-tasku zo stretnutia, na ktorom sa daný subtask rozoberal. Sub-tasku sa priradí šprint, do ktorého patrí a prípadne sa priradí závislosť na iný sub-task. K úlohám je potrebné priraďovať watchers, aby boli kompetentné osoby upozorňované na všetku aktivitu týkajúcu sa sub-tasku Stavy Story aj sub-task prechádza tými istými stavmi, avšak pre každý typ to znamená niečo málo odlišné. Story má vždy jeden zo 6 možných stavov: TO DO - úloha, ktorú je potrebné vyriešiť a nezačala práca na nej. V tejto fáze sa vytvárajú sub-tasky, ktoré predstavujú menšiu granularitu práce na story. IN PROGRESS - na úlohe sa aktuálne pracuje, sú vytvorené sub-tasky, ktoré je potrebné realizovať v rámci danej story. Sub-tasky môžu byť priradené rôznym osobám. READY FOR REVIEW - bola dokončená práca na tejto úlohe, dokončili sa všetky subtasky, ktoré boli vytvorené k story. Úloha čaká na kontrolu. IN REVIEW - úloha prebieha kontrolou správnosti, väčšinou formou demo ukážky, ktoré sa prezentuje Product Ownerovi (PO). DONE - úloha bola skontrolovaná PO a spĺňa jeho kritériá. BLOCKED - do tohto stavu dáme úlohu, na ktorej nevieme pracovať, pretože nie je dokončená iná úloha, od ktorej je závislá. CANCELED - daná úloha sa nebude realizovať, zamietne sa jej realizovanie Sub-task má vždy jeden zo 6 možných stavov: TO DO - úloha, ktorú je potrebné vyriešiť a nikto na nej práve nepracuje. IN PROGRESS - úlohu si prebrala konkrétna osoba a pracuje na nej. READY FOR REVIEW - osoba, zodpovedná za úlohu dokončila svoju prácu. Úloha čaká na kontrolu. IN REVIEW - úloha prebieha kontrolou správnosti a či spĺňa definition of done. DONE - úloha bola skontrolovaná a spĺňa definition of done. BLOCKED - do tohto stavu dáme úlohu, na ktorej nevieme pracovať, pretože nie je dokončená iná úloha, od ktorej je závislá. CANCELED - daná úloha sa nebude realizovať, zamietne sa jej realizovanie Na obrázku č. 1 je znázornený proces, ako sa môžu jednotlivé stavy medzi sebou meniť. Do stavov BLOCKED a CANCELED môžu prejsť všetky úlohy zo všetkých stavov. 17

18 Obr. č. 2 : Grafické znázornenie stavov a prechodov medzi nimi Akceptovanie user story Product ownerom 1. Tím vytvorí demo s požadovanou funkcionalitou, ktorá bola špecifikovaná v story. 2. Product owner (PO) presunie story zo stavu READY FOR REVIEW na stav IN REVIEW pred odskúšaním demo ukážky. 3. PO odskúša demo. 4. Rozhodnutie PO: 1. Ak je demo v poriadku a PO nemá žiadne výhrady, presunie ho do stavu DONE a táto story sa považuje za vyriešenú. 2. Ak časť funkcionality nie je v poriadku: 1. PO presunie aktuálnu story do stavu DONE 2. Tím odhadne chýbajúcu funkcionalitu story pointami a odpočíta nové story points od pôvodného odhadu. 3. Chýbajúcu časť pridá s novým odhadom do ďalšieho šprintu. 3. Ak demo nebolo vôbec vyhovujúce, PO vráti tímu story na prerobenie (z IN REVIEW sa potrebujeme chceme dostať do stavu TO DO): 1. Zo stavu IN REVIEW sa pomocou "Stop QA" dostaneme naspäť do stavu READY FOR REVIEW. 2. Zo stavu READY FOR REVIEW sa pomocou "Not Completed" dostaneme do stavu IN PROGRESS. 3. Zo stavu IN PROGRESS sa pomocou "Stop Work" dostaneme do stavu TO DO Metodika ku dokumentácií 18

19 (Michaela Balážová) Dokumentáciu priebežne tvoríme v nástroji Confluence, kde sú zoskupené všetky vytvorené dokumenty k projektu. Do tohto priestoru má prístup celý tím, spolu s vedúcim projektu. Dokumentáciu tvorí najmä určený dokumentarista v tíme, avšak vždy na viacerých častiach spolupracujú viacerí členovia tímu. Pri každom priebežnom kontrolnom bode tieto dokumenty zoskupujeme, upravujeme ich do požadovanej formy a zverejňujeme ich na našom tímovom webe na adrese - vo formáte pdf Formálna úprava Štruktúra dokumentu Každý dokument obsahuje: úvodnú stranu obsah dokumentu úvod - obsahuje bližší popis dokumentu samotný text Úvodná strana Úvodná strana obsahuje: názov univerzity, fakulty a jej adresu názov dokumentu názov tímu vedúceho projektu zoznam členov tímu (mená zoradené podľa abecedy) dátum poslednej úpravy Obrázky a tabuľky Každý obrázok alebo tabuľka majú popis vo formáte - napr. "Obr. č. 1 - popis obrázka" alebo "Tabuľka č. 1 - popis tabuľky". Tento text je zvýraznený kurzívou. Číslovanie strán Každá strana v dokumente je číslovaná okrem úvodnej strany Jazyk Dokumentácia je napísaná v slovenskom jazyku. Niektoré dokumenty budú v anglickom jazyku, aby boli prístupné širokej verejnosti. 19

20 Tvorba retrospektívy šprintu Na konci každého šprintu tvoríme dokument, obsahujúci retrospektívu šprintu. názov šprintu - tvar : Retrospektíva (x. šprint) dátum trvania šprintu účastníci čo sme urobili dobre? čo sme mohli urobiť lepšie? akcie pre ďalší šprint Dokumenty big picture inštalačná príručka používateľská príručka dokumentácia k riadeniu o metodiky dokumentácia k inžinierskemu dielu (aj v anglickom jazyku) o technická dokumentácia 7.6. Metodika Definition of ready (Michal Maňak, Tomáš Jendrejčák) akceptačné kritéria musia byť definované a overiteľné story musí mať dostatočný opis o tím si musí byť istý svojou schopnosťou splniť story poznať oblasť a problém poznať technológie, ktoré budú použité, prípadne mať priestor pre ich naštudovanie tím musí mať dostatočné časové kapacity pre splnenie úlohy o mala by obsahovať aspoň jeden scenár využitia funkcionality story musí byť odhadnutá story pointami story musí mať veľkosť primeranú na to, aby sa dala vykonať v jednom šprinte 7.7. Metodika Definition of done (Michal Maňak, Tomáš Jendrejčák) user story všetky sub-tasky danej story musia byt dokončené akceptačné kritéria musia byť splnené story schvalená product ownerom 20

21 o po predvedení demo ukážky a prejdení scenárov managment story všetky sub-tasky musia byt dokončené dokončené všetky úlohy, ktoré boli definované v popise musí sa nachádzať v stave DONE epic story všetky user stories, ktoré boli zahrnuté v epic story: o sú dokončené o schválené Product ownerom 7.8. Metodika plánovania (Michaela Balážová, Michal Maňak) Na našom projekte fungujeme pomocou Scrumu, ktorý máme upravený pre fungovanie na predmete Tímový projekt. Realizujeme 2-týždňové šprinty. Stretnutia s product ownerom realizujeme každý utorok počas 3 hodín. Na každom stretnutí robíme "daily stand-up" (avšak na týždennej báze), kde diskutujeme ako každý člen tímu od posledného stretnutia pokročil a prípadne aké má problémy. Na tomto stretnutí otvárame aj uzatvárame šprint. Čo sa týka plánovania šprintu, na začiatku šprintu si vyberieme stories, ktoré budeme realizovať v danom šprinte. Každá story, ktorá sa zahrnie do šprintu musí mať zodpovednú osobu, ktorá je zodpovedná za túto story (vytváranie sub-taskov, ich prideľovanie...). V tomto kroku je potrebné vedieť aj ktoré stories sú od seba závislé, aby sme vedeli rozumne rozdeľovať prácu. Jednotlivé story pri začínaní šprintu odhadujeme pomocou story points. Zvyčajne do jedného šprintu zahrnieme úlohy, ktoré majú v súčte story points. Do šprintu sa môže dostať aj dostatočne veľká úloha, v našom ponímaní je to napr. 21 story points. Pri uzatváraní šprintu realizujeme retrospektívu šprintu, kde prebieha diskusia o tom, čo sme spravili dobre alebo zle v aktuálnom šprinte a plánujeme ďalšie akcie. Backlog priebežne upravujeme (zvyčajne na stretnutí v strede šprintu alebo pred začatím ďalšieho šprintu) - zoraďujeme ho podľa priority, pridávame stories a bližšie špecifikujeme nejasnosti s PO. Tímové 3-hodinové stretnutia realizujeme každý pondelok, kde musí byť prítomný každý člen tímu. Toto stretnutie využívame najmä na riešenie spoločných problémov a diskusiu v tíme. Každý člen tímu pracuje na pridelených úlohách samostatne predovšetkým mimo tohto časového priestoru. 21

22 8. Export evidencie úloh Export evidencie úloh z JIRY je poskytnutý na našom webovom sídle. 9. Webové sídlo tímu 22