lmasi/webzine
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Documentation: relecture, ajout de la conclusion. Dossier de configuration complété.

Browse Source
This commit is contained in:
josephine.vetu
2026-04-09 00:19:46 +02:00
parent c676019040
commit 267a50f053
8 changed files with 170 additions and 132 deletions
Download Patch File Download Diff File Expand all files Collapse all files

46
Webzine.Documentation/Rapport/equipe 1 - 2.Organisation Dev.md
View File

@@ -1,4 +1,4 @@
# Rapport d'équipe — Projet Webzine
# Rapport d'équipe - Projet Webzine
**Équipe 1**
**Formation :** Développement .NET niveau 1 / Dr1-P4
@@ -11,18 +11,19 @@
Chaque développeur s'est vu attribuer une responsabilité principale sur l'une des entités du domaine : `Artiste`, `Titre`, `Commentaire`, `Style`. Cette segmentation verticale a permis à chacun de maîtriser son périmètre tout en contribuant à l'ensemble. En pratique, les tâches couvraient systématiquement les trois couches : entité (avec ses annotations de validation), repository (logique de données), et contrôleur/vue (rendu web).
Concernant les rôles :
- Tout le monde a pu suivre "le cycle de la vie", ce qui a favorisé une bonne compréhension commune du modèle de données, de la factory aux repository.
- Au fil du projet, chaque personne a pu se spécialiser dans un domaine particulier. Le reste de l'équipe était tenu au courant à l'aide de TOS réguliers.
- Tout le monde a pu suivre "le cycle de la vie" d'une entité, ce qui a favorisé une bonne compréhension commune du modèle de données, de la factory aux repository.
- Au fil du projet, chaque personne a pu se spécialiser dans un domaine particulier (voir la partie "Répartition des tâches"). Le reste de l'équipe était tenu au courant à l'aide de TOS réguliers.
L'équipe de développement est composée de cinq membres:
| Membre | Rôle principal | Domaine |
|---|---|---|
| Joséphine | Cheffe de projet & développeuse | Dev |
| Clément B | DevOps (CI/CD) | Dev |
| Loïc | Développeur / intégration BDD | Dev |
| Baptiste | Développeur | Dev |
| Mathys | Ingénieur système et réseau | Ops |
| Membre | Rôle principal | Domaine |
| --------- | ------------------------------- | ------- |
| Joséphine | Cheffe de projet & développeuse | Dev |
| Clément B | DevOps (CI/CD) | Dev |
| Loïc | Développeur / intégration BDD | Dev |
| Baptiste | Développeur | Dev |
| Mathys | Ingénieur système et réseau | Ops |
Mathys étant le seul membre côté ops, il a travaillé en parallèle de l'équipe de développement tout en étant intégré aux dailys et aux jalons.
@@ -41,27 +42,27 @@ Chaque jalon a été ponctué d'une **code review** encadrée, qui a joué un r
### Démonstrations et supports
Les démonstrations de fin de jalon ont imposé un moment de convergence collective. Le 26 et 27 mars, la préparation du support de démo (sur Canva) a mobilisé l'ensemble de l'équipe. Ces moments ont aussi servi à clarifier les livrables attendus — notamment côté ops, où les attendus du jalon 2 (dashboard Grafana, schéma infra, HTTPS) ont été précisés lors du daily du 26 mars.
Les démonstrations de fin de jalon ont imposé un moment de travail collectif. La préparation du support de démo (sur Canva) a mobilisé l'ensemble de l'équipe.
---
## Répartition des tâches
### Joséphine — Cheffe de projet & développeuse
### Joséphine - Cheffe de projet & développeuse
Joséphine a endossé un double rôle tout au long du projet. D'un côté, elle a assuré la gestion de projet : rédaction des tickets, priorisation, animation des dailys, compte-rendus et revue de code. De l'autre, elle a contribué activement au développement : page artiste, repository Artiste, pagination, correction transversale des erreurs de controllers et de HTML.
Ce double rôle a représenté une charge de travail importante, notamment en fin de jalon où la gestion de projet et les corrections de bugs se sont superposées.
### Clément — Développeur mais surtout DevOps
### Clément - Développeur mais surtout DevOps
Clément a posé les bases de l'architecture : initialisation du dépôt Git, mise en place du patron MVC, création des factories et des controllers de base. Il a ensuite pris en charge les repositories Style et Titre, la mise à jour de l'API, la rédaction de la documentation, et la CI/CD côté tests d'endpoints.
### Loïc — Développeur / intégration BDD
### Loïc - Développeur / intégration BDD
Loïc a développé la page d'accueil dès le jalon 1, en y intégrant Bootstrap, les fausses données via Faker, puis le ViewModel. Au jalon 2, il a pris en charge la configuration de la base de données SQLite, la création du seeder, et le CRUD sur les entités Style et Artiste. Il a également travaillé sur l'optimisation de la recherche et l'intégration de l'API Spotify en jalon 3.
### Baptiste — Développeur fonctionnel
### Baptiste - Développeur fonctionnel
Baptiste a développé les fonctionnalités liées aux commentaires (modèle, vue, controller, repository) et aux styles côté administration. Il a aussi contribué à la correction des bugs. En jalon 3, il a réalisé la refactorisation des routes dans une classe `RouteConfiguration.cs` et l'implémentation d'un middleware de logging.
@@ -76,6 +77,7 @@ L'ensemble du code source, des tickets et de la documentation a été centralis
Le travail a été découpé en branches Git par fonctionnalité. Les nommages utilisés reflétaient généralement l'entité ou la fonctionnalité concernée (ex : `feat/artiste-controller`, `feat/titre-entity`, `feat/administration-dashboard`). Les merges ont été faits via des pull requests revues par au moins un autre membre de l'équipe.
Cette pratique a contribué à maintenir la qualité du code, mais elle a également constitué un **goulot d'étranglement**. Les reviews de code ont pris beaucoup de temps. Il y a eu quelque fois un volume important de PR ouvertes simultanément. L'équipe n'avait pas défini en amont de règles sur la taille maximale des PR ou les délais de review.
A partir du jalon 3, les revues de code ont été réparties entre chaque membre de l'équipe.
### Qualité du versioning
@@ -83,18 +85,10 @@ La discipline de versioning s'est améliorée au fil du projet. En jalon 1, Bapt
### Décisions d'architecture en daily
Un point notable de l'organisation est que plusieurs décisions techniques structurantes ont été prises *collectivement*, pendant les dailys en demandant à l'intervenant, plutôt qu'en amont lors d'une phase de conception :
Un point notable de l'organisation est que plusieurs décisions techniques structurantes ont été prises _collectivement_, pendant les dailys en demandant à l'intervenant, plutôt qu'en amont lors d'une phase de conception :
- La stratégie de double repository (`repositorydb` pour la prod PostgreSQL, `repositorylocal` pour le dev SQLite) — décidée le 25 mars
- La stratégie de double repository (`repositorydb` pour la prod PostgreSQL, `repositorylocal` pour le dev SQLite) - décidée le 25 mars
- Le découpage de `Program.cs` en sous-classes pour éviter un fichier trop long
- Le remplacement du ViewModel Dashboard par un DTO pour respecter la séparation des couches — identifié le 1er avril
- Le remplacement du ViewModel Dashboard par un DTO pour respecter la séparation des couches - identifié le 1er avril
Cette approche a permis de s'adapter aux contraintes au fur et à mesure, mais elle a aussi engendré du refactoring qui aurait pu être évité avec une conception initiale plus approfondie.
---
## Montée en compétences
La progression de l'équipe est visible tout au long du projet. Dès les premiers jours, l'architecture MVC est comprise. L'équipe se familiarise avec Bootstrap et les bonnes pratiques Git en cours de jalon 1. Loïc et Clément explorent Faker pour les données de test dès les premiers jours.
En jalon 2, l'équipe maîtrise suffisamment l'architecture pour introduire la couche repository et abstraire l'accès aux données. En jalon 3, les sujets abordés sont les middleware, la CI/CD, les différents seed et les hooks Git.