# Kick-off: the course, the teams, the tools

> How the semester runs: teams of three (at most four) build the same game through four milestones that simulate sprints, with a weekly three-question scrum, GitLab as the project hub and individual scores from 0 to 10.

Source: https://laszlonemes.com/university/software-technology/kickoff · Author: László Nemes

Session 1 · Software Technology

How the semester runs: teams of three (at most four) build the same game through four milestones that simulate sprints, with a weekly three-question scrum, GitLab as the project hub and individual scores from 0 to 10.

13 min read `Waterfall vs agile` `Milestones as sprints` `Team forming` `The three scrum questions` `GitLab, Teams, UML tools` `How grading works`

In most courses you program alone, for yourself, against a deadline. In this one a team of three (at most four) builds one game together over a semester. Every team of the semester builds the same game from the same specification, and the way you build it counts as much as what you build. You will plan before you code, keep your work in GitLab issues and branches, review each other's code, and let a CI pipeline check every change.

This first session sets everything up: what the course wants from you, how the semester runs, how the team forms, which tools you use and how you are graded.

After this session you can

- explain the difference between a waterfall and an agile process, and how this course simulates sprints
- list the four milestones and what each one requires
- form a team of three (at most four) and split the competencies it needs
- answer the three scrum questions in a way that is useful to the team
- say how your individual milestone score is formed

## What the course is for

The practice part of Software Technology (*Szoftvertechnológia*) is about the **software development process**, not about one more programming language. By the end of the semester you should have been through every step of it once, in a team:

- **the process itself** – the traditional (waterfall) model and the agile one, and why teams moved from the first to the second;
- **planning and modelling** – use cases, user stories, class and database diagrams, before any code;
- **developing in a team** – splitting work, version control, merge requests, code review;
- **industry tools** – issue tracking, CI pipelines, unit testing, static analysis, releases.

> The game is the vehicle, not the goal. A team with a smaller game and a clean history of issues, branches, reviews and green pipelines is doing better than a team with a beautiful game that one person pushed to `main` the night before the demo.

## Waterfall and agile

The **waterfall model** runs the phases once, in order: collect every requirement, design the whole system, implement it, verify it, then maintain it. It is easy to plan and easy to explain. Its weakness is that the first working software appears at the very end – so a misunderstood requirement shows up when it is most expensive to fix.

An **agile** process (scrum is the most common variant) cuts the work into short **sprints** of two to three weeks. At the start of a sprint the team picks the most important items from the backlog; every day it holds a short **daily scrum**; at the end it shows a **working increment** – something that runs – and the feedback goes back into the backlog (Fig. 1).

> **Fig. 1** · Waterfall delivers once, at the end. Agile delivers a working increment every sprint, so mistakes surface while they are still cheap.
>
> *Diagram:* Waterfall runs each phase once, in order: requirements, design, implementation, verification, maintenance – working software appears only at the end. Agile picks a slice of the backlog for a sprint of two to three weeks, holds a short scrum every day, and delivers a working increment at the end of every sprint; feedback flows back into the backlog.

This course squeezes the agile loop into a semester. A **milestone is a sprint**: it ends with a demo of something that works. A **weekly session is the daily scrum**: short status, next steps, obstacles. The first milestone is the one waterfall-like step – you design before you code – because a team needs a shared picture of the game before it can split the work.

- **Backlog** – Every known requirement and task, ordered by importance. In GitLab: the open issues.
- **Sprint** – A fixed time box with a chosen slice of the backlog. Here: the weeks between two milestones.
- **Increment** – The working software at the end of a sprint – something you can run and demo.
- **Scrum** – A short status meeting with three questions per person. Here: weekly, at the session.
- **Product owner** – The person who decides what the product needs. Here: your practice instructor.

## The semester at a glance

There are four milestones (*mérföldkő*), in weeks 4, 7, 10 and 13. Every week in between is a scrum session (Fig. 2).

> **Fig. 2** · Four milestones, three weeks apart. The requirement grows each time: from a design, through 30% and 90% of the use cases, to a finished, tested game.
>
> *Diagram:* A thirteen-week timeline. Milestones fall in weeks 4, 7, 10 and 13: requirements and design without code, Prototype I with git in use and 30% of the use cases, Prototype II with CI, unit tests and 90%, and the final product with clean code and a gameplay video. Every week in between is a scrum session.

| Milestone | Week | What has to be ready |
| --- | --- | --- |
| M1 Requirements and design | 4 | Use cases, use-case diagram, class diagram, database diagram – as text and diagrams on the GitLab wiki. No implementation yet. |
| M2 Prototype I | 7 | Version control working and actively used by everyone. About 30% of the use cases work. |
| M3 Prototype II | 10 | CI set up and used on every merge request, with a static-analysis check. Unit tests exist. About 90% of the use cases work. |
| M4 Final product | 13 | Clean code, thorough unit tests including edge and failure cases, every feature works. A short gameplay video. |

The jump from 30% to 90% between weeks 7 and 10 is the steepest part of the semester, and it coincides with tests in your other courses. Teams that leave it late arrive at M3 with half the game and no time. Each milestone has its own page here – [M1](https://laszlonemes.com/university/software-technology/requirements-design), [M2](https://laszlonemes.com/university/software-technology/version-control), [M3](https://laszlonemes.com/university/software-technology/continuous-integration) and [M4](https://laszlonemes.com/university/software-technology/final-product).

In your assignment

**Finish the core before the extras**

The specification has a core game and optional sub-tasks on top. Aim to finish the core first and properly. Five half-done sub-tasks are worth less than two finished ones – a feature counts when its use case works end to end, is tested and is merged.

Use **placeholders** for graphics and sound: coloured rectangles, a letter on a tile, a free placeholder sprite. Hunting for art assets in week 6 is the most pleasant way to lose a week. Swapping in real assets later is easy if the drawing code is separated from the game logic.

## Forming the team

Teams have three members, at most four, and you form them yourselves. Before the end of the first session, every team gives the instructor its members and a team name, and every member logs in once to the course GitLab server (`szofttech.inf.elte.hu`) with their faculty account – the account only exists after the first login. The team then gets its GitLab repository and a private Teams channel.

Before you start planning, look at the [Hall of Fame](https://szofttech.inf.elte.hu/hall-of-fame) on the course GitLab: the highlighted projects of earlier semesters – finished games together with their repositories, issues and pipelines.

A good team covers these competencies between its members – not every member needs all of them:

| Competency | What it means in this project |
| --- | --- |
| Programming | In one language for the whole team. Java and C# get the most support. |
| UI | Windows, menus, drawing the game board, input handling. |
| Version control | Branches, merge requests, resolving conflicts – everyone does it, one person should be good at it. |
| CI | Writing and fixing the pipeline; knowing the build tool (Gradle, Maven, dotnet, Unity batch mode). |
| Testing | Unit tests for the model, edge cases, coverage. |
| Organisation | Keeping the board, the milestones and the wiki up to date. |

Good to know

**Engines and other languages**

Other languages and frameworks are allowed, but help is more limited. Teaching Unity, Godot or PyGame is not part of the course: if you choose one, learning it is extra work your team takes on. For Unity and Godot only the versions announced at the start of the semester run on the course CI servers – in practice the current LTS versions – so install exactly those. With Godot you write C#; GDScript is not accepted.

To get the team talking, everyone answers four questions in the first session: Which language would you like to build the game in? Have you used version control before (git, SVN)? Have you used a CI tool (GitLab CI, GitHub Actions, Jenkins, Azure DevOps)? Have you built anything in a team?

## The weekly scrum

Most sessions run as a scrum meeting per team, in person. Every member answers three questions, then the rest of the session is for technical discussion and working together (Fig. 3).

> **Fig. 3** · A week of the course. The scrum is short; what makes it useful is that the answers match what GitLab shows.
>
> *Diagram:* One week of the course as a loop: the scrum at the session, where everyone answers three questions; planning the week as assigned issues; work on a branch per issue with daily pushes; review and merge through merge requests; then the next session. The three questions: what did you do since last week, what will you do by next week, is anything blocking you.

A useful answer is concrete: it names issues and merge requests, commits to something for next week, and raises a blocker while there is still time to remove it.

Two answers to the same question

```text
Weak:   "I worked on the map."

Strong: "I closed #14 (load the map from a file); its MR is merged.
         This week I take #17 (collision with walls) and review the MR for #15.
         Blocked: we haven't agreed on the save format – can we settle it today?"
```

Common mistake

**Hiding a blocker until the demo**

"I couldn't do it because the model wasn't ready" is a scrum answer from three weeks ago that nobody gave. If you are waiting on a teammate, a decision or a tool, say so in the next scrum – that is exactly what the third question is for.

Good to know

**If the team can't attend**

If the whole team can't come to a session, hold the scrum in writing on your Teams channel – in advance, with the reason. Each member still answers the three questions.

## Tools

| Tool | What you use it for |
| --- | --- |
| GitLab | The project hub: repository, issues, board, milestones, merge requests, CI pipelines – and the wiki, where the M1 design lives. One of the pillars of grading. |
| Teams channel | Private to your team and the instructor. Chat and calls outside the sessions; feedback arrives here. |
| UML editor | Any you like: StarUML or Enterprise Architect offline, diagrams.net or Creately online. |
| PlantUML | Diagrams written as text, rendered right on the GitLab wiki – so they live next to the documentation and can be reviewed like code. |

Two GitLab rules matter from day one. **Everyone works from their own account**: only your own work can be graded, and GitLab attributes commits by the e-mail address git writes into them. And **every piece of work is an issue**, assigned to a person and a milestone – the [repository setup guide](https://laszlonemes.com/university/software-technology/repository-setup) shows how to prepare the project. Set your git identity once per machine:

Once per machine

```shell
git config --global user.name "Your Full Name"
git config --global user.email "<the e-mail address of your GitLab account>"
git config --list --show-origin | grep user.   # check what git will write into your commits
```

If git itself is new, read [Git and GitHub: the mental model, in pictures](https://laszlonemes.com/blog/git-and-github) first – commits, branches, merges and remotes in a dozen figures. Everything there applies to GitLab too.

## How grading works

The instructor scores each milestone from a product owner's point of view – does it work, does it match the requirements, is the process healthy – and gives **every member an individual score** from 0 to 10 (Fig. 4). The criteria of a milestone can be announced before it.

> **Fig. 4** · Four individual scores, a minimum on each, an average at the end – and the lecture tests as a gate.
>
> *Diagram:* Each of the four milestones gives every member 0 to 10 points, with at least 4 required on each. The practice grade is the average of the four. It is awarded only if both lecture tests are passed with two thirds of the answers right; the test results don't change the grade.

- You need at least **4 points on every milestone**. There is no milestone you can sit out.
- The practice grade is the **average of the four** milestone scores.
- From M2 on, **GitLab activity weighs heavily**: your issues, commits, branches, merge requests and reviews. It shows who did what – and the scrum answers should match it.
- The milestone demo takes **5–10 minutes per team**. Different members present at different milestones; one person can't present all four.
- The lecture has a mid-term and an end-of-term test. You need two thirds right on each; they don't change the grade, but passing both is a condition of getting one.

Common mistake

**One person commits everything**

The most common pattern in weak teams: two members "help" and the third commits. In the history it looks like one person did the project – and that is how it is graded. Pair programming is fine; then take turns at the keyboard and commit from the account of whoever wrote the code.

## Summary

- The course is about the process: plan, model, develop as a team, use industry tools. The game is the vehicle.
- Milestones simulate sprints, weekly sessions simulate the daily scrum with three questions per person.
- M1 design (week 4), M2 30% of use cases with git (week 7), M3 90% with CI and tests (week 10), M4 finished and clean (week 13).
- Scores are individual, 0–10 per milestone, at least 4 each; from M2 your GitLab activity weighs heavily.
- Everyone uses their own account; every piece of work is an issue. Finish the core first; use placeholders for art.