Riadenie projektu Behametrics

Transcription

1 Slovenská technická univerzita Fakulta informatiky a informačných technológií Ilkovičova 2, Bratislava Projektová dokumentácia Riadenie projektu Behametrics Tím č. 7 - ByteCrowd skupinac07@gmail.com Akademický rok: 2017/2018 Predmet: Tímový projekt Vedúci tímu: Ing. Kamil Burda Členovia tímu: Peter Bakonyi, Jakub Kazimír, Tomáš Lach, Gergely Abelovský, Patrik Beka, Matúš Čičman, Peter Kaňuch, Michaela Nguyenová

2 Obsah Úvod 3 Roly členov tímu 4 Manažovanie vývoja metódou Scrum (Scrum master) 4 Manažovanie projektovej dokumentácie 4 Manažovanie verziovania 4 Manažovanie testovania 4 Administrátor webu 4 Správca servera 4 Podiel práce 5 Podiel práce na vývoji aplikácie za zimný semester 5 Podiel práce na vývoji za letný semester 6 Podiel práce na vypracovaní dokumentácie 7 Aplikácie manažmentov 8 Používané metodiky 9 Metodika pre správu verzií 9 Metodika pre evidenciu úloh 10 Metodika pre komunikáciu 12 Metodika pre integráciu 12 Metodika pre písanie kódu 13 Metodika pre testovanie 13 Metodika pre prehliadku kódu 13 Metodika pre ukladanie súborov 13 Metodika pre plánovanie úloh 14 Sumarizácie šprintov 15 Globálna retrospektíva pre zimný semester 17 Globálna retrospektíva pre letný semester 17 Retrospektívy 18 Exporty taskov 32 2

3 Úvod V projektovej dokumentácii k riadeniu projektu popisujeme fungovanie nášho tímu a spoluprácu členov vrámci tímu. Opísané sú aj manažérske činnosti a úlohy, ktoré bolo potrebné zadeliť. V dokumente sa taktiež venujeme metodikám a stratégiám, ktoré sme počas nášho fungovania praktizovali za účelom dosiahnutia čo najlepších výsledkov. Nakoľko sme sa pri vývoji riadili agilnou metódou vývoja Scrum, dokument zahŕňa aj podrobnosti našich šprintov a prislúchajúce retrospektívy. 3

4 Roly členov tímu V tejto kapitole sú popísané manažérske roly definované v rámci nášho projektu. Aktuálne manažérske pozície sú pridelené členom tímu na webovej stránke tímu. Manažovanie vývoja metódou Scrum (Scrum master) Scrum master zabezpečuje hladký priebeh pravidelných tímových stretnutí. Organizuje jednotlivé stretnutia a ich priebeh, zahajuje diskusie, plánovanie i retrospektívy. Má na zodpovednosť podporný systém pre plánovanie úloh (Asanu). Rieši problémy, ktoré sa vyskytnú počas šprintu, či už týkajúce sa manažmentu úloh, alebo komunikácie v rámci tímu. Stará sa o spokojnosť členov tímu a zabezpečuje dobrú komunikáciu aj mimo oficiálnych tímových stretnutí. Manažovanie projektovej dokumentácie Manažér dokumentácie sa stará o to, aby boli správne zdokumentované priebehy tímových stretnutí, jednotlivé retrospektívy a ostatné dokumenty, ktoré sú výsledkom práce tímu. Stará sa o gramatickú aj pravopisnú korektnosť a zabezpečuje prezentovateľnosť jednotlivých dokumentov po formálnej stránke. Manažovanie verziovania Zodpovedný člen tímu sa stará o obsah a štruktúru Git repozitára, spravuje podporný systém GitLab, prepája moduly implementované členmi tímu, kontroluje dodržiavanie dohodnutých konvencií pre pomenovanie vetiev či commit-ov. Manažovanie testovania Jednotlivé moduly produktu je potrebné otestovať na úrovni unit-ov (jednotiek) i komponentov. Unit (jednotka) za chytáva menšiu časť funkcionality (obvykle je to napr. jedna funkcia), komponent reprezentuje väčšiu časť funkcionality (napr. celá trieda). O to sa väčšinou stará člen tímu, ktorý svoju časť modulu napísal. To znamená, že napíše testy pre svoju časť kódu. Administrátor webu Administrátor webu sa stará o aktuálnosť webovej stránky tímu a kvalitu jej obsahu. Taktiež má na starosti vizuálnu stránku webu. Správca servera Zodpovedná osoba sa môže postarať o spracovanie požiadaviek na strane servera, ukladanie súborov na serveri či inštalovanie knižníc potrebných pre strojové učenie. Taktiež inštalácie rôznych nástrojov na serveri pre potreby tímu a vývoja. 4

5 Podiel práce Podiel práce na vývoji aplikácie za zimný semester V tabuľke sú popísané časti týkajúce sa vývoja našej aplikácie na zber dát zo senzorov, ich logovanie, posielanie na server a osoby zodpovedné za ich naimplementovanie a otestovanie. Členovia, ktorí sa nepodieľali na hlavnom vývoji aplikácie, sa buď zapájali v rámci prehliadky kódu alebo sa podieľali na analýze, návrhu či technickej dokumentácii. Stories Logovanie dát zo senzorov, spracovanie požiadavky na serveri Zapisovanie dát do súboru, vytvorenie základných grafov v Kibane Odosielanie na server, Nastavenie konfigurácie Príprava aplikácie na prepojenie s externou aplikáciou, Prihlásenie používateľa Zodpovedný člen tímu Matúš Čičman Tomáš Lach Jakub Kazimír Peter Kaňuch 5

6 Podiel práce na vývoji za letný semester V nasledujúcej tabuľke sú stručne napísané hlavné oblasti, ktorým sa venovali jednotliví členovia tímu. Práca Strojové učenie Strojové učenie optimalizácia, testovanie, skúšanie modelov Strojové učenie vytvorenie modelov, experimentovanie Všetko ohľadom loggera, experimenty so strojovým učením Strojové učenie vytvorenie modelov, experimentovanie Strojové učenie neurónová sieť Serverová časť, Socket logger (prepojenie so serverom), Experimentálna banková aplikácia Zodpovedný člen tímu Gergely Abelovský Peter Bakonyi Patrik Beka Matúš Čičman Tomáš Lach Jakub Kazimír Peter Kaňuch Michaela Nguyenová 6

7 Podiel práce na vypracovaní dokumentácie Podiel práce na jednotlivých častiach dokumentácie je znázornený v nasledujúcej tabuľke. Zodpovedný člen tímu Peter Bakonyi Jakub Kazimír Tomáš Lach Gergely Abelovský Patrik Beka Matúš Čičman Peter Kaňuch Michaela Nguyenová Časť dokumentácie Ciele pre zimný semester, analýzy k strojovému učeniu Používateľská príručka Metodika pre testovanie Analýza API OS Android, návrh Android aplikácie, testovacie scenáre Metodika pre správu verzií, metodika pre testovanie, globálna retrospektíva pre zimný semester Metodika pre písanie kódu a prehliadku kódu, používateľská príručka pre integrovanie Behametrics Aplikácie manažmentov, zápisnice zo stretnutí, exporty zo šprintov a produktové backlogy, metodika pre plánovanie úloh, architektúra vizualizácie dát, používateľská príručka, analýza pre produkčnú verziu Úvod, roly členov tímu, metodika pre evidenciu úloh, komunikáciu a integráciu, ukladanie súborov, sumarizácie šprintov, retrospektívy 7

8 Aplikácie manažmentov Dokumentácia Pre odstránenie nadbytočnej byrokracie, sme zrušili písanie zápisníc zo stretnutí. Uskutočnené zmeny v riadení zapíšeme v dokumentácii o riadení, prípadne upravíme metodiky riadenia na základe retrospektívy z daného šprintu. Na úlohy súvisiace s manažmentom používame scrum-desk. Pre dostupnosť a prácu na jednotlivých dokumentoch je vytvorená Metodika pre ukladanie súborov. Okrem toho sa po každom šprinte zhodnotí posledný šprint v rámci retrospektívy. Retrospektíva prebieha po ukážke produktu a vykonanej práce produktovému vlastníkovi (review) pred ukončením šprintu. Počas nej členovia tímu zhodnotia pozitíva a negatíva posledného šprintu. Spolu s grafom progresu za daný šprint sú tieto poznatky zavesené v jednom dokumente na webovej stránke tímu v prehľadnej tabuľke plusov a mínusov a v niekoľkých výstižných odrážkach. Komunikácia Pre oficiálnu komunikáciu s verejnosťou používame vytvorený tímový mail skupinac07@gmail.com, na ktorý dohliada zodpovedný člen tímu. Komunikácia v tíme je popísaná v kapitole Metodika pre komunikáciu. Plánovanie Pre správne plánovanie a evidenciu úloh boli vytvorené Metodika pre plánovanie úloh a Metodika pre evidenciu úloh. Z nástroja pre evidenciu úloh pri každom šprinte zodpovedný člen tímu generuje exporty úloh, a to na začiatku každého šprintu, v polovici a na konci šprintu z produktového backlog-u. Tieto exporty sú zverejnené na webovej stránke tímu do niekoľkých hodín po stretnutí. Správa verzií a testovanie Pre správu verzií používame GitLab - webový manažér pre správu Git repozitára. Správe verzií sa venuje kapitola Metodika pre správu verzií. Pre testovanie bola napísaná kapitola Metodika pre testovanie. Kvalita písania zdrojového kódu Každý vývojár by sa mal snažiť písať kvalitný a prehľadný kód. Pre jednotnú syntax a štýl písania kódu bola vytvorená Metodika pre písanie kódu, ktorou by sa mal riadiť každý člen tímu. Prehľadnosť kódu následne skontroluje aj iný člen tímu počas prehliadky kódu. Prehliadka kódu je bližšie popísaná v kapitole Metodika pre prehliadku kódu. Akceptovanie dokončených úloh V rámci metodiky plánovania úloh máme úlohy rozdelené na epics, stories a tasky (viď Metodika pre plánovanie úloh). Pre odľahčenie produktového vlastníka, dokončené tasky a manažmentové tasky z daného šprintu akceptuje Scrum master. Stories, ktoré majú hodnotu pre produktového vlastníka, akceptuje on sám vždy na konci šprintu na základe dohodnutých akceptačných kritérií. 8

9 Používané metodiky Metodika pre správu verzií Git repozitár pozostáva z 3 typov vetiev: master vetva - produkčná verzia, na 100% funkčná develop vetva - funkčná verzia najnovšie pridávanej funkcionality, práve testovaná, neskôr bude spojená s master vetvou ostatné vetvy - obsahujúce rôznu novú funkcionalitu, na ktorej sa pracuje vrámci šprintu (šprintov), bugfixy,... Workflow 1. Zosynchronizovanie všetkých vetví s repozitárom pomocou príkazu git fetch --prune 2. Vytvorenie novej vetvy z develop vetvy. Postupne zmeny vrámci vetvy. 3. Keď je úloha hotová, vytvorí sa merge request do develop vetvy. 4. V Asane pridám k úlohe link na merge request a označím niekoho na prehliadku kódu. 5. Po prehliadke kódu zapracovaní pripomienok a následnom schválení zodpovedný člen tímu vykoná spojenie vetvy s develop vetvou. Pomenovanie vetiev Pre riešenie novej funkcionality programu je potrebné vytvoriť vetvu s konvenciou pomenovania feature/opis_funkcionality alebo fix/co_fixujem. Názov vetvy tak musí dodržiavať tvar regulárneho výrazu feature\/* fix\/*. Commit správy Správy prisluchajúce commit-om sú písané v anglickom jazyku. Slovesá sú v spráach uvádzané v tvare imperatívu a musia začínať jedným zo slov Add, Fix, Change, Remove, Refactor alebo Update, aby bola uľahčená orientácia medzi príslušnými commit-mi v kóde. Na konci správy je uvedené ID tasku z Asany, aby bola Asana automaticky schopná prepojiť commit s úlohou, ktorej sa týka. V GitLabe tak máme v Push Rules nastavené, aby tieto správy dodržiavali regulárny výraz #^(Add. Fix. Change. Remove. Refactor. Update.)(.*)(#[0-9]+$). Obr. 1 Ukážka commit správy Obr. 2 Ukážka prepojenia úlohy v Asane s GitLab-om 9

10 Metodika pre evidenciu úloh Na sledovanie a manažovanie práce v tíme využívame aplikáciu Asana. V rámci nášho projektu Behametrics máme vytvorený produktový backlog, kde definujeme epics a stories podľa dohody s produktovým vlastníkom. Okrem toho je v ňom zavedená i sekcia Čakajúce na schválenie pre stories či tasky (úlohy), ktoré neboli schválené počas stretnutí, no niekomu napadli priebežne počas šprintu a chcel ich pridať do backlogu, aby sa na to nezabudlo. Obr. 3 Ukážka boardu pre šprint z Asany Jednotlivé šprinty sú reprezentované tabuľami so siedmimi stĺpcami: Stories, Todo, In progress, Code review, Acceptance testing, Stories done a Cancelled. Pre prehľadnosť máme v stĺpci Stories natiahnuté stories z backlogu, ktorým sa v danom šprinte venujeme. Každá story má zavedený aj vlastný farebný tag, ktorým sú potom označené úlohy, ktoré pod ňu patria. Zvyšných 5 stĺpcov predstavuje stavy, v ktorých sa jednotlivé úlohy a stories nachádzajú. Keď sa v rámci plánovania naplánuje splnenie konkrétnej úlohy, úloha sa presunie do stĺpca Todo a jeden z členov tímu zaviaže k jej splneniu tým, že sa v Asane k úlohe priradí ako Assignee. Úloha sa ďalej dostane do stavu In progress, keď na nej člen tímu začne pracovať. Ak je kód napísaný v rámci úlohy pripravený na prehliadku kódu, zodpovedný člen ju presunie do stĺpca Code review, kde potom úloha čaká na prehodnotenie iným členom tímu. Ak boli pri prehliadke kódu objavené nedostatky, úloha sa presunie naspäť do stĺpca In progress. Ak bol kód schválený, úloha sa v Asane označí ako Completed, čo je znázornené zelenou fajkou pri názve úlohy. Ak sú všetky úlohy v rámci story hotové, story sa presunie do stĺpca Acceptance testing, kde čaká na prehodnotenie produktovým vlastníkom. Keď produktový vlastník zhodnotí, že story bola stopercentne splnená, presunie sa do stĺpca Stories done. 10

11 Uloha je jednoznacne definovana [uloha bola vybrana do sprintu] Todo [clen zodpovedny za ulohu na nej zacal pracovat] In progress [iny clen timu vykonal code review, vo vypracovani sa nasli nedostatky] [zodpovedny clen timu ulohu dokoncil a potrebuje ju skontrolovat] Code rev iew [uloha bola vypracovana dobre, v Asane sa oznaci ako Completed] [clenovia timu sa s produktovym vlastnikom z roznych dovodov rozhodli, ze uloha moze byt zrusena] Completed Cancelled Obr. 4 Stavy, v ktorých sa jednotlivé úlohy môžu nachádzať Stĺpec Cancelled slúži na výnimočné situácie, kedy sa počas šprintu členovia tímu spolu s produktovým vlastníkom dohodnú, že je úlohu možné zrušiť a v danom šprinte sa už na nej nebude pracovať. Dohodli sme sa, že činnosti týkajúce sa manažmentu, akými sú písanie zápisníc zo stretnutí či retrospektív nebudú v Asane trackované ako samostatné tasky, nakoľko sú vykonávané na pravidelnej báze a na starosť ich majú vždy rovnakí členovia tímu. Technická dokumentácia pre novonaimplementované veci však bude môcť byť evidovaná ako osobitná úloha, nakoľko môže zahŕňať napríklad vytvorenie diagramov. To isté sa týka písania časovo náročnejších častí dokumentácií k riadeniu a inžinierskemu dielu. Definition of ready Ak bola úloha estimovaná (boli jej priradené story pointy odhlasované tímom), bol k nej napísaný dobre definovaný scenár a boli pre ňu vypísané aj akceptačné kritériá, úlohu je možné označiť za pripravenú a pridať ju do nasledujúceho šprintu. Definition of done Úlohu vo všeobecnosti možno označiť za dokončenú, ak bola schválená produktovým vlastníkom a označená za hotovú. V prípade, že úloha zahŕňala aj implementáciu a napísanie kódu, tento kód musí najprv prejsť kontrolou kódu, musia byť k nemu napísané testy a samotná funkcionalita musí prejsť automatizovaným testovaním predtým, ako vôbec môže 11

12 byť schválená produktovým vlastníkom. Produktový vlastník si následne môže ručne otestovať na aplikácii, či úloha skutočne spĺňa, čo má. Ak sa jedná napríklad o úlohu analytického charakteru, musí byť jasne zadefinované, čo za výstup sa z analýzy očakáva (príklad: pri analýze využitia rôznych nástrojov sa na konci očakáva odporučený jeden nástroj a zdôvodnenie tohto odporučenia). Úloha však taktiež môže byť aj zrušená, ak trebárs došlo ku zlej komunikácii alebo požadovaná funkcionalita bola nakoniec vyhodnotená ako nepotrebná. Metodika pre komunikáciu Komunikácia počas stretnutí prebieha voľne v rámci slušnosti správania sa. Jednotlivé návrhy a pripomienky môže ktorýkoľvek člen predniesť na stretnutí počas voľnej diskusie alebo k danej problematike počas danej fázy stretnutia. Stretnutia prebiehajú zväčša dvakrát do týždňa, raz oficiálne počas troch hodín uvedených v rozvrhu aj s pedagogickým vlastníkom, raz ako tzv. stand-up, ktorý býva v pondelky večer o desiatej, ak sa členovia tímu nedohodnú inak. Pre komunikáciu v rámci projektu používame aplikáciu Slack, kde máme vytvorené osobitné kanály pre rôzne časti tímového projektu: #general pre komunikáciu a riešenie všeobecných problémov i s produktovým vlastníkom a pedagogickým vedúcim, #devops pre vývoj aplikácie a diskusie kódu, #machinelearning pre metódy strojového učenia, #documentation pre riešenie problémov týkajúcich sa dokumentácie, #asana pre notifikácie z aplikácie Asana, ktorá slúži na plánovanie a evidenciu úloh, #gitlab pre upozornenia z GitLabu a správach o builde a výsledkov testov zo systému Jenkins, #random pre veci na odľahčenie, napríklad aj novinky a správy z IT sveta, na ktoré niekto z tímu natrafil. Samozrejme, že zavedený máme kanál aj pre teambuilding. Metodika pre integráciu Aplikácia Slack podporuje aj integráciu s Asanou či GitLab-om, čo zabezpečuje, že všetci členovia tímu dostanú upozornenie, akonáhle niekto pridá komentár k niektorej z úloh či zmení stav úlohy. Takisto dostávame upozornenia zo systému na správu verzií, takže máme prehľad o tom, kedy boli spravené zmeny v jednotlivých vetvách. Tieto upozornenia prichádzajú do kanálov #asana a #gitlab. V kanáli #gitlab sa zobrazujú aj upozornenia od Jenkins-u, ktoré nám dávajú vedieť o stave buildov a testov, ktoré sú nasadené. Aby bol zabezpečený dobrý pracovný režim, každý člen tímu je povinný raz za deň si skontrolovať Slack a upozornenia v jednotlivých kanáloch. 12

13 Metodika pre písanie kódu Štýl písania kódu je zvolený ako predvolené nastavenie nástroja Android Studio 3.0 RC2, ktorý spĺňa Google štandard písania Java kódu. Dokumentácia kódu prebieha procesom písania JavaDoc komentárov v anglickom jazyku. Pre ten sa taktiež vzťahuje tento štandard. Pravidlá písania Java kódu sú popísané tu. Odkaz na konfiguračný súbor pre zadefinovanie štýlu kódu tu. Pre písanie kódu v jazyku Python sme zvolili metodiku PEP8 (detailne popísaná je tu), dokumentácia tejto časti kódu prebieha prevažne formou komentárov priamo v ňom. Metodika pre testovanie Každý, kto vytvára resp. upravuje či dopĺňa určitú funkcionalitu, musí zvážiť, či bude prínosné mať k tejto časti implementované jednotkové testy. Netestujeme funkcionalitu, ku ktorej by implementácia testov ďaleko presiahla náročnosť implementácie samotnej funkcionality (napr. testovanie odosielania súborov z mobilnej aplikácie na server). Testovanie prebieha formou jednotkových testov vo framework-u JUnit, ktoré bežia na lokálnej Java Virtual Machine (JVM). Tieto testy sú umiestnené v priečinku behametrics/app/src/test/java/behametrics, adresárová štruktúra testov kopíruje štruktúru samotnej aplikácie. Testy bežiace na fyzickom zariadení alebo emulátore nepoužívame. Okrem manuálneho spúšťania testov sú testy spúšťané aj automaticky pomocou nástroja Jenkins pri každom push-nutí do develop vetvy v GitLab-e. Metodika pre prehliadku kódu Prostredie pre prehliadku kódu vytvára GitLab, teda nástroj pre verziovanie samotného kódu. Pri plánovaní aktuálneho šprintu, priamo určíme člena, ktorý vykoná prehliadku k danej úlohe, po tom čo vývojár ju presunul zo stavu In Progress do stavu Code Review. Prehliadka prebieha týmto spôsobom: Ak sú nedostatky/chyby Označí sa riadok a pridá sa komentár, ktorý ma formu Čo je zlé Prečo je to zlé Prípadne ako by to mohlo vyzerať Ak prebieha dialóg medzi vývojárom A, B na daný kód C, potom sa budúce iterácie prehliadky kódu C riešia len medzi A, B z dôvodu predošlého poznania kódu C (šetrí sa čas a energia). Prehliadka je ukončená, ak vývojár A, ktorý vykonal prehliadku kódu je spokojný a pridá nad zdrojový kód C správu Akceptované. Následne ten, kto vykonal prehliadku aj presunie úlohu do stavu na akceptačné testovanie. Metodika pre ukladanie súborov Súbory týkajúce sa tímového projektu, ako napríklad zápisnice, retrospektívy či výsledky analýz, sú ukladané na Google Drive v zdieľanom priečinku Tímový projekt, ku ktorému má každý z členov prístup a môže jednotlivé súbory upravovať. Ak je to potrebné, súbory sú zatriedené do príslušných priečinkov pre lepší prehľad. V systéme pre evidenciu úloh je vždy pripojený súbor alebo je v komentári napísaný odkaz na súbor uložený na Google Drive, ktorý prináleží k danej úlohe. 13

14 Obr. 5 Ukážka zdieľaného priečinku Konvencie pre pomenovanie súborov a priečinkov sú nasledovné: - názvy začínajú veľkým písmenom, - názvy sa píšu bez diakritiky, - jednotlivé slová v názve sú oddelené podčiarkovníkom _. Vzorový názov súboru: Analyza_senzorov.docx. Metodika pre plánovanie úloh Slovník: 1. Epic - Časť výsledného produktu, jeden súvislý celok finálneho produktu (napr., vizualizácia dát,...) 2. Story - Jedna funkcionalita väčšieho celku, ktorá má hodnotu pre produktového vlastníka (napr. vytvorenie základných grafov v Kibane) 3. Task - Menšia úloha v rámci jednej story (napr. analýza vizualizácií dát v Kibane) Plánovanie šprintu pozostáva: 1. Pridanie story z vrchu backlogu do šprintu - každému členovi tímu sa vyberie z backlog-u story (ak je daná story väčšia, tak pre viacerých členov tímu) na základe skúseností daného člena s problematikou alebo podľa preferencií. 2. Estimovanie danej story - jednotlivé stories následne estimujeme pomocou Scrum pokrových kariet. Pri nezhode diskutujeme, prečo daní členovia volili dané hodnoty. Ak sa po diskusii nezhodnú všetci členovia tímu na jednej hodnote, hlasovanie a diskusie sa opakujú, až kým sa tím nezhodne na tej istej hodnote. 3. Vytvorenie taskov danej story - pre každú story následne vytvoríme jednotlivé úlohy pre splnenie funkcionality. 14

15 Sumarizácie šprintov V zimnom semestri sme mávali dvojtýždňové šprinty a jeden dlhší šprint, ktorý trval aj cez skúškové obdobie. V rámci prípravy na TP Cup sme v letnom semestri presedlali na jednotýždňové šprinty, dokopy sme tak mali 14 šprintov. Exporty z nástroja pre plánovanie úloh sú dostupné na našej webovej stránke v sekcii Dokumenty/Exporty-Scrum. V tejto kapitole sú zhrnuté najdôležitejšie veci daných šprintov. Šprint 1 - oboznámenie sa s Asanou - určenie Scrum mastera - zavedenie funkčnej webovej stránky - na serveri vytvorené prostredie pre Python - nainštalovanie potrebných knižníc pre strojové učenie - analýza existujúcich API pre OS Android - začiatok vývoja Android aplikácie - vytvorený skript pre RESTful komunikáciu servera s aplikáciou Šprint 2 - vyplnenie prihlášky na TP Cup - doladenie webovej stránky - analýza nástrojov pre automatizované akceptačné testovanie - objavenie bugu so zapisovaním nulových súborov na serveri - zbieranie dát zo senzorov a logovanie nemohli byť akceptované z dôvodu nedostatku testov - zavedené neoficiálne stretnutia tímu mimo tých v rozvrhu Šprint 3 - ošetrenie bugov, napísanie testov - rozbehanie Jenkinsu, prepojenie so Slackom - nastavenie konvencií pre Git - zlepšená čistota kódu Šprint 4 - rozbehanie ElasticSearchu a Kibany - požiadanie o rozšírenie RAM na serveri na 4GB v Redmine - odovzdanie dokumentácií k riadeniu projektu a inžinierskemu dielu Šprint 5 - vytvorenie konfiguračného súboru pre Behametrics - naplánovanie dizajn šprintu - príprava na prezentáciu na MTS - analýza vytvárania produkčnej verzie 15

16 Šprint 6 - testovanie aplikácie pred vytvorením produkčnej verzie - endurance testing - vytvorenie prvej produkčnej verzie - ošetrená komunikácia aplikácie so serverom, ukladanie dát na serveri Šprint 7 - pridanie socketov v mobilnej aplikácii - napísanie abstraktu na IIT.SRC - počiatočné experimenty s machine learningom (extrakcia čŕt, noise filtering, normalizácia dát) - úprava metodík Šprint 8 - vytvorenie kostry aplikácie experimentálnej appky, na ktorej môže byť Behametrics knižnica prezentovaná - nový release aplikácie, aktualizácia dokumentácie k produktu Šprint 9 - vyskúšanie neurónovej siete - implementácia RNN - prechod z PHP do Flasku na strane servera - spojazdnený flow aplikácie aj s autentifikáciou - analýza využitia negative samples - test klasifikátorov Šprint 10 - experimentovanie s neurónovou sieťou - zdokonalovanie časti strojového učenia na serveri - napísanie článku pre robime.it - vyplnenie dotazníka na TP Cup Šprint 11 - nový release loggera a autentifikačnej časti knižnice - práca na strojovom učení - úprava funkcionalít testovacej aplikácie Šprint 12 - vytvorenie plagátu na TP Cup a loga tímu - integrácia knižnice do testovacej aplikácie - pokračovanie v práci na strojovom učení Šprint 13 - napísanie scenárov testovania celého procesu autentifikovania na experimentálnej aplikácii - optimalizácia modelov - testovanie robustnosti - úprava serverovej časti Šprint 14 - doplnenie dokumentácie - príprava na obhajobu - upratanie Git-u 16

17 Globálna retrospektíva pre zimný semester Počas zimného semestra sme dosiaľ postupovali podľa vytýčených cieľov, ktoré sme popísali v časti Globálne ciele pre zimný semester, v projektovej dokumentácii k inžinierskemu dielu. Sústredili sme sa prioritne na vytvorenie -a za účelom možnosti získavania dát pre neskoršie strojové učenie. Ten sa nám podarilo vytvoriť počas prvých troch šprintov, po ktorých si už produktový vlastník aj vyskúšal jeho funkčný prototyp počas Mini-Erazmu, na ktorom študenti stredných škôl pomohli nalogovať nemalé množstvo dát. V ďalšom šprinte sme sa venovali najmä refaktorizácii kódu a vizualizáciám surových dát. Tie sú realizované pomocou nástroja Kibana. Ďalej sme si aj vďaka mentoringu v rámci TP CUP-u uvedomili, že síce sme boli schopní dodať určitú časť funkcionality a vytvoriť prototyp, ale plánovanie šprintov a stories v nich vôbec nebolo na dostatočne dobrej úrovni. Preto sme sa rozhodli za štýlom plánovania predošlých šprintov urobiť hrubú čiaru a začať inak. To sa pretavilo do piateho šprintu, v ktorom máme naplánované hlavne prípravné úlohy pre dizajn šprint - techniku, ktorú chceme vyskúšať počas skúškového obdobia. Tie sme už plánovali do menších a lepšie zadefinovaných stories. Globálne by sme radi pokračovali v nastolenom štýle po mentoringu a chceli by sme zapracovať na lepšom pokrytí implementovanej funkcionality testami. Taktiež budeme pokračovať aj v pravidelných stretnutiach mimo školy, ktoré nám pomohli vyriešiť mnohé komunikačné problémy. Veríme, že práve tieto tímové stretnutia môžu zlepšiť súdržnosť tímu, posilniť tímového ducha a zefektívniť našu prácu na projekte. Globálna retrospektíva pre letný semester S porovnaním so zimným semestrom bola práca na úlohách viac experimentálna a výskumná, nakoľko sa veľká časť tímu venovala strojovému učeniu, ktoré malo zabezpečiť autentifikáciu užívateľa. Vytvorili sme experimentálnu aplikáciu, na ktorej by priebežné autentifikovanie používateľa mohlo byť demonštrované na TP Cupe. Celkovo však bolo menej reálneho kódenia než v zimnom semestri, čo nás mrzí. Veľkú časť práce zabrala príprava na TP Cup, kvôli ktorej boli zavedené jednotýždňové šprinty, aby sme boli viac motivovaní k splnení úloh. Zistili sme však, že náš produkt nie je práve najvhodnejším, nakoľko sa nehľadilo na vnútro, ale skôr vonkajšok, čo ťažko posudzovať pri produkte ako je knižnica. Ale celkovo si myslíme, že sme boli celkom dobrý kolektív a sadli sme si aj s pedagogickým vedúcim Kamilom, s ktorým sme mohli podebatovať aj o iných veciach než je tímového projekt. 17

18 Retrospektívy Retrospektíva k šprintu č. 1 Progres Za dva týždne sa nám z dvanástich taskov podarilo splniť 9, zvyšné 3 nám ostali do ďalšieho šprintu, konkrétne úlohy pre CSV writer, analýzu senzorov a TP Cup prihlášku. Precenili sme tak naše schopnosti. Čo bolo zlé Prvý šprint sme označili za testovací, aby sme do budúcnosti vedeli, v čom sa bude treba zlepšiť. Medzi negatíva tohto šprintu patrili: komunikácia - veľa členov tímu dusilo v sebe otázky a pri taskoch, ktoré boli závislé od splnenia iných úloh bola odpoveď často neskorá málo stretnutí - okrem oficiálnych stretnutí sme sa takmer všetci členovia tímu zišli iba raz a to večer pred review, čo bolo nedostačujúce neochota členov pracovať product owner nám mohol priebežne povedať svoje pripomienky, či už pridávaním komentov na Asane, alebo písaním do Slacku SCRUM master Čo bolo dobré Ako povedal jeden z členov tímu: "Optimizmus je luxus, ktorý si nemôžeme dovoliť." Zhodnotili sme, že na tomto šprinte nebolo nič dobré a budeme sa musieť snažiť viac. Celkové zhodnotenie Zistili sme, že okrem oficiálnych stretnutí sa ako tím budeme musieť stretávať častejšie, minimálne ešte raz do týždňa. Ak niektorý z členov tímu nevie, čo má robiť, má napísať na Slack, kde mu ostatní členovia tímu určite nejakú úlohu vymyslia. Product owner sa nemusí báť písať nám častejšie. 18

19 Retrospektíva k šprintu č. 2 Progres V druhom šprinte sa nám z jedenástich úloh podarilo splniť 7, pričom 4 úlohy nám ostali do ďalšieho šprintu. Úlohy pre zber dát zo senzorov, logovanie eventov a zapisovanie do súborov nie sú kompletne pokryté testami a vyžadujú kontrolu kódu a prípadný refactoring. Čo treba zmeniť Estimácia úloh V tomto šprinte sme mali definované iba dve stories, ktoré sme ohodnotili 45 a 3 story pointami. Už počas šprintu sme prišli na to, že story s masívnym počtom SP mala byť definovaná ako epocha a jednotlivé úlohy, ktoré do nej patrili, mali byť definované ako stories. Bude preto potrebné estimovať úlohy tak, ako by sa správne malo: najprv si zadefinovať stories, ohodnotiť ich a diskutovať až kým sa tím nezhodne na jednej hodnote SP a až potom definovať úlohy pre jednotlivé stories. Testovanie Zišlo by sa vylepšiť techniku testovania, skúsiť využiť TDD a písať testy pred samotnou implementáciou. Testovať treba nielen ideálne prípady, ale aj tie ostatné. Rozdelenie úloh V budúcnosti bude potrebné lepšie si prerozdeliť úlohy, aby sa nestalo, že nejakí členovia tímu nemajú na čom robiť. Taktiež je potrebné zmenšiť závislosť jednotlivých úloh, aby nikto nemusel príliš dlho čakať na druhého. Treba sa vyvarovať aj commitovaniu sa k viacerým úlohám a vybrať si jednu, ktorú treba splniť poriadne. Definition of ready Pri Definition of ready si treba už na začiatku pre stories a tasky jednoznačne definovať akceptačné kritériá, aby product owner neskôr vedel, čo všetko musí byť splnené, aby ich 19

20 mohol schváliť pri akceptačnom testovaní. Product owner sa nemusí báť pridávať položky do product backlogu aj mimo stretnutí s tímom :) Git Bude treba zaviesť konvencie pre vytváranie a pomenovanie branch-í, aby sa opätovne nestalo, že po premazaní branch-e zber_dat_zo_senzorov sa ďalšia vetva nazve zber_dat_zo_senzorov2. Čo bolo dobré Po prvom šprinte sme sa začali pravidelne stretávať minimálne raz do týždňa, čo nás prinútilo pracovať na projekte priebežne. Taktiež sme vďaka tomu mali možnosť viac diskutovať, brainstormovať a bližšie sa spoznať. Plánujeme si pre takéto stretnutia zarezervovať miesto v študovni Y-base na internáte Mladosť na každý pondelok večer na pravidelné stand-upy. Celkové zhodnotenie Tento šprint bol oproti prvému šprintu z pohľadu dodania produktu lepší, dokonca sme mali aj čo prezentovať product ownerovi, hoci sme si toho naložili na tanier viac, než sme stihli spraviť. Potvrdilo sa nám, že priebežné stretnutia počas šprintu prinášajú ovocie aj SCRUM master bol lepším motivátorom než predtým. 20

21 Retrospektíva k šprintu č. 3 Progres V treťom šprinte sa nám z 18 úloh podarilo splniť 16, pričom dve zvyšné úlohy zahŕňali technickú dokumentáciu a dokumentácie k riadeniu projektu a inžinierskemu dielu, na ktorých ešte popracujeme do dňa odovzdania ( ). Čo bolo zlé Práca na úlohách Počas šprintu sa jednému z členov tímu stalo, že chcel ísť robiť na svojej úlohe, ku ktorej sa commitol, no kým si na ňu našiel čas, úloha už bola spravená iným členom tímu bez toho, aby o tom vedel. Každý člen tímu sa tak musí zaviazať nerobiť na úlohách, ku ktorým sa už niekto iný commitol a nevyfúknuť mu tak úlohu. Platí však aj, že sa netreba commitovať k úlohám, ktoré daný človek neplánuje splniť. Úlohu si treba brať až vtedy, keď je člen tímu naozaj odhodlaný na nej robiť. Git V branch-iach, ktoré sa vytvorili v repozitári počas šprintu, nastal neporiadok a zmeny neboli tam, kde mali byť. V branch-iach je potrebné dodržiavať poriadok a možno by bolo fajn zaviesť jednu branc-u pre fixovanie bugov, na ktoré sa prišlo a nevytvárať branch-u pre každý bug osobitne. Písanie testov Testy treba písať už priebežne počas písania vlastnej časti kódu a nie naraz na konci. Prepojenie s inou aplikáciou Product ownerovi sa žiaľ nepodarilo dokódiť aplikáciu, ktorú plánoval prepojiť s našou aplikáciou, aby si mohol overiť, či naša aplikácia skutočne dokáže fungovať ako framework. 21

22 Čo bolo dobré Komunikácia v rámci tímu funguje a členovia tímu poctivo pracujú na projekte i dokumentácii. Celkové zhodnotenie Tretí šprint bol pre nás zatiaľ najúspešnejší - podarilo sa nám dokončiť prakticky všetko, čo sme si naplánovali. Product owner bol prvýkrát spokojný s výsledkom a aplikácia už nerobila nečakané veci. Taktiež už máme na serveri rozbehnutý Jenkins a prechádzajú nám tam testy. 22

23 Retrospektíva k šprintu č. 4 Progres Vo štvrtom šprinte sme označili za kompletné spolu 14 úloh, pričom 4 úlohy nám ostali do piateho šprintu. Počas tohto šprintu sme tri úlohy priebežne zrušili, nakoľko sme v polke šprintu po mentoringu z manažmentu i po celkovom pohľade na tímový projekt v rámci vytvárania lean canvasu a diskusie s produktovým vlastníkom zistili, že sa bude treba uberať iným smerom, ako doteraz a naša vízia výsledného produktu sa podstatne zmenila. Vzhľadom na to, že sa blížil koniec semestra a s tým súvisiace nespočetné množstvo zápočtov, zadaní i skúšok, rozhodli sme sa predĺžiť tento šprint na trojtýždňový a ukončiť ho až s tým, že piaty šprint bude prebiehať aj počas sviatkov pokoja až do 13. januára. Čo bolo zlé Analýza vizualizácií dát v Kibane bola spravená nedostatočne a nebola prezentovateľná Členovia tímu nevenovali tímovému projektu dostatočné množstvo času kvôli ostatným školským povinnostiam Čo bolo dobré Komunikácia je stále dobrá a zlepšili sme sa aj v plánovaní a definovaní úloh do budúcich šprintov. Celkové zhodnotenie Vzhľadom na hektické obdobie na FIITke spojené s blížiacim sa koncom semestra sme sa tímovému projektu nemohli venovať do takej miery, s akou by mohol byť náš pedagogický vedúci/produktový vlastník spokojný, čo nás mrzí. Nevzdávame sa však a sme odhodlaní na tímovom projekte pokračovať i počas skúškového obdobia. 23

24 Retrospektíva k šprintu č. 5 Progres Piaty šprint trval vzhľadom na sviatky a začiatok skúškového obdobia až do 13. januára. V rámci tohto šprintu sme absolvovali prezentáciu na Manažment v tvorbe softvéru, doladili sme našu Android aplikáciu pre logovanie dát, ktorá bola následne odskúšaná na DOD na FIIT a naplánoval sa dizajn šprint. Čo bolo zlé Plnenie úloh na poslednú chvíľu Code review sa nestihlo vykonať pri všetkých úlohách Čo bolo dobré Naplánovanie dizajn šprintu Celkové zhodnotenie V tomto šprinte sme sa sústredili hlavne na doladenie aplikácie, aby sme mohli so správne nameranými dátami pracovať na naplánovanom dizajn šprinte. Vzhľadom na skúškové obdobie sa nestihli všetky úlohy spraviť načas tak, aby spĺňali akceptačné kritériá. 24

25 Retrospektíva k šprintu č. 6 Progres Plusy a mínusy + - sobotné jednodňové celodenné šprinty viditeľný posun v projekte code review (nech nerobí iba pár jedincov) čakanie na code review testy značne zlepšiť postup pri code review: vysvetliť, čo je zlé, dať návrhy ako postupovať inak hneď pri začatí práce na úlohe sa určí človek zodpovedný za code review začať používať statické analyzátory kódu 25

26 Retrospektíva k šprintu č. 7 Progres Plusy a mínusy + - pondelkové stretnutia definovanie taskov budú jednotýždňové šprinty pondelkové stretnutia o 22:00 definovať každý task lepšie - vstup, výstup, obsah, atď. 26

27 Retrospektíva k šprintu č. 8 Progres Plusy a mínusy + - lepšia produktivita vďaka jednotýždňovému šprintu nevykonané code review pre všetky tasky neskôr bude potrebné naplánovať ďalší dizajn šprint 27

28 Retrospektíva k šprintu č. 9 Progres Plusy a mínusy + - nedodržiavanie konvencií pre správu verzií (pri code review a merge request) 28

29 Retrospektíva k šprintu č. 10 Progres Plusy a mínusy + - kvalita pondelkových stretnutí výhrady voči Scrum masterovi zlepšiť kvalitu pondelkových stretnutí 29

30 Retrospektíva k šprintu č. 11 Progres Plusy a mínusy + - napriek sviatkom sme stihli spraviť adekvátne množstvo taskov Retrospektíva k šprintu č. 12 Progres 30

31 Retrospektíva k šprintu č. 13 Progres Plusy a mínusy + - všetko sa stihlo spraviť 31

32 Exporty taskov Created At Completed At Name Tags Notes 05/10/17 Odosielanie na server Odosielať dáta na server po určitej veľkosti (1MB) pri pripojení na internet. Ak pripojenie nie je dostupné a kapacita pamäte je naplnená, logovanie sa zastaví. 12/10/17 Logovanie Android eventov 05/10/17 Čakajúce na schválenie: Cakajuce 05/10/17 Mergovanie dát zo senzorov,cakajuce Data zo senzorov sa zaznamenavaju v roznych casovych intervaloch. Preto je potrebne vytvorit modul,algoritmus ktory nad datami vykona korekciu pre jednotnost nameranych vzoriek. 11/10/17 Podpora pre Android 4.1: Story Product owner chce pridať podporu pre Android 4.1 v produkčnej verzii. 11/10/17 Manažment: Manažment 11/10/17 Dokumentácie zo stretnutí Manažment 32

33 11/10/17 Technická dokumentácia Manažment Ako developer k hotovému modulu spravím technickú dokumentáciu 05/10/17 Vizualizácia dát: Story Ako výskumník chcem vidieť surové dáta na serveri, aby som v tom mal prehľad 11/10/17 Klasifikátor: Story,Klasifikátor Product owner chce aby som ako výskumník vyskúšal rôzne metódy klasifikácie 12/10/17 Vzdialenostné metriky: Story,Metriky Product owner chce aby som ako výskumník vyskúšal rôzne vzdialenostné metriky 12/10/17 Štatistické testy: Story,Štatistické testy Product owner chce aby som ako výskumník vyskúšal rôzne štatistické testy 12/10/17 Hodnotenie modelov: Story,Hodnotenie modelov Ako výskumníci potrebujeme vyhodnotiť úspešnosť/chybovosť/vhodn osť modelov. 12/10/17 Predspracovanie : Epic 12/10/17 Extrakcia čŕt: Epic 12/10/17 Logovanie userdefined eventov: Story 12/10/17 12/10/17 33

34 12/10/17 Created At Completed At Name Assignee Tags Notes 12/10/17 TP-cup prihláška 12/10/17 analýza previazania taskov z asany s commit-mi z gitlabu Patrik Beka 04/10/17 :,Story Ako výskumník chcem vedieť zbierať dáta z jednotlivých senzorov, ukladať ich. 05/10/17 Logovanie dát Tomas Lach '- surové dáta logované do CSV 05/10/17 Webstránka: Peter Kanuch Story,Webstrá nka Ako pouzivatel chcem informovat o svojich vystupoch na webstranke. 05/10/17 Popisy upraviť Peter Kanuch Webstránka 05/10/17 07/10/17 Pridať fotografie Peter Kanuch Webstránka 05/10/17 07/10/17 Zápisnica Peter Bakonyi Webstránka 34

35 05/10/17 Experimentálna aplikácia Jakub Kazimír Vytvorenie prázdneho Android projektu - jedna prázdna obrazovka. -Verzia Android: 05/10/17 05/10/17 Analýza senzorov Matus Cicman Analyzovať dostupné senzory v Android zariadeniach. -Výstup: zoznam senzorov, ktoré môžu byť implementov ané 05/10/17 Nainštalovať knižnice Patrik Beka Server NumPy, SciPy, Pandas. + PIP 05/10/17 Vytvoriť prostredie pre strojové učenie v jazyku Python Patrik Beka Server 05/10/17 RESTful API pre upload Matus Cicman Server,Cakajuc e Vytvoriť script na upload CSV súboru na server 05/10/17 Skontrolovat stav kodu Code Review 35

36 05/10/17 05/10/17 10/10/17 Server: Story,Server Ako používateľ chcem odosielať dáta na serveri, aby som nezaťažoval zariadenia. 05/10/17 09/10/17 Vygenerovanie SSH kľúčov Peter Kanuch 05/10/17 08/10/17 Vygenerovanie SSH kľúčov Tomas Lach 05/10/17 07/10/17 Vygenerovanie SSH kľúčov Peter Bakonyi 05/10/17 06/10/17 Vygenerovanie SSH kľúčov Patrik Beka 05/10/17 07/10/17 Vygenerovanie SSH kľúčov Michaela Nguyenová 05/10/17 07/10/17 Vygenerovanie SSH kľúčov Matus Cicman 05/10/17 06/10/17 Vygenerovanie SSH kľúčov Kamil Burda 05/10/17 10/10/17 Vygenerovanie SSH kľúčov Jakub Kazimír 05/10/17 06/10/17 Vygenerovanie SSH kľúčov Gergely Abelovsky 05/10/17 Analýza API Android OS Gergely Abelovsky Analýza verzií 4.1 a vyššie 36

37 assignee/name Peter Kanuch assig nee_ statu s com plete d FALS E membe rships/0 /project /name 1 memb ership s/0/se ction/ name modified_at name notes tags/0/name tags/1/name Accep tance testin g Patrik Beka 1 Done 19/10/17 8:35 19/10/17 8:09 TP-cup prihláška Analýza previazania taskov z asany s commit-mi z gitlabu Manažment upco ming FALS E 1 Storie s 12/10/17 9:36 : Ako výskumník chcem vedieť zbierať dáta z jednotlivých senzorov, ukladať ich. Story Tomas Lach FALS E 1 In progr ess 18/10/17 23:04 CSV writer - surové dáta logované do CSV Peter Kanuch FALS E 1 Accep tance testin g 19/10/17 8:35 Webstránka: Ako pouzivatel chcem informovat o svojich vystupoch na webstranke. Story Webstránka

38 Peter Kanuch 1 Done 12/10/17 18:14 Popisy upraviť Webstránka Peter Kanuch 1 Done 07/10/17 23:22 Pridať fotografie Webstránka Peter Bakonyi 1 Done 07/10/17 23:22 Zápisnica Webstránka Jakub Kazimír 1 Done 19/10/17 8:11 Experimentálna aplikácia Vytvorenie prázdneho Android projektu - jedna prázdna obrazovka. -Verzia Android: Matus Cicman FALS E 1 In progr ess 11/10/17 19:50 Analýza senzorov Analyzovať dostupné senzory v Android zariadeniach. -Výstup: zoznam senzorov, ktoré môžu byť implementované Patrik Beka 1 Done 19/10/17 8:08 Nainštalovať knižnice NumPy, SciPy, Pandas. Server 2

39 + PIP Patrik Beka 1 Done 19/10/17 8:08 Vytvoriť prostredie pre strojové učenie v jazyku Python Server Matus Cicman 1 Done 19/10/17 8:17 RESTful API pre upload Vytvoriť script na upload CSV súboru na server Server Cakajuce upco ming 1 Done 10/10/17 16:12 Server: Ako používateľ chcem odosielať dáta na serveri, aby som nezaťažoval zariadenia. Story Server Gergely Abelovsky 1 Done 19/10/17 8:27 Analýza API Android OS Analýza verzií 4.1 a vyššie assignee_status name notes projects/0/name tags/0/name tags/1/name upcoming upcoming Integračné testovanie integrovanie pridaných modulov navzájom Umožnenie background service: Story upcoming Čakajúce na schválenie: Cakajuce 3

40 upcoming Podpora pre Android 4.1: Product owner chce pridať podporu pre Android 4.1 v produkčnej verzii. Story upcoming Manažment: Manažment upcoming Dokumentácie zo stretnutí Manažment upcoming Technická dokumentácia Ako developer k hotovému modulu spravím technickú dokumentáciu Manažment upcoming Vizualizácia dát: Ako výskumník chcem vidieť surové dáta na serveri, aby som v tom mal prehľad Story upcoming Klasifikátor: Product owner chce aby som ako výskumník vyskúšal rôzne metódy klasifikácie Story Klasifikátor upcoming Vzdialenostné metriky: Product owner chce aby som ako výskumník vyskúšal rôzne vzdialenostné metriky Story Metriky upcoming Štatistické testy: Product owner chce aby som ako výskumník vyskúšal rôzne štatistické testy Story Štatistické testy 4

41 upcoming Hodnotenie modelov: Ako výskumníci potrebujeme vyhodnotiť úspešnosť/chybovosť/vhodnosť modelov. Story upcoming Predspracovanie: Epic upcoming Extrakcia čŕt: Epic upcoming Logovanie user-defined eventov: Story Hodnotenie modelov assignee_status completed Progress name notes tags/0/name assignee/name tags/1/name Analyzovať dostupné senzory v Android zariadeniach. -Výstup: upcoming 2 Todo Analýza senzorov Ako zbierať dáta z touchscreenu a či sa dajú zbierať Konfigurácia jednotlivých senzorov (čo a ako sa robí) 5

42 Čo sa dá zbierať mimo aktívnej aplikácie. upcoming upcoming upcoming upcoming Todo Todo Todo Todo Návrh architektúry Overenie batchovania eventov Implementovať zber dát zo senzorov CSV writer UML-diagramy Na základe analýzy senzorov sa implementuje zber dát z vybraných senzorov. - surové dáta logované do CSV 2 In progress Odosielanie na server Odosielať dáta na server po určitej veľkosti (1MB) pri pripojení na internet. Jakub Kazimír 6

43 Ak pripojenie nie je dostupné a kapacita pamäte je naplnená, logovanie sa zastaví. upcoming upcoming 2 2 Todo Todo Mergovanie dát zo senzorov Logovanie Android eventov Data zo senzorov sa zaznamenavaju v roznych casovych intervaloch. Preto je potrebne vytvorit modul,algoritmus ktory nad datami vykona korekciu pre jednotnost nameranych vzoriek. 7

44 Ako výskumník chcem vedieť zbierať dáta z jednotlivých senzorov, ukladať ich. -zbierať dáta zo senzorov upcoming 2 Stories [45] : -ukladať dáta do.csv Story -posielať dáta na server -uložiť dáta na server (spravené v sprinte 1) upcoming upcoming 2 2 Todo Analyzovať nástroje pre automatizované akceptačné testovanie Manažment Stories [3] Manažment: Manažment 2 In progress Webstránka Ako pouzivatel chcem informovat o Manažment Peter Kanuch 8

45 svojich vystupoch na webstranke. upcoming 2 In progress TP-cup prihláška Manažment assignee_status completed created_at name notes tags/0/name tags/1/name upcoming 19/10/17 9:43 Integračné testovanie integrovanie pridaných modulov navzájom upcoming upcoming 19/10/17 10:07 05/10/17 10:48 Umožnenie background service: Čakajúce na schválenie: Cakajuce Story upcoming 12/10/17 8:25 Podpora pre Android 4.1: Product owner chce pridať podporu pre Android 4.1 v produkčnej verzii. Story upcoming 12/10/17 8:44 Manažment: Manažment 9

46 upcoming 26/10/17 8:39 Pridať plug-in do Android Studia pre kontrolu konvencií písania kódu Manažment upcoming 26/10/17 9:07 Vytvoriť develop branch v GitLabe Manažment upcoming 26/10/17 8:21 Požiadavka do Redminu Rozšírenie RAM na serveri (4GB) Manažment upcoming 12/10/17 8:47 Dokumentácie zo stretnutí Manažment upcoming 12/10/17 8:50 Technická dokumentácia Ako developer k hotovému modulu spravím technickú dokumentáciu Manažment upcoming 05/10/17 10:24 Vizualizácia dát: Ako výskumník chcem vidieť surové dáta na serveri, aby som v tom mal prehľad Story upcoming 12/10/17 8:57 Klasifikátor: Product owner chce aby som ako výskumník vyskúšal rôzne metódy klasifikácie Story Klasifikátor 10

47 upcoming 12/10/17 9:07 Vzdialenostné metriky: Product owner chce aby som ako výskumník vyskúšal rôzne vzdialenostné metriky Story Metriky upcoming 12/10/17 9:08 Štatistické testy: Product owner chce aby som ako výskumník vyskúšal rôzne štatistické testy Story Štatistické testy upcoming 12/10/17 9:10 Hodnotenie modelov: Ako výskumníci potrebujeme vyhodnotiť úspešnosť/chybovosť/vhodnosť modelov. Story Hodnotenie modelov upcoming upcoming upcoming upcoming 12/10/17 9:17 12/10/17 9:19 12/10/17 10:26 26/10/17 8:20 Predspracovanie: Epic Extrakcia čŕt: Epic Logovanie userdefined eventov: Zaviesť priebežnú integráciu: Jenkins Story Story Server upcoming 26/10/17 8:22 Rozbehať Jenkins Rozbehať testovacie prostredie. 11

48 upcoming 26/10/17 8:22 Prepojenie so Slackom assignee/name assignee_status completed completed_at Progress name notes tags/0/name Analyzovať dostupné senzory v Android zariadeniach. -Výstup: Peter Bakonyi 2 In progress Analýza senzorov Konfigurácia jednotlivých senzorov (čo a ako sa robí) UML-diagramy Matus Cicman 2 In progress Návrh architektúry Merging all functionality into one app 12

49 according to UML design Gergely Abelovsky Matus Cicman Tomas Lach In progress In progress In progress Overenie batchovania eventov Implementovať zber dát zo senzorov CSV writer Na základe analýzy senzorov sa implementuje zber dát z vybraných senzorov. - surové dáta logované do CSV Odosielať dáta na server po určitej veľkosti (1MB) Jakub Kazimír 2 In progress Odosielanie na server pri pripojení na internet. Ak pripojenie nie je dostupné a kapacita pamäte je naplnená, logovanie sa zastaví. 13

50 Tomas Lach Matus Cicman 26/10/17 9: Canceled In progress Mergovanie dát zo senzorov Logovanie Android eventov Data zo senzorov sa zaznamenavaju v roznych casovych intervaloch. Preto je potrebne vytvorit modul,algoritmus ktory nad datami vykona korekciu pre jednotnost nameranych vzoriek. Patrik Beka 2 In progress Analyzovať nástroje pre automatizované akceptačné testovanie Manažment upcoming 2 Stories [3] Manažment: Manažment 14

51 Ako výskumník chcem vedieť zbierať dáta z jednotlivých senzorov, ukladať ich. -zbierať dáta zo senzorov upcoming 2 Stories [45] : -ukladať dáta do.csv -posielať dáta na server -uložiť dáta na server (spravené v sprinte 1) Peter Kanuch Peter Kanuch 26/10/17 9:28 26/10/17 8: Done Done Webstránka TP-cup prihláška Ako pouzivatel chcem informovat o svojich vystupoch na webstranke. Manažment Manažment 15

52 Analyzovať dostupné senzory v Android zariadeniach. -Výstup: Analýza senzorov Peter Bakonyi 29/10/17 19:16 19/10/17 9:19 Done Konfigurácia jednotlivých senzorov (čo a ako sa robí) UML-diagramy Návrh architektúry Matus Cicman 19/10/17 9:45 Code review Merging all functionality into one app according to UML design Overenie batchovania eventov Gergely Abelovsky 02/11/17 8:50 18/10/17 22:22 Done 16

53 Implementovať zber dát zo senzorov Matus Cicman 19/10/17 9:40 In progress Na základe analýzy senzorov sa implementuje zber dát z vybraných senzorov. CSV writer Tomas Lach 19/10/17 9:19 In progress - surové dáta logované do CSV 17

54 Odosielať dáta na server po určitej veľkosti (1MB) Odosielanie na server Jakub Kazimír 02/11/17 9:24 05/10/17 10:29 Done pri pripojení na internet. Ak pripojenie nie je dostupné a kapacita pamäte je naplnená, logovanie sa zastaví. 18

55 Mergovanie dát zo senzorov Tomas Lach 26/10/17 9:54 05/10/17 23:46 Canceled Data zo senzorov sa zaznamenavaju v roznych casovych intervaloch. Preto je potrebne vytvorit modul,algoritmus ktory nad datami vykona korekciu pre jednotnost nameranych vzoriek. Logovanie Android eventov Matus Cicman 12/10/17 10:25 In progress Analyzovať nástroje pre automatizované akceptačné testovanie Patrik Beka 02/11/17 8:12 19/10/17 9:36 Done Manažment [3/3] Manažment: upcoming 19/10/17 9:24 Stories Manažment 19

56 Ako výskumník chcem vedieť zbierať dáta z jednotlivých senzorov, ukladať ich. -zbierať dáta zo senzorov [45/45+] : upcoming 19/10/17 9:19 Stories -ukladať dáta do.csv Story -posielať dáta na server -uložiť dáta na server (spravené v sprinte 1) 20

57 Webstránka Peter Kanuch 26/10/17 9:28 19/10/17 9:19 Done Ako pouzivatel chcem informovat o svojich vystupoch na webstranke. Manažment TP-cup prihláška Peter Kanuch 26/10/17 8:05 19/10/17 9:19 Done Manažment assignee_status memberships/0/project/name name notes tags/0/name tags/1/name upcoming : upcoming upcoming upcoming upcoming Integračné testovanie Umožnenie background service: Čakajúce na schválenie: Podpora pre Android 4.1: Logovanie dát a odosielanie na server. integrovanie pridaných modulov navzájom Product owner chce pridať podporu pre Android 4.1 v produkčnej verzii. Cakajuce upcoming Manažment: Manažment upcoming Pridať plug-in do Android Studia pre kontrolu konvencií písania kódu Manažment Story Epic Story 21

58 upcoming Požiadavka do Redminu Rozšírenie RAM na serveri (4GB) Manažment upcoming Vizualizácia dát: Ako výskumník chcem vidieť surové dáta na serveri, aby som v tom mal prehľad. Story upcoming Klasifikátor: Product owner chce aby som ako výskumník vyskúšal rôzne metódy klasifikácie Story Klasifikátor upcoming Vzdialenostné metriky: Product owner chce aby som ako výskumník vyskúšal rôzne vzdialenostné metriky Story Metriky upcoming Štatistické testy: Product owner chce aby som ako výskumník vyskúšal rôzne štatistické testy Story Štatistické testy upcoming Hodnotenie modelov: Ako výskumníci potrebujeme vyhodnotiť úspešnosť/chybovosť/vhodnosť modelov. upcoming Predspracovanie: Epic upcoming Extrakcia čŕt: Epic upcoming upcoming Logovanie userdefined eventov: Zaviesť priebežnú integráciu: Jenkins Story Story Story Hodnotenie modelov Server 22