STAG-AUIUI-P8VT 2025
Náplň a požadavky
Kurz AP8VT si klade za cíl naučit studenty kvalitně a efektivně vyvíjet aplikace podle moderních přístupů a postupů. Přednášky jsou realizovány také formou praktických workshopů, v rámci nichž dílčí týmy postupně budují svůj webový produkt. Cvičení se zaměřují na využívání konkrétních technologií, pomocí kterých studenti průběžně realizují týmový projekt.
Lektoři
Petr Záček Organizační záležitosti univerzity, garant předmětu, Product Owner
Jiří Urban Hlavní přednášející, organizace kurzu, Product Owner
Tomáš Juřička Hlavní cvičící
Stanislav Čermák Product Owner
Docházka
Povoleny jsou 3 absence, v opačném případě je třeba donést omluvenku od doktora.
Způsob hodnocení
Studenti mohou během semestru získat až 70 bodů v následující struktuře:
Projekt – 65 bodů
- Projekt je rozdělen do 5 sprintů, každý po 10 bodech.
- Finální sprint (ve zkouškovém období) má hodnotu 15 bodů.
Go to market – 5 bodů
- Extra body je možné získat za prokazatelnou snahu uvést aplikaci na “trh”.
- Získání a zpracování zpětné vazby od reálných uživatelů.
- Marketingové aktivity spojené s propagací aplikace
- Viditelný engagement uživatelů aplikace
Bodování projektu sestává z hodnocení dílčích sprintů (Scrum terminologie). Konkrétní bodování za jednotlivé sprinty probíhá následovně:
- Vedení kurzu a product owneri ohodnotí increment každého sprintu hodnotou 0-100 % za plánování a jeho formální správnost, dodané množství práce (increment), komunikaci a projev v průběhu sprintu, prezentaci při sprint review.
- 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říklad 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ů).
- Tyto body si mezi sebe rozdělí členové týmu na základě vzájemné dohody, jak kdo v daném sprintu pracoval.
- Tým je povinen nahlásit do 3 dnů od přidělení bodů po sprint review počet bodů pro jednotlivé členy v týmu (např. Karel 8b, Monika 10 bodů, Pepa 5 bodů, Simona 10 bodů, Šimon 10 bodů). Tímto způsobem můžete reflektovat skutečnou práci na projektu napříč týmem. Pokud tým nestihne poslat body včas, body za sprint propadají.
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, maximálně však o 2 body více než je maximum. Počet přidělených bodů na jednoho zaokrouhlete na celá čísla. Za finální (poslední) sprint je nutné, aby tým obdržel minimálně 50% bodů pro úspěšné absolvování kurzu. V případě, že se tak nestane, bude vedoucí kurzu s týmem řešit celou situaci a buď celý tým nebo určití jedinci dostanou z kurzu známku F.
Přepočet bodů na konkrétní známky odpovídá standardům vysokých škol.
Program výuky
Lekce | Datum | Přednáška |
---|---|---|
1. Lekce | 10.2.2025 | Seznámení s předmětem, Představení projektu, Sestavení týmů, Základy Scrumu a Agilniho vývoje, Seznámení s šablonou aplikace |
2. Lekce | 17.2.2025 | Lean Canvas workshop, Continuous development & Continuous integration, Azure |
3. Lekce | 24.2.2025 | Přednáška - UI a UX / Figma / Backlog |
4. Lekce | 3.3.2025 | Sprint review 1 / Základy scrumu 2, Git, Trunk based development, small releases |
5. Lekce | 10.3.2025 | Scrum game |
6. Lekce | 17.3.2025 | Sprint review 2 |
7. Lekce | 24.3.2025 | Přednáška - Filip Kapler |
8. Lekce | 31.3.2025 | Sprint review 3 |
9. Lekce | 7.4.2025 | Přednáška - Život ve startupu s OpenVibe |
10. Lekce | 14.4.2025 | Sprint review 4 |
11. Lekce | 21.4.2025 | – Velikonoce – |
12. Lekce | 28.4.2025 | Sprint review 5 |
13. Lekce | 5.5.2025 | Finální retrospektiva / Pokročilý scrum |
14. Lekce | 12.5.2025 | Finální prezentace projektu |
1. Lekce
Seznámení s předmětem, Představení projektu, Sestavení týmů, Základy Scrumu a Agilniho vývoje
Odkaz na přednášku: Úvod
Seznámení s šablonou aplikace
Prerequisites:
- .NET 9 SDK
- Your favorite IDE (Rider recommended)
- Docker
- MSSQL Docker image (mcr.microsoft.com/mssql/server:latest) for local database. And some management tool
- Azure Data Studio for db management
Copy project a get it working locally
- Copy the project from github repo
- Run your MSSQL Docker image
docker pull mcr.microsoft.com/mssql/server:latest
docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=yourStrong(!)Password" -p 1433:1433 -d mcr.microsoft.com/mssql/server:2022-latest
- See how to use section in https://hub.docker.com/_/microsoft-mssql-server
- Create a database in your local SQL server
CREATE DATABASE "STAG-AUIUI-P8VT"
- Change your connection string in your
appsettings.json
"ConnectionStrings": { "Database": "Data Source=localhost;Initial Catalog=STAG-AUIUI-P8VT;Integrated Security=false;User ID=sa;Password=yourStrong(!)Password;TrustServerCertificate=true" },
- Build the application via
dotnet build
- Run the application via IDE or
dotnet run
- Application is running and has applied db migrations
More info
2. Lekce
Lean Canvas workshop
Continuous development & Continuous integration, Azure
- Push code to your repository in Azure devops
- Add PublishProfile.pubxml file to
Properties/PublishProfiles
- Copy the file from here
- Adjust the properties in the file
- MSDeployServiceURL
- DeployIisAppPath
- UserName
- DestinationAppUrl
- MSDeployServiceURL
- UserName
- DestinationAppUrl
- Just change the
internal-test
to your application name (provided to each team individually) - Save the file, commit and push to the azure devops repository
-
Create a build definition using YAML
trigger: - main pool: vmImage: ubuntu-latest steps: - task: UseDotNet@2 displayName: Use Dotnet 9 inputs: version: "9.0.x" - script: dotnet clean displayName: "dotnet clean" - script: dotnet publish -p:PublishProfile=PublishProfile -p:Password=$(PASSWORD) displayName: "dotnet publish"
- Go to Pipelines/Pipelines and at right, click
New pipeline
- Select Azure Repos git
- Select your repository
- Select Starter pipeline
- Replace the content with provided yaml
- Don’t save yet
- At top right, click Variables
- Create new variable called
PASSWORD
and set the value to the deploy password (provided to each team individually) - Save it
- Your build should now trigger and you can check it.
- After the build is finished your application should be running
Application Urls:
- Internal test: https://ap8vt-internal-test.azurewebsites.net/
- Al-kaida: https://ap8vt-al-kaida.azurewebsites.net/
- Hercules: https://ap8vt-hercules.azurewebsites.net/
- Kohorta: https://ap8vt-kohorta.azurewebsites.net/
- R-gen: https://ap8vt-r-gen.azurewebsites.net/
- Staci e https://ap8vt-staci-e.azurewebsites.net/
- Team jedna https://ap8vt-team-jedna.azurewebsites.net/
- Team lorax https://ap8vt-team-lorax.azurewebsites.net/
More info:
3. Lekce
Přednáška - UI a UX / Figma
Přednáška - UI a UX by Jakub Žídek
Backlog
4.Lekce
Git, Trunk based development, Small releases
5. Lekce
Scrum game
6. Lekce
Pull requests
- Move code into
src/
folder- Adjust pipeline accordingly
dotnet clean src/Application.csproj
dotnet publish src/Application.csproj ...
- Adjust pipeline accordingly
- Add solution file
.sln
to the folder, and add reference to theApplication.csproj
project - Create xUnit tests project in the solution
- Reference
Application
project in the tests project - Write your unit tests!
- Create new pull requests pipeline file
azure-pipelines-pull-requests.yml
-
Fill it with pipeline that builds your app and runs unit tests
pool: vmImage: ubuntu-latest steps: - task: UseDotNet@2 displayName: Use Dotnet 9 inputs: version: "9.0.x" - script: dotnet build src/Application.csproj displayName: "dotnet build" - script: dotnet test tests/Application.Tests.csproj displayName: "dotnet test"
- Commit this to your repository
- Create new pipeline from this existing yaml pipeline
- You can also rename the pipelines accordingly
- Go to Repos -> Branches
- Open Branch policies for your
main
branch - Set branch policies
- Atleast 2 reviewers
- Allow requestors to approve their own Changes
- Check for linked work items as optional
- Check for comment rsolution as required
- Limit merge types to squash merge
- Add build validation for branch
- Select your pull request pipeline
- Automatic trigger
- Required policy
- Expire default value
- Save
- Now you can’t commit to main branch directly, you need a pull request
- When you open PR
- A build is triggered, validating your code
- You need to get some reviewers and their approval
- Merge conflicts are checked
- Can be extended with various checks later on
- What if I really need to push some code without a PR?
- You shouldn’t
- And if you really need to, adjust your branch security, to allow yourself to bypass policies