ˇ ´ Cesk e ´ vysoke ˇen´ı uc ´ technicke v Praze Fakulta Elektrotechnick´ a Katedra Poˇ c´ıtaˇ c˚ u
Bakal´ aˇrsk´ a pr´ ace
Kanban Board pro Gitlab Michal Chv´ ala
Kvˇ eten 2015 Vedouc´ı pr´ ace: Ing. Ondˇrej Macek, Ph.D.
Prohl´ aˇsen´ı Prohlaˇsuji, ˇze jsem pˇredloˇzenou pr´aci vypracoval samostatnˇe a ˇze jsem uvedl veˇsker´e pouˇzit´e informaˇcn´ı zdroje v souladu s Metodick´ ym pokynem o dodrˇzov´an´ı etick´ ych princip˚ u pˇri pˇr´ıpravˇe vysokoˇskolsk´ ych z´avˇereˇcn´ ych prac´ı.
V Praze dne 11. 5. 2015
i
Podˇ ekov´ an´ı T´ımto bych velice r´ad podˇekoval vedouc´ımu pr´ace Ing. Ondˇreji Mackovi, Ph. D. za poskytnut´e konzultace a pozitivn´ı pˇr´ıstup.
ii
Abstrakt Tato pr´ace se zab´ yv´a tvorbou webov´e aplikace pro spr´avu a ˇr´ızen´ı v´ yvoje softwarov´ ych projekt˚ u, propojenou s issue tracking syst´emem aplikace Gitlab. Aplikace vyuˇz´ıv´a koncept Kanban, kter´ y pom´ah´a optimalizovat v´ yvojov´e procesy.
Abstract This project realizes web application for management and control of software projects. Application is synchronized with issue tracking system of application Gitlab. Application uses the concept of Kanban, which helps to optimize development processes.
iii
Obsah ´ 1 Uvod
1
2 Spr´ ava a ˇ r´ızen´ı v´ yvoje software 2.1 Issue Tracking System . . . . 2.2 Kanban Board . . . . . . . . . 2.3 SCRUM . . . . . . . . . . . . 2.4 Gitlab . . . . . . . . . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
2 2 2 4 5
3 Poˇ zadavky 3.1 Propojen´ı s Gitlabem 3.2 Kanban . . . . . . . 3.3 F´orum se z´akazn´ıkem 3.4 V´ ykazy a statistiky .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
6 6 6 7 8
4 Podobn´ e projekty 4.1 Taiga . . . . . . 4.2 Pivotal Tracker 4.3 LeanKit . . . . 4.4 Trello . . . . . 4.5 Shrnut´ı reˇserˇse
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
10 10 10 11 12 12
. . . . . . . .
14 14 14 15 15 19 20 21 21
. . . . . .
23 23 23 24 24 24 24
. . . .
26 26 26 27 27
. . . . .
. . . . .
. . . . .
5 Anal´ yza 5.1 Uˇzivatelsk´e role . . . . . . . . . . 5.2 Dom´enov´ y model . . . . . . . . . 5.3 Pˇr´ıpady uˇzit´ı . . . . . . . . . . . 5.3.1 F´orum se z´akazn´ıkem . . . 5.3.2 Issues . . . . . . . . . . . 5.3.3 Kanban . . . . . . . . . . 5.3.4 V´ ykazy a administrace . . 5.3.5 Mapov´an´ı pˇr´ıpad˚ u uˇzit´ı na 6 N´ avrh 6.1 Pouˇzit´e technologie . 6.1.1 MEAN Stack 6.1.2 NPM . . . . . 6.1.3 Bower . . . . 6.1.4 Gulp . . . . . 6.2 Datab´aze . . . . . .
. . . . . .
. . . . . .
7 Implementace 7.1 Server . . . . . . . . . . 7.2 Klient . . . . . . . . . . 7.2.1 Kanban Board . . 7.2.2 Backlog a Sprinty
. . . . . .
. . . .
. . . . . .
. . . .
iv
. . . . . .
. . . .
. . . . . .
. . . .
. . . . . .
. . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . poˇzadavky
. . . . . .
. . . .
. . . . . .
. . . .
. . . . . .
. . . .
. . . . . .
. . . .
. . . . . .
. . . .
. . . . . .
. . . .
. . . . . .
. . . .
. . . . . . . .
. . . . . .
. . . .
. . . . . . . .
. . . . . .
. . . .
. . . . . . . .
. . . . . .
. . . .
. . . . . . . .
. . . . . .
. . . .
. . . . . . . .
. . . . . .
. . . .
. . . . . . . .
. . . . . .
. . . .
7.3
Nedostatky . . . . . . . . . . . . . . . . . . . . . . . . . .
28
8 Testy 8.1 Selenium testy . . . . . . . . . . . . . . . . . . . . . . . . . 8.2 Akceptaˇcn´ı testy . . . . . . . . . . . . . . . . . . . . . . .
29 29 29
9 Zhodnocen´ı 9.1 Souˇcasn´e probl´emy a n´amˇety na zlepˇsen´ı . . . . . . . . . . 9.2 Osobn´ı zhodnocen´ı . . . . . . . . . . . . . . . . . . . . . .
34 34 34
v
Seznam obr´ azk˚ u 1 2 3 4 5 6 7 8 9 10 11 12 13
Z´akladn´ı Kanban Board, pˇrevzato z [9] Kanban Board - bootleneck, pˇrevzato z Gitlab issue tracking . . . . . . . . . . Dom´enov´ y model . . . . . . . . . . . . Stavov´ y diagram poˇzadavku . . . . . . Pˇr´ıpady uˇzit´ı - f´orum se z´akazn´ıkeml . Pˇr´ıpady uˇzit´ı - issues . . . . . . . . . . Pˇr´ıpady uˇzit´ı - Kanban . . . . . . . . . Pˇr´ıpady uˇzit´ı - v´ ykazy a administrace . Model datab´aze . . . . . . . . . . . . . Kanban Board . . . . . . . . . . . . . . Sprints . . . . . . . . . . . . . . . . . . Selenium testy . . . . . . . . . . . . . .
vi
. . . [10] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
4 4 5 16 17 17 18 18 19 25 27 28 30
Seznam tabulek 1 2 3 4 5 6 7
Pˇrehled podobn´ ych aplikac´ı a jejich vyhovov´an´ı poˇzadavk˚ um Mapov´an´ı pˇr´ıpad˚ u uˇzit´ı na poˇzadavky 1 . . . . . . . . . . Mapov´an´ı pˇr´ıpad˚ u uˇzit´ı na poˇzadavky 2 . . . . . . . . . . Mapov´an´ı pˇr´ıpad˚ u uˇzit´ı na poˇzadavky 3 . . . . . . . . . . Mapov´an´ı pˇr´ıpad˚ u uˇzit´ı na poˇzadavky 4 . . . . . . . . . . Splnˇen´ı poˇzadavk˚ u . . . . . . . . . . . . . . . . . . . . . . Splnˇen´ı use cases . . . . . . . . . . . . . . . . . . . . . . .
vii
13 22 22 22 22 32 33
viii
´ 1 UVOD
1
´ Uvod
Spr´ava a ˇr´ızen´ı v´ yvojov´ ych proces˚ u jsou d˚ uleˇzit´e souˇc´asti vytv´aˇren´ı software. Existuje mnoho technik a n´astroj˚ u usnadˇ nuj´ıc´ıch tyto ˇcinnosti. Jedn´ım z takov´ ych n´astroj˚ u je open source webov´a aplikace Gitlab, kter´a je vyuˇz´ıv´ana i na t´eto fakultˇe a je pˇr´ıstupn´a student˚ um a zamˇestnanc˚ um1 . C´ılem pr´ace je vytvoˇrit aplikaci, kter´a bude vych´azet z funkcionality Gitlabu a rozˇsiˇrovat ji o dalˇs´ı prvky. Rozˇsiˇruj´ıc´ı funkcionalita bude inspirov´ana technikou Kanban, jej´ıˇz c´ılem je optimalizovat v´ yvojov´e procesy. Hlavn´ı komponentou bude kanban board, kter´ y umoˇzn ˇuje vizualizovat tok pr´ace a zv´ yˇsit efektivitu t´ ymu. Funkcionalita vyh´azej´ıc´ı z Gitlabu bude s Gitlabem synchronizov´ana, takˇze k jednotliv´ ym projekt˚ um p˚ ujde pˇristupovat jak z nov´e aplikace, tak z Gitlabu. To umoˇzn´ı snadn´ y pˇrechod k nov´e aplikaci a to tˇreba jen ˇc´asti t´ ymu. Napˇr´ıklad osoba, kter´a bude pouze pˇrid´avat issues, nebude potˇrebovat u ´ˇcet v nov´e aplikaci. Ve v´ yvoji software je velice d˚ uleˇzit´a komunikace se z´akazn´ıkem. Spr´avn´e pochopen´ı a specifikov´an´ı poˇzadavk˚ u je z´akladem pro vytvoˇren´ı produktu, se kter´ ym bude z´akazn´ık spokojen. Osobn´ı sch˚ uzky se z´akazn´ıkem mohou b´ yt ˇcasovˇe n´aroˇcn´e a vˇetˇsinou u nich nem˚ uˇze b´ yt pˇr´ıtomen cel´ y v´ yvojov´ y t´ ym. Nepˇr´ıjemnosti m˚ uˇzou zp˚ usobovat i zmˇeny poˇzadavk˚ u v pr˚ ubˇehu projektu. Proto bude aplikace obsahovat ˇca´st pro spr´avu uˇzivatelsk´ ych poˇzadavk˚ u, kter´a bude umoˇzn ˇovat i zapojen´ı z´akazn´ıka. Z´akazn´ık bude moci vloˇzit do aplikace sv˚ uj poˇzadavek a pˇr´ıpadnˇe o nˇem diskutovat s v´ yvojov´ ym t´ ymem. Sn´ıˇz´ı se t´ım potˇreba osobn´ıch setk´an´ı a do diskuze se bude moci zapojit cel´ y t´ ym.
1
https://gitlab.fel.cvut.cz/users/sign_in
1/35
´ ˇ´IZEN´I VYVOJE ´ 2 SPRAVA AR SOFTWARE
2
Spr´ ava a ˇr´ızen´ı v´ yvoje software
C´ılem spr´avy a ˇr´ızen´ı je zajistit, aby v´ yvoj prob´ıhal co nejefektivnˇeji a bylo dosaˇzeno v´ ysledku v poˇzadovan´e kvalitˇe a v poˇzadovan´em ˇcase. Jedn´ım z c´ıl˚ u pr´ace je vhodnˇe zkombinovat klasick´ y issue tracking s pokroˇcilejˇs´ımi metodami Kanban a SCRUM.
2.1
Issue Tracking System
Issue tracking system (ITS) je syst´em pro spr´avu issues. Issue m˚ uˇze b´ yt jak´ ykoliv probl´em, kter´ y je potˇreba vyˇreˇsit. Napˇr´ıklad odstranˇen´ı chyby nebo pˇrid´an´ı nov´e funkcionality. ITS umoˇzn ˇuje shromaˇzd’ovat issues na jednom m´ıstˇe a sd´ılet je mezi ˇcleny t´ ymu. Kaˇzd´e issue by mˇelo obsahovat tyto u ´daje [6] • co se m´a udˇelat • co nefunguje a jak by to mˇelo fungovat spr´avnˇe, pokud se jedn´a o chybu • kdo issue vytvoˇril a kdo je za nˇej zodpovˇedn´ y • kdy bylo issue vytvoˇreno • jak´e zmˇeny byly provedeny • jak dlouho trvalo vyˇreˇsen´ı issue Spr´avn´e pouˇz´ıv´an´ı ITS pom´ah´a zv´ yˇsit kvalitu software a spokojenost z´akazn´ıka [6]. Mezi jiˇz existuj´ıc´ı ITS patˇr´ı napˇr´ıklad Assembla2 nebo Bugzilla3 .
2.2
Kanban Board
Kanban [1] je technika pro optimalizaci proces˚ u vych´azej´ıc´ı z konceptu just-in-time [4]. Just-in-time ˇr´ık´a, ˇze produkt by mˇel b´ yt vyroben a dod´an pr´avˇe tehdy, kdy je tˇreba, a t´ım minimalizovat n´aklady na skladov´an´ı a zamezit pl´ ytv´an´ı prostˇredky. Kanban je technika, kter´a pod´av´a n´avod, jak tohoto c´ıle dos´ahnout. Tento koncept se d´a aplikovat i na v´ yvoj software. D. J. Anderson ve sv´e knize [2] definuje pˇet z´akladn´ıch princip˚ u Kanbanu pouˇzit´eho pro v´ yvoj software: 1. Vizualizovat tok pr´ace K vizualizaci je v praxi pouˇzita tabule (Kanban Board) a kartiˇcky, na kter´ ych jsou naps´any u ´koly. Na tabuli jsou vyznaˇceny sloupce s n´azvy f´az´ı, ve kter´ ych ´ se m˚ uˇzou u ´koly nach´azet. Toto ˇreˇsen´ı je vidˇet na obr´azku 1. Ukoly lze posouvat mezi sloupci podle toho, v jak´e f´azi se zrovna nach´az´ı. Kartiˇcky by mˇely b´ yt co 2 3
https://www.assembla.com/ https://www.bugzilla.org/
2/35
´ ˇ´IZEN´I VYVOJE ´ 2 SPRAVA AR SOFTWARE
nejn´azornˇejˇs´ı. M˚ uˇzeme napˇr´ıklad pouˇz´ıt r˚ uzn´e barvy kartiˇcek pro r˚ uzn´e druhy u ´kol˚ u nebo dopsat na kartiˇcky jm´ena pracovn´ık˚ u, kteˇr´ı se u ´kolem zab´ yvaj´ı a podobnˇe. D´ıky vizualizaci je okamˇzitˇe vidˇet, kdo na kter´ ych u ´kolech pr´avˇe pracuje. Tak´e m˚ uˇzeme sledovat postup pˇri ˇreˇsen´ı u ´kol˚ u a snadnˇeji odhalovat pˇr´ıpadn´e probl´emy. 2. Omezit rozdˇelanou pr´aci Nad sloupce je moˇzno napsat ˇc´ısla, kter´a urˇc´ı maxim´aln´ı poˇcet u ´kol˚ u v dan´em sloupci, a t´ım omezit rozdˇelanou pr´aci. Omezen´ı rozdˇelan´e pr´ace je jednou z kl´ıˇcov´ ych souˇca´st´ı Kanbanu. Je to n´astroj, kter´ y dok´aˇze zamezit nadprodukci a udrˇzet proces just-in-time. Z´asadn´ı ovˇsem je omezen´ı dobˇre nastavit. Spr´avn´ ym nastaven´ım se zab´ yvaj´ı dalˇs´ı definovan´e body. Omezen´ı rozdˇelan´e pr´ace nav´ıc zabraˇ nuje pracovn´ık˚ um v pˇreskakov´an´ı mezi r˚ uzn´ ymi u ´koly, a t´ım p´adem jsou u ´koly dokonˇceny rychleji a v lepˇs´ı kvalitˇe [2]. 3. Mˇeˇrit a optimalizovat tok pr´ace D´ıky vizualizaci lze snadno pozorovat postup pr´ace a pˇr´ıpadn´e probl´emy. Je moˇzn´e vidˇet, kde se u ´koly zasek´avaj´ı nebo kter´e sloupce jsou naopak m´alo vyt´ıˇzen´e a na z´akladˇe tˇechto u ´daj˚ u m˚ uˇzeme tok optimalizovat. Jedn´ım z u ´kol˚ u optimalizace je nalezen´ı a odstranˇen´ı pˇr´ıpadn´ ych bootleneck˚ u. Bootleneck je ˇc´ast procesu, kter´a zpomaluje celkov´ y tok pr´ace. Podle ˇcl´anku [1] umoˇzn ˇuje kanban board objevit bootleneck. Na obr´azku 2 lze vidˇet, ˇze analytici a v´ yvoj´aˇri nemohou zaˇc´ıt pracovat na dalˇs´ım u ´kolu, dokud testeˇri nˇejak´ y nedokonˇc´ı. Analytici a v´ yvoj´aˇri tedy mohou pomoci s testy a zajistit plynulejˇs´ı tok pr´ace. Pokud takov´a situace nast´av´a ˇcasto, m˚ uˇze to znamenat, ˇze f´aze test je bootleneck a mˇely by se pˇrehodnotit zdroje. 4. Udˇelat procesn´ı politiky explicitn´ı Tento bod ˇr´ık´a, ˇze politiky by mˇely b´ yt jasnˇe definovan´e, snadno dohledateln´e a kaˇzd´ y ˇclen t´ ymu by jim mˇel rozumˇet. Jednou z d˚ uleˇzit´ ych politik je napˇr´ıklad Definiton of Done, tedy za jak´ ych podm´ınek m˚ uˇze b´ yt u ´kol uzavˇren. U kaˇzd´eho sloupce kanban boardu mohou b´ yt definov´any podm´ınky, kter´e je tˇreba splnit pˇred pˇresunem u ´kolu do tohoto sloupce. Procesn´ı politikou je i omezen´ı rozdˇelan´e pr´ace popsan´e v bodu 2. Je d˚ uleˇzit´e, aby omezen´ı bylo viditeln´e a vˇsem jasn´e. Pˇr´ıpadnˇe je moˇzno definovat podm´ınky, za jak´ ych m˚ uˇze u ´kol do sloupce vstoupit, i kdyˇz pˇrekroˇc´ı limit. 5. Kontrolovat a vylepˇsovat kvalitu procesu Pˇredchoz´ı body by nebyly tak uˇziteˇcn´e, pokud bychom nekotrolovali kvalitu procesu a nesnaˇzili se o jeho vylepˇsov´an´ı. M˚ uˇzeme napˇr´ıklad sledovat, kolik je celkem rozdˇelan´e pr´ace a kolik rozdˇelan´e pr´ace pˇripad´a v pr˚ umˇeru na jednoho ˇclena t´ ymu, a na z´akladˇe toho upravit omezen´ı poˇctu u ´kol˚ u ve sloupc´ıch na kanban boardu. Tak´e m˚ uˇzeme mˇeˇrit propustonst procesu, tedy celkov´ y poˇcet dokonˇcen´e pr´ace v urˇcit´em ˇcasov´em obdob´ı. Dalˇs´ı mˇeˇrenou veliˇcinou je lead time. Lead time je ˇcas, 3/35
´ ˇ´IZEN´I VYVOJE ´ 2 SPRAVA AR SOFTWARE
Obr´azek 1: Z´akladn´ı Kanban Board, pˇrevzato z [9]
Obr´azek 2: Kanban Board - bootleneck, pˇrevzato z [10] za kter´ y kartiˇcka s u ´kolem projde cel´ y kanban board. Tento u ´daj m˚ uˇzeme porovnat se skuteˇcn´ ym str´aven´ ym ˇcasem na u ´kolu. Rozd´ıl mezi tˇemito hodnotami by mˇel b´ yt ide´alnˇe co nejniˇzˇs´ı. Kanban Board je tedy jeden z prostˇredk˚ u k realizov´an´ı techniky Kanban. Slouˇz´ı zejm´ena k vizualizaci, omezen´ı rozdˇelan´e pr´ace a pom´aha pˇri meˇren´ı a zlepˇsov´an´ı kvality proces˚ u.
2.3
SCRUM
SCRUM[7] je agiln´ı4 metodika ˇr´ızen´ı projekt˚ u, vyˇz´ıvan´a zejmen´a pro v´ yvoj software. 4
http://agilemanifesto.org/iso/cs/
4/35
´ ˇ´IZEN´I VYVOJE ´ 2 SPRAVA AR SOFTWARE
Obr´azek 3: Gitlab issue tracking Z´akladn´ı prvky scrumu jsou product backlog a sprint. V product backlogu jsou seˇrazeny uˇzivatelsk´e poˇzadavky podle priority. Sprint je ˇcasov´e obdob´ı dlouh´e maxim´alnˇe jeden mˇes´ıc uvnitˇr kter´eho prob´ıh´a implementace. Pˇred zah´ajen´ım se z product backlogu do sprint backlogu pˇresunou poˇzadavky, kter´e budou v r´amci sprintu implementov´any. Po skonˇcen´ı sprintu se provede zhodnocen´ı a v pˇr´ıpadˇe potˇreby m˚ uˇze probˇehnout dalˇs´ı sprint.
2.4
Gitlab
Gitlab [11] je open source webov´a aplikace pro spr´avu k´odu obsahuj´ıc´ı tak´e jednoduch´ y Issue tracking system. Umoˇzn ˇuje vytv´aˇret projekty a pˇriˇrazovat do nich ˇcleny t´ ymu pod r˚ uzn´ ymi uˇzivatelsk´ ymi pr´avy. V r´amci projektu je moˇzno vytv´aˇret issues. K vytvoˇren´emu issue lze pˇriˇradit pracovn´ık, ˇst´ıtky a stav, kter´ y m˚ uˇze b´ yt bud’ open nebo closed. K issue lze tak´e pˇrid´avat koment´aˇre. Issues lze organizovat pomoc´ı milestones. Kaˇzd´ y milestone m˚ uˇze obsahovat datum, do kdy by mˇel b´ yt splnˇen. Pomoc´ı milestones m˚ uˇzeme tedy simulovat v´ yvojov´e iterace. Vˇetˇsina funkcionality ITS je pˇr´ıstupn´a pˇres REST API.
5/35
ˇ 3 POZADAVKY
3
Poˇ zadavky
Poˇzadavek je specifikace toho, co by mˇelo b´ yt implementov´ano [8]. Poˇzadavky urˇcuj´ı pouze to, co by mˇel v´ ysledn´ y syst´em umoˇzn ˇovat, nikoliv jak toho bude dosaˇzeno. Poˇzadavky na tuto aplikaci vych´azej´ı z kombinace metod Kanban a SCRUM, zad´an´ı pr´ace a poˇzadavk˚ u vedouc´ıho pr´ace.
3.1
Propojen´ı s Gitlabem
REQ-1: Propojen´ı s u ´ˇctem na Gitlabu Syst´em bude umoˇznovat propojen´ı s existuj´ıc´ım u ´ˇctem na Gitlabu. REQ-2: Vytvoˇrit issue Syst´em bude umoˇznovat vytvoˇren´ı issue. Issue bude synchronizov´ano s Gitlabem a to vˇcetnˇe ˇst´ıtk˚ u. REQ-3: Pˇriˇrazen´ı pracovn´ıkovi Syst´em bude umoˇzn ˇovat pˇriˇradit issue konkr´etn´ımu uˇzivateli. Pokud issue nebude nikomu pˇriˇrazeno, m˚ uˇze ho kdokoliv pˇriˇradit s´am sobˇe. Pˇriˇrazen´ı bude synchronizov´ano Gitlabem. REQ-4: Komentovat issue Syst´em bude umoˇzn ˇovat komentovat jednotliv´a issue. Koment´aˇre budou synchronizov´any s Gitlabem. REQ-5: Uzavˇr´ıt issue Syst´em bude umoˇznovat uzavˇr´ıt issue. Uzavˇren´ı issue bude synchronizov´ano s Gitlabem.
3.2
Kanban
REQ-6: Backlog Vˇsechna issue budou po vytvoˇren´ı pˇriˇrazena do backlogu. REQ-7: Odhad pomoc´ı story points Syst´em bude umoˇznovat pˇridat k issue odhad pomoc´ı story points. REQ-8: Vytvoˇren´ı iterace Syst´em bude umoˇznovat vytvoˇrit iteraci. Bude moˇzn´e nastavit d´elku iterace. 6/35
ˇ 3 POZADAVKY
REQ-9: Kanban Board Syst´em bude obsahovat kanban board. Na kanban boardu se budou zobrazovat issues z pr´avˇe prob´ıhaj´ıc´ı iterace. Pozice na kanban boardu bude urˇcovat stav issue. REQ-10: Pˇrijmut´ı/nepˇrijmut´ı Syst´em bude umoˇzn ˇovat pro issues nach´azej´ıc´ıch se v sekci done moˇznosti pˇrijmout nebo nepˇrijmout. Pokud bude zvoleno pˇrijmout, issue se uzavˇre a bude povaˇzov´ano za splnˇen´e. Pokud se nepˇrijme, uˇzivatel ho bude moci posunout na jinou pozici kanban boardu nebo vr´atit do backlogu. REQ-11: Druhy issue Syst´em bude umoˇzn ˇovat k issue pˇriˇradit druh. Druhy budou: feature, bug, (chore, release) REQ-12: Automatick´a tvorba iterace Syst´em bude umoˇzn ˇovat automatick´e vytvoˇren´ı iterace podle poˇrad´ı issues v backlogu. REQ-13: Pˇrid´an´ı issue do iterace Vedouc´ı pracovn´ık bude moci pˇriˇradit issue z backlogu do konkr´etn´ı iterace. REQ-14: Statistiky z kanban boardu Syst´em bude umoˇzn ˇovat zobrazit statistiku o pohybu issue na kanban boardu. Bude moˇzn´e zobrazit v jak´em ˇcasov´em intervalu a na jak´e pozici v kanban boardu se issue nach´azelo. REQ-15: Mapov´an´ı issue na poˇzadavek Syst´em bude umoˇzn ˇovat pˇriˇrad´ıt k issue konkr´etn´ı poˇzadavek, ke kter´emu se issue vztahuje. REQ-16: Pˇrid´an´ı nov´eho uˇzivatele Syst´em bude umoˇznovat osob´am s pr´avy administr´atora pˇr´ıd´an´ı nov´eho uˇzivatele. Pˇri pˇrid´av´an´ı se budou nastavovat uˇzivatelsk´a pr´ava (z´akazn´ık, zamˇestnanec, administr´ator). REQ-17: Smaz´an´ı uˇzivatele Syst´em bude umoˇznovat osob´am s pr´avy administr´atora smazat uˇzivatele.
3.3
F´ orum se z´ akazn´ıkem
Aplikace bude umoˇzn ˇovat zapojen´ı z´akazn´ıka prostˇrednictv´ım diskuzn´ıho f´ora, kter´e bude z´arovˇen ˇ slouˇzit ke spr´avˇe poˇzadavk˚ u. Tato sekce byla pˇrid´ana na z´akladˇe poˇzadavk˚ u 7/35
ˇ 3 POZADAVKY
vedouc´ıho pr´ace. REQ-18: Pˇrihl´aˇsen´ı pˇres Google Syst´em bude umoˇzn ˇovat pˇrihl´aˇsen´ı pˇres Google u ´ˇcet. Uˇzivatel bude pˇrihl´aˇsen jen tehdy, pokud bude jeho e-mail zaznamen´an v lok´aln´ı datab´azi. REQ-19: Pˇrid´an´ı poˇzadavku Syst´em bude umoˇznovat pˇridat poˇzadavky. Poˇzadavek bude obsahovat n´azev, popis, prioritu a identifik´ator osoby, kter´a poˇzadavek vytvoˇrila. REQ-20: Pˇripojen´ı souboru k poˇzadavku Syst´em bude umoˇznovat pˇridat k poˇzadavku obr´azky, pdf sobory a rar/zip archivy. REQ-21: Stav poˇzadavku Syst´em bude umoˇznovat pˇriˇrazen´ı a zmˇenu stavu k poˇzadavku. Aktu´aln´ı stav bude ovlivˇ novat barvu poˇzadavku. Stavy budou: nov´ y, rozpracovan´ y, k posouzen´ı, pˇrijat´ y, odm´ıtnut´ y, smazan´ y. REQ-22: Komentov´an´ı poˇzadavku Syst´em bude umoˇznovat komentovat jednotliv´e poˇzadavky i jednotliv´e koment´aˇre. Koment´aˇre budou m´ıt stromovou strukturu. REQ-23: Pˇripojen´ı souboru ke koment´aˇri Syst´em bude umoˇznovat pˇridat ke koment´aˇri obr´azky, pdf sobory a rar/zip archivy. REQ-24: Stav koment´aˇre Syst´em bude umoˇznovat ke koment´aˇri pˇriˇradit stav. Stavy budou vytvoˇren´ y, vyˇreˇsen´ y a neplatn´ y. REQ-25: Rozdˇelen´ı koment´aˇr˚ u Syst´em bude koment´aˇre rozdˇelovat do dvou sloupc˚ u podle stavu koment´aˇre. Neplatn´e a vyˇreˇsen´e koment´aˇre budou v samostatn´em sloupci a bude je moci zobrazit jen v´ yvoj´aˇr a administr´ator, ne z´akazn´ık.
3.4
V´ ykazy a statistiky
REQ-26: V´ ykaz hodin Syst´em bude umoˇznovat pˇridat k issue poˇcet hodin, kter´e pracovn´ık str´avil pˇri jeho plnˇen´ı. Na jednom issue m˚ uˇze pracovat v´ıce lid´ı. 8/35
ˇ 3 POZADAVKY
REQ-27: Statistika odpracovan´ ych hodin Syst´em bude umoˇznovat zobrazen´ı statistiky odpracovan´ ych hodin. Odpracovan´ y ˇcas bude moˇzno filtrovat podle pracovn´ıka a data. REQ-28: Staˇzen´ı v´ ykaz˚ u Syst´em bude umoˇzn ˇovat staˇzen´ı a vytisknut´ı v´ ykazu hodin. REQ-29: Burndown chart Syst´em bude zobrazovat burndownt chart pro jednotliv´e iterace i pro celkov´ y projekt.
9/35
4 PODOBNE´ PROJEKTY
4
Podobn´ e projekty
Aplikace pro ˇr´ızen´ı v´ yvoje software ˇcerpaj´ıc´ı z techniky Kanban jiˇz existuj´ı. C´ılem reˇserˇse je zjistit, jak existuj´ıc´ı aplikace vyhovuj´ı zadan´ ym poˇzadavk˚ um, pˇr´ıpadnˇe se inspirovat zaj´ımavou funkcionalitou.
4.1
Taiga
Taiga [12] je open source aplikace zamˇeˇren´a pˇredevˇs´ım na scrum. Umoˇzn ˇuje vytv´aˇret user stories a pˇriˇrazovat je do sprint˚ u. Kaˇzd´ y sprint m´a vlastn´ı taskboard, kde lze na ´ z´akladˇe user stories vytv´aˇret u ´koly. Ukoly m˚ uˇzeme posouvat po taskboardu, a t´ım mˇenit jejich stav. Taiga obsahuje i kanban board, ale od taskboardu se liˇs´ı jen t´ım, ˇze zobrazuje stavy user stories, ne stavy task˚ u. Aktivity prov´adˇen´e s user stories i tasky jsou zaznamen´av´any, vˇcetnˇe pohybu po kanban boardu. Aplikace umoˇzn ˇuje propojen´ı s Gitlabem, ale ne s jeho issue trackerem. Jedin´a funkcionalita je zmˇena stavu u ´kolu pomoc´ı zpr´avy pˇri commitu k´odu. Nedostatky • Zat´ım jen v beta verzi, doch´az´ı k chyb´am • Nelze propojit s issue trackerem na Gitlabu • Nepˇrehledn´e zobrazen´ı historie posun˚ u po kanban boardu • Nepodporuje vykazov´an´ı ˇcasu Pˇ rednosti • Orientace na SCRUM • Moˇznost mapovat u ´koly na user story • Konfiguravateln´e uˇzivatelsk´e role umoˇzn ˇuj´ıc´ı zapojen´ı z´akazn´ıka do projektu
4.2
Pivotal Tracker
Pivotal Tracker [13] je aplikace pro agiln´ı ˇr´ızen´ı v´ yvoje software. Umoˇzn ˇuje vkl´adat user stories a pˇrid´avat k nim odhad pomoc´ı story points, koment´aˇre, pracovn´ıka, ˇst´ıtky a chcecklist s pod´ ukoly. User stories jsou ˇrazena v backlogu. Poˇrad´ı v backlogu urˇcuje prioritu. Iterace jsou tvoˇreny automaticky na z´akladˇe poˇrad´ı v backlogu. Iteraci lze nastavit d´elka v poˇctu t´ ydn˚ u. Poˇcet user stories kter´e se pˇriˇrad´ı do iterace z´avis´ı na velocitˇe t´ ymu. User stories se pˇriˇrad´ı do iterace tak, aby se souˇcet jejich story points rovnal 10/35
4 PODOBNE´ PROJEKTY
velocitˇe. Na zaˇca´tku projektu mus´ıme velocitu odhadnout, pozdˇej´ı se vypoˇc´ıt´av´a automaticky jako pr˚ umˇer jedn´e aˇz ˇctyˇr pˇredchoz´ıch iterac´ı. V prob´ıhaj´ıc´ı iteraci m˚ uˇzeme postupnˇe mˇenit stav user story na started, finished a delivered. Pot´e m˚ uˇze b´ yt user story pˇrijmuto nebo odm´ıtnuto. Pˇri pˇrijmut´ı se uzavˇre, v pˇr´ıpadˇe odm´ıtnut´ı z˚ ustane v souˇcasn´e iteraci a m˚ uˇze b´ yt znovu zah´ajeno. Nedostatky • Nelze propojit s issue trackerem na Gitlabu • Nepodporuje vykazov´an´ı ˇcasu • Neobsahuje uˇzivatelskou roli pro z´akazn´ıka • Neobsahuje Kanban Board Pˇ rednosti • Automatick´e vytv´aˇren´ı iterace na z´akladˇe vypoˇc´ıtan´e velocity
4.3
LeanKit
LeanKit [14] je placen´a aplikace pro ˇr´ızen´ı projekt˚ u pomoc´ı metody Kanban. Umoˇzn ˇuje vytv´aˇret kartiˇcky s u ´koly a posouvat je po kanban boardech. Kartiˇcky s u ´koly mohou obsahovat vˇsechny potˇrebn´e informace a data jako odhadovan´ y zaˇc´atek a konec, prioritu, druh u ´kolu, sloˇzitost, zodpovˇedn´e pracovn´ıky, pod˚ ukoly, soubory a koment´aˇre. Kaˇzd´a kartiˇcka m´a historii proveden´ ych akc´ı, vˇcetnˇe posun˚ u po kanban boardu. U kaˇzd´eho sloupce m˚ uˇzeme omezit poˇcet kartiˇcek, kter´e se v nˇem m˚ uˇzou nach´azet. Sloupce mohou obsahovat podsloupce a mohou b´ yt ˇrazeny i pod sebou. D´ıky tomu m˚ uˇzeme napˇr´ıklad vizualizovat paraleln´ı pr´aci dvou t´ ym˚ u. Aplikace tak´e obsahuje pokroˇcil´e grafick´e n´astroje pro anal´ yzu proces˚ u. Nedostatky • Nelze propojit s issue trackerem na Gitlabu • Nepodporuje vykazov´an´ı ˇcasu • Neobsahuje uˇzivatelskou roli pro z´akazn´ıka • Vˇse se odehr´av´a na kanban boardech, backlog m˚ uˇzeme vytvoˇrit jen jako sloupec na kanban boardu, nelze vytvoˇrit spoleˇcn´ y backlog pro v´ıce kanban board˚ u 11/35
4 PODOBNE´ PROJEKTY
Pˇ rednosti • V´ yborn´e vizu´aln´ı proveden´ı • Moˇznost omezit poˇcet kartiˇcek ve sloupci • Moˇznost ke kaˇzd´emu sloupci pˇripsat procesn´ı politiku • Grafick´e n´astroje pro anal´ yzu proces˚ u • Velk´e mnoˇzstv´ı pˇripraven´ ych ˇsablon pro Kanban Boardy • Sloupce mohou obsahovat podsloupce a sloupce se mohou nach´azet i pod sebou
4.4
Trello
Trello [15] je aplikace pro organizov´an´ı pr´ace pomoc´ı kanban boardu. Nen´ı nijak zamˇeˇrena na v´ yvoj sotware. Umoˇzn ˇuje vytv´aˇret tabule a posouvat po n´ı u ´koly. Kartiˇcka s u ´kolem m˚ uˇze obsahovat pracovn´ıky, ˇst´ıtky, koment´aˇre, soubory, datum expirace a checklist s pod´ ukoly. Nedostatky • Nelze propojit s issue trackerem na Gitlabu • Nepodporuje vykazov´an´ı ˇcasu • Neobsahuje uˇzivatelskou roli pro z´akazn´ıka • Neumoˇzn ˇuje pˇridat ˇcasov´ y odhad • Vyuˇz´ıv´a jen kanban boardy, ˇza´dn´ y centr´aln´ı backlog Pˇ rednosti • Jednoduch´e a intuitivn´ı uˇzivatelsk´e rozhran´ı • Moˇznost vloˇzit obr´azek pˇr´ımo na kartiˇcku zobrazenou na Kanban Boardu
4.5
Shrnut´ı reˇserˇse
Tabulka 1 ukazuje, kter´e aplikace splˇ nuj´ı jak´e poˇzadavky. Terminologie se v aplikac´ıch liˇs´ı. Pˇri posuzov´an´ı splnˇen´ı poˇzadavku byl br´at v potaz u ´ˇcel a pouˇzitelnost funkˇ cionality, ne jej´ı pˇresn´ y n´azev. Z´adn´a z aplikac´ı neumoˇzn ˇuje propojen´ı s issue trackerem na Gitlabu. Poˇzadavky, kter´e jsou splnˇeny kromˇe sychnronizace s Gitlabem, jsou v tabulce povaˇzov´any za splnˇen´e. Vzhledem k tomu, ˇze ˇz´adn´a z nalezen´ ych aplikac´ı nepodporuje propojen´ı s issue trackerem na Gitlabu, je k uspokojen´ı poˇzadavk˚ u potˇreba vytvoˇrit novou aplikaci. 12/35
4 PODOBNE´ PROJEKTY
REQ-1: REQ-2: REQ-3: REQ-4: REQ-5: REQ-6: REQ-7: REQ-8: REQ-9: REQ-10: REQ-11: REQ-12: REQ-13: REQ-14: REQ-15: REQ-16: REQ-17: REQ-18: REQ-19: REQ-20: REQ-21: REQ-22: REQ-23: REQ-24: REQ-25: REQ-26: REQ-27: REQ-28: REQ-29:
Taiga 7 3 3 3 3 3 3 3 3 7 3 7 3 7 3 3 3 7 3 3 3 3 7 7 7 7 7 7 3
Trello 7 3 3 3 3 7 7 7 3 7 3 7 7 7 7 3 3 3 7 7 7 7 7 7 7 7 7 7 7
Pivotal Tracker 7 3 3 3 3 3 3 3 7 3 3 3 3 7 7 3 3 3 7 7 7 7 7 7 7 7 7 7 3
LeanKit 7 3 3 3 3 7 3 7 3 7 3 7 7 3 7 3 3 7 7 7 7 7 7 7 7 7 7 7 7
Tabulka 1: Pˇrehled podobn´ ych aplikac´ı a jejich vyhovov´an´ı poˇzadavk˚ um
13/35
´ 5 ANALYZA
5
Anal´ yza
C´ılem anal´ yzy je co nejl´epe pochopit zadan´ y projekt a definovat z´akladn´ı pojmy. Anal´ yza neˇr´ık´a nic o tom, jak m´a b´ yt poˇzadovan´ ych v´ ysledk˚ u dosaˇzeno.
5.1
Uˇ zivatelsk´ e role
Uˇzivatelsk´e role popisuj´ı uˇzivatele syst´emu a jejich pr´ava v aplikaci. Z´ akazn´ık Osoba, kter´a je zadavatelem projektu. Do aplikace m˚ uˇze vkl´adat poˇzadavky diskutovat o nich s v´ yvoj´aˇri. Z´akazn´ık nemus´ı m´ıt u ´ˇcet na Gitlabu. V´ yvoj´ aˇ r Osoba pracuj´ıc´ı na v´ yvoji projektu, kter´a m´a u ´ˇcet na Gitlabu. Uˇzivatelsk´a pr´ava u jednotliv´ ych projekt˚ u z´avis´ı na pr´avech pˇridˇelen´ ych na Gitlabu5 . Administr´ ator Osoba, kter´a m´a pr´avo pˇrid´avat do aplikace nov´e uˇzivatele. Mus´ı m´ıt u ´ˇcet na Gitlabu. Uˇzivatelsk´a pr´ava u jednotliv´ ych projekt˚ u z´avis´ı na pr´avech pˇridˇelen´ ych na Gitlabu.
5.2
Dom´ enov´ y model
Dom´enov´ y model popisuje z´akladn´ı entity, se kter´ ymi bude aplikace pracovat, a vztahy mezi nimy. Dom´enov´ y model je zobrazen na obr´azku 4. Osoba symbolizuje uˇzivatele aplikace. M˚ uˇze se jednat o v´ yvoj´aˇre, administr´atora nebo z´akazn´ıka. Poˇ zadavek popisuje, co m´a vytv´aˇren´ y produkt splˇ novat. M˚ uˇze ho vytv´aˇret z´akazn´ık i pracovn´ık. Moˇzn´e stavy a pˇrechody mezi nimi jsou vyj´adˇreny obr´azkem 5. Projekt seskupuje informace t´ ykaj´ıc´ı se jednoho konr´etn´ıho zad´an´ı. Issue symbolizuje u ´kol, kter´ y je potˇreba splnit. M˚ uˇze se jednat napˇr´ıklad o implementaci nov´e funkcionality nebo o opravu chyby. Sprint rozdˇeluje v´ yvoj do iterac´ı. Jedn´a se o ˇcasovˇe ohraniˇcen´ yu ´sek v r´amci kter´eho by mˇely b´ yt splnˇeny u ´koly, kter´e jsou do sprintu pˇriˇrazeny. Backlog shromaˇzd’uje issues, kter´e jeˇstˇe nebyly pˇriˇrazeny do ˇz´adn´eho sprintu. 5
https://gitlab.fel.cvut.cz/help/permissions/permissions.md - zde je po pˇrihl´aˇsen´ı dostupn´ a specifikace pˇr´ıstupov´ ych pr´ av r˚ uzn´ ych rol´ı na Gitlabu
14/35
´ 5 ANALYZA
KanbanBoard seskupuje sloupce a spojuje je s konkr´etn´ım sprintem. Pˇredstavuje kanban board, kter´ y je pops´an v kapitole 2.2. Sloupec je sloupec na kanban boardu. M˚ uˇze obsahovat issues v urˇcit´em poˇrad´ı. Odpracovan´ yˇ cas pˇredstavuje skuteˇcn´ y ˇcas, kter´ y osoba str´avila prac´ı na konkr´etn´ım issue. Gitlab pˇredstavuje issue tracker aplikace Gitlab pˇr´ıstupn´ y pˇres REST api. Pomoc´ı tohoto api bude prob´ıhat synchronizace.
5.3
Pˇr´ıpady uˇ zit´ı
Pˇr´ıpady uˇzit´ı ˇr´ıkaj´ı, kdo a jak´ ym zp˚ usobem bude moci syst´em pouˇz´ıvat. Zachycuj´ı akt´ery a ˇcinnosti, kter´e mouhou v syst´emu vykon´avat. Pˇr´ıpad uˇzit´ı vˇzdy zahajuje akt´er. Jedn´a se o dalˇs´ı zp˚ usob zaznamen´an´ı poˇzadavk˚ u zadavetele. Pˇr´ıpady uˇzit´ı tak´e ˇcasto slouˇz´ı jako podklad pro testov´an´ı. [8] 5.3.1
F´ orum se z´ akazn´ıkem
UC1: Vloˇzit poˇzadavek Uˇzivatel m˚ uˇze vloˇzit poˇzadavek. Poˇzadavek obsahuje n´azev, popis a prioritu. Vˇsechna pole jsou povinn´a. K poˇzadavku m˚ uˇze b´ yt tak´e nepovinnˇe pˇripojen obr´azek, pdf soubor nebo rar/zip archiv. UC2: Komentovat poˇzadavek Uˇzivatel m˚ uˇze k poˇzadavku pˇridat koment´aˇr. Koment´aˇr m˚ uˇze odpov´ıdat i na jin´ y koment´aˇr. Ke koment´aˇri m˚ uˇze b´ yt pˇripojen obr´azek, pdf soubor nebo rar/zip archiv. UC3: Zobrazit poˇzadavky Uˇzivatel m˚ uˇze prohl´ıˇzet n´ahledy poˇzadavk˚ u seˇrazen´e podle data vytvoˇren´ı. N´ahled poˇzadavku obsahuje n´azev, stav, prioritu, datum vytvoˇren´ı a jm´eno uˇzivatele, kter´ y poˇzadavek vytvoˇril. Poˇzadavky jsou barevnˇe odliˇseny podle stavu, ve kter´em se nach´az´ı. UC4: Filtrovat poˇzadavky podle stavu Uˇzivatel m˚ uˇze filtrovat zobrazen´e poˇzadavky podle jejich stavu. UC5: Zobrazit detail poˇzadavku Uˇzivatel m˚ uˇze zobrazit detail poˇzadavku. Detail obsahuje n´azev, popis, prioritu, stav, datum vytvoˇren´ı a jm´eno osoby, kter´a poˇzadavek vytvoˇrila. 15/35
´ 5 ANALYZA
Obr´azek 4: Dom´enov´ y model
16/35
´ 5 ANALYZA
Obr´azek 5: Stavov´ y diagram poˇzadavku
Obr´azek 6: Pˇr´ıpady uˇzit´ı - f´orum se z´akazn´ıkeml
17/35
´ 5 ANALYZA
Obr´azek 7: Pˇr´ıpady uˇzit´ı - issues
Obr´azek 8: Pˇr´ıpady uˇzit´ı - Kanban 18/35
´ 5 ANALYZA
Obr´azek 9: Pˇr´ıpady uˇzit´ı - v´ ykazy a administrace UC6: Zobrazit koment´aˇre Uˇzivatel m˚ uˇze zobrazit koment´aˇre. Koment´aˇre jsou zobrazeny ve vl´aknech. Lze tedy vidˇet, jestli koment´aˇr reaguje na jin´ y koment´aˇr, pˇr´ıpadnˇe na kter´ y. Koment´aˇre se rozdˇeluj´ı do dvou sekc´ı podle stavu. V jedn´e sekci jsou vytvoˇren´e koment´aˇre, ve druh´e jsou vyˇreˇsen´e a neplatn´e koment´aˇre. UC7: Editovat poˇzadavek Uˇzivatel m˚ uˇze editovat poˇzadavek. Lze zmˇenit n´azev, popis i prioritu. UC8: Zmˇenit stav poˇzadavku Uˇzivatel m˚ uˇze zmˇenit stav poˇzadavku. UC9: Zmˇenit stav koment´aˇre Uˇzivatel m˚ uˇze zmˇenit stav koment´aˇre na vyˇreˇsen´ y nebo neplatn´ y. UC10: Pˇrijmut´ı/odm´ıtnut´ı poˇzadavku Pokud se poˇzadavek nach´az´ı ve stavu dokonˇceno, uˇzivatel ho m˚ uˇze pˇrijmout nebo odm´ıtnout. UC11: Pˇrihl´aˇsen´ı pˇres Google u ´ˇcet Uˇzivatel se bude moci pˇrihl´asit pˇres Google u ´ˇcet.
5.3.2
Issues
UC12: Vloˇzit issue 19/35
´ 5 ANALYZA
Uˇzivatel m˚ uˇze vloˇzit issue, kter´e obsahuje n´azev, popis, story points, druh, zodpovˇednou osobu a poˇzadavek, ke kter´emu se issue vztahuje. N´azev je povinn´ y, ostatn´ı voliteln´e. Vytvoˇren´e issue se vloˇz´ı do backlogu. UC13: Editovat issue Uˇzivatel m˚ uˇze editovat issue. Editovat lze n´azev, popis, story points, zodpovˇednou osobu a souvisej´ıc´ı poˇzadavek. UC14: Prohl´ıˇzet issues Uˇzivatel m˚ uˇze prohl´ıˇzet n´ahledy issues seˇrazen´e podle data pˇrid´an´ı. N´ahled obsahuje n´azev, stav, story points, zodpovˇednou osobu a sprint, ve kter´em se issue nach´az´ı. UC15: Zmˇenit stav issue Uˇzivatel m˚ uˇze zmˇenit stav issue. Stavy jsou opened, closed, reopened. UC16: Prohl´ıˇzet detail issue Uˇzivatel m˚ uˇze zobrazit detail issue. Detail obsahuje n´azev, popis, story points, osobu, kter´a issue vytvoˇrila, ˇcas vytvoˇren´ı, stav, zodpovˇednou osobu, sprint a souvisej´ıc´ı poˇzadavek. UC17: Komentovat issue Uˇzivatel m˚ uˇze pˇridat koment´aˇr k issue. UC18: Prohl´ıˇzet koment´aˇre issue Uˇzivatel m˚ uˇze prohl´ıˇzet koment´aˇre issue. UC19: Pˇriˇradit issue pracovn´ıkovi Uˇzivatel m˚ uˇze issue pˇriˇradit sobˇe nebo jin´emu pracovn´ıkovi. UC20: Filtrovat issues podle stavu Uˇzivatel m˚ uˇze filtrovat issues podle jejich stavu. UC21: Propojit s Gitlabem Uˇzivatel m˚ uˇze vloˇzit pˇr´ıstupov´ y token z Gitlabu a URL adresu Gitlabu. Aplikace tedy lze propojit i s lok´alnˇe nasazen´ ym Gitlabem. 5.3.3
Kanban
UC22: Vytvoˇrit sprint Uˇzivatel m˚ uˇze vytvoˇrit sprint. Sprint obsahuje n´azev, popis a datum ukonˇcen´ı. 20/35
´ 5 ANALYZA
UC23: Pˇriˇradit issue do sprintu Issue lze pˇresovat mezi backlogem a sprinty. UC24: Vytvoˇrit sprint automaticky Uˇzivatel m˚ uˇze nechat sprint vytvoˇrit automaticky na z´akladˇe poˇrad´ı issues v backlogu. UC25: Posouvat issue po kanban boardu Issue lze posovat mezi sloupci na kanban boardu. UC26: Editovat kanban Kanban board umoˇzn ˇuje pˇrid´avat sloupce, mazat sloupce a mˇenit poˇrad´ı sloupc˚ u. 5.3.4
V´ ykazy a administrace
UC27: Vloˇzit nov´eho uˇzivatele Uˇzivatel m˚ uˇze do syst´emu pˇridat nov´eho uˇzivatele. UC28: Smazat uˇzivatele Uˇzivatel m˚ uˇze ze syst´emu vymazat jin´eho uˇzivatele. UC29: Vykazovat ˇcas Uˇzivatel m˚ uˇze k issue vyk´azat odpracovan´ y ˇcas. UC30: Zobrazit odpracovan´ y ˇcas Uˇzivatel m˚ uˇze zobrazit celkov´ y odpracovan´ y ˇcas u konkr´etn´ıho issue. Bude moci zobrazit i odpracovan´ y ˇcas jednotliv´ ych uˇzivatel˚ u u konkr´etn´ıho issue. UC31: Zobrazit burdnown chart Uˇzivatel m˚ uˇze zobrazit burndown chart pro jednotliv´e sprinty i pro cel´ y projekt. UC32: Zobrazit statistiky z kanban boardu Uˇzivatel m˚ uˇze u kaˇzd´eho issue zobrazit historii pohybu po kanban boardu. UC33: St´ahnout v´ ykazy Uˇzivatel m˚ uˇze st´ahnout v´ ykazy hodin. 5.3.5
Mapov´ an´ı pˇr´ıpad˚ u uˇ zit´ı na poˇ zadavky
Mapov´an´ım pˇr´ıpad˚ u uˇzit´ı na poˇzadavky ovˇeˇrujeme, jestli kaˇzd´emu poˇzadavku n´aleˇz´ı alespoˇ n jeden pˇr´ıpad uˇzit´ı. 21/35
´ 5 ANALYZA
REQ-18: REQ-19: REQ-20: REQ-21: REQ-22: REQ-23: REQ-24: REQ-25:
UC1: UC2: UC3: UC4: UC5: UC6: UC7: UC8: UC9: UC10: UC11: 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 Tabulka 2: Mapov´an´ı pˇr´ıpad˚ u uˇzit´ı na poˇzadavky 1
REQ-1: REQ-2: REQ-3: REQ-4: REQ-5: REQ-7: REQ-11: REQ-15:
UC12: UC13: UC14: UC15: UC16: UC17: UC18: UC19: UC20: UC21: 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 Tabulka 3: Mapov´an´ı pˇr´ıpad˚ u uˇzit´ı na poˇzadavky 2 UC22: REQ-6: REQ-8: REQ-9: REQ-10: REQ-12: REQ-13:
UC23: 3
UC24:
UC25:
UC26:
3 3
3 3
3
3 3
Tabulka 4: Mapov´an´ı pˇr´ıpad˚ u uˇzit´ı na poˇzadavky 3 UC27: REQ-14: REQ-16: REQ-17: REQ-26: REQ-27: REQ-28: REQ-29:
UC28:
UC29:
UC30:
3
3 3
UC31:
UC32: 3
3 3
3 3 Tabulka 5: Mapov´an´ı pˇr´ıpad˚ u uˇzit´ı na poˇzadavky 4
22/35
UC33:
´ 6 NAVRH
6
N´ avrh
Tato kapitola popisuje pouˇzit´e technologie a n´avrh datab´aze.
6.1
Pouˇ zit´ e technologie
Tato sekce popisuje z´asadn´ı technologie, kter´e budou vyuˇzity. 6.1.1
MEAN Stack
Mean stack je soubor technologi´ı (MongoDB, Express, AngularJS, Node.js) zaloˇzen´ ych na JavaScriptu, kter´e se pouˇz´ıvaj´ı k tvorbˇe webov´ ych aplikac´ı. Umoˇzn ˇuje tvoˇrit servery i klienty. Klient komunikuje se serverem pomoc´ı rest api. Mezi hlavn´ı pˇrednosti patˇr´ı rychlost, jednoduchost a testovatelnost. AngularJS Angular6 je MVC framework pro tvorbu webov´ ych aplikac´ı. V´ yraznˇe usnadˇ nuje pr´aci a tak´e podporuje vysokou modularitu a testovatelnost. Vzhled prezentaˇcn´ı vrstvy m˚ uˇzeme mˇenit pomoc´ı direktiv. Direktivy urˇcuj´ı, jak bude zach´azeno s modelem. Zapisujeme je jako atributy HTML znaˇcek. Pokud m´ame napˇr´ıklad model items a chceme poloˇzky vypsat do seznamu, pouˇzijeme direktivu ng-repeat.
< l i ng−r e p e a t =’ item i n items ’>{{ item }} l i> ul> Angular umoˇzn ˇuje i tvorbu uˇzivatelsk´ ych direktiv, coˇz zjednoduˇsuje znovupouˇzitelnost k´odu. Dalˇs´ı v´ yhodou angularu je two-way data binding7 . Two-way data binding zajiˇst’uje synchronizaci modelu a prezentaˇcn´ı vrstvy. Zmˇena modelu se tedy okamˇzitˇe projev´ı na obrazovce. Angular za n´as tak´e ˇreˇs´ı z´avislosti mezi jednotliv´ ymi komponenty pomoc´ı dependency injection.
Node.JS Node8 je prostˇred´ı, umoˇzn ˇuj´ıc´ı bˇeh JavaScriptu mimo webov´ y prohl´ıˇzeˇc, vyuˇz´ıvan´e zejm´ena pro bˇeh back-end server˚ u pro webov´e aplikace. Node bˇeˇz´ı vˇzdy jen ’ v jednom vl´aknˇe, soubˇeˇznost zajiˇst uje architektura ˇr´ızen´a ud´alostmi. Pokud vl´akno provede nˇejak´ y poˇzadavek (napˇr´ıklad dotaz do datab´aze), vl´akno se nezablokuje, ale m˚ uˇze vykon´avat nˇeco jin´eho. Pokud pˇrijde odpovˇed’ na n´aˇs poˇzadavek, vyvol´a se ud´alost a provede se k´od, kter´ y na ud´alost reaguje. Napˇr´ıklad z´ısk´an´ı uˇzivatele z datab´aze provedeme takto: 6
https://angularjs.org/ https://docs.angularjs.org/guide/databinding 8 https://nodejs.org/ 7
23/35
´ 6 NAVRH
User . FindById ( id , f u n c t i o n ( u s e r ) { // kod , k t e r y s e p r o v e d e po z i s k a n i u z i v a t e l e z d a t a b a z e }) Express Express9 je framework pro Node.js, umoˇzn ˇuj´ıc´ı tvorbu server˚ u pro webov´e a mobiln´ı aplikace.
MongoDB MongoDb10 je dokumentovˇe orientovan´a datab´aze. Jedn´a se o NoSQL datab´azi. Data se ukl´adaj´ı do dokument˚ u, kter´e jsou tˇr´ıdˇeny do kolekc´ı. Filozofie spoˇc´ıv´a v tom, ˇze data, kter´a spolu souvis´ı, jsou uloˇzena v jednom dokumentu a mˇela by odpov´ıdat poˇzadovan´ ym dotaz˚ um na datab´azi. Pˇri dotazu na datab´azi tedy obvykle vrac´ıme jen jeden dokument, coˇz je mnohem snaˇzˇs´ı a rychlejˇs´ı, neˇz v klasick´ ych SQL datab´az´ıch. 6.1.2
NPM
NPM je bal´ıˇckov´ y manaˇzer pro node.js a dalˇs´ı technologie. Umoˇzn ˇuje jednoduˇse stahovat pˇr´ıdavn´e moduly pro naˇs´ı aplikaci. Modul naistalujeme pˇr´ıkazem npm install nazevModulu. Z´avislosti na modulech m˚ uˇzeme zapsat do souboru package.json a pot´e naistalovat najednou pˇr´ıkazem npm install. 6.1.3
Bower
Bower je bal´ıˇckov´ y manaˇzer pro frontend aplikace. Funguje podobnˇe jako NPM. Pro instalaci modulu pouˇzijeme pˇr´ıkaz bower install nazevModulu. Z´avislosti m˚ uˇzeme ukl´adat do souboru bower.json. Bower bal´ıˇcky lze stahovat i pomoc´ı NMP. Bower jsem pouˇzil kv˚ uli oddˇelen´ı z´avislost´ı pro backend a frontend. 6.1.4
Gulp
Gulp je n´astroj pro automatizaci sestavovac´ıho procesu. Umoˇzn ˇuje spojovat k´od z v´ıce soubor˚ u do jednoho, minifikaci JavaScriptu, automatick´ y rebuild pˇri zmˇenˇe sledovan´eho souboru atd.
6.2
Datab´ aze
Datab´aze, jak je vidˇet na obr´azku 10, je jednoduˇsˇs´ı neˇz dom´enov´ y model. To je zp˚ usobeno t´ım, ˇze nˇekter´e tˇr´ıdy jsou ukl´ad´any pouze do datab´aze Gitlabu. Atributy s pˇredponou id pˇredstavuj´ı identifik´atory objekt˚ u na Gitlabu. Data, kter´a lze ukl´adat na 9 10
http://expressjs.com/ https://www.mongodb.org/
24/35
´ 6 NAVRH
Obr´azek 10: Model datab´aze Gitlab, jsou ukl´ad´ana na Gitlab. D´ıky tomu jsou u ´daje vloˇzen´e z m´e aplikace pˇr´ıstupn´e i na Gitlabu. Lok´aln´ı datab´aze pˇredstavuje rozˇsiˇruj´ıc´ı funkcionalitu. Hlavn´ı zmˇenou oproti dom´enov´emu modelu je to, ˇze chyb´ı tˇr´ıdy Projekt, Backlog a Sprint. Sprinty jsou ukl´ad´any na Gitlab jako milestones a v Backlogu se nach´az´ı vˇsechny issues, kter´e nejsou pˇriˇrazeny do ˇza´dn´eho milestone. Tyto tˇr´ıdy tedy nejsou potˇreba v lok´aln´ı datab´azi. Stejnˇe tak jsou u ´daje o projektech pˇreb´ır´any z Gitlabu. Pˇr´ısluˇsnost objekt˚ u ke konktr´etn´ımu projektu je zaznamen´ana atributem id project.
25/35
7 IMPLEMENTACE
7
Implementace
Tato kapitola popisuje nejd˚ uleˇzitˇejˇs´ı prvky aplikace a strukturu k´odu. K implementaci byly pouˇzity technologie popsan´e v kapitole 6.1.
7.1
Server
Server poskytuje REST API pro klientskou ˇca´st aplikace. Prob´ıh´a zde komunikace z Gitlabem a spojov´an´ı dat z lok´aln´ı datab´aze a Gitlabu. Klientsk´a aplikace je tak od Gitlabu odst´ınˇena. Ke komunikaci s Gitlab API jsem pouˇzil bal´ıˇcek node-gitlab11 , kter´ y dotazy maxim´alnˇe zjednoduˇsuje. Pro komunikaci s lok´aln´ı datab´az´ı jsem pouˇzil framework mogoose12 . Klient v kaˇzd´em dotazu mus´ı v hlaviˇcce poslat priv´atn´ı gitlab token a gitlab URL. Tyto u ´daje se na serveru pˇreˇctou z hlaviˇcky a s jejich pomoc´ı se vytvoˇr´ı gitlab klient. K´od je rozdˇelen na modely a routy. Modely urˇcuj´ı podobu objekt˚ u ukl´adan´ ych do datab´aze a specifikuj´ı metody, kter´e mohou s objektem manipulovat. Routy jsou metody, obsluhuj´ıc´ı konkr´etn´ı adresy REST API, maj´ı pˇr´ıstup k dat˚ um zaslan´ ym v ’ ’ poˇzadavku a zajiˇst uj´ı odesl´an´ı odpovˇedi. Routy tedy zajiˇst uj´ı zpracov´an´ı poˇzadavku, z´ısk´an´ı potˇrebn´ ych dat a odesl´an´ı odpovˇedi klientovi. Zde je seznam dalˇs´ıch modul˚ u, kter´e jsem v aplikaci pouˇzil: • bcrypt - obsahuje hash funkci, pouˇz´ıvanou k ˇsifrov´an´ı hesel. • body-parser - umoˇzn ˇuje automaticky ˇc´ıst JSON v POST dotazu. • jwt-simple - umoˇzn ˇuje vytv´aˇret a ovˇeˇrovat JWT (JSON Web Token). Pouˇz´ıv´a se pro autentizaci uˇzivatele.
7.2
Klient
K´od v klientsk´e aplikaci je rozdˇelen servisy, kontrolery a html str´anky. Servisy zajiˇst’uj´ı komunikaci se serverem prostˇrednictv´ım dotaz˚ u na REST API. Controlery ke komunikaci se serverem vyuˇz´ıvaj´ı tyto servisy. T´ım jsou odst´ınˇeny od konkr´etn´ı podoby dotazu na REST API, coˇz ulehˇcuje pˇr´ıpadn´e zmˇeny. Controlery zajiˇst’uj´ı v´ ymˇenu dat mezi serverem a zobrazen´ ymi str´ankami. Kaˇzd´e str´ance pˇr´ısluˇs´ı jeden kontroler. Existuje jeden glob´aln´ı kontroler, kter´ y zajiˇst’uje pˇrihlaˇsov´an´ı do aplikace a udrˇzuje u ´daje o pˇrihlaˇsen´em uˇzivateli. Pro tvorbu uˇzivatelsk´eho rozhran´ı jsem pouˇzil css framework Semantic-UI13 11
https://github.com/node-gitlab/node-gitlab http://mongoosejs.com/ 13 http://semantic-ui.com/ 12
26/35
7 IMPLEMENTACE
Obr´azek 11: Kanban Board
7.2.1
Kanban Board
ˇ ısla v lev´em Vzhled implementovan´eho kanban boardu je zobrazen na obr´azku 11. C´ horn´ım rohu sloupc˚ u pˇredstavuj´ı maxim´aln´ı poˇcet issues v dan´em sloupci. Sloupec Doing m´a kapacitu 2 a jiˇz v nˇem jsou dvˇe issues. Proto je ˇc´ıslo zobrazeno ˇcervenˇe. Do sloupce uˇz nelze pˇridat ˇza´dn´e dalˇs´ı issue, dokud se alespoˇ n jedno m´ısto neuvoln´ı. Kl´ıˇcek v lev´em horn´ım rohu sloupce Done znaˇc´ı, ˇze issue pˇresunuta do nˇej, se automaticky uzavˇrou na Gitlabu. V prav´em horn´ım rohu kaˇzd´eho issue se nach´az´ı story points. Pˇri implementaci kanban boardu jsem vyuˇzil bal´ıˇcek ui-sortable14 . Bal´ıˇcek umoˇzn ˇuje ˇradit poloˇzky v poli pomoc´ı drag & drop. Umoˇzn ˇuje i pˇresouvat poloˇzky mezi r˚ uzn´ ymi poli. To se pˇresnˇe hod´ı pro implementaci kanban boardu, kde je potˇreba ˇradit poloˇzky ve sloupc´ıch a pˇresouvat je mezi sloupci. Bˇehem prov´adˇen´ı drag & drop jsou vyvol´av´any ud´alosti, na kter´e lze reagovat v kontroleru. Vˇsechny vyvol´avan´e ud´alosti jsou posps´any v dokumentaci bal´ıˇcku. J´a jsem vyuˇzil ud´alosti start, update a stop. Pˇri obsluze ud´alosti start se zaznamen´a id posouvan´eho objektu. Pˇri obsluze update se vyhodnocuje, jestli po pˇresunut´ı issue nebude pˇrekroˇcena kapacita sloupce. Pokud by mˇela b´ yt pˇrekroˇcena, pˇresunut´ı se neprovede. Pˇri ud´alosti stop se proveden´e zmˇeny odeˇslou na server. 7.2.2
Backlog a Sprinty
Str´anka se sprinty je zachycena na obr´azku 12. Mezi backlogem a sprinty lze issues pˇresouvat pomoc´ı drag & drop. 14
https://github.com/angular-ui/ui-sortable
27/35
7 IMPLEMENTACE
Obr´azek 12: Sprints K implementaci jsem vyuˇzil modul ngDraggable 15 umoˇzn ˇuj´ıc´ı drag & drop. Elementy kter´e lze posouvat jsou oznaˇceny direktivou ng-drag=’true’ a elementy, do kter´ ych lze posouvan´e prvky vkl´adat jsou oznaˇceny direktivou ng-drop=’true’. Direktiva ngdrop-success=’onDropComplete($data,$event, m)’ registruje metodu, kter´a se zavol´a po dokonˇcen´ı drag & drop. K pˇresunu issues v modelu, dojde aˇz v t´eto metodˇe. Modul m´a nˇekolik nev´ yhod a to zejm´ena tu, ˇze drag & drop nelze nijak zak´azat, coˇz znemoˇzn ˇuje nastaven´ı pˇr´ıstupu pro r˚ uzn´e uˇzivatelsk´e role.
7.3
Nedostatky
Nejvˇetˇs´ım nedostatkem implementace je n´ızk´a u ´roveˇ n zabezpeˇcen´ı klienta i serveru. Uˇzivatelsk´e role jsou zajiˇstˇeny jen r˚ uzn´ ym pˇr´ıstupem k HTML element˚ um. Konkr´etn´ı URL adresy a RESP API uˇzivatelsk´e role nekontroluje.
15
https://github.com/fatlinesofcode/ngDraggable
28/35
8 TESTY
8
Testy
´ Ukol testov´an´ı je zjistit, do jak´e m´ıry v´ ysledek odpov´ıd´a poˇzadovan´emu zad´an´ı a objevit pˇr´ıpadn´e chyby.
8.1
Selenium testy
Selenium testy umoˇzn ˇuj´ı testovat uˇzivatelsk´e rozhran´ı, v´ ystupy na obrazovku a uˇzivatelsk´e vstupy. Umoˇzn ˇuj´ı automatizovat pr˚ uchod aplikac´ı, kter´ y m˚ uˇze b´ yt proveden i ruˇcnˇe. V pˇr´ıpadˇe testov´an´ı dynamick´ ych aplikac´ı maj´ı vˇsak Selenium testy jist´a omezen´ı. K zamˇeˇren´ı elementu je potˇreba ho jednoznaˇcnˇe identifikovat, coˇz lze prov´est nastaven´ım atributu id, nebo odkazov´an´ım na pozici v HTML dokumentu. V dynamick´em webu nˇekdy ovˇsem nelze urˇcit jednoznaˇcn´e id, ani pozice v dokumentu pˇredem a testov´an´ı je tak omezeno. Tak´e nelze otestovat drag & drop funkcionalitu. K vytvoˇren´ı testu jsem pouˇzil Selenium IDE16 . Jedn´a se o doplnˇek pro Firefox umoˇzn ˇuj´ıc´ı nahr´av´an´ı sekvence krok˚ u a vkl´ad´an´ı pˇr´ıkaz˚ u z kontextov´eho menu. Vytvoˇren´e testy lze ve Firefoxu rovnou spustit. Vytvoˇril jsem celkem 9 test˚ u ovˇeˇruj´ıc´ıch z´akladn´ı funkcionalitu a vˇsechny u ´spˇeˇsnˇe proˇsly, jak je vidˇet na obr´azku 13. Testy pro kanban board a pˇresov´an´ı issues mezi backlogem a sprinty se mi nepodaˇrilo vytvoˇrit z d˚ uvod˚ u omezen´ı Selenium IDE.
8.2
Akceptaˇ cn´ı testy
Akceptaˇcn´ı testy se prov´ad´ı po dokonˇcen´ı aplikace. Jejich u ´ˇcel je zhodnotit, jak byly naplnˇeny specifikovan´e poˇzadavky. Akceptaˇcn´ı testy jsem provedl ruˇcnˇe vzhledem k poˇzadavk˚ um a pˇr´ıpad˚ um uˇzit´ı. Poˇzadavky oznaˇcen´e v tabulce 6 hvˇezdiˇckou byly splnˇeny jen ˇca´steˇcnˇe. • REQ-22: koment´aˇre nemaj´ı stromovou strukturu • REQ-27: v´ ykazy nelze filtrovat • REQ-2: nen´ı iplementov´ano vkl´ad´an´ı ˇs´ıtk˚ u Poˇzadavky byly celkem splnˇeny na 70%17 Pˇr´ıpady uˇzit´ı oznaˇcen´e v tabulce 7 hvˇezdiˇckou byly splnˇeny jen ˇca´steˇcnˇe. • UC1: nelze vloˇzit soubor • UC2: nelze odpov´ıdat na jin´ y koment´aˇr 16
http://www.seleniumhq.org/projects/ide/ C´ asteˇcnˇe splnˇen´e poˇzadavky byly povaˇzov´any za splnˇen´e na 75%
17 ˇ
29/35
8 TESTY
Obr´azek 13: Selenium testy
30/35
8 TESTY
• UC6: koment´aˇre netvoˇr´ı vl´akna • UC30: nelze filtrovat podle uˇzivatele Pˇr´ıpady uˇzit´ı byly celkem splnˇeny na 80%18 . Vyˇsˇs´ıho ˇc´ısla bylo dosaˇzeno proto, ˇze pˇr´ıpady uˇzit´ı a poˇzadavky nejsou sv´az´any jedna ku jedn´e. Jeden poˇzadavek m˚ uˇze m´ıt nˇekolik pˇrpad˚ u uˇzit´ı, a proto se v´ ysledek liˇs´ı.
18 ˇ
C´ asteˇcnˇe splnˇen´e byly povaˇzov´ any za splnˇen´e na 75%
31/35
8 TESTY
Splnˇeno REQ-18: REQ-19: REQ-20: REQ-21: REQ-22: REQ-23: REQ-16: REQ-17: REQ-24: REQ-25: REQ-1: REQ-2: REQ-3: REQ-4: REQ-5: REQ-6: REQ-7: REQ-8: REQ-9: REQ-10: REQ-11: REQ-12: REQ-13: REQ-14: REQ-15: REQ-26: REQ-27: REQ-28: REQ-29: celkem
Nesplnˇeno 7
3 7 3 3* 7 3 7 3 3 3 3* 3 3 3 3 3 3 3 3 7 7 3 3 3 3 3*
21
7 7 8
Tabulka 6: Splnˇen´ı poˇzadavk˚ u
32/35
8 TESTY
UC1: UC2: UC3: UC4: UC5: UC6: UC7: UC8: UC9: UC10: UC11: UC12: UC13: UC14: UC15: UC16: UC17: UC18: UC19: UC20: UC21: UC22: UC23: UC24: UC25: UC26: UC27: UC28: UC29: UC30: UC31: UC32: UC33: celkem
Splnˇeno 3* 3* 3 3 3 3* 3 3 3 3
Nesplnˇeno
7 3 3 3 3 3 3 3 3 3 3 3 3 7 3 3 3 7 3 3* 7 3 28
7 5
Tabulka 7: Splnˇen´ı use cases
33/35
9 ZHODNOCEN´I
9
Zhodnocen´ı
Tato kapitola hodnot´ı v´ ysledky pr´ace, upozorˇ nuje na nˇekter´e nedostatky a navrhuje jejich budouc´ı ˇreˇsen´ı.
9.1
Souˇ casn´ e probl´ emy a n´ amˇ ety na zlepˇsen´ı
Pokud je zmˇenˇen milestone z Gitlabu, zmˇena se neprojev´ı na Kanban Boardu v m´e aplikaci. Gitlab API neumoˇzn ˇuje naˇc´ıtat issues pˇr´ısluˇs´ıc´ı do konkr´etn´ıho milestone. Issues mus´ı b´ yt naˇcteny vˇsechny. Nen´ı moˇzn´e tedy efektivnˇe zjistit, jestli issues na kanban ˇ sen´ım by mohla b´ boardu odpov´ıdaj´ı issues v pˇr´ısluˇsn´em milestone na Gitlabu. Reˇ yt asi jedinˇe u ´prava Gitlab API. Modul ngDraggable neumoˇzn ˇuje vypnut´ı drag & drop, coˇz znemoˇzn ˇuje zabr´anit nˇekter´ ym uˇzivatelsk´ ym rol´ım pˇresunu issues mezi sprinty a backlogem. Nejlepˇs´ım ˇreˇsen´ım by podle m´eho n´azoru bylo str´anku pˇredˇelat a pouˇz´ıt modul ui-sortable, kter´ y byl pouˇzit pro implementaci kanbanu. D´ıky tomu by mohla b´ yt implementov´ana i prioritizace issues v backlogu pomoc´ı poˇrad´ı. To by umoˇznilo i automatick´e tvoˇren´ı sprint˚ u na z´akladˇe poˇrad´ı v backlogu. V k´odu se nach´azej´ı nepouˇz´ıvan´e metody, pˇr´ıpadnˇe zakomentovan´e ˇca´sti k´odu, kter´e jsem nestihl odstranit. U nˇekter´ ych ˇca´st´ı k´odu by bylo vhodn´e pˇred dalˇs´ım postupem zv´aˇzit refactoring. Ve vykazov´an´ı ˇcasu a tvorbˇe sprintu chyb´ı komponenta k v´ ybˇeru data. V dobˇe v´ yvoje Semantic-ui nenab´ızel komponentu pro v´ ybˇer data. Pole je oznaˇceno typem date. Webov´ y prohl´ıˇzeˇc Chrome zobrazuje date picker automaticky, Firefox a Safari zat´ım ne. Bylo by dobr´e nˇejak´ y date picker zakomponovat pˇr´ımo do aplikace, pˇr´ıpadnˇe zjistit, jestli Firefox s Safari maj´ı v pl´anu podporu typu date.
9.2
Osobn´ı zhodnocen´ı
Aplikace splˇ nuje zhruba tˇri ˇctvrtiny specifikovan´ ych poˇzadavk˚ u. Vˇetˇsina nesplnˇen´ ych poˇzadavk˚ u ovˇsem nebyla pˇr´ıliˇs podstatn´a a nebyla nutn´a ke splnˇen´ı zad´an´ı pr´ace. D˚ uleˇzit´ ym faktorem, kter´ y ovlivnil kvalitu pr´ace je fakt, ˇze jsem na zaˇc´atku pr´ace neovl´adal ˇz´adnou z vyuˇz´ıvan´ ych technologi´ı, coˇz se rozhodnˇe projevilo na kvalitˇe k´odu. V pr˚ ubˇehu pr´ace jsem se st´ale uˇcil a zlepˇsoval, ale na refaktoring vˇetˇsinou nezb´ yval ˇcas. Pˇrestoˇze aplikace jeˇstˇe nen´ı dokonal´a, tak vzhledem k rozsahu poˇzadavk˚ u a v´ yˇse zm´ınˇen´ ym fakt˚ um, povaˇzuji v´ ysledek sv´e pr´ace za u ´spˇeˇsn´ y.
34/35
LITERATURA
Literatura c 2009-2015 [cit. [1] What is Kanban?. PETERSON, David. Kanban Blog [online]. 2015-04-12]. Dostupn´e z: http://kanbanblog.com/explained/ [2] ANDERSON, David J. Kanban: successful evolutionary change in your software business. Sequim, Wash: Blue Hole Press, 2010. ISBN 09-845-2140-2. c 2015 [cit. 2015-04-28]. Do[3] What is Kanban?. EVERYDAY KANBAN [online]. stupn´e z: http://www.everydaykanban.com/what-is-kanban/ c 2011-2013, 25.04.2013 [cit. 2015[4] JIT (Just-in-time). ManagementMania [online]. 04-21]. Dostupn´e z: https://managementmania.com/cs/just-in-time ˇ [5] KOTACKA, V´ıt. Kanban, lehk´ y u ´vod. SoftWare Samuraj [online]. 4.3.2014 [cit. 2015-04-21]. Dostupn´e z: http://www.sw-samuraj.cz/2014/03/ kanban-lehky-uvod.html ´ [6] JANAK, Jiˇr´ı. Issue Tracking Systems. Brno, 2009. Dostupn´e z: http://is.muni. cz/th/60778/fi_m/thesis.pdf. Diplomov´a pr´ace. Masarykova Univerzita. Vedouc´ı pr´ace RNDr. Jan Pavloviˇc. [7] Scrum Guides [online]. 2015 [cit. 2015-05-18]. Dostupn´e z: http://www. scrumguides.org/ [8] ARLOW, Jim a Ila NEUSTADT. UML 2 a unifikovan´y proces v´yvoje aplikac´ı: objektovˇe orientovan´a anal´yza a n´avrh prakticky. Vyd. 1. Brno: Computer Press, 2007, 567 s. ISBN 978-80-251-1503-9. [9] A physical Kanban board with a basic, three-step workflow [obr´azek]. Leanc 2014 [cit. 2015-04-23]. Dostupn´e z: http://leankit.com/kanban/ Kit [online]. kanban-board/ c 2009[10] Kanban-board-1 [obr´azek]. PETERSON, David. Kanban Blog [online]. 2015 [cit. 2015-04-13]. Dostupn´e z: http://kanbanblog.com/explained/ [11] GitLab [online]. 2015. [cit. 2015-04-23]. Dostupn´e z: https://about.gitlab.com/ [12] Taiga [online]. 2014. [cit. 2015-05-13]. Dostupn´e z: https://taiga.io/ [13] Pivotal Tracker [online]. 2015. [cit. 2015-05-14]. Dostupn´e z: http://www. pivotaltracker.com/ [14] LeanKit [online]. 2015. [cit. 2015-05-14]. Dostupn´e z: http://leankit.com/ [15] Trello [online]. 2015. [cit. 2015-05-14]. Dostupn´e z: https://trello.com/
35/35