Týmový projekt je velmi důležitou částí bodového hodnocení v tomto předmětu, jeho motivací je naučit vás pracovat jako tým vývojářů – ve čtyřčlenném týmu už můžete zažít plnohodnotnou zkušenost vývoje uceleného softwaru.
Vašim úkolem bude vyvinout komplexní projekt od zadání až po stav, ve kterém by bylo možné ho vydat. Budete se muset naučit rozdělit si práci mezi členy týmu, podobně jako na skutečných projektech v reálném světě (ať už akademickém nebo průmyslovém). Dopředu bychom vás rádi varovali, že práce na týmovém projektu zabere netriviální množství času i úsilí, proto doporučujeme patřičně nastavit vaše očekávání s projektem a tím pádem i s tímto předmětem.
Pro přehlednost zde zveřejňujeme ve formě tabulky harmonogram důležitých milníků týmových projektů. O jednotlivých bodech blíže pojednává zbytek této sekce Interaktivní osnovy.
| Týden semestru | Datum a čas | Věc |
| 3. | pondělí 2. 10. 2023 v 20:00 | zveřejnění zadání projektů |
| 4. | pondělí 9. 10. 2023 v 20:00 | spuštění přihlašování pro 1 člena týmu |
| 4. | středa 11. 10. 2023 v 20:00 | spuštění přihlašování pro zbývající členy týmu |
| 4. – 10. | 9. 10. 2023 – 20. 11. 2023 vč. | změny v sestavě týmu |
| 4. – 10. | 9. 10. 2023 – 20. 11. 2023 vč. | možnost schválení vlastního zadání projektu |
| 10. | pondělí 20. 11. 2023 v 24:00 | ukončení přihlašování a změn v sestavě týmu |
| NA | nejpozději 1. 1. 2024 | zveřejnění termínů obhajob a spuštění přihlašování na obhajoby |
| NA | během celého zkouškového období | obhajoby týmových projektů |
| NA | 3 dny před zvoleným termínem obhajoby | odevzdání projektu, ukončení práce na projektu |
Zadání projektů jsou relativně stručné a jen přibližně popisují, co se od vás bude očekávat. Chceme, abyste projekt vyvíjeli podle vlastní intuice a naučili se sami specifikovat požadavky podle toho, co dává pro daný software rozumný smysl. Vždy však můžete svá rozhodnutí konzultovat, ať už s vašimi spolužáky, se svými cvičícími, nebo na předmětovém Discord serveru v kanále #topics.
Zadání projektu budou dostupné v ISu v rozpisu Týmové projekty, k němuž se dostanete skrz agendu
Student > PV281 > Rozpisy > Týmové projekty, nebo pomocí následujícího odkazu:
Zadání týmových projektů budou zveřejněna v pondělí 2. 10. 2023 v 20:00.
Obecně máte během vývoje vašeho projektu volnou ruku co se týče jakýchkoliv rozhodnutí (volba databáze, architektury, knihoven, ...), ovšem s jednou výjimkou.
Novinkou v tomto běhu semestru je, že zakazujeme používat frameworky/knihovny z JavaScript/TypeScript ekosystému pro tvorbu frontendu vaší aplikace. Jinými slovy musíte při vývoji projektu pro frontend využít frameworky/knihovny dostupné v Rustu, jakými jsou například Leptos, Yew, Askama, Maud aj.
Zde je důležité říct, že nezakazujeme občasné použití kusů JavaScript kódu pro client-side skriptování v HTML apod. Důležité je, aby nebyl v JS/TS napsaný celý frontend.
V minulosti se nám stávalo, že nadpoloviční část projektů tvořil frontend napsaný například v Reactu, do kterého byla delegovaná i část logiky aplikace, takže ve výsledku tvořil Rustový kód poměrně malou část daného závěrečného projektu předmětu PV281 Programování v Rustu.
Z tohoto důvodu jsme se rozhodli frontend v technologiích z JS/TS světa zcela zakázat.
Přihlašování na projekty bude možné od pondělí 9. 10. 2023 v 20:00, tj. ihned po přednášce ve 4. týdnu semestru. Přihlášení probíhá u daného tématu v agendě Rozpisů kliknutím na tlačítko Přihlásit se.
Nejprve bude umožněno přihlášení jednoho člena týmu, nejčastěji tzv. teamleadera (což však není žádná oficiální role, jak tomu může být v jiných předmětech). Přihlašování probíhá formou časové soutěže, tedy kdo dřív přijde, ten dřív mele. S odstupem pár dnů bude umožněno přihlášení i ostatním členům týmu, konkrétně od středy 11. 10. 2023 v 20:00. Prosíme, abyste respektovali, pokud už na nějaké téma bude někdo přihlášený, a nesnažili se na dané téma protlačit, aniž byste byli v jeho týmu.
Přihlašování na projekty se uzavře 20. 11. 2023 o půlnoci. Do té doby zůstane možnost přihlášení otevřená, tedy pokud ještě nebudete členem týmu nebo se jako tým rozhodnete s výběrem zadání počkat, poprvé se přihlásit k zadání můžete i později. Doporučujeme však tuto volbu neodkládat, neboť je vhodné mít na projekt co nejvíce času. Pokud však ani po 20. 11. 2023 nebudete přihlášeni na žádný projekt, hrozí vám zisk známky N pro nesplnění požadavků na úspěšné ukončení předmětu.
Pro hledání týmu můžete využít mimo jiné i kanál #looking-for-a-team na předmětovém Discord serveru. Členové týmu mohou patřit do různých seminárních skupin.
Novinkou v tomto běhu předmětu je fakt, že v období mezi 9. 10. 2023 a 20. 11. 2023 vč. máte možnost bez problému měnit složení týmu na projekt.
Pokud ve výše zmíněném období budete chtít
obraťte se prosím s žádostí o změně na našeho koordinátora projektů, Petra Wehrenberga (Discord: @fasaloft, email: 485059@mail.muni.cz). Nehrozí vám žádný postih, pouze z naší strany musíme zajistit administrativu přesunu studentů v agendě Rozpisů v ISu.
Samozřejmě chápeme, že ne vždy je fungování týmu jednoduché. Pokud by se ve vašem týmu vyskytly problémy i po skončení doby bezproblémových změn týmu, jako např. náhlá nekooperativnost člena týmu, rozpad týmu, odchod člena týmu z předmětu skrze žádost na studijní oddělení aj., ani tehdy se nebojte napsat email či zprávu koordinátorovi, který váš problém bude řešit individuálně.
Pokud by vám žádné z předepsaných zadání nevyhovovalo, nebo zkrátka máte nápad na projekt, můžete během doby přihlašování na projekty vymyslet a nechat si schválit vlastní zadání projektu.
Abychom uznali vaše vlastní zadání, musíte ho sepsat a poslat vašemu cvičícímu
/ vašim cvičícím na email či Discord. Ve výsledku o něm bude rozhodovat
celý organizační tým předmětu, který vyhodnotí jeho rozsáhlost,
obtížnost a proveditelnost. Pokud aktuální zadání nebude splňovat
požadavky kladené na týmové projekty, dáme vám na něj zpětnou vazbu a vy
se můžete rozhodnout zadání vylepšit.
Po odsouhlasení vlastního zadání vám v ISu vypíšeme vlastní téma projektu a rovnou vás k němu přihlásíme, o čemž by vám měl přijít informační email. Pokud by se posléze váš tým rozhodl změnit své téma projektu, odsouhlasené zadání se stane veřejným a bude se na něj moct přihlásit libovolný tým.
V souvislosti s vlastními zadáními projektu si dejte pozor na následující úskalí:
Nejpozději do konce kalendářního roku 2023 budou vypsány termíny obhajob, rovněž v agendě rozpisů, přičemž u každého termínu bude napsané, kteří organizátoři tohoto předmětu se ho budou účastnit:
Termíny obhajob budou rozprostřené po celou dobu zkouškového období semestru podzim 2023, tj. do pátku 16. 2. 2024.
Za jeden tým se jeden člověk přihlašuje k jednomu termínu obhajoby. Po celou dobu bude možnost změny přihlášení na termín obhajoby. Pokud bude nový termín volný, přehlášení jednoduše provedete sami, v opačném případě můžete případné směny termínů obhajob poptávat nebo nabízet v kanále #presentation-exchange na předmětovém Discord serveru.
Novinkou letošního běhu předmětu je odevzdávání projektu s třídenním předstihem před obhajobou. Odevzdáním projektu se rozumí:
project-submission z větvě, na které jste aktivně projekt vyvíjeli (main, dev apod.). Až do obhajoby do této větve nesmíte přidávat žádné nové commity.Developer na Gitlabu nebo jí ekvivaletní na jiných platformách.Pokud by váš tým byl přihlášený k (fiktivní) obhajobě v pátek 19. 1. 2024 v 14:00, musíte projekt odevzdat do půlnoci v úterý 16. 1. 2024.
Stejný termín odevzdání (úterní půlnoc vč.) by platil i pro další tým přihlášený například na obhajobu v pátek v 19:30.
Čas mezi odevzdáním projektu a jeho obhajobou nám umožní blíže posoudit jeho kód a mít připravené případné otázky pro samotnou obhajobu.
Očekáváme, že kód ve větvi project-submission bude sestavitelný, spustitelný a případné odlišnosti od standardního spuštění pomocí příkazu cargo run (např. použití kontejnerizace) budou popsány v přiloženém souboru README.md. Zkrátka by odevzdaný kód měl být production-ready.
V projektu kromě jeho sestavitelnosti a spustitelnosti také požadujeme nějaká reprezentativní data. Například nechceme v každém projektu vidět uživatele someuser123 a položky Foo a Bar.
Pokud váš projekt pracuje s databází (např. e-shop), tak si vyhraďte čas a pomocí nástrojů jako jsou například Mockaroovygenerujte databázová data / texty v aplikaci tak, abyste projekt obhajovali v takové podobě, jako byste měli investorovi ukazovat vaši aplikaci s účelem ji prodat.
Pokud do větve project-submission mezi odevzdáním projektu a obhajobou přibyde nějaká změna, ať už omylem nebo cíleně ve snaze něco na poslední chvíli opravit, takováto situace může být na obhajobě bodově penalizována.
Obhajoby budou probíhat online v hlasovém kanálu #project-defence na našem předmětovém Discordu, kam vás přetáhneme, když se předtím připojíte do kanálu #waiting-room. Očekává se účast všech členů týmu. V kanálu #project-announcements můžeme zveřejňovat důležité informace o průběhu obhajob (zpoždění, technické potíže, ...), proto mu věnujte v den vaší obhajoby pozornost.
Obhajoba bude trvat cca 20 minut. Během nich představíte v rychlosti (max. 2 minuty) svůj projekt, tým a použité technologie, většinu času se budete věnovat ukázce funkční aplikace a ve zbytku času budeme probírat váš kód, který díky předešlému odevzdání budeme mít prostudovaný.
Na konci obhajoby se v rámci organizátorů krátce soukromě poradíme o vašem bodovém hodnocení, které vám v závěru řekneme – zůstaňte tedy připojeni. Za projekt můžete dostat maximálně 50 bodů, za nedostatky odhalené v kódu nebo při demu aplikace můžete nějaké body ztratit; za nadstandardní kvalitu kódu, významný přesah zadání či jiné výjimečnosti můžete naopak získat bonusové body.
Pokud jste dočetli až sem, gratulujeme. Ze zkušenosti vám zde přikládáme několik dobrých rad, které by vám měli pomoct úspěšně zvládnout týmový projekt v tomto předmětu:
Vyhraďte si na projekt dostatek času a neodkládejte práci na poslední chvíli.
Vyberte si svého scrum mastera – většinou jde o člověka s nejlepšími sociálními / manažerskými schopnostmi. Tento člověk bude dohlížet na chod a směřování projektu. Respektujte svou volbu, vést skupinu lidí je těžší, než se na první pohled zdá.
Vyberte si specialistu na infrastrukturu – člověka, který se bude starat o projekt samotný: setup repozitáře, setup projektů, git workflow, CI/CD, nasazení a testování kódu. Nastavením jistých pravidel pro práci s commity, větvemi či Merge requesty si v týmu vzájemně zpřehledníte práci.
Nevybírejte jednu osobu do více než jedné dedikované role – je jednoduché, pokud někdo zapálený udělá všechno, ale jako jediný si z projektu vezme něco cenné a ve výsledku se nikdo nenaučíte spolupracovat v týmu. Rozdělením práce mezi všechny členy týmu také předejdete situaci, kdy by jeden člověk byl single-point-of-failure.
V rámci většiny projektů budete muset nějakým způsobem řešit frontend a backend vaší aplikace. Doporučujeme si z nich vybrat dle svých osobních preferencí, někdy ale může být přínosné vyjít ze své komfortní zóny.
Jeden člen týmu nemusí mít po celou dobu zafixovanou roli. Průběžně se domlouvejte, kdo zrovna bude dělat jakou část projektu. Máme však ověřené, že relativně pevně nastavené role obvykle pomůžou odbourat prvotní bariéry při práci na týmových projektech.
Pravidelně se setkávejte, zhodnocujte dokončenou práci a naopak plánujte nové úkoly. Včas tak můžete odhalit, pokud některý člen týmu nereaguje, neodpovídá nebo nepracuje.
Vždy si testujte svůj kód, integrační testy jsou váš přítel. Ruční testovaní kódu je nejlepší přenechat člověku, který na daném kódu nepracoval a jen mu představit, co by daná část aplikace měla splňovat za funkcionalitu.
Nastavte si v repozitáři CI/CD, byť jednoduchou. Pokud si například nastavíte, aby Merge Request nešlo zamergeovat se selhanou pipeline, zabráníte tak situaci, kdy by nějaká last-minute změna zabránila sestavení projektu těsně před jeho odevzdáním.
Dělejte si párová / vzájemná hodnocení kódu (tzv. code reviews) před tím, než přidáte novou funkcionalitu do projektu. Kromě odhalení možných nedostatků také zvýšíte vzájemné povědomí o tom, na čem zbytek týmu pracuje.