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 2018/2019. 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). --- --- Ja ako vedúci som sa snažil tlačiť na dodržiavanie určitých pravidiel pri tímovej práci, avšak niektorí členovia skutočne nedbali na akúkoľvek potreby komunikácie. To spôsobilo veľa nedorozumení a tento fakt značne brzdil našu prácu. Problém by sa dal čiastočne eliminovať napríklad formou interaktívnych ankiet alebo časovým ohraničením práva na vyjadrenie. Po tomto čase by sa brala do úvahy väčšinová odpoveď od tímu, ktorý sa stihol vyjadriť. --- * Náš tým fungoval spíše na vzájemné domluvě, vůdčí postava u nás nebyla a z toho plynuly určité problémy. * Možné řešení: Vůdce by našemu týmu rozhodně pomohl, upozornil by na termíny, které jsme podcenili, donutil by nás začít dřív, než když už bylo pomalu pozdě. --- Největším nedostatkem naší týmové spolupráce byla nedostatečná komunikace. Domluvili jsme se, že naším komunikačním kanálem bude skupinový chat na Facebooku v domnění, že na Facebooku (Messengeru) jsme přece všichni skoro pořád. Avšak ze čtyř členů jsme byli v chatu aktivní pouze dva. I když nevěřím, že by další dva členové navštěvovali Facebook dvakrát do týdne – spíš si myslím, že se jim nechtělo čelit povinnosti (tvorbě projektu). Projekt hodnotím jako velmi přínosný, ačkoli se jednalo o zdánlivě triviální projekt, jeho komplexnost nakonec tolik jednoduchá nebyla. --- 1. Vytvořené úkoly Při tvorbě úkolů sme nehleděli na relace mezi nimi a posloupnost, v jaké by se měli řešit. Pár kŕat se nám stalo, že jednen úkol blokoval vytvoření druhého nebo jeho dokončení. Návrh řešení: Analyzovat možné závislosti, vymezit více času tvorbě úkolů, posunout termíny dokončení blokovacích úkolů na dříve. 2. Brát na vědomí svátky, termíny u ostatních předmětů, možná onemocnení... Posunovali se termíny dokončení jednotlivých úkolů kvůli svátkům nebo pracím na jiných předmětech, což mělo za důsledek nahromadění práce u konci vývoje. Návrh řešení: Vymezit dostatečný čas na vypracování, využívat mezer v semestru (když má student pár dní volno), zvolit deadline, který nekoliduje s jinými odpovědnostmi studenta 3. Nekonzistence konvencí Každý byl zvyklý psát kód podle jazyka, ve kterém se angažoval v minulosti. Jelikož každý jazyk má konvence víceméně jiné, kód se stával nejednotným. Od názvu metod, proměnných po rozdělení kódu mezi třídami nebo složkovým roztřídením souborů/tříd. Návrh řešení: Stanovit si normy na začátku projektu, zjistit konvence jazyka, ve kterém pracujeme. --- Odkladanie práce po dobrom štarte (syndrom 90% hotovo, aj keď v našom prípade skôr 50) - ilúzia náskoku pred termínami - treba makať pravidelne podľa plánu --- Nedostat se do situace, kdy celý projekt vysí na práci jednoho jedinci. -Vyvarovat se nepostradatelným členům týmu, neboť to dělá celek zranitelný --- Spolupráca v tíme bola na prvý pohľad bezproblémová. Každý člen robil to čo mal. Keď si niekto nebol s niečím istý, obrátil sa na zvyšok týmu a spoločne sme problém vyriešili. Problém nastal až v prístupe k práci ostatných členov týmu. Blížil sa deadline projektu a o stave dôležitého inštalátoru sme nič nevedeli. Člen tímu zodpovedný za vytvorenie inštalátoru sa neozýval, ostatní členovia usúdili, že s ničím nemá problém. Tento prístup sa nám vypomstil a inštalátor sme boli nútení dokončiť len pár hodín pred odovzdaním projektu. Toto správanie som pozoroval najmä na sebe, preto si z tohto projektu beriem ponaučenie. Ide predsa o tímový projekt, preto by malo byť v mojom najlepšom záujme ako bude výsledný produkt vyzerať a to aj v prípade, že konkrétnu úlohu nemám vypracovať ja. Ako náš hlavný komunikačný kanál sme zvolili instant messaging, konkrétne skupinu na Facebook-u. Viedol nás k tomu fakt, že všetci členovia tímu sú s Facebookom oboznámení a trávia na ňom najviac času so všetkých dostupných komunikačných kanálov. Komunikácia cez Facebook je síce rýchla a pohodlná, no dôležité informácie sa v nej veľmi ľahko strácajú a naopak ťažko spätne vyhľadávajú. Riešením by bolo využitie iného komunikačného kanálu, ktorý podporuje lepšie štrukturovanie informácií (pin-ovanie správ) ako napríklad Discord, alebo ideálne Slack. --- S inštaláciou sme mali malý problém a to taký, že chalan čo to mal na starosti nevedel nájsť tú aplikáciu kam sa nainštalovala keď sa ho na to cvičiaci spýtal. Mal si to doma lepšie odskúšať. --- - Vadila mi neochota některých členů přistoupit na kompromis a dohodnout se. Diskuze pak vypadala tak, že kdo déle obhajoval svůj postoj, ten vyhrál. --- 2. Komunikácia: Občas prebiehala komunikácia iba medzi vedúcim a 1 členom týmu, ktorá nebola podstatná pre zvyšok týmu a na komunikačnom kanále to vytváralo spam, v ktorom sa mohli stratiť dôležité informácie --- Komtrola chyb: V odevzdaném řešní zůstalo hodně chyb, protože jsme dostatečně nekotrolovali naši práci. (Částečně plyne z nedodržování termínů.) Navrhované řešní: Na konci provést systematickou revizi, zda je opravdu všechno vpořádku a připraveno k odevzdání. Nejlépe zvolit vždy někoho kdo bude kontrolovat daný úkol. --- Co ovšem byl problém, byl "obsah" komunikace. Měli jsme každý přidělené své úkoly a každý jsme řešili hlavně to své. Vývoj probíhal tak trochu jako puzzle, každý vytvořil nějaké části, které se poté měly dát dohromady a najednou se zjistilo, že to nejde tak hladce jak se očekávalo. Osobně jsem při práci na gui narazil na problém, kdy matematická knihovna vracela něco jiného než jsem čekal a musel jsem část svého kodu přepsat. Příčiny: Pracovali jsme jako 4 individuální jedinci (případně ve dvojicích), než jako opravdový team. --- Někteří členové týmu začali pracovat až po tom co byli informování, že jejich část neodevzdali v daném termínu. Dopad na celkové dokončení nebyl nijak výrazný, protože jsme měli naplánované termíny s dostatečnou rezervou. ŘEŠENÍ: Zajímat se o postup práce ostatních. Ne až ve chvíli kdy jsme pozadu oproti plánu. Používali jsme dva komunikační kanály, Discord a Facebook, což vedlo k nižší přehlednosti. ŘEŠENÍ: Mnohem lepší by bylo, kdybychom vytvořili pouze jeden komunikační kanál. Informace by byly k nalezení na jednom místě. --- Na začiatku sme mali problém s git klientom SourceTree, ktorý využívali niektorí členovia tímu, postupne sme všetci prešli na git nástroj vstavaný do Visual Studia. --- 3. Komunikacia - Slack Ako primarny komunikacny kanal pre projekt sme si stanovili Slack. A facebook mal sluzit iba na dohadovanie stretnuti a komunikaciu ktora sa priamo nevztahuje k projektu. No nakoniec sme svetci komunikovali cez facebook skupinu a na Slacku bolo iba cca 10 sprav. Komunikacia sa potom velmi zle spatne dohladavala ale nastastie to nemalo na fungovanie teamu tak velky dopad pretoze sme facebook aspon pravidelne kontrolovali a boli aktivny. Riesenie: Nepouzivat facebook ako komunikacny kanal, pripadne ak sa nieco riesilo na facebooku jeden z clenov moze napisat nejaku sumarizaciu kominikacie na Slack --- 1) Najväčším problémom bolo pravdepodopne neodhadnutie času, ktorý bol potrebný pre jednotlivé problémy. Najviac času sme vyčlenili na naprogramovanie GUI a matematickej knižnice, čo sme zvládli celkom rýchlo ale ďalšie veci ako testy, dokumentácie, oprava chýb a inštalátor. Preto naše pracovné vyťaženie bolo na začiatku pomerne mierne ale ako sa blížil termín odovzdania, tak sme museli zabrať oveľa viac. Do budúcnosti by bolo určite dobré lepšie si rozvrhnúť termíny a nechať si viac času na "drobnosti". --- Problém 3 : PyCharm - Na vývoj programu som používal IDE PyCharm a osobne s ním niesom veľmi spokojný, je to veľmi hardvérovo namáhavé IDE, čo je dosť problém pre môj relatívne nevýkonný laptop a nemyslím si že jeho výhody sú dosť dobré na to aby vyvážili tie požiadavky, v budúcnosti by som pozeral po iných alternatívach. --- 1. plan: Nejvetsim problemem byl nas plan, ktery realne nedaval smysl. To bylo dle meho nazoru zpusobeno absenci zkusenosti s planovanim projektu. Napr. uzivatelska prirucka vznikla drive nez GUI. To nam zpusobilo prolem: po vytvoreni GUI jsme zjistili, ze ovladani neodpovida popisu v uzivatelske prirucce, ktera ale uz byla vytvorena. Resenim bylo prirucku zmenit, protoze to bylo snazsi, nez predelavat GUI. --- Moje rada, kterou bych dal týmům, které budou dělat projekt v budoucnu by zněla asi tak, že by se měli řídit podle nejméně zkušených členů jejich týmů a jejich znalostí různých jazyků, jelikož zkušenější programátor se snáze přeorientuje na jiný jazyk než nezkušený programátor. Ke komunikaci v týmu jsme použivali nástroj Slack, který je dostupný například v internetovém prohlížeči a tudíž jak na systémech Windows, tak na systémech Linux, tento nástroj mohu pouze doporučit, je velmi přehledný a díky němu byla naše komunikace rychlá a jasná. Mým osobním problémem na začátku projektu bylo zvyknout si na to, že se každý den, když přijdu ze školy nebo se probudím a zapnu počítač, mám podívat na slack a na github, vyzvedávat si pravidelně několikrát za den osobní poštu od ostatních členů týmu a pročítat zprávy ke commitům od ostatních členů. Nakonec jsem byl v týmu jediný, kdo předtím ještě nepracoval s githubem, takže mi na začátku trvalo delší dobu udělat i jenom jeden commit, naštěstí měl se mnou vedoucí týmu na začátku trpělivost a s nasazením mi odpovídal na mé dotazy. --- 3) Návrh na zlepšení: Pokud někdo z členů narazí na problém, který se mu nedaří překonat, měl by to dát najevo co nejdříve. --- Dôležitým poznatkom z tohto projektu je tiež že začať trvá naozaj najdhlšie, preto treba začať čo najskôr, aby sa potom mohlo iba ďalej robiť na konkrétnej veci. --- Hlavní body (z části nám chyběly) --------------------------------- * návrh, návrh, návrh i u trivialit, které zdánlivě nepotřebují návrh * osobní konzultace před psaním, brainstorming v týmu a mít přitom zábavu * angažovanost v týmu, hledat řešení na vlastní úlohu a konzultovat * vyzkoušet nové nástroje a technologie * vybrat vhodné nástroje s vhodnou abstrakcí * dohodnout se na pravidlech a projít je s týmem * zadefinovat si tresty, tvrdé sankce při neplnění * vhodně a spravedlivě rozdělit práci * reálný plán, počítající se zkouškami * dodržovat deadlines za každou cenu (k čemu plán, když se nebude dodržovat?) Pravidla -------- Jako jeden z prvních komitů (již 6. února) byl právě CODING_STANDARD, který nakonec činil 221 řádků. Poté byl zhotoven sdílený dokument s dalšími pravidly jako komunikace v týmu, nástroje, git workflow, atd. Často se stávalo, že členové v týmu nerozumněli některým pravidlům. Někdy se člen ani často nepřiznal a vyhýbal se takto pravidlům, nebo pravidla prostě neplnil a očekával, že je druzí na to upozorní nebo mu to prostě opraví. Příště pravidla dělat s týmem, nebo je aspoň projít __opravdu__ pravidlo po pravidlu, aby každý tomu rozumněl a všichni s tím souhlasili. Komplikovanost a délka pravidel k tomu také přispívaly, takže více doplnit pravidla o příklady a snažit se to nějak strukturovat, aby to bylo co nejvíce stravitelné pro členy - nejlépe checklist pravidel + modul v githubu na ověření coding standardu. Nakonec zavést asi pevné a tvrdé tresty při nedodržování. Návrh, návrh, návrh ------------------- Již od naší první schůze jsem říkával, že nikdo nechytne na kód dokud nebude mít návrh řešení na papíru. Tohle mě rozhodně naučil FIT a pokud to člověk neudělá, tak na to __tvrdě__ časově doplácí. A to i v tomto případě. Někteří členové si prostě nedělali návrh nebo dělali ale dost bídně a hned se pouštěli do psaní kódu, a potom řešení bylo jednak chybné, tak i kód vypadal odporně. Ke konci jsem vynechával návrh i já a to v dobré víře, že řešení či opravu provedu rychle, že to není komplikovaná úprava. Ale stávalo se mi, že jsem neustále chodil v kruhu s opravou, že jsem musel nakonec použít ten papír a během chviličky bylo vše vyřešeno. Časová ztráta je nenahraditelná, proto návrh, návrh, návrh. Nakonec jako malá poznámka, dejte si pozor na práci s datovým typem double v Qt5. Objevoval se tzv. heisenbug. Jednalo se o chybu Qt spojenou s konverzí stringu na double pomocí fukce std::stod, kde se double část osekávala. Kdykoliv, ale došlo k debuggingu, tak tahle chyba se neprojevila. Tento "neduh" je způsoben defaultním nastavením locale v Qt. --- Do budoucna se budeme snazit o transparentnejsi a castejsi komunikaci, ke kazdemu ukolu by se mohl priradit neajky supervisor, ktery bude dohlizet na kvalitu vysledku. Tim se ulevi ostatnim clenum, kteri nebudou muset dokoncovat praci za ostatni, zamezi se vyhrocenym situacim a nedorozumenim. Dale si myslim je - zvlaste u skolnich projektu - dulezite sdelit si navzajem motivaci k projetku, a to nejlepe jeste pred zacatkem planovani. Zamezi se tim pak neprijemnym situacim, kdy jednotlivi clenove tymu maji jine priority a svuj vysledek meri jinym metrem. --- Ze začátku jsem mergnul nějaké pull requesty, které nebyly funkční. Zjistil jsem, že odpověď "jo jo, pohoda" na otázku: "Zkusil si to otestovat, jestli to funguje a můžu to mergnout?" může ve finále znamenat, že člověk ani neví, že nějaké unit testy jsou a po zkontrolování projdou 3 z 10 testů. Všechny pull requesty před mergnutím jsem pak tedy kontroloval sám a mergoval je až po úplném dokončení. To se osvědčilo. --- Počas vývoja sme spoločne s kolegom začali mať problém s git GUI klientom Sourcetree. Klient bol nestabilný a často padal. --- Viac-menej jediný závažnejší problém z môjho pohladu bolo nedostatok komunikácie a to konkrétne v prípade, keď niekto nevedel naimplementovať požadovanú funkcionalitu. Ako riešenie by som videl hlavne nenadhodnocovanie schopností jednotlivcov pri prelozdelovaní práce na začiatku projektu, poprípade aby sa človek netrápil a napísal tímu v dostatočnom časovom predstihu. --- Hlavní problém týmu dle mého názoru byl následující: Pokud byl některý úkol naplánován tak, že se měl dělat společně, tak nevznikla žádná iniciativa k jeho splnění. Bylo to dáno tím, že každý člen čekal na někoho, kdo se do toho pustí. Naopak pokud byl úkol svěřen konkrétnímu členovi, nebyly s tím problémy. --- Dle mého názoru nebyla komunikace úplně ideální, protože jsme používali klasický chat na Discordu a tudíž se zprávy rychle ztrácely v historii, takže občas nedošlo k zodpovězení nějakého dotazu a musel se problém vyřešit později osobně. Spíše by to pro příště chtělo více kanálů, kde v každém by se komunikovalo a diskutovalo o jednom tématu. --- 4. Vyvarovať sa zlému pochopeniu zadania. Po úvahe ohľadom tejto problematiky som prišiel na to, že je dôležitá komunikácia nie len medzi členmi tímu ale aj so zadávateľmi projektu. Niektoré časti projektu sme pochopili po svojom, niektoré sme doslova zle prečítali. Jedna z možností ako tomu predísť je vopred dohodnutá konzultácia alebo emailová komunikácia s vedúcim projektu. --- Nástroje - Pro tvorbu projektu jsme si zvolili Framework Kivy, který se ukázal celkem nevhodný a problémový, hlavně pak pro tvoření profilingu a testů. Řešení - nezačít tvořit v první věci co najdeme ---