Web application for budget management.

• Target skills for:

  • searching for and evaluating information

  • expressing oneself orally: posture, body language, intonation

  • dynamism

  • defending one's opinion and arguing

  • quality and richness of the French language

  • organisation: respecting the time allowed, deadlines, the context of the oral production ("D-Day of Positive Impact" Event), etc.

• Duration: From December to February

Within each self-organised team, a SM is appointed and possibly a PO (if one of the students feels that he or she has the necessary business approach).

• As PO, the consistency between the choices in the sprint backlog and the objective defined by the team in the context of the sprint.

• As a SM :

  • Feasibility

  • Consistency in the allocation of tasks

  • Absence of collisions: dependent/linked/blocking tasks

The number of sprints and duration of each one are determined by the teacher.

Each self-organising team must:

• Define the objective of the sprint

• Based on this objective, select the US to be processed from the Backlog (to define the Sprint Backlog), taking into account the story points (priority to units with high added value)

Each developer takes responsability for US in a concerted manner, avoiding collisions with other US (cf. step 4 of the Sprint Backlog):

• Identify the tasks for each US

• Has his/her choices validated by the team, the SM and the PO

Step 1 (By team) :

Identification of requirements expressed in the form of user stories US (Digital Brainstorm)

Each US is not yet written in the form :

as... 

I can... 

In order to...

but only with :

code Title

Step 2:

Summary of the different needs identified by each team.

Use of the INVEST matrix to determine the admissibility of each US.

The initial backlog is therefore common to all the teams, but they will each be able to develop it differently afterwards.

Step 3:

Prioritisation of backlog items :

Assessment of the story points awarded to each US using online planning poker (whole group)

Story points are awarded on the basis of 2 criteria:

• business value

• complexity (scope of the work)

Step 4:

Categorisation of items (tag per part), for a better future distribution of tasks, avoiding collisions.

See https://gitlab.com/

• What do I want from my speech?

• Step 2: Whole class
  

  • Summary of US needs

• Step 3: Prioritisation of needs

  
  

As a speaker, I want to...

• find a thesis that is important to me and that I want to defend with conviction.

• produce an organised, convincing and well informed speech.

• practise using non-verbal communication techniques to enhance the impact of my speech on the audience.

• manage my speaking time effectively so that I stick to the time available for my speech.

• get feedback on my speech from my peers to identify areas for improvement before the public presentation.

• be proud of what I have achieved.

As a member of the audience, I want to...

• be convinced, moved

• learn more about the "world of work" and "happiness".

• to be able to form my own opinion on the subject.

• have the opportunity to ask questions after the speech to clarify or debate issues.

• have a great time.

A general outline is given.

Each team is then free to develop it as it sees fit.

• Code review carried out

• User story acceptance criteria all validated

• Tests finalised and accepted by product quality stakeholders (QA -Quality Assurance-, PO, developers)

• Documentation updated

• Graphic mock-ups respected

• Delivered on a stable environment

Assessment grid as a means of checking.

Creation of a web application dedicated to banking management

• In the description, write:

  • As {actor}

  • I can {achieve}

  • in order to {gain business}.

• Add acceptance criteria (Customer+Techniques)

• Analyse dependencies (US diagram with <<include>> and <<extend>>)

• Create mock-ups

• List the operations to be performed (tasks)

• Document interface dynamics (kinematics)

• Mark the US with the ‘In progress’ label

This request will enable :

A series of automated checks (tests, conflict checking).

A request for a code review from other team members (at least 2 required).

The code review encourages emulation within the team, harmonisation of practices and of the business approach, and better knowledge of the increment produced.

CI:

Continuous integration consists of checking, when a developer merges code, that their work integrates correctly into the product (avoiding regression) through the automated execution of tests (unit, integration, functional).

Continuous integration can also carry out code standardisation processes.

CD :

Continuous deployment involves automating the deployment or release to production when a new feature is merged, to enable the customer to follow product developments as soon as possible.

CI/CD is implemented by DevOps teams.

Method used in our case: the 4Ls

For each milestone, the team identifies :

• For each milestone, the team identifies :Liked points

• Negative points (Lacked)

• Aspirations (Longed)

• Learnt

Action plan for the project retrospective on 18 Oct. 2024 :

• Seek help as quickly as possible on a US

• Work on the issues at home outside the sessions

• Consult the Product Owner for the naming of the US

• Better planning of US for better support

• Communicate more effectively within the team

• be productive outside the classroom

• make better use of AI and intensify the use of documentation

• Code sharing, better team cohesion,

• Use of AI in case of problems.

• pull the main more often to have less conflict

• consult with the team before pulling into main to avoid losing code

• Communicate within the team to resolve the problems identified

• conduct more frequent internal reviews

Use of a physical kanban with sticky notes when teams are on site.

Remote continuity:

Multiple Gitlab boards that can be customised by the teams.

In addition to enabling remote sharing, Gitlab boards have the advantage of enabling US to be viewed in columns according to specific criteria:

• developpers assigned

• workflow (Sprint, backlog, in progress, Done, to test, etc.)

• tags (thumbnails created and affixed by the team)

• Sprint

• upload resource documents

• annotate work

Check the progress of work.