Dans le cadre du Bloc 1 – B1.4 « Travailler en mode projet » du BTS SIO option SLAM, j’ai réalisé un TP portant sur les méthodes de gestion de projet. Ce TP m’a permis de découvrir et pratiquer deux approches : la méthode agile Scrum et la méthode classique Gantt.
🔄 Partie 1 – Méthode Agile : Scrum
Qu’est-ce que Scrum ?
Scrum est une méthode agile itérative et incrémentale : le produit est développé par petites étapes successives appelées sprints, ce qui permet de tester et d’améliorer le produit tout au long du projet, plutôt qu’en une seule fois à la fin.
Les rôles dans un projet Scrum
Il existe 3 rôles principaux :
- 🧑💼 Product Owner (PO) : représente le client, définit les priorités et gère le backlog
- 🏃 Scrum Master : garant de la bonne application de la méthode, il lève les obstacles
- 👨💻 Équipe de développement : développeurs, testeurs, designers… qui réalisent les fonctionnalités
La User Story
Une user story est une description simple d’un besoin fonctionnel, rédigée du point de vue de l’utilisateur.
Format standard :
« En tant que [utilisateur], je veux [action] afin de [bénéfice] »
Exemple concret :
« En tant qu’administrateur, je veux pouvoir créer un compte utilisateur afin de gérer les accès à l’application. »
Les user stories permettent de découper le projet en fonctionnalités compréhensibles par tous, aussi bien par l’équipe technique que par le client.
Le Product Backlog
Le Product Backlog est une liste ordonnée de toutes les fonctionnalités à développer pour le produit. Il contient :
- Les user stories
- Les bugs à corriger
- Les améliorations techniques
C’est le Product Owner qui le gère et le priorise. Il évolue tout au long du projet.
Le Sprint : les étapes d’une itération
Un sprint dure maximum 4 semaines (généralement 2 semaines). Voici ses étapes :
Sprint Planning → Développement + Daily Scrum → Sprint Review → Sprint Retrospective
| Étape | Description |
|---|---|
| Sprint Planning | L’équipe sélectionne les user stories à réaliser et planifie les tâches |
| Développement | L’équipe développe les fonctionnalités choisies |
| Daily Scrum | Réunion quotidienne de 15 min pour synchroniser l’équipe |
| Sprint Review | Démonstration du travail réalisé au client |
| Sprint Retrospective | L’équipe identifie les axes d’amélioration pour le sprint suivant |
Le Burn Down Chart
Le Burn Down Chart est un graphique qui représente l’avancement du sprint dans le temps.
- 📉 L’axe Y représente le travail restant (en points ou heures)
- 📅 L’axe X représente le temps (jours du sprint)
Idéalement, la courbe descend progressivement jusqu’à zéro en fin de sprint. Si elle descend moins vite que prévu, il y a du retard.
C’est le Scrum Master qui le met à jour quotidiennement.
La Mêlée quotidienne (Daily Scrum)
| Caractéristique | Détail |
|---|---|
| Fréquence | Tous les jours |
| Durée | 15 minutes maximum |
| Participants | Toute l’équipe de développement + Scrum Master |
| Utilité | Synchronisation, détection rapide des blocages |
Chaque membre répond à 3 questions :
- Qu’ai-je fait hier ?
- Que vais-je faire aujourd’hui ?
- Ai-je des obstacles ?
📊 Partie 2 – Méthode Classique : Gantt avec GanttProject
Présentation
J’ai utilisé le logiciel GanttProject pour planifier un projet de développement web composé de 17 tâches réparties sur une équipe de 7 personnes, avec un démarrage le 1er avril.
Initialisation du projet
J’ai configuré le projet en :
- Définissant le calendrier (pas de travail le week-end, jours fériés français)
- Créant des rôles personnalisés : Éditeur de contenu, Administrateur système
- Ajoutant les 7 ressources : Chef, Graphiste, Éditeur, Dev1, Dev2, Analyste, Admin
Saisie des tâches et dépendances
J’ai saisi l’ensemble des tâches avec leurs durées, antériorités et ressources associées. Voici un extrait :
| ID | Tâche | Durée | Ressource(s) |
|---|---|---|---|
| 2 | Définition du cahier des charges | 12j | Chef |
| 1 | Lancement du projet | 1j | Toute l’équipe |
| 6 | Développement des contrôleurs | 20j | Dev2 |
| 13 | Développement des vues | 25j | Dev1, Dev2 |
| 17 | Mise en prod / test montée en charge | 4j | Chef |
Analyse du chemin critique
Le chemin critique est la séquence de tâches la plus longue du projet. Tout retard sur ces tâches décale directement la date de fin du projet.
➡️ Suite à des difficultés sur la tâche 6 (développement des contrôleurs) qui prend 2 jours de plus : comme cette tâche est sur le chemin critique, la date de fin du projet est repoussée de 2 jours.
Analyse des marges
La marge d’une tâche représente le retard maximum qu’elle peut prendre sans impacter la date de fin du projet.
Pour les tâches graphiques (8, 9, 11) :
- Cas 1 – Absence de 5 jours : la marge absorbe le retard ✅ → pas d’impact sur la date de fin
- Cas 2 – Absence de 15 jours : le retard dépasse la marge ❌ → la date de fin est repoussée
⚖️ Comparaison des deux méthodes
| Critère | Méthode Classique (Gantt) | Méthode Agile (Scrum) |
|---|---|---|
| Planification | Précise dès le départ | Progressive et adaptable |
| Flexibilité | Faible | Forte |
| Détection des risques | Tardive | Rapide |
| Budget | Facile à estimer | Difficile à fixer |
| Idéal pour | Migration de données, projets bien définis | Développement logiciel, besoins évolutifs |
💡 Ce que j’ai appris
- L’importance du chemin critique pour anticiper les retards
- L’utilité des marges pour gérer les imprévus humains (absence, maladie…)
- Comment planifier un projet réaliste avec des dépendances entre tâches
- La gestion des ressources humaines dans un projet informatique
Comments are closed