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 2014/2015 a obdobného 2. projektu 2015/2016. 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 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). K některým jsem dopsal svůj komentář. Zbytek tohoto souboru je v následujícím formátu: * Citace ze souboru xloginNN_problemy.txt - Můj komentář Termíny: -------- - Některé týmy měly pocit, že zvolená časová rezerva byla příliš velká (popsáno různými způsoby). Z hodnocení se však ukázalo, že tyto týmy měly využít onu časovou rezervu a lépe zkontrolovat a otestovat výsledné produkty. Často tam byly zbytečné chyby. - Většina týmů měla problémy s termíny, ale vždy jsou to typické příčiny (mnoho jiné práce, pasivita členů týmu, ...) a nějaké obecné řešení neexistuje. Kvalita výsledku: ----------------- * "Celkovo by som hodnotil náš projekt na 70%." - takto svůj projekt hodnotí člen týmu, co má za produkt 46 ze 48 bodů. Proč? - sebekritičnost zlepšuje výsledek (sice to nebylo úplně bez chyby, ale rozhodně nad průměrem). * "Určitě by bylo lepší aby ostatní členové týmu důkladně zkontrolovali vypracovanou část kolegy a případně poskytli svůj názor co dělat jinak, v našem týmu toto byl občasný jev a to ještě spíše na vyžádání" - Tohle se anglicky jmenuje "Peer review". Odhalí se tak spousta chyb od absolutních cest v nějakých souborech, přes špatně zdokumentované závislosti až po různé problémy, které původního autora nenapadly (třeba otestovat dělení nulou). * Myslím ze by bylo vhodné, abychom si práci rozdělili do dvojic, přicemz by v kazdé dvojici jeden něco vytvořil, a druhý to po něm automaticky kontroloval. Zaručuje to mnohem lepší kvalitu práce a pohled z více stran. * "3) Zvolit vývojářské nástroje dostupné na cílovém serveru (vývoj - Qt5.4 x merlin - Qt5.2)." - Když opomineme to, že cílovým serverem zde neměl být merlin, je to zcela zásadní problém. Pokud použijeme nejnovější verze knihoven (často označení testing, unstable, nightly build apod.), může dojít na situaci, kdy zákazník tyto verze ani nemusí být ochotný nainstalovat a bude nutné doplňování zpětné kompatibility. * "s QTcreator-om nemal nikto z týmu skúsenosti, preto sme nevedeli, akým spôsobom sa dajú implementovať niektoré funkcionality. Do veľkej miery sme prispôsobovali návrh funkcionality k naším zručnostiam a schopnostiam a nie naopak." - Toto je obecně velký problém, když se návrh neudělá předem ale dotváří se až za běhu, nebo když návrh dělají vývojáři a rovnou u toho přemýšlí o tom, jak to budou implementovat. Pak se funkcionalita přizpůsobuje tomu, aby ji bylo snadné udělat, místo aby se udělala tak, aby byl výsledek co nejlepší. * " postupem času jsme do projektu přidávali další a další věci, takže nakonec nabyl několikanásobného rozsahu, než bylo plánované, a navíc někteří na těchto věcech dělali spoustu práce, aniž by museli, zatímco ti, kteří měli přidělenou práci typu dokumentace, pak neměli co dělat" - Nadšení pro dosažení lepšího výsledku a zabudování zajímavých funkcí navíc může být dobré. Jen je třeba pohlídat, aby pak nedošlo na situaci, kdy jsou sice hotová různá zajímavá rozšíření, ale nestihne se dokončit něco zásadního, co bylo na začátku požadováno (dokumentace, instalátor, ...). * "Zkusit přidat aplikaci textové rozhraní, aby byla použitelná jak v grafickém, tak i textovém režimu. Takto to má například VLC, které umí přehrávat video pomocí zobrazování znaků (pokud je spuštěn v textovém režimu)." - Toto někdy může být užitečné rozšíření. * Ešte by som zlepšila jednu vec a to je komentovanie kódu, lebo ten člen tímu, čo mal na starosti písanie JavaScriptu tam nepísal skoro žiadne komentáre a keď som sa potom ja pozrela na ten kód, tak som v ňom bola stratená. * Kompletaci a odevzdání jsme nepřikládali velkou váhu. Avšak zjistili jsme, že věci námi ukládané v repozitáři a celková adresářová struktura jsou špatně. Posléze nastávaly menší problémy se spouštěním jednotlivých odevzdávaných částí. Proto docházelo k ůpravám ať už samotných částí nabo Makefile. Řešení: Řešit finální kompletaci průběžně popřípadě si na ni vyhradit více času. * Menší problém, kterého jsem si všimla bylo to, že ne všichni byli pečliví a zodpovědní a s klidnou hlavou dávali ostatním k dispozici nefunkční věci. My jsme po sobě sice vzájemně práci kontrolovali, ale některé chyby byly lehce odhalitelné (například syntaktické chyby v testech, které se projevily okamžitě po snaze testy spustit) už člověkem, který se jich při práci dopustil. Opět bych podotkla, že u nás to nevyvolalo velké problémy, alespoň jsme si procvičili porozumění cizímu kódu, ale v projektech většího rozsahu bych určitě očekávala pečlivěji zkontrolovaný kód. Chyba se určitě může stát vždycky, ale my jsme mnohdy opravovali drobnosti způsobené nepozorností nebo zbrklostí. A určitě bychom si tím ušetřili i nějaký čas. - Kdyby si po sobě práci vzájemně nekontrolovali, mohla z toho být velká ztráta bodů. * Poslední problém, který mi příjde významný, souvisí jak s plánováním, tak s komunikací. Před tím, než jsme se pustili do samotné implementace, jsme se nedomluvili na tom, jakým stylem budeme pojmenovávat funkce, proměnné, jakým jazykem budeme psát komentáře, zprávy při commitech v gitu atd. Důsledkem tohoto také bylo, že grafické rozhraní kalkulačky bylo částečně česky, částečně anglicky. Což je něco, co jsme museli později upravovat a popisky přepisovat (zvlášťe u mockupu). * Zpožděný začátek práce na projektu, z důvodu čekání na to, až někdo začne. Dalo by se předejít lepším naplánováním práce. - viz přednáška - tohle potvrzuje, že to na ní nezaznělo zbytečně * Mohli sme implementovať viac funkcí, ale nakolko sme chceli plne funkčný software bez chýb, radśej sme v konečnej verzií nezahrnuli niekolko funkcií. - Opravdu rozumný postup - lepší málo a správně, než hodně, ale špatně. * Termíny - síce sme mali naplánované termíny, avšak sme sa ich nedržali a veľa vecí sme robili na poslednú chvíľu, kvôli čomu sme aj nestihli spraviť všetko. Takže nabúdúce by sme sa určite snažili termínov držať. Týmová spolupráce a komunikace v týmu: -------------------------------------- * "U kápa bych uvítal trochu větší iniciativu k vedení týmu. Vlastně myslím, že nám všem by prospělo mít větší iniciativu." - Hezky řečeno - iniciativu musí mít všichni - vedoucí nemůže jen popohánět ostatní a donucovat je k práci - pak by sám neměl čas na nic jiného. * "Spolupráce: Každý udělal co měl a ještě jsme si navzájem vypomáhali. Návrh: Stanovení pravidel tvorby kódu v tomto ohledu velice pomohlo. Je to věc, kterou určitě budu prosazovat do budoucna ve všech týmových projektech." - Stanovení pravidel pro psaní kódu (odsazování, konvence pro názvy identifikátorů, komentáře, ...) zlepší nejen možnosti spolupráce (nemusíte přenastavovat vývojové prostředí pro pomoc kolegovi), ale i výsledek, který pak bude konzistentní a lépe udržovatelný. Dodatečné přeformátovávání kódu znepřehledňuje historii v repozitáři a téměř znemožňuje merge větví, které vznikly před tím. * "Jediný problém který byl ve spolupráci je to, že když, jako vedoucí, psal o nějakém problémů do chatu, tak spolupracovníci mohli začít vypracovávat to zadání ihned. Pár malých věci vypracoval tým 2x. Řešení je během komunikace striktně ukazovat, kdo musí splnit tento úkol." - Striktní rozdělování vedoucím je řešení, ale ne jediné. Když u nějakého úkolu není jasné, kdo ho bude dělat, může ten, kdo na něm začne pracovat, napsat ostatním, že si tento úkol bere na starost. Pak ostatní mají lepší přehled a tyto situace nenastávají. * "Malé zásahy a koordinace práce od vedoucího týmu. Osobně si myslím, že tento faktor byl klíčový. Často jsme nevěděl na čem kdo, a jak pracuje. Připadal jsem si nevyužitý a neinformovaný" * "Rozhodně častější osobní schůzky. Důsledné používání komunikačních kanálů. Zakázání používání hromadného chatu na Facebooku - velmi nepřehledný a svádí k osobním konverzacím." - Zdůraznil bych "Důsledné používání komunikačních kanálů." - tedy stanovení a dodržování pravidel pro komunikaci. Toto bylo ve Vašich souborech různými způsoby zmíněno N-krát - proto jsem o tom mluvil i na přednášce... * "Největším problémem bylo začít, pravděpodobně proto, že každý z týmu měl rozpracované jiné projekty (které se musely odevzdávat dříve než tento a proto měli větší prioritu). Řešení by bylo začít dříve a pečlivě dodržovat plán termínů." - Další z věcí, co zazněly na přednášce - toto potvrzuje, že to mělo smysl zmínit. * "Ještě jednu malou výtku bych měl k tomu, že ne všichni členové týmu dávali do sdíleného repozitáře všechny věci, které už měli hotovy. Příklad: Byly vytvořené testy, ale já nemohl testoval, protože testy nebyly v repozitáři." - Toto je typický problém - někdo má něco jen u sebe a nesmyslně odkládá zpřístupnění ostatním. Příští rok tohle asi přidám do přednášky. * "Co bych udělal příště jinak: - Na začátku bych přesně definoval ... coding style, jazyk psaní kódu, unixovou filosofií při psaní programů," * "Najzávažnejším problémom bola neochota jednoho člena týmu pracovať na vývoji aplikácie. Navyše sa ukázalo, že schopnosti tohto člena sú nedostatočné a riešený problém mu musel byť odobraný a implementovaný ďalšími členmi. To však považujem za častý problém. Riešením by bolo napr. prijímacie konanie, kde by bolo nutné preukázať príslušnú odbornosť." - Toto je skutečně velmi častý problém a navžené řešení je také velmi často využíváno. Nicméně ve školních projektech jej nelze použít a problémy jsou s ním i tam, kde je nedostatek lidí (je potřeba rychle někoho přijmout i za cenu, že bude potřeba doplnit jeho znalosti). * "Vedoucím jsem již byl u více projektů, ale teprve u tohoto projektu jsem si poprvé tuto roli opravdu uvědomoval. Musel jsem částečně rozdělovat práci a dohlížet na vývoj projektu. Vzhledem k rovnocennému postavení všech členů týmu (studenti stejného ročníku) mi tato pozice nebyla příliš příjemná. Myslím si, že by u školního týmového projektu měli všichni členové projevit stejnou míru zodpovědnosti." * "jediná výhrada by byla k pozdnímu odevzdání první části třetího projektu, ačkoliv o ní nikdo z týmu nevěděl včas, tak to byl úkol pro vedoucího týmu, tím pádem dávat na tento problém pozor i příště" - Sice je hlídání termínú primárně úkolem vedoucího, ale vedoucí je také člověk a žádný člověk není neomylný (tím spíše, když má i řadu dalších starostí). Ostatní členové týmu by se také měli zajímat o termíny a mít alespoň hrubý přehled, aby v takové situaci vedoucího někdo upozornil. * "Během vývoje se několikrát vylepšovala adresářová struktura projektu. Pro příště by bylo záhodno se dopředu domluvit, co kam patří a podle toho postupovat." - Jen k tomu dodám, že změny adresářové struktury dělají problémy s prohlížením historie v GITu. Když už se dělají, je třeba používat "git mv". * "některé dílčí úlohy jsme si nerozdělili konkrétně mezi členy týmu, takže pak později nebylo jasné, kdo má co vlastně dělat" * "Největší problém naší skupiny byl v komunikaci. V tomto projektu jsme zvolili jako hlavní prostředek pro komunikaci školní email, což nebyl nejlepší nápad. Většina komunikace proběhla mezi dvojicemi, které si posílali e-maily jen mezi sebou, tutíž zbytek týmu neviděl co si píší." - viz přednáška (přesně na toto vždy upozorňuji u toho "odpovědět všem" - jsem rád, že vidím, že to má smysl)... * "Spolupráce - Rozdělení úkolů se po pár týdnech nepatrně obměnilo. Musím však říci, že k lepšímu. Zjistili jsme, co komu jde nejlépe a podle toho přizpůobili původní plán." - Plán je často třeba průběžně přizpůsobovat. Jeho zafixování na začátku je téměř nemožné (už po 1. problému s dílčím termínem apod. by měl být aktualizován). * "Během řešení projektu odejde nebo onemocní člen týmu. Tento problém se dá řešit tak, že bude jeden člen týmu vyhrazen pro tyto případy a nebude mu přidělena konkrétní práce. Může pomáhat v aktuálně potřebné části projektu a ve chvíli odchodu případně nemoci jiného člena týmu jej nahradí." - Zajímalo by mě, jestli toto bylo vypsáno z přednášky, nebo jestli bylo znovu objeveno řešení popsané na přednášce. * "Komunikácia v týme - Komunikovali sme prostredníctvom vytvorenej skupiny na facebooku a kedže sme sa na presných časoch komunikácie nedohodli, tak sa stalo že ak niekto napísal a niečo chcel vediť tak mu nemal kto odpovedať. Dva krát sme sa stretli a pracovali spoločne. V budúcnosti by sme si mali vopred dohodnúť presné časy kedy budeme na projekte pracovať, aby sme boli zladený a vedeli kedy môžme očakávať odpovede od iných členov tímu." - Typický problém, když se nestanoví pravidla pro komunikaci. * "Problém - Rozdělení práce někdy příliš obecné, například rozdělení mezi dva lidi úkolu na jedné funkcionalitě. Řešení -> Dúslednější specifikace požadavků od jednotlivého členu" * "Planovani - ujistit se, ze vsechny casti projektu budou vypracovany a na zadnou cast se nezapomene. Stalo se nam, ze kazdy clen mel urcene hlavni funkce kalkulacky (+-/*....), ale nikdo nemel zadane ty pomocne funkce. (konkretne treba zpracovani zadaneho cisla, osetreni toho, aby uzivatel nemohl zadavat pismena apod.) Problem to vylozene nebyl, ale pri planovani si na to musime dat priste pozor." * Z mojí strany byl možná trochu problém s úvodní aktivitou, neboť jsem se při výchozím plánování ... nebyla schopna k ničemu zapsat, protože jsem si na nic z toho nevěřila. ... Jakmile byla možnost zapsat se k něčemu ve dvojici, už jsem takový problém neměla. - Přidělení úkolů dvojicím může být řešením, jen je nutné jasně specifikovat, zda se bude jednat o párové programování nebo zda 1 práci udělá a 2. zkontroluje (jiný úkol může mít stejná dvojice naopak - tedy 2. programuje a 1. kontroluje). * V jistém ohledu bylo naše přátelství možná trochu překážkou. Sice vyloženě schůzek týmu kvůli projektu nebylo zase tak moc, ale obecně se vídáme často (a tedy podle mě chybí nějaké psychologické tlačení k tomu, že toto je vzácná chvíle, která je zasvěcena společné práci). Stejně se to často zvrhávalo spíše v přátelské setkání než schůzku vyhrazenou pro práci na projektu. To je ale možná taky dáno (minimálně z mojí strany) nedostatkem sebekázně. A možná by to taky chtělo lepší organizaci setkání. - Rozhodně souhlasím, že přátelství může být při práci na projektu paradoxně překážkou. Jednak může být problém udržet koncentraci na projekt na schůzkách a jednak není tak snadné dát kamarádovi, který nic neudělal, spravedlivých 0 bodů a připravit jej tak o zápočet. I když dobrý kamarád by Vás v tom projektu neměl nechat samotné, když má problém s povinnými předměty, jeho priority se mohou rychle změnit... * problémy okolo neaktivního člena - 1-2 týdny čekáte, že člen dodá matematickou knihovnu, aby jste mohli dodělat zpracovávání příkladu, ale ono stále nic. - Jekmile je někdo neaktivní, je nesmysl čekat. Není-li jasné, že pracuje, je lepší úkoly přerozdělit a buď později udělá něco jiného, nebo ne. * Jelikož jsme dali třetímu členovi čas na jeho část úkolu dva dny a on se vymluvil, že nestíhá apod., byla naplánovaná jeho čast na dní 5. Nakonec jsme to po 5-ti dnech vzdali, člen nekomunikoval, čili se nám čas výrazně protáhl. Ponaučení pro mě jako vedoucího je volit jasné deadliny, které se musí dodržovat, i kdyby měl část vypracovat někdo jiný a daný člověk ztratí body. * Komunikovali jsme především přes sociální síť a občas se stalo, že někdo na ni nebyl připojený, a tak se některé věci dozvěděl později, což by se u týmových projektů nemělo stávat a měli by jsme domluvit jiný komunikační kanál. - Bez jasných pravidel pro komunikaci je problém u celé řady nástrojů - nejen u sociální sítě. * Postupem času jsem vedení převzal, protože na mně stála většina komunikace a rozdělování práce v týmu. Nechci ovšem, aby se to dotklo hodnocení oficiálního vedoucího, protože chyba byla už při jeho volbě do této funkce a v průběhu projektu jsme již nechtěli zatěžovat vedení, aby v systému složitě měnili vedoucího - pokud by to vůbec šlo... - Změna vedoucího není až zas tak velký problém. Rozhodně je lepší než zbytečná ztráta bodů. Vždy je třeba zjistit, jaká rizika "papírové" ponechání původního vedoucího přináší (např. když je jediný, kdo může odevzdat, ...) a raději se ozvat včas, než pak řešit problém. * Problém: Nezačali jsme včas + nesledovali jsme průběžné termíny odevzdání. Řešení: Nedávat volitelné předměty na vedlejší kolej kvůli předmětům povinným. Buď si volitelný předmět zrušit nebo lépe zorganizovat čas. * Problém: Nenastavili jsme si pravidla z hlediska jednotné formy kódu. Někdo psal komentáře, někdo ne apod. Řešeníí: Rozhodně se domluvit, jak bude kód vypadat a vytvářet jej podle nějakých pravidel. Ne, jak je každý zvyklý (někdo úhledný, někdo ne). * Náš tým měl určitě největší problém při rozdělování úkolů. Z počátku nebyl aktivní vůbec nikdo, s postupujícím časem jsme s jedním kolegou začali pracovat na úkolech, které bylo nutné splnit co nejdříve. Ke konci zase zbyly nesplněné úkoly a členové týmu si je rozdělili podle preferencí a podle toho, kdo se o daný úkol dřív přihlásil. Neměli jsme tedy vedoucího, který by kontroloval plnění úkolů a případně je přiděloval. Příčinou našeho problému zřejmě bylo to, že jsme nepovažovali za důležité určit vedoucího týmu. * Pasivita některých členů týmu - Možné řešení: Více do hloubky promyšlený návrh implementace a s tím spojené detailnější zadání pro každého člověka (jednoduché úkoly se budou plnit snadněji). Reálné a férové nastavení a dodržení sankcí (doplňujících či náhradních úkolů, srážky bodů) za nesplnění povinností. * Nedodržení stanovených termínů a nepochopení návaznosti jednotlivých úkolů a blokování ostatních členů nedodržením termínu. Možné řešení: Neustálý aktivní zájem všech členů týmu o stav vývoje u ostatních. Analogie denních stand-up setkání týmu používaných například v metodoligii Scrum. * Největší problém jsme měli dodržet zadaný plán a termín. Stanovili jsme si kolektivně, že si první pokud možno vyřídíme všechny ostatní záležitosti, a poté se budeme soustředit na projekt do IVS. To nebyl dle mého zas tak dobrý nápad, jelikož se stejně v průběhu vývoje objevovaly další záležitosti, které bylo třeba vyřídit... a zkrátka není možné si v průběhu semestru "vyřídit všechny záležitosti", protože se pořád objevují nové a nové. A tak jsme nabrali celkem zbytečný skluz. Poučení pro příště: řešit problém postupně a od stanoveného data počátku, nevyplatí se na nic čekat, stejně se ten čas jen těžko najde - čím dřív, tím líp. * Věřím, že kdybychom dostali práci, kterou měla udělat slečna ..., tak bychom stihli všechny termíny, ale vzhledem k tomu, že jsme jí dali 8 dní za 1. termínem, měli jme problém projekt vůbec dokončit a proto si myslím, že jsme jí dali příliš času a měli jsme začít na matematické knihovně dělat sami již ... * Špatný prvotní plán projektu - na papíře vypadal plán v pořádku, ovšem při realizaci se ukázalo, že úlohy nebyly rozloženy rovnoměrně mezi jednotlivé členy. Lepší plán by vyžadoval důkladnější analýzu požadavků a náročnosti jednotlivých úloh. Něco, co ovšem v naší situaci, kdy jsme plán vytvářeli v době velkého půlsemestrálního vytížení pouze jako nutnost k odevzdání, nebylo možné. Řešením by bylo vytvoření plánu dříve nebo naopak vyjít z odevzdaného plánu a před začátkem realizace vytvořit detailnější variantu. - Dodatečné rozepsání předběžného plánu je rozumné. * Problém: Nedodržení termínů plánu: Celý vývoj začal skoro o dva týdny později než byl plánován. Důsledkem bylo nedodržování termínů a prakticky se nedalo držet původního plánu vývoje. Řešení: Více lpět na daných termínech a striktně se držet plánu. Při nedodržení plán co nejdříve přepracovat. Tím by měl být neustále zajištěn přehled o průběhu vývoje a mělo by být známé předpokládané dokončení projektu. * Jeden z členů týmu se během vypracovávání projektu rozhodl, že tým opustí a tím narušil vešekerý časový plán, s tím se naše skupina moc dobře nevypořádala a místo abychom vytvořili plán nový tak jsme řešili úkoly od této doby spíše chaoticky, to bylo ovšem dle mého názoru způsobené rovněž neznalostmi potřebných k úspěšnému zvládnutí projektu a jednotlivé úkoly jsme tedy spíše objevovali a zjišťovali co je třeba udělat až v průběhu. - Možným řešením by bylo ujasnění motivace jednotlivých členů pro tento projekt. Mohli bychom tímto zjistit, že někdo není dostatečně motivován dovést projekt do zdárného konce a tudíž práci lépe rozplánovat. Například dát člověku, u kterého si myslíme že by mohl během projektu skupinu opustit, menší povinosti. Nebo aspoň zjistíme-li možnost, že někdo skupinu opustí, promyslet řešení takové situace. Nástroje a komunikační kanály: ------------------------------ * "Příčina: K problémum s mikrofony jsme bohužel byli nuceni využít pouze IM messengery. Řešení: Výměna hardwaru případně osobní schůzky" - Při volbě nástrojů pro komunikaci je vždy třeba přihlédnout i k dostupnému HW - ostatně toto zaznělo i na přednášce... * "Nástroje: Prostředek git byl v celku dobrou volbou, problém byl v možnostech jeho využití. Ačkoliv jsme si určili jednotnost kódu, neurčili jsme si už jednotnost v užívání gitu (využití branch, špatné commitování z Visual Studia...) Návrh: Naučit se používat branche v gitu, a vždycky si udržovat v master funkční spustitelnou verzi se kterou lze testovat samostatné části. - Jednou z hlavních výhod GITu oproti SVN apod. je právě možnost vytvářet větve a dělat do nch malé commity, po kterých program nemusí být funkční (v SVN by nikdo neměl udělat commit, po kterém výsledek nelze přeložit apod.). V master by však vždy měla být funkční verze. Buď by měl být někdo, kdo je zodpovědný za kontrolu a merge větví s jednotlivými funkčními částmi do master, nebo si každý musí hlídat, co tam chce přidat. * "Zvolili jsme pro sdílení dat původně pouze repozitář na bitbucketu a případné soubory jsme si plánovali posílat mailem. Nicméně ke konci projektu bylo třeba předávat si a chystat větší množství dat, k čemuž jsme založili složku na Mega a Google Drive ... Příště budu věnovat pozornost při domluvě nutnosti předávat si pohodlně velké soubory." * "setkali jsme se s problémem s gitem, kde každý pracoval trošku jinak a dostali jsme se do fáze, kde jsme museli některé kommity mazat a jiné přesouvat, tak abychom na projektu mohli dále pokračovat, tento počin vedl k tomu, že jsme se několik hodin zpozdili a znovu jsme museli psát některé ztracené části kódu ... problém nastal s překrýváním verzí u gitu, které se nám přes sebe nemohly commitnout a pushnout na server a při vyřešení problému jsme zjistili, že některé části kódu chybí" - Tohle ukazuje na nesprávné použití GITu. Každý by měl pracovat ve větvi pro danou funkci (feature branch) a po dokončení se teprve provede merge do master. Když všichni pracují v 1 větvi (často master), jsou problémy (před push se musí provést pull a řešit konflikty apod.). - Mazání commitů by za běžných okolností nikdy nemělo být potřeba (nepočítám-li mazání celé větve, ve které je něco špatného, co nevede ke správnému výsledku). Obvykle existuje i jiné řešení. * "Jakožto hlavní komunikační kanál byl využit facebook, ... Napadlo mě použít i jiné systémy, ale tento zvítězil, protože ho všichni důvěrně známe. Sekundárně jsem byl okolnostmi nucen 3x použít telefonní spojení." - Hezky potvrzuje, že je výhodné mít možnost použít telefon. * "V komunikaci samotné nenastal žádný problém nicméně zvolené prostředky pro omunikaci nebyly nejlepší pro IT projkety. V příštím projektu rozhodně nepoužiji Facebook, ale raději Slack. Který umužňuje napojení na velké množství služeb, které usnadňují práci programátorům a vývojářům, např.: napojení na GitHub." * "Určitě by bylo dobré příště založit sdílený kalendář pro všechny členy týmu a aby se jim zobrazovalo upozornění na nadcházející termíny" * "Komunikácia - Ako komunikačný kanál sme zvolili Facebook, kde niekedy reakcia tímu alebo vedúceho nebola okamžitá. Lepšie by bolo použiť IM typu ICQ, Skype či v neposlednom rade mobilný telefón." * "využívání GITu na maximum - jsou zde commity pouze od vedoucích sekcí daného projektu - řešení nechat commitovat všechny členy teamu a pouze opravovat či upravovat vedoucími" * "GTK+ 3 Python, nie až také skvelé rozhodnutie. Python port mal slabú dokumentáciu. Často som zistovaľ, že fungujú metódy z C implementácie GTK+ 3, ktoré pre Python neboli zdokumentované. Niektoré metódy boli zle portnuté a spôsobovali stack overflow." * Pro komunikaci jsme zvolili Facebook, což mělo své výhody i nevýhody. Nevýhodou byla nepřehlednost a složitost vyhledávání starších zpráv. Příště by bylo možná vhodné se podívat po alternativním komunikačním kanálu. * Komunikace v týmu fungovala bez problému, a to i přesto, že námi vybraný způsob, a to sice Facebook (skupina + chat), není nejšťastnější prostředí pro domluvu více lidí na větším projektu. Nejsem si jist, zda mě napadá konkrétní vhodná alternativa, ale prostředí, které by uchováválo to nejdůležitější o každé výměně informací + by dokázalo lépe zprostředkovat výměnu souborů (které nebylo vhodné ihned dávat na Git), by komunikaci zlepšilo ještě více. Nenahraditelné však byly osobní schůzky členů, na kterých se vyřešilo nejvíce. * Hlavním komunikacním kanalem byl pro nás team facebook, coz mi nevyhovovalo. Ve skupinovém chatu je komunikace nepřehledná. Kdyz je např. jeden clen offline, a zbytek teamu v chatu několik hodin debatuje, offline clen potom přijde ke konverzaci ve které je 400 nepřectených zpráv a tězko ji bude celou cist a vse si zapamatuje. Lepsí variantou by bylo diskuzní forum s jednotlivými topicy, a nebo mnou upřednostňovanou variantou osobní schůzky ( je ale někdy tězké najít spolecný cas ). * Komunikace probíhala většinou jen přes Skype skupinu, což je na domlouvání termínů v případě nepřítomnosti některých členů nešikovné (možnost přehlédnutí). V budoucnu by bylo lepší využívat nějaké internetové služby, která by prezentovala důležité informace podle priority, nikoliv podle času vzniku jejich záznamu. * Problém: pushovani do master větve. Řešení: měl jsem to před začátkem projektu zakázat, ale nezakázal jsem to kvůli rozsahu projektu a velikosti týmu- Jakmile se nástroj začne používat nesprávně, vznikne problém. Malá velikost týmu problému nezabrání. * Problém: pushovanie nepotrebných súborov do repozitára - stávalo sa, že sa v repozitári objavili veci, ktoré boli používané len na testovacie účely a z pkratického hľadiska tam nemali čo hľadať. * Napriek tomu, že si myslím, že dohodnuté dokunikačné prostriedky boli v poriadku, v ďalšom projekte by som určite zvažoval možnosť telefonického kontaktu na ostatných členov skupiny, kedže sa stalo, že jeden člen nebol online v čase na ktorý sme sa dohodli a nebola tak možnosť sa s ním skontaktovať. * Tady to zas tak velký problém nebyl, jelikož to byl relativně menší projekt (z časového hlediska) a s menším počtem lidí, ale v případě větších projektů (které nás v dalších ročnících čekají) bych určitě nevolil FB Messenger, protože ačkoliv je sice pohodlný, velmi často se do něj míchají i věci netýkající se projektu samotného a je nepřehledný... * Data sme zdieľali pomocou git a Facebook chat. Nebol tam takmer žiadny problém okrem pár maličkostí pri gite. V našom týme bol aj windowsák a problém nastal, keď sa na Linuxe spravil screenshot, ktorý sa potom pushol na git. Screenshot obsahoval v názve nepovolené znaky pre windows, preto keď sa spustil príkaz pull ich nestiahlo do lokálneho repozitára. Problém však nastal po spustení príkazu push na windowse. Screenshoty, koré nevedel stiahnuť, vymazal. Vyriešili sme to premenovaním screenshotov. - Používání diakritiky a různých nestandardních znaků v názvech souborů je vždy rizikové - nejvíce při odevzdání. - Vždy je potřeba se podívat, jaké změny máme ve staging area. Když se omylem smaže soubor a provede commit a push všech změn... * Git - Zde by stálo za uvážení využívání „rozšíření“ Gitu – Git Flow, který by práci na některých částech projektu mohl částečně zjednodušit a zpřehlednit. Ovšem v rámci časového vytížení v průběhu semestru a velikosti projektu se jedná spíše jen o drobnou výhodu. - Toto rozšíření nemám vyzkoušené, ale obecně může být zajímavé najít si vhodné rozšíření, které Vám práci zjednoduší. * Aj napriek dohode, že najneskôr do 24 hodín každý odpovie, sa stávalo že niekto dlho neodpovedal. Možné riešnie: poskytnúť ostatným členom tímu svoje tel. číslo, aby v prípade že sa rieši niečo dôležité, bolo možné zavolať danému človekovi a upozorniť ho na to. * Na komunikáciu sme používali Slack čo prinášalo veľké výhody (zobrazovali sa všetky zmeny v Gite, Trelle a hodnotení okamžite). No nie každý si otváral Slack pravidelne čo viedlo k dlhším odozvám. * Komunikace - přes facebook byla rychlá ale člověk se v ní ztrácel, hlavně pokud jsme řešeli více aspektů projektu naráz - např. zároveň GUI a Matematickou knihovnu, člověk si to musel několikrát pročíst aby věděl, pro příště bych spíše zvolil komunikační kanál kde bude možně nějak oddělit probíraná témata. * KOMUNIKÁCIA CEZ FACEBOOK - keď sa riešilo viac problémov naraz bolo to veľmi neprehľadné. Keď človek chcel niečo nájsť čo sa už riešilo trebalo veľa scrollovať. * Pokud jde o spolupráci, tak především díky systému GIT jsme si všichni mohli přijít na své a paralelně řešit problémy. * Prvním problémem komunikace v týmu bylo stanovení populárních nicméně nepříliš efektivních komunikačních kanálů. Sdílený dokument téměř nebyl využit, kvůli zdlouhavosti zápisu a od prvního týdne řešení se využíval zejména chat na facebooku. Facebook není příliš vhodným nástrojem ke komunikaci kvůli špatně dohledatelné historii, nemožnosti zvýrazňovat důležité zprávy, ztrátě přehlednosti pro člena, kterému tzv. uteče vlákno zpráv. Díky špatně zvolenému komunikačnímu kanálu docházelo k informačnímu šumu a zkreslení informací, což vyústilo ve zbytečné zdržování a předělávání věcí kvůli nekompatibilitě. Ostatní ------- * Lenost - nejhorší nepřítel a jeho stejně nevítaný kamarád málo motivace něco dělat společně dokážou divy a jejich 100% řešení neexistuje. Já to řešil spánkem, pěkně jsem se vyspal a poté jsem kódil. - Únava snižuje produktivitu, takže vyspat se může být řešením.