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 2016/2017. 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).

* Za komunikačný kanál sme si zvolili Facebook. Výhodou tejto komunikácie bola okamžitá odpoveď, pretože na facebook-u trávime veľa času. Myslím že to bolo velmi pohodlné takto komunikovať. Všetci členovia tímu boli ochotní a hneď reagovali. Nevýhodou bolo, že keď som si chcel vyhladať našu konverzáciu z minulého týždňa, musel som dlho skrolovať v histótii chatu. Tá prehladnosť bola občas problém. V buducnosti by som chcel komunikovať prostredníctvom Redmine.

* Rozhodně jsme jako tým mohli postupovat lépe. Naše problémy začaly již zpočátku, založením týmu. Jelikož jsme si jako člena, a dokonce i vedoucího týmu, vzali kolegyni, která rozvolňuje a neměla tedy takovou motivaci, byli jsme oslabeni o silného vedoucího, které by všechny kontroloval. To ovlivnilo i naše ne-odevzdání plánu v termínu, jelikož jsme se spoléhali na vedoucího.

* "Facebook je špatným komunikačním kanálem a doporučuji Vám ho při týmové komunikaci nepoužívat." - S tímto moudrem získaným na přednášce jsme se dohodli na využití služby Slack. Dopadlo to ovšem tak, že Slack jsme využívali spíše z povinosti a vše podstatné jsme řešili přes Facebook, který každý z nás denně používá. Běžně se stávalo, že jsme na Facebooku napsali zprávu, že jsme na Slack napsali zprávu. :-D V příštím projektu bych se určitě nezaobíral tím, zda-li komunikační kanál umožňuje to a tamto, spíše jestli je pro všechny členy přívětivý a často kontrolovaný.

* Náš plán bol trochu málo špecifický, na niektoré veci sme nemysleli a potom sme sa museli dohadovať čo kto spraví a to trochu 
to samozrejme brzdilo vývoj. NÁVRHY NA ZLEPŠENIE: 1. Striktnejšie dodržiavať plán projektu. 2. Myslieť trochu viac dopredu, čo bude treba spraviť a jasne definovať, kto to spraví.  

* 1) Problém: Domluva na programovacím jazyce, ve kterém se bude projekt implementovat. Příčina: Jeden člen týmu si neusále prosazoval svůj programovací jazyk, který ostatní členové týmu neuměli. Řešení: Více prokonzultovat, zdali výhody daného jazyka pokryjí úsilí toho, aby se zbytek týmu daný jazyk naučil. Případně najít jiný jazyk, který by měl stejné výhody, ale znali by ho všichni členové. (Pokud možno na jedné zchůce, aby se tento problém rychle vyřešil)

* Spolupráce byla částečně poznamenaná odchodem vedoucího našeho týmu. I přes to s dělbou práce nebyl žádný problém a úkoly jsme si rovnoměrně  rozdělili. Nakonec však někteří členové týmu museli řešit i věci, které jim nenáleželi aby se včas stihlo dokončit co nejvíce úkolů. Určitě by dost pomohlo, kdybychom neodkládali řešení na poslední chvíli. V připadě, že někdo z nějakého důvodu nemůže dodat svou část projektu měl by o tom dát zbytku týmu co nejdříve vědět.

* Ačkoliv v týmu fungovala komunikace bez problémů a skupinový chat na Facebooku naplno pokryl potřeby vývoje kalkulačky dala by se i komunikace lehce vylepšit. Členové týmu dávali vědět přiliš pozdě pokud něco nestíhali. Tak jako v předchozím době by byla velkým přínosem větší transparentnost. I špatná zpráva je lepší než žádná zpráva. Pokud někdo onemocní a dám včas vědět, že nestihne svou část není to žádný problém a ostatní členové týmu to mohou udělat za něj.

* Z vývojárskych nástrojov sme si zvolili jazyk Golang, framework GTK na tvorbu grafických rozhraní a systém git na správu verzií programu. Golang ponúka silné nástroje avšak určité postupy sa líšia od konvencií na ktoré sme zvyknutý z iných jazykov, aj preto nám vývoj niektorých častí projektu zabral viac času. Najväčším problémom čo sa týka verzovania bolo, že sme si nedohodli od začiatku jednotný štýl kódu a niektoré commity sa staly neprehladnými kvoli miešaniu tabulátorov a medzier.

* Při plánování termínů jsme kvůli neznalosti práce s vývojovým prostředím nedokázali odhadnout jak dlouho nám bude trvat vytvořit přenositelý Makefile pro projekt, nestihli jsme ho proto dokončit. Příště se musíme více seznámit s průběhem tvorby abychom mohli správně nastavit termíny.

* Příště u plánování termínů více zohlednit termíny ostatních předmětů bylo těžké dodržet stanovené termíny, na druhou stranu byly určeny s dostatečnou rezervou takže i při nedodržení bychom projekt zvládli.

* Nástroje - komunikace přes Facebook mi přišla dost nepraktická, nepřehledná a často mi unikaly kusy konverzace. Příště doporučím zvolit jiný komunikační prostředek.

* Vedení týmu: Byla jsem vedoucí týmu a nejsem se svým výkonem spokojená. Na začátku jsem nevěděla, co mám jako vedoucí dělat, nikdy předním jsem v podobné pozici nebyla. Mohla jsem už od začátku psát co má kdo dělat na začátku každé fáze a kontrolovat jestli jsou úkoly splněné. Toto jsem začla dělat až po několika fázích.

* Na mé straně byl v XMPP klientovi bug ohledně MUC (Multi User Chat). XMPP MUC používat spíše pro řešení problémů, hotové věci vyhlásit e-mailem a nespoléhat, že je protistrana přítomna u chatu

* nebyl zvolen nejlepší komunikační prostředek - FB zprávy - chaotické hledání historie a občas docházelo k řešení věcí, které úplně nesouvisely se zadáním. Řešení: používání lepších prostředků: Diskuzní fórum... 

* Terminy: Planovali sa vcelku dobre, vzdy tak, aby sa nekryli s nejakym odovzdavanim projektu alebo inym deadlinom z ostatnych predmetov. Kazdy sa vzdy vyjadril, ci moze alebo nie v dany termin, ak nemohol, navrhol sa nahradny ktory potom zvysok musel schvalit. Veduci planoval vzdy tak, aby mu ostala casova rezerva v pripade komplikacii - ktore nastali napriklad pri realizacii testov, nakoniec sa vsak vsetko vyriesilo vcas.

* Pouzivali sme Visual Studio a Bitbucket - vo VS sa dalo stiahnut rozsirenie pre Bitbucket a potom sa 	vsetko dalo pekne pullnut do repozitara. Trocha nestastnym riesenim bol vyvoj aplikacie na Windowsoch a VS, kde bol troska problem s vytvaranim makefile-u. S tymto ziaden clen nemal skusenosti, preto som zabil vela casu hladanim vhodneho riesenia ako makefile spojazdnit. Dosiel som k zaveru, ze je dobre pouzit nmake.exe, ktory je sucastou VS. Myslim si, ze by ste mohli pripadne na buduci rok spomenut v prednaske k tvorbe makefile aj nmake, ja som to totiz na prednaske nezachytil a pride mi to ako rozumne riesenie pre projekty na Windowsoch bez instalovaneho gnuwin32, ktory obsahuje make.

*  Ako vedúci som si vedomí, že som nerobil všetko čo som mal robiť. Spoliehal som sa aj na kolegov čo sa týka kontrolovania zadania a termínov. Či všetko plníme ako máme. Nevyplatilo sa to, kedže nakoniec to bol jeden z dôvodov prečo sme museli veľa veci dorábať na poslednú chvíľu. Na druhú stranu iniciativa od kolegov z môjho pohľadu bola rovnako malá, až na sporadickú otázku na FB, či niekto niečo urobil. Pravdepodobne to je moja vina, kedže som bol vedúci. Mal som sa sám o to viac starať a nútiť kolegov pracovať a hlavne komunikovať. 

* Nestretávali sme sa osobne, čoho dôsledkom bol zle zohraný team. Malo sa viac pomáhať slabším článkom, aby sa všetká ťažšia úloha nepripisovala iba tým lepším. Tak by každý odviedol takmer rovnakú časť práce, aj keď s pomocou druhého. Takto si nie každý odniesol veľa z projektu, na ktorom sa dalo naučiť veľa vecí. Silnejšie články "zhadzovali" tie slabšie.  

* Zpočátku byl problém s nástrojem ReSharper, který fungoval jen některým členům týmu a ještě k tomu každému jinak. Později jsme problém vyřešili, ale stejně například mně místo tabelátorů zanechával mezery. Řešil jsem to pomocí možnost "Tabify lines" ve Visual Studiu před každým commitem.

* Práca s rozličnými verziami visual studia spôsobila pár problémov (napr. chýbajúca možnosť "add unit test" in VS 2017), ideálne by bolo buď sa dohodnúť na 1 prostredí, alebo prispôsobiť rozdelenie úloh ak nastane takáto situácia.

* Niektoré súbory sa v rámci týmu zdieľali v skupinovom chate na Facebooku. Pri väčšom počte správ bol ale problém tieto odkazy vyhľadať. Čiastočne tento problém vyriešilo rozdelenie týmu na 2 menšie týmy, ktoré zväčša komunikovali oddelene. Možné riešenie: Použiť iné programy na týmovú komunikáciu, ktoré umožnujú oddelené ukladanie súborov a sú prehľadnejšie

* Problém: Jako první problém bych viděl námi zvolený komunikační kanál. Zvolili jsme si facebookový skupinový chat. Problém byl v tom že starší informace nebo otazky se posunovali dozadu a tak si jich nikdo nevšiml. Řešení - příště bych zvolil jiný komunikační kanál například slack, kde se dají rozdělit témata atd.

* niekedy pri praci nebol prehlad o tom co uz je hotove a co treba spravit -> do buducnosti mozno pevne stanovit terminy sprav/podavani hlaseni o praci

* Systém pojmenování na verzovacím systému. Náš vedoucí, sice stanovil způsob pojmenovávání větví a komitů, necméně tento systém se později přestal dodržovat z části proto,
že občas se nějaký komit odeslal omylem a z části z nedůslednosti. Na výsledek tento drobný problém neměl vliv, nicméně u rozsáhlejšího projektu by bylo vhodné pravidla stanovit striktněji a také je dodržovat.

* Jako vedoucí jsem jednou selhal při prošvihnutí termínu odevzdání první části. Byla to má chyba. Možná bych očekával ze strany ostatních členů týmu vyšší zájem o to jestli odevzdání probělo v pořádku.

* Špatně jsme si prostudovali zadání, ve kterém se nachází značné množství dílčích deadlinu a lokací kam je potřebné odevzdávat jednotlivé části, což se ukázalo jako problém, když tyto dílčí deadliny a místa ukládání nebyly patřičně sledovány a kontrolovány. 

* Pro týmovou komunikaci jsme vybrali ze zpětneho pohledu nevhodný komunikační kanál v podobě skupinového chatu na Facebooku. Problém byl v nepřehlednosti poslaných zpráv a složitosti dohledavaní drivějších příspěvků. ŘEŠENÍ: Využití jiného komunikačního kanálu (např. Slacku) místo Facebooku.

* při přistim projektu by bylo lepši komunikovat ne kolem pulnoci, ale trochu dřiv protože ne každý si toho všimne

* Až se zdál projekt dokončen tak namísto přesunutí sil na další fázi došlo z druhé poloviny týmu (která neměla napojení na starost) k rozhodnutí tento kód celý přepsat za účelem zpřesnění výsledků. To nás také zdrželo a mírně naštvalo, rozhodnutí nebylo projednáno. Rovněž nebylo týmu oznámeno dokončení předělání a tak projekt zbytečně stál.
Osobně si myslím, že snaha o větší přesnost kalkulačky neměla být důvodem pro porušování dohodnutých postupů a pro další zpožďování projektu.

* Testování dokumentace stejně jako kódu: Zatímco kód si každý z nás průbězně zkoušel, tak dokumentaci si nejspíš někteří ani nepřečetli. Přístě bych zavedl, že po sepsání dokumentace si každý zkusí dle dokumentace program používat včetně ručního sestavení, nainstalování a odinstalování.

* Dokončení fáze s předstihen nemělo vliv na započetí následující fáze První fáze byly dokončeny vždy s předstihem před termínem, avšak bezprostředně následující fáze nebyla nidky zahájena dřív, než po termínu dokončení předchozí fáze. Zvláštní psychologický jev. Přitom není nic špatného, začít s úkolem dřív, než se plánovalo.

*  Náš "leader" nám odporúčal "Discord" - komunikačný kanál, čo sme používali behem celého projektu. Ja som s ním spokojný. Myslím, že vedoucí týmu splnil všetky kritéria a keď bude na to príležitosť rád budem s ním spolupracovat v budúcnosti.

* Jemny problem nastal v oznacovaniu koncov riadkov sposobene pouzivanim rozlicnych editorov - jednoduche riesenie tohto problemu pri dalsich projektoch je vytvorenie editorconfigu.

* Věcí, kterou bych příště v projektu nepoužil, je knihovna pro uživatelské rozhraní Kivy. Rozhodli jsme se ji v tomto projektu vyzkoušet a z tohoto pohledu naše volba nebyla chybou. Díky tomu víme jak funguje a získali jsme tak nové poznatky a zkušenosti. Při vývoji jsme ovšem narazili na několik komplikací a problémů, kvůli kterým bych při dalších příležitostech raději zvolil jinou variantu.

* Jako třetí problém bych vypíchnul špatné přečtení zadání. Naším menším problémem bylo důsledné čtení zadání projektu. Kvůli tomu jsme museli dodělávat funkce, a řešit nesrovnalosti, což nás stálo úsilí a samozřejmě i čas. Tento problém by se dal řešit vymezením si času na detailní přečtení zadání a nedělat to na několikrát.

* Úlohový systém - využívali sme tasky ktoré boli vložené v bitbuckete, problém bol že nebolo možné im nastaviť deadline. Lepší systém by bol nejaký redmine, alebo niečo podobné.

* Najväčším stresujúcim momentom práce na projekte bol večer odovzdávania. Práve tento moment hodnotím ako organizačne nezvládnutý. Projekt sme ako kompletný odovzdali len pár minút pred termínom odovzdania. Jednoznačne sme mali funkčnú verziu odovzdať pre istotu skorej.

* U dalšího projektu bych rád zprovoznil službu Weblate, což je služba na vytvřáření překladů.

* V budúcom projekte by som robil uživateľskú dokumentáciu v Latexu namiesto Wordu už len kvoli výrazne lepšej štruktúre.

* Málo času na finálnu časť projektu: Samozrejme, nevyčlenili sme pre projekt dosť času a ako leader týmu som si dopredu nenaštudoval poriadne formát odovzdania. Najväčšou chybou, ktorá nás bude stáť najviac bodov, bolo, že som dopredu nevyčlenil čas, kedy pospájam všetky časti projektu a odovzdám. Kvôli tomu som nestihol odovzdať načas súbor zip cez WIS (na ivs serveri sme ho odovzdali) a nestihol som skontrolovat finálny súbor.

* Nástroje: osobně jsem měl zpočátku menší problémy s programem SmartGit, ale po seznámení s prostředím byla práce s ním jednoduchá.

* Úloha vedúceho - bola podla môjho názoru pochopená zle, resp. nedostatočne. Vedúci vzal na seba úlohu, poukazovateľa na problémy avšak neprevzal zodpovednosť za odovzdanie projektu a kontrolu súboru, ktorý bol oficiálne odovzdaný, čo viedlo, k núdzovému alternatívnemu riešeniu (úloha vedúceho nie je len o riadení).

* Metodika TDD nám vývoj po nějakou dobu značně zpomalila, protože se muselo začít testy a do jejich psaní se nikomu z nás zrovna moc nechtělo. Rozložení psaní testů mezi všechny členy týmy určite pomohlo, tudíž každý psal nějakou část testů a nepadlo to jen na jediného člověka. Zároveň jsme se snažili je rozdělit tak, aby každý psal testy někomu jinému a ne sobě sama, což se nám podařilo. Nakonec nám testy pomohly odhalit chyby a vývoj matematické knihovny s nimi byl určitě jednodušší.

* Problém výběru IDE (NetBeans vs Eclipse): Každý si volil, v jakém IDE bude pracovat. Moje první volba byla Netbeans a celý týden jsem rešil, proč projekt nefunguje, tak jak má. Později jsem se dočetl, že otevřít projekt, který byl vytvořen pomocí Eclipse, je obtížné a Designer v NetBeans nebude fungovat. Tedy jsem přešel na Eclipse a problémy tím vyřešil, ale už jsem mohl být s prací mnohem dál. Příště raději pevně stanovit jedno IDE, které bude používat celý tým hned na začátku.

* Jeden z členov tímu ochorel v nevhodnú dobu a tiež nám to narušilo plán. Mali sme na takéto veci myslieť dopredu a pripraviť sa na ne.

* V příštím týmovém projektu bych byl za to, aby se projekt rozvrhl do ještě menších částí po kratších časových úsecích. Přeci jenom je tak jednodušší sledovat kdo kolik udělal a myslím si, že tím, že jednotlivé cíle jsou menší a zaberou méně času, by se nám dařilo pracovat na nich i během doby kdy máme rozdělaný jiný projekt.

* V planu projektu se udelaly chyby s terminy na Makefile a instalatory, ktere se nedeji udelat pred naprogramovanim celeho projektu. Musi se tvorit postupne.

* Jako největší problém v našem týmu vidím to, že jsme neměli žádnou osobní schůzku, kde bychom se sešli a rozebrali potřebné věci. Všechno se řešilo pouze elektronickou cestou. Přitom jsme se potkávali ve škole a znali jsme se, takže by takové krátké setkaní (jedno či více) nebylo žádný problém.