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 2020/2021. 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 daného ročníku IVS a za vyučující Ing. Jaroslav Dytrych, Ph.D. (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). --------- Tím, že jsme si na začátku zvolili programovací jazyk Python, jsme si značně v určitých částech projektu zjednodušili práci a zefektivnili ji. Naopak volba technologie pro tvorbu GUI nebyla nejšťastnější volbou. Zvolili jsme si framework KivyMD. Špatnou volbou byla tato technologie z následujících důvodů: - nepříliš uživatelsky přátelská dokumentace technologie - jedná se o novější framework, tudíž je zatím velmi malé množství informací pro jeho použití - při tvorbě spustitelné aplikace bylo nutno vytvořit virtuální prostředí -> komplikace při tvorbě Makefile a instalátoru ---------- Návrhu jsme se věnovali opravdu jen velmi okrajově, protože jsme projekt dlouho podceňovali. Kvůli tomuto problému jsme při rozdělování úkolů na některé věci zapomněli nebo je rovněž podcenili. Také to úplně nepodpořilo týmovou morálku (i přes to, že jsme s řešením projektu začali poměrně brzy, jsme zbytečně dlouho netušili, jak bude náš výsledek přibližně vypadat). Lepší plánování by nám také usnadnilo práci, protože některé části projektu (např. testy) jsme takto museli několikrát přepracovávat. Řešení: Příště plánovat i zdánlivé triviálnosti (čím je tým větší, tím je úloha plánování zřejmě důležitější). Nebát se vypracovat konrétní návrhy na úkor času stráveného implementací (např. přesné chování funkcí, vzhled GUI, využít diagramy). ---------- 3. Nedostatečná motivace Na rozdíl od jiných předmětů, kde mě (a myslím, že i jiné členy týmu) motivoval zisk/ztráta bodů, zde jsem neměl žádný přímý postih za nedodržení deadlinu. Pokud nebylo na práci nic jiného, tak to nevadilo. Horší situace nastala ve chvíli, kdy si tento projekt začal konkurovat s jinými úkoly, protože jsem je často upřednostňoval. Řešení: Během počátečního plánování stanovit penalizaci za nedodržení termínu (např. ubrat procenta z celkového hodnocení projektu). ---------- Návrhy: 1. Dohodnúť si každotýždenne stretnutia na rovnaky deň a čas, aby si členovia týmu dokázali spraviť voľno a usporiadať podľa toho čas 2. Dohodnúť sa na začiatku, kto je presne leader tímu, pretože nie vždy si intuitívne zoberie niekto túto rolu. 3. Prepracovať plán, pretože zanedbaný plán dokáže neskutočne stažiť celý projekt ---------- 1) Sdílení vlastní práce s ostatními členy týmu Na první pohled se může tento bod jevit samozřejmě, ale po zkušenostech z projektu musím říct, že není. Na konci semestru jsem zjistil, že v podstatě neznám práci svých kolegů, ale jsem s ní pouze přibližně seznámen. Tento bod také vedl k tomu, že jsme do dokumentace zapomněli uvést část funkcionality, protože zmíněnou funkcionalitu vytvořil jeden člověk a dokumentaci tvořil někdo jiný. ---------- 3) Obličeje a osobní kontakt Je pravda, že tento bod je v podstatě důsledkem doby Covidu, ale myslím si, že je možné ho vztáhnout na každou dobu. V týmu jsme čtyři, ale v době, kdy tento text píšu, znám obličej pouze jednoho z kolegů a viděl jsem ho pouze jednou. Chtěl bych říct, že je důležité nepodcenit osobní kontakt. Pokud to je možné, co nejdříve se osobně sejít, nebo alespoň uspořádat videohovor. Kvůli Covidu může být osobní schůzka náročná. Ale i za normálních okolností nemusí být možná okamžitě. Ale když se lidé v týmu alespoň trochu poznají, může to spolupráci hodně pomoci. Řekl bych, že naše produktivita časem stoupala a z nemalé části tuto skutečnosti připisuji vzájemnému poznávání a prohlubování důvěry. ---------- 1. Na zacatku jsme se dohodli, ze nase komunikace bude probihat pres Discord, jenze jsme zaroven pouzivali i GitHub, kde pri pull requestech vznikaji dalsi debaty - pulku veci jsme resili na Discordu, druhou na GitHubu, bylo to obcas hodne na divoko. Reseni: na zacatku si stanovit pravidla pro komunikaci - pouze Discord nebo presne dane, jake oblasti se budou resit kde. Chce to urcite na zacatku trochu vic zapremyslet. ---------- 2. Nenastudovali sme si presne problematiku domeny, takze niektore veci sme mohli implementovat lepsie. ---------- - minimálna oponentúra v týme: oponentúra je vždy produktívna keď je odôvodnená ---------- Nabudúce viac rozložit termíny. Radšej viac termínov pre jendotlivé malé veci, ako menej veľkých. ---------- Používaní GITu přes rozšíření ve Visual Studio není úplně ideální. ---------- Rozdelenie vyvoju na podcasti ktore posobili "spravitelne" pre kazdeho clena tymu sa ukazalo byt dobrou taktikou. ---------- Nejprve projít teoreticky pak až programovat - třeba u GUI nejdříve vymyslet aplikaci tak aby byla co nejvíce uživatelsky přívětivá a až potom programovat ---------- - V budúcnosti by sme si isto detailnejšie prečítali zadanie aby sa nám nestalo že na nejaké veci zabudneme a naopak zbytočne by sme nerobili čo sa od nás nepožaduje. ---------- Komunikační kanály - nedodžovali jsme stanovené textové kanály v Discordu -> psali jsme všechno do General -> obtížně jsme dohledávali staré zprávy, popř. pokud někdo nebyl aktivní delší dobu, tak si musel přečíst zprávy, které se vůbec netýkaly jeho práce a až pak se dostal ke zprávám, které jsou pro něj důležité ---------- Co bych udělal lépe: 1) Probrat návrh kalkulačky do detailu, sepsat jej (nepodcenit to, ušetří to spoustu času) a měnit jej pouze ve výjimečných situacích se souhlasem všech - jasný návrh si "sám řekne co potřebuje" - návrh by měl být stabilní základ od kterého se všechno odvíji a dá se přes něj všechno měřit 2) Jakékoliv nejasnosti nebo vady v návrhu řešit s maximální prioritou 3) Zajistit, aby se každý aktivně zajímal o práci ostatních, aby mohl poskytnout feedback a pomoct, pokud by bylo třeba 4) Používat Trello, nebo ClickUp 5) Dělat meetingy častěji, ale hlavně na nich říkat to podstatné, nebát se na rovinu říct co je špatně (to se snadno řekne, ale k nedorozumění vždy dojde, a tak je třeba si důkladně promýšlet co ostatní říkají a co tím myslí) 6) Řešit problémy, neodkládat je na později ---------- Domluvené kanály pro komunikaci byly MS Teams a Messenger. MS Teams nikdo z nás nepoužívá každý den, nemáme je v telefonu a nevyskakují nám upozornění. Proto jsme veškerou písemnou komunikaci měli na Messengeru, který nemá možnost vláken a při více lidech se rychle zhoršuje přehlednost. Pro větší tým nebo v zaměstnání by bylo jistě výhodnější mít návyk zapnout MS Teams hned po příchodu a využívat vlákna pro různé problémy. Takto nám však Messenger umožňoval mnohem rychlejší reakci a domluvu. ---------- Jako technologie aplikace byl povužit React, NodeJS a Electron. Jako vývojové studio bylo použito VScode. Problémy nastaly při tvorbě profilování, kdy byl velký problém s STDIN, které nufugovalo správně v starších verzích node. Od tud plyne ponaučení, vždy používat nejnovejší vezi nástrojů, když vytváříme projekt. Další problém nastal při vyváření balíčků pro operační systémy, kdy ElectronBuilder naopak od profiligu fungoval správně jen v starších verzích nodeJS, ---------- Pro profiling naší aplikace jsme zvolili zabudované nástroje Visual Studia, jelikož nám přišlo smysluplné využít maximálně možnosti, které nám komplexní vývojové prostředí nabízí. Bohužel jsme posléze zjistili, že tyto nástroje nejsou ideální, výstup profilingu je těžko zobrazitelný a celé prostředí je dosti nepřehledné. V budoucnu bych rozhodně použila jiné nástroje pro profiling. ---------- Pro příště budeme vědět, či aspoň já si budu vědoma faktu, že i když může daný úkol vypadat hotově, tak právě on se bude dolazovat i v posledních fázích dokončování. ---------- Po vytvorení inštalačného balíku ho každý člen týmu otestoval na svojom počítači s pozitívnymi výsledkami. Pár dní pred odovzdaním projektu sme však našli problém. Knižnica používaná pre grafické rozhranie sa neinštalovala v rámci balíka. Každý z nás to totiž testoval s danou knižnicou už nainštalovanou, takže sme na to neprišli okamžite. Našťastie vedúca tímu si skúsila balík nainštalovať na čistom virtuálnom stroji. ---------- Největším problémem bylo dodržování stanovených termínů pro jednotlivé části a úkoly. Tento problém pravděpodobně nastal, protože jsme měli termíny pouze pro větší části projektu. Kdybychom měli stanovených více termínů i pro menší části, bylo by dříve vidět jestli někdo nestíhá nebo má s něčím problém. Také by to jednotlivé členy týmu donutilo pracovat více během semestru a ne jenom těsně před velkým termínem. ---------- Na projekt jsme zvolili programovací jazyk golang. Ten ale není podporován v nástroji Doxygen a oficiální nástroj pro generování dokumentace neumí vytvořit statickou dokumentaci. Museli jsme tedy řešit jak vygenerovat statickou dokumentaci ze zdrojového kódu. Také pro tento jazyk není úplně kompletní knihovna gtk. Takže v některých věcech byla implementace gui náročnější než musela být. Kdyby se jednalo o větší projekt, byly by tyto problémy ještě nepříjemnější. Bylo by tedy lepší kdybychom si zjistili o tomto jazyku a jeho nástrojích více, abychom se případně mohli rozhodnout ještě před začátkem, jestli se jedná o vhodný nástroj. ---------- Zatímco na knihovnu jsme měli vytvořenou sadu testů, na samotný produkt jsme si nestanovili žádné konkrétní testy, což v tomto případě mohla být jednotná sada příkladů, které kalkulačka musí spočítat. Tohle společně s mou implementační chybou způsobilo, že na kalkulačce nejdou zadávat záporná čísla a místo toho se vždy provede operace odčítání. ---------- Komunikace v týmu - Jako platformu jsme zvolili Discord a myslím že to byla dobrá volba - Na jednotlivé části jsme vytvořili kanály, takže orientace byla rychlá a vše bylo přehledné - Velké plus byla možnost kdykoliv uspořádat hovor a dohodnout se na čemkoli ---------- Nástroje - C# - MS Visual Studio - Pro C# parádní vývojové prostředí, na skoro vše (GUI, testy,...) je vytvořeno nějaké rozšíření, které práci ulehčuje - Na druhou stranu je to vcelku velké prostředí (spousta tlačítek, možností a i velikost není zrovna malá) a poměrně často má jinčí představu o úkonech než programátor (takže je často třeba řešit, co se změnilo a proč tady není to okno s debugem, které by tady mělo být) - VS mohu pro C# doporučit, chce to ale velké nervy a připravit se na to že ne vždy bude VS dělat to co chci a že na pomalejších strojích bude chvíli trvat, než se zapne VS, nebo zkompiluje a pustí kód ---------- Občas vázla trochu komunikace, protože nikdo z nás není natolik upřímný a "statečný", aby pokládal doplňující dotazy a na rovinu si řekl o pomoc. Většinou jsme si pomohli, až jsme na druhým cítili nějakou bezradnost. Bylo by tedy dobré víc pracovat na vzájemné komunikaci. ---------- Zvolením jazyka Python jsme si velmi ulehčili práci, ale za to zvolením Kivy pro grafické rozhraní nás stálo spousty hodin času a pár vypadaných vlasů na hlavě. ---------- Na začátku jsme plán jaksi splácali a řekli si, že při nejhorším budeme dělat všichni na všem. Bohužel až ke konci jsem zjistil, že tento přístup je k ničemu, protože nikdo se necítí být nucen k práci a všichni nechávají všechno na později. Měli jsme si vytvořit podrobnější plán, aby každý věděl, co má na starosti. ---------- 1. Problém: Slabšia kontrola vykonanej práce v tíme, kedy by mali ostatní členovia tímu viac zhodnotiť prácu jedinca a poskytnúť mu lepšiu spätnú väzbu k jeho práci. ---------- Dobrá je práce na instalátoru v průběhu projektu, instalátor se dá udělat i na nefunkční projekt, jde o spojování knihoven, tvoření exe atd... ---------- 3. problém: Podcenění projektu Příčina: Nejdřív jsme si mysleli, že projekt zvládneme vypracovat velice rychle, protože se nám kalkulačka zdála jednoduchá, ale překvapil nás rozsah ostatní práce(profiling, makefile...) Řešení: Lepší sezámení se s projektem hned po zadání ---------- Python a Pyqt5 bola pre nás dobrá voľba ktorú by som odporúčil aj ďalším ročníkom. ---------- Naším nedostatkem byla méně kvalitní uživatelská přívětivost, při které se uživatel nemusí dozvědět, že udělal chybu při zadávání složitějších výrazu do kalkulačky. Řešením by bylo věnovat více času návrhu a přemýšlením nad různými případy užití kalkulačky. ---------- Hlavný problém z môjho pohľadu bolo používanie jedného chatovacieho kanálu na všetko. Použili sme messenger od facebooku ako náš hlavný komunikačný kanál a z môjho pohľadu sa po pár týždnoch konnverzácia v tejto skupine veľmi nezprehladnila a bol v tom mierny chaos. Bolo ťažké spätne dohladať dôležité informácie napríklad o našich plánoch na konkrétny týždeň. ---------- FXRuby, grafická knihovna, kterou jsme používali, neměla na Debianu oficiální balíček - proto ji náš instalátor kompiloval a tím se výrazně prodloužila instalace. Řešením by bylo buď daný balíček vytvořit a udržovat, nebo zvolit jinou knihovnu. GitLab má na soukromých repozitářích omezené množství volných CI minut, což jsme na začátku nevěděli - dlouho jsme nemohli používat CI, i když samo o sobě bylo plně fukční. Vyřešili jsme to instalací GitLab Runneru na naše zařízení. ---------- Na prvních pár shcůzkách jsme si nezapisovali dohodnuté závěry, takže nastávaly nejasnosti v budoucnu. -> Bylo vyřešeno založením Google dokumentu, do kterého se zapisovalo během shcůzky. Na konci byly důležité body zapsány do GitHub wiki projektu. Příští projekt zapotřebí praktikovat něco podobného od začátku práce. ---------- Nahrávali jsme instalátor na Git -> Instalátor vytvářel jeden člověk, ale neuvědomili jsme si, že si Git bude zaznamenávat každou verzi instalátoru do historie, takže výsledná odevzdávaná kopie Gitu včetně historie neúměrně narostla na velikosti. Máme názornou ukázku, proč přesně se na Git opravdu nedávají generované soubory. ---------- Pro přehlednější spolupráci a přehled o stavu projektu jsme měli využít službu jako např. Trello. Na Messengeru/Discordu, které jsme zvolili pro komunikaci, se důležité informace rychle ztratily mezi méně podstatnými zprávami. ---------- Komunikace byla v zásadě dobrá, nicméně někteří členové neměli headset a tedy byla slyšet ozvěna, což dělalo komunikaci obtížnější. ---------- Niektoré veci neboli dostatočne otestované, čo spôsobovalo problémy v neskorších častiach projektu -> ZLEPŠENIE: vytvoriť komplexnejšie testy, aby odhalili čo najviac problémov v skorších fázach projektu ---------- Skupinová komunikace probíhala pouze technicky v rámci skupiny místo serveru - pouze jeden společný kanál, ze strachu o zaspamování ostatní členové raději používali přímé zprávy s tím koho potřebovali, ale pro ostatní teammates to vedlo k absenci přehledu o tom co se vlastně děje, jak moc se to děje a jestli není potřeba s něčím pomoct ---------- 4. Měli jsme lépe využít discord pro přehlednost jednotlivých úkolů. Například více místností, odškrtáváni toho co je hotovo. To by se nám potom nestalo, že zapomeneme na nápovědu a podobně. ---------- -Nástroj pro profiling: Zvolili jsme si nástroj z prostředí Visual Studio 2019. Tento nástroj by měl poskytovat mnoho typů profilingu, ale práce s ním byla problematická. Dávám to za vinu primárně tomu, že platforma .net 5 je nová, a tak tyto nástroje pro ni nejsou správně odladěné. Dalším problémem je, že nenabízí generování kvalitních výstupů. Příště bych se porozhlédl po jiných nástrojích pro profiling. ---------- Navrh na zlepsenie 2: Uzivatelske testy Druha vec co chybala nasmu projektu boli uzivatelske testy. Myslim ze by dost pomohli, hlavne pri vacsom projekte, najst vela chyb a pripadne aj navrhov na zlepsenie funkcionali a prace s programom. V nasom pripade sme mohli nas program poslat napr. rodinnym prislustnikom na otestovanie a navrhnutie zlepsenia. ---------- Progres v projektu Nemeli jsme zadne nastroje na sledovani prubehu prace, nikde se nepoznamenavalo co jsme jiz spravili a co zatim stale chybi. Pusobilo to zmateni, navic orientace v projektu zabirala potom hodne casu behem setkani. ---------- Na začátku se čekalo, kdo začne, a na konci jsme zase dodělávali projekty do jiných předmětů, takže pokud někdo nepotřeboval aktivitu od jiného člena, tak jsme se do toho nehrnuli - Dalo by se to nejspíš řešit tím, že jsme mohli udělat na začátku a v průběhu více práce a být více aktivní, aby se věci nemuseli dohánět a nemuseli jsme čekat na první impulz ---------- Myslím si, že by bylo dobré většinu úkolů dělat průběžně a nenechávat je až jako poslední, jmenovitě doxygen dokumentace a instalační balíček. Je myslím lepší mít jistotu, že to bude alespoň nějak fungovat a je mnohem snažší průběžně kontrolovat jestli se pár nových přidaných funkcí do dokumentace přidalo jak má, nebo přidání jedné závislosti do instalátoru, než muset řešit, že něco nefunguje a je potřeba celý koncept měnit jako poslední věc ve vývoji. Dokumentace by taky mohla průběžně pomoct lidem se orientovat ve zdrojových kódech při vývoji. ---------- Vyskytli sa u nás najmä na začiatku aj problémy s gitom, odovzdávali sme práce bez popisu toho čo sa v nich zmenilo alebo čo bolo pridané poprípade opravené, zabralo nám viac času zistiť kde nastala zmena a stratili sme čas, ktorý mohol byť venovaný práci. Do budúcna už viem, že tieto údaje sú dôležité nie len pre mňa ale aj pre mojich kolegov, ktorý na prácu chcu nadviazať. ---------- Další kámen úrazu byla dokumentace, když jsme na poslední chvíli zjistili, že doxygen nepodporuje generování dokumentace z typescriptu. Měli jsme se na začátku více obeznámit, s jakými nástroji budeme pracovat a jak je správně používat. ---------- Asi naším největším problémem byla zvolená cílová platforma. Předem jsme si neprověřili jak námi vybraný programovací jazyk pracuje na vybrané platformě (Ubuntu 20.04) -> problémy s javafx -> instaluje se samostatně (není obsažena v openjdk ale musí se doinstalovat openjfx). Řešením je tedy si předem zjistit jak vybrané jazyky fungují na cílové platformě. ---------- Ako ďalšie by som spomenul nedostatočnú komunikáciu. V prípade že sa niekomu vyskytol problém a po dostatočnom čase nebol schopný daný problém odstrániť, sa mal obráťiť na ostaných členov týmu, aby mohli spoločne vyriešiť problém a tým sa posunúť ďalej a nestagnovať a nezamlčať situáciu v akej sa aktuálne nachádzal, čo poškodzovalo celý priebeh projektu. ---------- Párové programování s pluginem Code With Me (v prostředí IntelliJ) se poměrně osvědčilo. Myslím, že setkat se osobně by byla lepší varianta, ale současná situace to zakazovala. ----------