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 2019/2020. 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). * Komunikačný kanál, ktorý sme si zvolili (Discord), bol zvolený vhodne, nakoľko poskytoval možnosť textových správ, hlasových hovorov, aj stremovania obrazovky čo sme vedeli využiť pri riešení problémov medzi sebou. Určite to bola dobrá voľba a využil by som ho znova * Nedodržiavali sme stanovené časy "scrumových" schôdzok (každý pracovný deň o 9:00, sme neskôr posunuli na 10:00), nakoľko každý z nás vynechal minimálne jednu schôdzku. Nakoľko ja som skôr osoba, ktorá dlho do noci pracuje a radšej sa ráno vyspím, tak mi robilo celkom problém vstať na 9 ráno a robiť niečo produktívne, preto by som do budúcna sprvil schôdzku skôr tak v rozmedzí 11:00-14:00 čo mi príde ako dostatočne veľké rozmedzie na nájdenie vhodného času pre všetkých ako aj možnosť robiť na projekte aj pred, aj po schôdzke. * Vedení týmu bylo možná našim největší problémem. V týmu nebyl stanoven žádný vedoucí, který by měl konečné slovo, či kontroloval termíny. Každý si svůj termín hlídal sám, nebo byl upozorněn kolegou, kterého mohl případně zbrzdit. Rovněž měl každý své slovo k práci. Vznikl tak například zmatek, zdali dělat komentáře česky nebo anglicky. Dále se objevil i problém s kódováním, který vedl k opakované opravě symbolu odmocniny. Do budoucna by bylo zajisté lepší zvolit vedoucího a lépe se dohodnout na zmíněných bodech. * Přes počáteční nedůvěru členů týmu se nakonec platforma Slack plně využila a velmi pomohla ke strukturovanější komunikaci. Snaha oddělit "formální" pracovní komunikaci od běžného chatu se až na vyjímky povedla. * Problém byl v tom že nebyly formálně stanoveny časy kdy musí být členové online a jejich zavedení by nejspíše pomohlo. * Byly zvoleny vhodné nástroje, jen jsme na začátku nepřidali soubor ".editorconfig" a pak se musela převážná část zdrojových kódů přeformátovat. Rovněž byl problém s tím, že jsme se nedohodli na tom, jak budeme sdílet příbuzné projekty (např. matematická knihovna a testy) a poté se v průběhu práce musela měnit struktura řešení ve Visual Studio. * Ako komunikacny kanal sme pouzivali Messenger (IM). Ziadne pravidla sme si nestanovili, to bol zrejme dovod, pre ktory sme komunikovali iba pri vyskytoch problemov, co by mozno nebol problem ak by spatna vazba na správu prisla obratom a nie (obcas) o niekolko dni * Pro komunikaci jsme používali discord, který nebyl vždy ideální. Když jsme chtěli dohledat staré zprávy, těžko se hledaly. * Na poslední chvíli jsme se museli rozhodnout neodevzdat verzi projektu pro platformu linux, protože jsme zvolili příliš nové verze knihovny QT, která ve virtuálním prostředí nainstalována nebyla. Tomuto šlo předejít, pokud bychom projekt ve virtálním prostředí zkoušeli včas. * Potešili nás hlavne niektoré Windows utility ktoré majú default exit code 1, ktoré samozrejme vždy ukončia MakeFile. * S tvorbou balíku sa čakalo až na dokončnenie projektu. - Pri tomto rozhodnutí sa nebral ohľad na to, že môžu vzniknúť rôznorodé problémy, z ktorých niektoré môžu mať hlboké korene - napr. zdieľaná knižnica potrebuje číslo verzie v názve. To spôsobilo, že keď už všetci považovali vývoj za hotový, tak zrazu bolo treba riešiť množstvo vecí. Riešenie: Použiť princípy Continuous Integration (periodická automatická výstavba balíka), alebo jednoducho robiť balík už od prvej (neodladenej) spustiteľnej verzie periodicky (manuálne). * Nejproblémovější se ukázal instalátor, který jsme měli řešit dříve a (když se vyskytly pak problémy) společně. Když se ukázalo, že zprovoznit jej je složitější, než se zdálo, bylo už poměrně pozdě. * Komunikace ze začátků probíhala bez problémů, volba Messengeru pro rychlou komunikaci k aktuálně řešeným problémům a Discord s místnostmi na řešení obecných problematik, například hlasování o vývojových prostředích, názvech proměnných či volbě samotného programovacího jazyka, byla dle mého názoru správná. * Ze začátku jsme nepoužívali github issues. Problémy/bugy jsme si psali pouze na Discord, díky čemu jsme na některé problémy zapomněli. * Nedostatečné pročtení zadání, přehlédnutí některých implementačních detailů (vhodnější by bylo sepsat jednotlivé úkoly na začátku projektu a označovat je za splněné a nedokončené). * Příště bych nepoužil TkInter v Pythonu, nebyli jsme s ním spokojeni a chová se na každé platformě velmi odlišně. Proto jsme si mezi OS navzájem rozbíjeli layout. * Někteří členové týmu nekomunikovali ze začátku vůbec, nebo později jen velmi málo. Pravidla ovšem stanovená byla. Nejspíš by pomohlo, kdybychom si na sebe vzali tel. číslo. Mohli bychom v extrémních případech zavolat. * Za největší problém považuji moji lenost, mé zadaní jsem vždy dělal jen dva, tři dny před termínem a nenechával si místo pro opravu případných chyb. Jako řešení bych viděl, určení vlastních detailnější a dřívějších termínu. * Další návrh by byl si přístě určit jak často máme kontrolovat komunikační prostředky. Zvláště ze začátku mi tak unikly některé diskuse. * Mělo proběhnout testování výsledků každého člena alespoň jedním dalším členem týmu. Tímto by se zvýšila celková kvalita produktu a vyhnuli bychom se zbytečným chybám. * Počáteční rozhodnutí při plánování nejspíš byla opravdu uskutečněna narychlo nebo byla méně promyšlena. Měli jsme se více zamyslet nad silnými stránkami jednotlivých řešitelů. Plánování je velmi důležitá součást vývoje softwaru. Nesmí být podceněna. Při tvorbě budoucího projektu se určitě mnohem více zaměřím na plánování a tvorbu specifikací. * Nedostatek komentářů na místech kde byly rozhodně potřeba pro potřeby peer review. Důsledkem toho byla nutnost dodatečné komunikace nebo prodlužování meetingů. Řešení: Ujasnit si už od začátku explicitní šablonu pro komunikaci skrze verzovací nástroje a zdrojový kód. * Ke komunikaci jsme používali platformu Discord, jelikož ji už všichni aktivně používáme a chtěli jsme tak minimalizovat šanci že si někdo něčeho nevšimne (Mimochodem se dá krásně integrovat s GitLabem pomocí WebHook bota a tak Vám příchází průběžné zprávy o tom co se děje na repu). Bohužel chyběla zásadní funkcionalita ověření přečtení zpráv, což vedlo k častým výmluvám "Sem si to přečetl až teď sorry". Nakonec jsme se dohodli povinně používat emote reakci na zprávu, příčemž tohle řešení je postavené na důvěře a nelze mu 100% věřit, ale alespoň autor zprávy ví s kým počítat. * S použitím GitFlow (https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow) a peer review měli v průběhu kolegové četné problémy, hlavně kvůli tomu že jim tyto metody připadaly občas jako zbytečně komplikované nebo zdlouhavé. Postupem se ale při řešení problémů přišlo na to že jsou to výhodné postupy a vřele je doporučuji ostatním i za cenu zvýšené režie. Tuto metodu už jsem sice používal, ale na oficiální název jsem narazil až z poznámek z minulých let, kde tuto možnost někdo dal jako něco co by se vyplatilo vyzkoušet. Potvrzuji že to i v menším počtu lidí vede k mnohem přehlednější a pohodlnější práci, nežli pokud by se pouze pushovalo do masteru. A historie projektu je také dle mého přehledněji vizualizovatelná. * Doporučuji se podívat na možnosti CI platformy kterou si zvolíte (Gitlab CI/CD, Github Actions) a využít zdarma dostupné prostředky k průběžnému testování commitů, i jednoduchý config ušetří neskutečně mnoho času a úsilí při peer review! * Vo všeobecnosti by som zhrnula, že väčšina našich problémov spočívala v nepozornom prečítaní zadania a nutnosti veľkých opráv pár hodín pred deadlinom. * Bylo nakonec opravdu dobře, že jsme si dávali termíny dopředu, protože večer před naším deadlinem, kdy měl mít jeden člen udělaný testy, nás dost nečekaně opustil i přes to, že odpoledne říkal, že vše stíhá... Žádná práce nebyla udělána a tak jsme to museli dohánět. Díky časové rezervě jsme to ale stihli poměrně v klidu. * Problémy byly s připojením se na Bitbucket v IDE. Já měl zobrazené jen modré okýnko a nikde nic. Až po tak třech hodinách googlovaní jsem zkusil pomale jet myší a ukázalo se pod kurzorem nápověda pro zadání údajů. Takže s tím bych chvíli problém, jinak nic. * Z mé iniciativy jsme se rozhodli pro použití .NET Core a aby mohla být aplikace multiplatformní, museli jsme použít GUI framework Avalonia, který jsem objevil spíš náhodou a neměl jsem s ním žádné zkušenosti. Bylo poznat, že tento framework není ještě zcela dotažený, musel jsem strávit nezanedbatelné množství času nad řešením různých drobností, myslím si ale, že výsledek je obstojný po stránce GUI i kódu. * Dalším problémem byl linker, který se mi podařilo zprovoznit až po napsání testů. Ve VS jsem nebyl schopný projekt zprovoznit, protože nefungoval linker s Google testy. Vše nakonec vyřešilo třídenní pátrání a nalezení řešení problému, které bylo: připsání do Cmake „set(gtest_force_shared_crt ON CACHE BOOL "" FORCE)“. * Jeden asi z najväčších problémov bola asi komunikácia. Hlavne vzhľadom k tomu, že ak mal niekto niečo na zodpovednosti, ale záviselo to aj od výsledku cudzej práce alebo od zmien ktoré vykonali iný, tak tieto zmeny/práca nebola odkomunikovaná. Napríklad z môjho pohľadu - mal som na starosti Makefile, čo bola jedna z prvých úloh nášho plánu. Preto som tam niektoré veci ešte nemohol zakomponovať, napr. niektoré závislosti ktoré som nepoznal. Po vytvorení relevantného zdrojového kódu mi nebola daná informácia aké závislosti treba do Makefile pridať. Alebo druhý príklad je pomenovanie projektu. Meno sa zmenilo bez toho aby sa updatol názov projektu v dokumentácií a podobne, a bez toho aby toto updatovanie dostal niekto na starosti. Následkom takýchto zmien je veľká šanca, že vznikne chyba ktorú si nikto nevšimne, lebo často po dokončení špecifickej časti sa na danú časť následne zabudne. Preto si myslím, že ak sa robí akákoľvek zmena ktorá ovplyvní už "uzavreté" časti projektu, alebo cudzie časti projektu, treba o tom jasne informovať a zaistiť, že všetky spätné zmeny budú vykonané. * U code review jsem někdy nevážil slova a vznikla z toho menší neschoda za kterou jsem se omluvil. Problém internetové komunikace je že se tam špatně rozlišuje záměr. Zjistil jsem že pokud požaduji nějakou změnu tak to musím podložit argumenty. Prosté "Tohle je špatně" nebo "Dělej to takto" nestačí. * Jira scrum board bola veľmi prehľadná a každý z členov mohol sledovať čo je už hotové a čo treba ešte spraviť. * Byl jsem vedoucí týmu. Svou roli hodnotím kladně. Osobně jsem měl problémy dělat vedoucího týmu lidí, se kterými jsem se nesetkal osobně. Měl jsem problém si udržet informace o členech pouze "pod přezdívkou na chattovací místnosti." Členové týmu byli pro mne částečně "anonymní," nevěděl jsem, na kolik se mohu na členy spolehnout. * Díky tomuto projektu jsem si uvědomil, jak důležité je, psát si důkladné zápisy z meetingů. Většinu zápisů z meetingů jsem dělal já a myslel jsem si, že jsou dostatečně důkladné. Bohužel jsem později zjistil, že nebyly. Možná to bylo i tím, že jsem je v pozdějším vývoji začal dělat trochu více stručné. Ke konci vývoje projektu jsme totiž zjistili, že jsme se nejspíš úplně neshodli. Pak vznikal zbytečný konflikt, kterému se dalo předejít, kdyby bylo vše řádně zdokumentováno. Možná by taky pomohlo, kdyby některý člen z týmu neměl zrovna hysterický záchvat. Což se určitě může stát i v reálném světě, takže se jednalo o hodnotnou lekci do budoucna. * S tím souvisí taky vhodně zvolený komunikační prostředek Slack. S jeho využíváním jsem byla naprosto spokojená, propojení s GitHubem bylo obrovskou výhodou, až mi občas vadí, že jej nemám propojený se všemi repozitáři, protože zvuk notifikací je naprosté pohlazení po uších. * Ako vzdialený repozitár sme použili gitlab, kde sme využívali merge requesty ako aj Milestones a Issue tickety. Z môjho pohľadu to fungovalo veľmi dobre s tým, že ak niekomu nebolo niečo jasné tak ako náhrada ústnej komunikácie sa používala služba Discord, kde sme si stanovili maximálnu dobu odpovede. * Not all of the team members had installed VSCode plugin which allows to use Editor Config, so sometimes we had different code styles in some files. * Při instalaci u zákazníka jsme se dozvěděli, že má aplikace umět zadávání pomocí klávesnice. Tuto funkci jsme chtěli zahrnout, ale postupem času se na ni zapomnělo. Při vývoji dalších aplikací budu budu myslet na to, že je třeba používat nějaký nástroj (ať už jenom sdílený Google Dokument) s jednotlivými TODO a chybami, na které narazíme. Tuto funkci by bylo snadné naimplementovat, ale prostě jsme na ní zapomněli. * Měl jsem své úkoly, které jsem plnil, i když někdy ne uplně v termínu, ale o větší rozhled v projektu jsem se moc nezajímal. Vnímám to jako promarněnou příležitost naučit se nové věci od zkušenějších spolužáků. * V týmu jsme si stanovili vlastni deadlines, jak je u mě zvykem, tak jsem je řešil pár dní před. U instalátoru se vyskytnul problém, s kterým jsem nakonec musel zaměstnat dalšího člena, což by se vyřešilo kdybych problém začal řešit dříve. Stanovení vlastních deadlines beru jako plus (za nedodržení každý den jsme se domluvili -5% bodů). * Kódování - několikrát se nám stalo, že jednotlivé znaky v souborech se přepsaly na neznámé znaky, zejména české měly problém, muselo se to opravovat, nahrávat nová verze na Git, vracet stará. Příšte použít editorConfig a nastavit stejné kódování. Příčinou bylo, že každý měl jinak nastavené kódování IDE. * Odporúčam stiahnuť visual studio code a v ňom LIVE SHARE. Tým pádom sme mohli viacerí písať naraz a vidieť kto čo robí. * Návrh: Při vývoji pro Ubuntu stále vše testovat na čistém Ubuntu poskytnutém na stránkách IVS. Na Gitlabu jsme sice měli nastavené CI, takže při každém merge requestu byla ověřena funkčnost. Ale na čistém Ubuntu například chyběl balíček, bez něhož nebylo možné zobrazit znak Unicode na klávesnici kalkulačky. * V prípade, že sa v rámci komunikačného kanálu riešilo niečo konkrétne (problém v kóde, návrh novej funkcionality), je vhodné to nejakým spôsobom označiť v histórii správ, aby sa ľahšie spätne dohľadávalo. Bez takýchto "značiek" som sa často strácal v správach.