Kodovani tohoto souboru: UTF-8

Tento soubor obsahuje výběr zajímavých částí ze souborů xloginNN_problemy.txt, které byly odevzdány v rámci 3. projektu 2017/2018. Jsou to užitečné informace o chybách, které jednotlivé týmy udělaly, a o navrhovaných vylepšeních. Tyto informace lze využít pro poučení do budoucích projektů. Vzhledem k tomu, že texty ukazují na problémy v týmech apod., výběr byl proveden tak, aby texty byly anonymní. Přeje-li si autor některého citovaného textu být jmenovitě uveden, může mě kontaktovat. Autory tohoto textu jsou tedy obecně všichni studenti těchto 2 ročníků IVS a za vyučující Ing. Jaroslav Dytrych (dytrych@fit.vutbr.cz), který text z vybraných příspěvků sestavil. V některých citovaných textech byla provedena korekce překlepů. Když se 1 problém vyskytoval vícekrát, což bylo časté, vybíral jsem z textů, které jej popisují, 1 - 3 (u důležitějších i více).

* Z mojej strany, projektu mohlo byť určite venované viac času, avšak kvôli rôznym okolnostiam ako napríklad nedostatok bodov z iného predmetu ma nútili presunúť čas k inému projektu. Uvedomoval som si ale, keďže išlo o týmový projekt, že sú na mojej práci a výkone závislí aj ostatní členovia a preto som sa projektu venoval aspoň tak, aby som nespôsobil kolegom problémy a splnil všetko čo sa odo mňa očakávalo. Avšak viem, že by to išlo naprogramovať lepšie, prehladnejšie, optimálnejšie.

* Určite by som zvýšil prehlad v akom stave sa daný projekt nachádza. Či už rôznym softwarom pre spoluprácu alebo väčším zapojením ostatných členov aj do časti projektu na ktorých realne nepracovali, ale myslím si že stálo by za to aby mali prehlaď, ktorá časť je v akom stave a na čom sa práve pracuje. Možno by vďaka tomu lepšie vedeli prispôsobiť svoju prácu, aj čo sa týka kompatibility ale aj čo sa týka budúcnosti. Mám na mysli, ak by som napríklad ja mal problém niečo v GUI urobiť, alebo mal nedostatok času a tak podobne, aby mohol na moju prácu môj kolega plynulo nadviazať a nemusel sa z danou časťou zoznamovať, ešte další dlhý čas. V tak malo týme o velkosti štyroch ludí si myslím že je to realizovatelné. Další bod, ktorý som mimochodom týmu navrhol ako reakciu na vedúceho ktorý požadoval aby sa členovia navzájom kontrolovali, navrhoval som aby na základe kalkulačky, tým pádom matematickej knižnici a GUI robili ludia vo dvojiciach. Tým som chcel odstrániť problém ktorý som spomenul vyššie s tým, že aspoň dvaja budú vedieť čo sa v každej časti robí a ako funguje a aby sa navzájom kontrolovali prípadne zlepšovali. Avšak môj návhr vtedy neprešiel, preto to prídávam raz a opäť do návrhov. Zároveň sme neboli na začiatku projektu schopný odhadnúť ktorá časť koľko času zaberie, preto som takto chcel udeliť funkčnosti kalkulačky prioritu.

* Ako komunikačný kanál sme najprv použili Facebook, kde sme sa skontaktovali a dohodli sa na začiatočných fázach projektu. Po čase sme sa zhodli, že facebook nie je najvhodnejší komunikačný kanál, a preto sme začali používat Discord, kde sme si vytvorili vlastný server a taktiež takzvané text channels pre jednotlivé úlohy projektu. Na Discorde sme si stanovili uričté pravidlá, ktoré mal každý dodržiavať. Zo začiatku to tak nebolo. Nie každý bol aktívny, ale po čase sa to zlepšilo.

* Pre zdieľanie dát sme používali git a hosting sme mali na GitHube. Vývojarské prostredie som používal NetBeans na linuxe, v ktorom sa mi pracovalo dobre. Pre vytvorenie grafického rozhrania som použil JAVA FX Scene Builder 2.0, v ktorom sa mi pracovalo tiež dobre nemal som s ničím problém. Taktiež sme používali MS Planner, v ktorom sme si vytvorili grafický návrh plánu. V MS Plannery sme mali priradené úlohy, ktoré sme si po ukončení mohli označiť ako dokončené.

* Co se týče komunikačních kanálů, tak jsme byli domluveni na Discord. Ten jsme ale prostupně opustili a přešli na Facebook, protože na Discordu jsme se kvůli přezdívkám nebyli schopni identifikovat. Na Facebooku má každý své jméno. Pokud by si každý dal na Discrod své pravé jméno, tak by to problém vyřešilo.

* Komunikace v týmu. Osobně pro mě na začátku byl drobný problém s jedním z komunikačních kanálů, co jsme zvolili, Facebookem. Nejsem zvyklý na sociální síte, a potřeboval jsem trochu času na to abych začal pravidelně sledovat zprávy na Facebooku a odpovidat kolegům včas.

* Nevím, jestli se jedná o problém, ale tým by bez řízení vedoucího, který stanovoval pravidla a tým doopravdy řídil, nefungoval.

* Osobně bych se asi příště pokusil si vše dopředu projednat, sjednat lepší a detailnější pravidla pro práci v týmu, aby se zamezilo konfliktům a jejich následným razantním řešením. A v případě konfliktů bych se příště více snažil být diplomatický, aby nedošlo k hádce v chatu, která zaspamovala chat, jako se nám v jednom bodu vývoje stalo.

* Ako komunikačný kanál sme použili Discord, kde sme si vytvorili vlastný server. Komunikácia spočiatku neprebiehala na Discorde, ale na Facebooku, čo bolo neefektívne. Neskôr sme sa však už presunuli úplne na Discord. Členovia boli dostatočne aktívny.

* Při komunikaci byl zvolen Facebook chat, nedá se říci, že by se tento způsob komunikace neosvědčil, ale do příštího projektu bych zvolil raději jinou službu s lepším archivováním historie. 

* Po předposlední schůzce bylo rozhodnuto z výsledného kalkulátoru odebrat funkci zpět a dopředu a byl ochuzen systém zakazování tlačítek, protože nebylo možné zajistit plnou funkčnost do odevzdání. 

* Nástroje prítomné vo VS pokladám za príliš komplexné pre začiatočníka v tejto oblasti a nami riešený problém. Z tohto dôvodu istú dobu trvalo, kým som bola schopná ich použiť. Narazila som ale na problém, že zo získaných dát som nebola schopná vyvodiť žiadne závery, pretože mi chýbal predovšetkým zoznam volaných funkcií a počet volaní. Som si istá, že problém nastal na mojej strane, ale ako začiatočník v práci s týmito nátrojmi som ho nebola schopná včas odstrániť.
Ako riešenie môjho problému som zvolila použitie iných nástrojov na profiling. Veľmi vhodnú alternatívu som našla v DotTrace od JetBrains. Výstup tohto nástroja pokladám za značne prehľadnejší a bez problémov som z neho získala všetky potrebné dáta.

* Na začátku nám trvalo velmi dlouho než jsme si určili vedoucího a rozdělili práci. Problémem byla neznalost ostatních členů týmu. Po nějaké době jsme se nějak domluvili a práce mohla začít, ale bylo zřejmé, že se nikomu příliž nechtělo udělat ten první krok. V příštím projektu by bylo dobré aby každý o sobě na začátku poskytl nějaké informace ohledně zkušeností s daným problémem, jazykem, vedením lidí... tohle jsme také nakonec udělali, ale trvalo nějakou dobu než jsme se k tomu dostali.

* Stalo sa nam, ze sme sa dohodli na urcitych chybovych stavoch u jednotlivych funkciach. Tie boli, neskor kvoli praktickejsiemu prepojeniu s grafickym prostredim zmenene a ja ako tester som o tom nebol informovany. Dozvedel som sa to na poslednu chvílu a uz sa nedalo nic ine urobit ako opravit testy. Pricina bola v chybe v komunikácii, kedy jednej strane proste nenapadlo, ze testy zrazu prestanu prechadzat. Chyba bola aj v nedodrzani TDD, kedy po prevedeni zmeny, program nebol otestovany.

* Počas vývoja projektu sme sa ako tím zišli 4x. Stretnutia, kde sme si zhodnotili doterajšiu prácu a spravili rozhodnutia o budúcnosti projektu. Jeden člen, sa 3x nezúčastnil, nereagoval na správy a nevykonával žiadnu prácu. Po poslednom stretnutí som sa teda rozhodol tohto člena z tímu neoficiálne vylúčiť, pretože sme sa nemohli spoľahnúť na to, že odvedie prácu, ktorá mu bola zadaná. Po tom, ako som mu to oznámil s tým, že jeho doteraz odvedená práca a jedna účasť na stretnutí bude pripočítaná v konečnom hodnotení, naraz problém s komunikáciou nebol a odpovedal hneď. Po nejakom čase premýšľania som si ale povedal, že ide o školský projekt a zapojil som ho späť do vývoja. Od tej doby už bol relatívne aktívny a nejakú-tú prácu aj odviedol. Z môjho pohľadu to bolo správne rozhodnutie a vykonal by som ho v tej situácii znova.

* Pro sdílení dat jsme používali GIT. Používali jsme systém "vše v jedné master branch", což nese veliký problém a to, když nějaký člen týmu svým commitem naprosto zničí celý repozitář. Tento problém se nám stal několikrát. Úzce se to váže k problému spolupráce. Nějaký člen, od něhož jiný člen potřebuje úpravu matematické knihovny zničí celý repozitář tak, že nahraje nefunkční verzi, ve které nefunguje build. Člen, který na úpravu knihovny čeká si tedy vezme patřičné úpravy a upraví knihovnu tak aby funguje - z důvodu toho, že musí urgentně udělat svoji práci - čímž poruší pravidlo rozvržené práce.
Možné řešení: Jasně říci jak se verzovací systém bude použít a toto jasně dodržovat.

* Více jsem se seznámil s VS a naučil se tvořit instalátory. Také jsem použil nástroj Resharper který mi pomohl s refaktorizací mého kódu.

* Dle meho nazoru byl nejvaznejsi problem naseho tymu hlavne ten, ze vetsina clenu nechodila na prednasky a  a v dobe psani projektu si jeste patricne znalosti nedoplnili. Tim jsem se dostaval do stresu, kdy jsem jim musel ve strucnosti vysvetlovat zaklady jako jak pracovat s GITem, ze se maji prepnout do jine vetve, pripadne si do sve vetve mergnout vetev jinou. Tento problem se ovsem objevil na posledni chvili pri dokoncovani projektu a znacne me prekvapil. 

* Dalsi velky problem, se kterym jsem se potykal byl, ze nekteri clenove necetli poradne zadani (respektive jej cetli jednou, mozna dvakrat) a pak pri implementaci jsem jim musel zakladni veci vysvetlovat i kdyz byly vysvetleny v zadani projektu. Tento pristup me (hlavne v hektickem zaveru projektu) znacne zpomaloval a odtrhaval od dalsich veci, ktere byly treba dodelat. Vedouci tymu (dle WISu) absolutne netusil podminky odevzdavani a o tom, ze se neco ma odevzdavat i do WISu se dozvedel ode me asi minutu pred deadlinem. O tom, jaka ma byt struktura archivu odevzdavana na IVS server take nevedel zrovna mnoho. 
Priciny: Hadam, ze dalsi aktivity ostatnich clenu tymu. Nenapada me jiny duvod. 
Mozna reseni: Prevest vedeni tymu dostatecne brzy na aktivnejsiho clena tymu, nechat si na odevzdavku vice casu i za cenu neodevzdani vice souboru.

* Nástroje na komunikáciu: Nástroje na komunikáciu boli zvolené vhodne, s ohľadom na rozsah a zložitosť projektu. K tejto etape nie sú žiadne výhrady, použité nástroje boli:
  1. Facebook - Komunikácia členov medzi sebou, kým sme sa dohodli na profesionálnejšom nástroji, ktorý by lepšie splňoval naše ciele.
  2. Freedcamp - Profesionálny nástroj na správu času a komunikáciu. Tento nástroj je jednoduchý na používanie a poskytuje pomerne veľké množstvo funkcií zadarmo(napríklad kalendár, možnosť ustanoviť si čiastočné ciele práce, pripomienky na email a množstvo ďalšieho).
  3. V prípade veľkých problémov s jednotlivými časťami projektu bolo usporiadaných niekoľko stretnutí, kde sa jednotlivý členovia tímu mohli vyjadriť k postupu a práci.

* Osobitnou súčasťou jazyka C++ je knižnica QT, ktorá slúži na vývoj grafického rozhrania. Rovnako ako celý jazyk, je táto knižnica vhodne zdokumentovaná avšak hlavným dôvodom výberu bolo to, že táto knižnica dokáže spraviť "natívne" zobrazenie všetkých svojich súčastí na rôznych systémoch. Nanešťastie je pomerne zložitá, pokiaľ sa nevyužíva IDE, alebo WYSIWYG systém(princíp spočíva v automatickom generovaní komponent, ktoré sú programátor umiestnené na nejakom už predpripravenom formulári). Pomerne dlho trvalo, kým sa ju podarilo naštudovať, nanešťastie toto prišlo až potom, čo museli byť mierne poupravené rôzne povinnosti jednotlivých členov. Po tom, čo došlo k výmene úloh, však konečne prišli aj žiadané výsledky. Avšak napriek všetkému si myslím, že sme mali použiť IDE a nie písať to všetko ručne. Práve toto bola ďalšia zo závažných chýb, ktoré nás stáli drahý čas

* Odchod clena tymu tesne pred deadlinom
  - nestihli sme veci ktore sme mali urobit
  - clen nebol moc aktivny uz od zaciatku => mohli sme to riesit skor
  - myslim ze sme nezvladli situaciu rozdelenia uloh odisleho clena teamu,  kazdy cakal kym niekto nieco spravi

* Podcenovanie (menej cenna) vykonanej prace ostatnych clenov
  - podcenovanie napr. dokumentace oproti backendu
  - myslim ze kazda praca je dolezita a netreba jej davat menejcennost

* Komunikovali sme výhradne cez Facebook, kde bol problém v tom, že nie vždy bol každý online. Mohli sme si aspoň dať tel. čísla pre rýchlejšie skontaktovanie.

* Každí člen tímu si splnil to, čo mal v pláne napísané. No na časti projektu, ktoré v pláne neboli ako je Makefile, alebo kto sa postará o doplnenie textových súborov(odovzdanie.txt, skutecnost...) sa zabudlo a boli vypracované v časovom deficite a nedostatočnej kvalite. Pred začiatkom práce na projekte, poriadne prečítať niekoľkokrát zadanie, rozplánovať úlohy dôkladne do posledného detailu a na nič nezabudnúť. 

* Nejzásadnějším problémem byla neaktivita všech členů týmu, kdy každý člen čekal na ostatní, až někdo začne tvořit.

* Samotná realizace projektu započala s několikatýdenním zpožděním rouzhoupáním ze strany vedoucího, čímž se následně nepodařilo projekt stihnout podle představ.

* Používali jsme facebook. Za sebe musím říct, že to byla dost špatná zkušenost. Pokud se přípěvky neoznačí nějakým tagem, tak je v tom za chvíli velký chaos a je hrozně těžké a nepříjemné cokoliv dohledávat. Největší katastrofa u facebooku je chat. Dohledat v něm cokoliv, ať už textový příspěvek nebo soubor, je téměř nadlidský úkol. Zvlášť v případě, že je potřeba něco najít rychle.