O kurzu 4IT580

Náplň a požadavky

Cílem předmětu je umožnit studentům prakticky si vyzkoušet realizaci projektu vývoje moderní webové aplikace v agilně řízeném týmu, a to v celém rozsahu od produktové myšlenky až po funkční MVP. Předmět umožní studentům řešit reálné problémy, se kterými se při vývoji webové aplikace agilním způsobem setkají.

Předmět reaguje na proměnu softwarového inženýrství spojenou s nástupem vývoje s podporou AI agentů. Těžiště práce se přesouvá od ručního psaní kódu k porozumění zadání, k práci se zadavatelem a k udržování kvalitní specifikace, na jejímž základě agent kód generuje. Studenti si proto vedle technické realizace osvojí zejména přístup shift-left: pochopit, jaký problém zadavatel skutečně řeší, ověřit jej u koncových uživatelů a navrhnout řešení, které nemusí odpovídat doslovnému znění původního zadání.

Studenti pracují v tříčlenných týmech, každý tým po celý semestr na jednom projektu pod vedením dedikovaného product ownera z praxe. Zadání dostávají v podobě stručného briefu odpovídajícího skutečným poptávkám od zákazníků — zadání je neúplné, obsahuje nedomyšlené i vzájemně si odporující požadavky a vyžaduje průběžný dialog se zadavatelem.

První část semestru je věnována produktovému discovery (analýza zadání, lean canvas, personas, rozhovory s koncovými uživateli, tvorba backlogu a wireframů) a vrcholí celodenním workshopem. Zbývající část semestru probíhá iterativně ve dvoutýdenních sprintech s pravidelnými prezentacemi přírůstků a zpětnou vazbou zadavatele. Pro vývoj se využívají technologie React, Node.js a GraphQL.

Vstupní předpoklady předmětu: student má obecný přehled o tom, jak vzniká software, a má za sebou předměty, ve kterých se vývoj softwaru řeší. Znalost konkrétních technologií použitých v projektu není podmínkou — vzhledem k využití vývoje s podporou AI agenta je podstatnější porozumění principům vývoje, schopnost číst a posoudit cizí kód a ochota pracovat v týmu. Předmět dále předpokládá, že si student po dobu semestru zajistí vlastní licenci k nástroji pro vývoj s podporou AI agenta.

Je doporučeno předchozí absolvování některého z předmětů zaměřených na vývoj softwaru, webových aplikací nebo návrh uživatelských rozhraní, například 4IT573 Základy Node.js, 4IT427 Základy programování v React.js, 4ME486 Design uživatelských rozhraní nebo 4IZ571 Vývoj pokročilých webových aplikací v PHP.

Předmět pokrývá následující tematické okruhy oblasti vzdělávání Informatika: Programování, Softwarové inženýrství, Uživatelská rozhraní.



Způsob hodnocení

Studenti mohou během semestru získat až 100 bodů v následující struktuře:

  • přednášky (workshopy) – 11 bodů 
  • cvičení – 11 bodů
    • 11b za účast (tedy 1b za každé cvičení)
    • 5b za splnění úlohy na konci cvičení
  • projekt – 70 bodů
    • první část projektu je produktová discovery za 20 bodů
    • poté následuje 5 implementačních sprintů po 10ti bodech za sprint
      • poslední sprint je ve zkouškovém období a finální prezentace je v polovině ledna
  • hackathon – 8 bodů (celodenní účast na hackathonu v pátek mimo prostory VŠE)

Konkrétní bodování za jednotlivé sprinty probíhá následovně:

  1. Vedení kurzu a product owner ohodnotí týmové plánování sprintu hodnotou 0-100 % za včasnost plánování a jeho formální správnost.
  2. Vedení kurzu ohodnotí týmové sprint review hodnotou 0-100 % za spokojenost s výsledkem a prezentací.
  3. Product owner ohodnotí týmové sprint review hodnotou 0-100 % za spokojenost s výsledkem a průběhem tvorby (pokud je product owner student – člen týmu, toto hodnocení se přesouvá na vedení kurzu).
  4. Všechna tři hodnocení se zprůměrují (např. 85 %) a tímto průměrem se násobí maximální možný počet bodů 10 bodů * počet členů týmu (např. pro 5ti-členný tým by součet byl max. 50 bodů, který mohl tým za sprint získat. Body se zaokrouhlí na celé číslo nahoru a tím se získá bodové ohodnocení za tento sprint pro daný tým (např. 43 bodů).
  5. Tyto body si mezi sebe rozdělí členové týmu na základě vzájemné dohody, jak kdo v daném sprintu pracoval . Team leader nahlásí do 3 dnů od sprint review počet bodů pro jednotlivé členy v týmu (např. Karel 8b, Monika 10bodů, Pepa 5bodů, Simona 10bodů, Šimon 10 bodů). Můžete tak tedy sami reflektovat skutečnou práci na projektu napříč týmem.
  6. Zvláštní pravidla:
    • Za jeden sprint může jednotlivec v rámci přerozdělování bodů v týmu dostat i více bodů než 10 (ve finální prezentaci 15bodů), maximálně však o 2 body více než je maximum (tedy 12b nebo 17b).
    • Počet přidělených bodů na jednoho zaokrouhlete na celá čísla.
    • Za finální sprint je nutné, aby tým obdržet minimálně 50% bodů pro úspěšné absolvování kurzu. V případě, že se tak nestane, bude řešit vedoucí kurzu s TeamLeaderem celou situaci a buď celý tým nebo určití jedinci dostanou z kurzu za 4.

Přepočet bodů na konkrétní známky odpovídá standardům VŠE.

  • Co si pohlídat na Sprint Review:
    • ve většině případů budete ukazovat aplikaci před ostatními studenty v rámci pondělní přednášky
    • časový limit bude na přednáškách vždy 10min
    • Ukazujte aplikaci na produkčním serveru (rozděláné úkoly můžete ukázat i na localhostu, ale měl by to být zlomek práce)
    • Ukažte vždy každy úkol v GitLabu issues a porovnejte zadání s realizací přímo v aplikaci.
    • Pokud je něco hotové pouze z části (např. pouze FE). Okomentujte to.
    • Nezapomeňte ukázat a zkontrolovat responzivitu dané featury
    • Zmiňte co se nestihlo a v jakém je to stavu
    • Pokud je cokoliv navíc co chcete navíc a nebo co není vidět, okomentujte to.
  • Co si pohlídat pro zisk plného počtu bodů:
    • Hodnocení Sprint Review v tomto předmětu je velice podobné hodnocení spokojenosti reálného zákazníka a to je vždy subjektivní a nedá se přesně definovat co je potřeba splnit pro 100% bodový úspěch. I přesto však vězte, že každé naše hodnocení se vás snaží někam posunout a nikdy za tím není snaha si na vás cokoliv kompenzovat 🙂
      1. Připravte si scénáře, které chcete ukázat a připravte si k tomu data, které budete potřebovat, abyste to nevymýšleli na koleni. Scénáře ukazujte tak, jako byste vaši aplikaci prodávali investorům a ne pouze prezentace z technického pohledu, že vám funguje formulář.
      2. Vše si otestujte, ať si buď stihnete chyby opravit před Review a nebo ať aspoň sami víte na Review co vám nefunguje a profesionálně říci, že tady je chyba a že o ní víte, než se zaseknout při prezentaci s tím, že vidíte chybu poprvé.
      3. Zkontrolujte si responzivitu všech stránek. Každý vývojář má mobil, tak si to na něm zkuste před Review.
      4. Businessově orientovaný zákazník se vždy zaměřuje více na to jak věci vypadají a fungují než jak jsou naimplementovány (na to se zaměřují cvičící). Proto si dejte práci s tím, aby bylo vaše řešení dotažené a neodfaknuté ze strany frontendu. To neznamená, že to musí mít nejhezčí design, ale musí být znát, že jste si dali s daným úkolem práci.
      5. Nespoléhejte na to, že to co je psáno to je dáno a že je to kompletní. Ukazujte průběžně vaší práci Product Ownerům během sprintu a ptejte se jich na zpětnou vazbu. To jako gesto samo o sobě zvýší spokojenost + odhalí maličkosti, které si můžete opravit ještě před Review.
      6. Prodejte i práci, která není vidět a udělali jste ji (Backend, CI/CD, Refactoring, unit testy….)
      7. Dejte si pozor na prezentaci abyste se drželi důležitých věcí, ukázali vše z pohledu uživatele a vešli se do časového limitu.
      8. Komunikujte komunikujte komunikujte!