[![Open in Visual Studio Code](https://classroom.github.com/assets/open-in-vscode-2e0aaae1b6195c2367325f4f02e2d04e9abb55f0b24a779b69b11b9e10269abc.svg)](https://classroom.github.com/online_ide?assignment_repo_id=16926468&assignment_repo_type=AssignmentRepo)
!Correction!
💡
|
Pensez à mettre à jour les infos dans ce fichier pour que les badges pointent sur les résultats effectifs de vos intégrations continue ou sur la bonne licence logicielle. |
|
Ce dépôt présente le projet à développer dans le cadre de la SAÉ 3.01 du BUT1 Informatique de l’IUT de Blagnac. |
Ce fichier README.adoc
(dont vous lisez sûrement le rendu HTML automatiquement effectué par GitHUb), fait partie du dépôt initial cloné à partir du lien GitHub classroom qui vous a été donné en cours (https://classroom.github.com/a/fePVlfpN).
Vous trouverez le dépôt "template" qui a servi de base ici : https://github.com/IUT-Blagnac/sae3-01-template. En complément du cours Moodle de la SAE 3.01 (cf. Liens utiles), ce dépôt template vous permet d’accéder à des exemples d’issues, de releases, ou d’autres artefacts à venir.
- Projet est réalisé par
-
-
Ducry Pierre-Louis : Scrum Master
-
Da Chao Romain : Product Owner
-
Razafinirina Mialisoa : Développeur
-
Pellegatta Matteo : Développeur
-
- Tuteur/tutrice enseignant(e) de l’équipe
Brickolo Sarl, fondée en 1924 à Blagnac, est un acteur majeur dans la conception de briques de jeu en plastique. Initialement centrée sur les jouets en bois, l’entreprise a su évoluer pour répondre aux attentes de ses clients et s’adapter aux enjeux modernes.
Depuis 2021, sous la direction d’Anna Müller, Brickolo s’engage dans une transition écologique en utilisant des plastiques recyclés pour ses produits. Parallèlement, l’entreprise investit dans une transformation numérique, avec une refonte complète de son site internet, visant à :
-
Moderniser l’expérience utilisateur.
-
Offrir une interface sobre, intuitive et accessible.
-
Mettre en avant ses valeurs écologiques.
-
Renforcer sa présence en ligne pour répondre aux besoins d’un secteur en pleine mutation.
💡
|
Cette partie de votre README.adoc peut être supprimée ou mise ailleurs.
|
Ce dépôt initial a été créé pour que tous les groupes de 2ème année aient les mêmes informations de départ.
Vous y trouverez des fichiers qui peuvent être supprimés s’ils ne vous sont pas utiles :
-
.gitignore
⇒ un fichier minimaliste des éléments à ne pas pousser en général sur vos dépôts (utiliser la commandegit add -f
pour forcer l’ajout d’un fichier Jar qui ne bougera plus, pour archive par exemple). -
.github
⇒ le répertoire qui contient des éléments de gestion de projet :-
workflows
⇒ le repertoire qui contient les actions à lancer à chaque push sur votre repo.-
blank.yml
⇒ un exemple bidon mais dont vous pourrez vérifier l’exécution correcte (1er tag)
-
-
ISSUE_TEMPLATE
⇒ le répertoire qui contient quelques templates pour vos issues.-
us.yml
⇒ Exemple de template pour les User Stories -
bug.yml
⇒ Exemple de template pour les issues de bug report
-
-
💡
|
Adaptez ces fichiers à votre projet et à votre organisation. Et inspirez-vous en pour en ajouter. |
-
Le cours Moodle sur la SAE
-
Le dépôt template qui sert de base à tous les dépôts étudiants.
-
Le lien classroom si besoin.
💡
|
Pensez à utiliser les salons Discord dédiés pour poser vos questions. |
Sprints | Documents |
---|---|
Sprint#1 |
|
Sprint #2 |
|
Sprint #3 |
|
Sprint #4 |
|
Sprint #5 |
|
Sprint #6 |
|
Sprint #7 |
|
Sprint #8 |
Livraison Finale du Site Web : Dossier WebSite
Lien du site web : Brickolo
Semaine |
ODJ |
Bilan |
49 |
||
50 |
||
51 |
||
02 |
||
03 |
J’ai l’ODJ mais pas le compte rendu ! ODJ : Préciser qui est responsable de chaque rubrique, combien de temps on y consacre, qui fera le CR. note : 0,3/3
ODJ : manque toujours qui est resp de chaque rubrique et quel temps on y consacre ! CR : Préciser ABS/Present, préciser qui a rédigé le CR. Manque CR réunion client et analyse réussites et difficultés. note : 1,95/3 note appel offre : 12,65/20
ODJ et CR: cf remarques semaine 49 !!! Merci d’en prendre compte ! note : 2,06/3
Chaque sprint (semaine) vous devrez livrer une nouvelle version de votre application (release). Utilisez pour cela les fonctionnalités de GitHub pour les Releases.
De plus ce fichier README.adoc
devra être à jour des informations suivantes :
Sprint |
Lundi AM |
Lundi PM |
Mardi AM |
Mardi PM |
Mercredi AM |
Mercredi PM |
Jeudi AM |
Jeudi PM |
Vendredi AM |
Vendredi PM |
|
Sprint 1 |
Télétravail |
Télétravail |
Télétravail |
Télétravail |
|||||||
Sprint 2 |
Télétravail |
Télétravail |
Télétravail possible |
Télétravail |
Télétravail |
Télétravail |
|||||
Sprint 3 |
Télétravail |
Télétravail |
Télétravail |
Télétravail |
Télétravail |
||||||
Sprint 4 |
Télétravail |
Télétravail |
Télétravail |
||||||||
Sprint 5 |
Télétravail |
Télétravail |
Télétravail |
||||||||
Sprint 6 |
Télétravail |
Télétravail |
Télétravail |
Télétravail |
Télétravail |
Télétravail |
Chaque nouvelle version de votre application doit être :
- Nommée version X.Y.Z
- Taggée en version X.Y.Z où X = majeure, Y = mineure, Z = patch
- Décrite dans un Changelog.md
incluant l’historique des versions.
-
Lancement continu des tests unitaires avec GitHub Actions
-
Tests fonctionnels réguliers de votre application
-
Versionner vos versions dans le fichier
Changelog.md
avec la norme Semver : https://semver.org/lang/fr/
Chaque groupe doit pousser régulièrement ses avancées.
-
Lors de la création du projet, commencez par créer une branche pour votre fonctionnalité.
-
Poussez chaque nouvelle version sur votre dépôt.