PES Guide

Tools

Taiga and GitHub, set up properly from day one

They are the two tools checked at every delivery. Set them up well at the start and you will save work (and points) for the whole course.

Taiga, step by step

  1. Create the project with the Scrum template (PES does not use Kanban) and make it public.
  2. Add every member in Settings → Members.
  3. Modules (Settings → Project → Modules): turn on Epics, Scrum, Issues and Wiki. Under Scrum, set 3 expected sprints and, if you have it, the total points.
  4. Attributes (Settings → Attributes): statuses, points, priorities, types and tags, as you like. The custom fields are required, though.
  5. Epics: identify a few, each with its own colour.
  6. Product backlog: each story uses the As a… I want… so that… template, is linked to an epic (required), has points and has numbered acceptance criteria (1., 2., 3.). In the product backlog the criteria may still be empty.
  7. Sort the backlog by priority.
  8. Sprint: Add sprint with its dates, drag the stories in and open the Sprint taskboard.
  9. Tasks: inside each story, with estimated hours (Estimated Effort), assigned as they get picked up.
  10. Close tasks by dragging them to Closed and fill in the actual hours (Actual Effort). When every task is closed, the story closes itself and the burndown updates.

Required custom fields

Settings → Attributes → Custom fields.

WhereFieldType
User storyPriorityDropdown: Low, Medium, High
User storyAcceptance CriteriaRich text
TaskEstimated EffortNumber (hours)
TaskActual EffortNumber (hours)

You can add more if they help, but explain them in the documentation.

Recommendations

  • Set the number of sprints and the expected points so that Taiga draws the backlog chart properly.
  • Customise story and task statuses to match your definition of done.
  • Integrations (GitHub, webhooks) and plugins are optional: try them once the project is running.
Do not forget the Actual Effort. Without actual hours there is nothing to compare with the estimate, and it is one of the things that get checked.

How to hand in Taiga at each Fag

The teachers do not grade the project you work on every day, but a frozen copy of how it looked at the end of the sprint.

  1. When the sprint ends, Settings → Project → Export: a copy of the project is downloaded.
  2. New project → Import project → Taiga with that copy, with a name that says which sprint it is (e.g. BiciVerda sprint 1).
  3. Share the restored project with the teachers.
  4. Never touch it again: delivered projects must stay unchanged. Keep working on the original.

Before exporting

0/6

GitHub, step by step

  1. Your lab group's organisation already exists and follows the pattern pes2627q1-<group>-gei-upc (e.g. pes2627q1-11-gei-upc). Ask your teacher to add every member.
  2. Create the repository inside the organisation (New repository). Public or private, as you prefer.
  3. Add the team: Settings → Collaborators → Add people, with the Write, Maintain or Admin role.
  4. One person creates the project locally with the framework's command (flutter create, npm create vite, django-admin startproject...) and pushes it.
  5. Everyone else clones it and you can start working on branches.
One repository or several? If you use different technologies, more than one is better: the typical case is one for the frontend and one for the backend. Any option is fine as long as you justify it in the documentation.

If the tool already created the .git folder:

cd bici-verda-app
git remote add origin https://github.com/pes2627q1-11-gei-upc/bici-verda-app.git
git branch -M main
git push -u origin main

Replace the group and the repository name with yours.

Try it

Commit message checker

Every commit must carry the Taiga task id, and everyone should commit often and evenly, even when you code in pairs. Type a message and see which rules it follows.

0/50

The rules

    Recommended reading: How to Write a Git Commit Message.

    Gitflow or GitHub Flow?

    Pick one, write it down in the project report and stick to it. Both work for PES.

    More structure

    Gitflow

    main holds delivered versions, develop is for integration, plus feature/*, release/* and hotfix/* branches. It fits planned deliveries such as sprint ends.

    See the diagram →

    Simpler

    GitHub Flow

    Only main and short branches: create the branch, commit, open a pull request, get a review, test and merge. Ideal if you have continuous integration and deployment.

    mainfeature commitsPRmerge