Bonjour ! Bienvenue dans cette nouvelle leçon du module sur les fondamentaux de la gestion de projet.
Dans la leçon précédente, nous avons appris à poser les fondations d'un projet en rédigeant une note de cadrage. Ce document nous a permis de définir le "pourquoi" (objectifs), le "quoi" à un haut niveau (périmètre et livrables) et le "qui" (parties prenantes). Nous avons ainsi une vision claire de la destination.
Aujourd'hui, nous allons nous attaquer à la question du "comment" en apprenant à décomposer un projet en lots de travail ou en fonctionnalités. C'est une compétence absolument fondamentale pour un futur chef de projet technique. Une fois le périmètre global défini, il faut le découper en morceaux plus petits et gérables pour pouvoir organiser le travail, l'estimer, et le suivre.
Nous explorerons deux approches principales pour cette décomposition :
- Le Work Breakdown Structure (WBS), ou Organigramme des Tâches, une méthode structurée issue de la gestion de projet traditionnelle.
- Les Epics et User Stories, l'approche privilégiée dans les méthodes Agiles comme Scrum, qui vous intéressent particulièrement.
Comprendre ces deux méthodes vous donnera la flexibilité nécessaire pour structurer n'importe quel type de projet, qu'il soit purement technique ou qu'il implique différentes équipes et métiers.
1. La décomposition par livrables : le Work Breakdown Structure (WBS)
Le WBS, ou Organigramme des Tâches en français, est une décomposition hiérarchique de l'ensemble du travail à réaliser dans un projet pour atteindre les objectifs et créer les livrables définis. L'idée est de décomposer le projet non pas en actions, mais en résultats concrets et vérifiables (les livrables).
Imaginez que vous construisez un arbre. Le tronc est le projet lui-même. Les branches principales sont les grands livrables (par exemple, "Application web", "Documentation", "Plan de formation"). Chaque branche se divise ensuite en branches plus petites, jusqu'à arriver aux plus petites feuilles, appelées lots de travail (work packages).
Pour vous familiariser avec ce concept, regardons une vidéo qui l'explique de manière très concrète.
WBS expliqué simplement ● Project Management ● Facile ● PMP ● CAPM
La chaîne Vision 6D explique très simplement le WBS en utilisant l'exemple parlant de la rénovation d'une maison. Cela vous aidera à saisir l'essence de la décomposition par livrables.
Regardez la vidéo du début jusqu'à 01:56 pour comprendre le principe de base. Ensuite, regardez la section de 07:50 à 08:58, qui définit ce qu'est un "lot de travail", l'élément le plus bas du WBS.
Maintenant que vous avez une idée générale, voyons comment cela s'applique spécifiquement à un projet informatique et quels sont les principes à respecter.
Fiche Méthode – WBS d'un Projet Informatique
Cette fiche méthode de LeCoursGratuit.com adapte le concept du WBS au monde de l'IT. Elle est parfaite pour faire le pont avec votre expérience de développeur.
Lisez attentivement la section "📚 Principes fondamentaux" pour bien comprendre les règles du jeu, notamment la "règle des 100 %". Ensuite, examinez le tableau dans la section "🧱 Exemple simplifié de WBS (Projet Application Mobile)". Il vous montrera comment un projet de développement peut être structuré.
Pour résumer, les points essentiels du WBS sont :
- Focus sur les livrables : On décompose le "quoi" (résultats), pas le "comment" (actions). Par exemple, un livrable est "Module d'authentification" et non "Coder le module d'authentification".
- La règle des 100% : Le WBS doit couvrir 100% du périmètre du projet. Ni plus, ni moins. La somme de tous les lots de travail doit correspondre à la totalité du projet.
- Exclusivité mutuelle : Il ne doit y avoir aucun chevauchement entre deux éléments du WBS. Chaque morceau de travail ne doit appartenir qu'à un seul lot de travail.
Le WBS est un outil extrêmement puissant pour clarifier le périmètre, s'assurer que rien n'est oublié et fournir une base solide pour l'estimation et la planification.
Testez votre compréhension !
Reprenons le projet de la leçon précédente : **migrer l'authentification des utilisateurs d'un système "maison" vers un fournisseur externe (ex: Auth0)**.Comment pourriez-vous structurer les deux premiers niveaux d'un WBS pour ce projet ? (Niveau 1 = le projet lui-même, Niveau 2 = les grands livrables).
Show answer
Voici un exemple de structure possible :
1.0 Projet de migration de l'authentification
- 1.1 Gestion de projet
- 1.2 Analyse et choix de la solution
- 1.3 Développement et intégration de la nouvelle solution
- 1.4 Migration des données utilisateurs
- 1.5 Tests et validation
- 1.6 Déploiement et communication
Notez que ces éléments sont des ensembles de livrables, pas des tâches. Par exemple, "1.3 Développement..." inclurait le code source, les scripts de déploiement, etc. "1.6 Déploiement et communication" inclurait les manuels pour les utilisateurs, les emails d'annonce, etc.
2. La décomposition par fonctionnalités : Epics et User Stories
Dans le monde Agile et Scrum, la décomposition se fait sous un angle différent. Au lieu de se concentrer sur les livrables, on se concentre sur la valeur apportée à l'utilisateur. Le travail est décomposé en fonctionnalités. C'est ici qu'interviennent les concepts d'Epic et de User Story.
- Une User Story (ou Récit Utilisateur) est une description simple et courte d'une fonctionnalité, racontée du point de vue de l'utilisateur. Elle est conçue pour être assez petite pour être réalisée en un seul Sprint.
- Une Epic est simplement une "grosse" User Story. C'est une fonctionnalité si vaste qu'elle ne peut pas être terminée en un seul Sprint et doit donc être décomposée en plusieurs User Stories plus petites.
Cette hiérarchie permet aux équipes de garder une vision d'ensemble (l'Epic) tout en travaillant sur des morceaux concrets et livrables rapidement (les User Stories).
Pour approfondir ces notions, commençons par une définition claire issue d'une référence du monde Agile.
Epics Agile : définition, exemples et modèles
Atlassian, l'éditeur de Jira, est une source d'autorité sur les concepts Agiles. Cet article définit clairement ce qu'est une Epic et donne des exemples concrets qui vous aideront à visualiser son rôle.
Lisez les sections "Qu'est-ce qu'une epic Agile ?" et "Exemples d’epic Agile". Concentrez-vous sur la manière dont une grande idée (comme un lancement spatial) est découpée en plus petits morceaux pour différentes équipes.
Le concept peut sembler simple, mais en pratique, il y a beaucoup de nuances. La vidéo suivante aborde les erreurs courantes et clarifie la place de ces concepts dans le cadre Scrum.
Cahier des charges déguisé 🫣 Bien utiliser User Story, Epic, Theme, Feature !
La chaîne Scrum Life propose une analyse très pertinente sur l'utilisation des Epics, User Stories, et Thèmes. Elle explique pourquoi ces termes n'apparaissent pas dans le Scrum Guide et comment les outils comme Jira influencent leur utilisation pratique. C'est une perspective très utile pour un futur leader technique.
Regardez la vidéo de 04:11 à 06:03. Cette section définit l'Epic comme une grande histoire, explique ce qu'il advient d'elle une fois décomposée, et fait un parallèle très intéressant avec le "Product Goal" de Scrum.
En résumé, dans une approche Agile :
- On part d'un grand objectif ou d'une grande fonctionnalité : l'Epic (ex: "Gestion du panier d'achat").
- On décompose cette Epic en plus petites fonctionnalités utilisables : les User Stories (ex: "En tant que client, je veux pouvoir ajouter un article à mon panier", "En tant que client, je veux pouvoir modifier la quantité d'un article dans mon panier").
- L'équipe de développement travaille sur ces User Stories une par une, au sein d'itérations courtes (Sprints).
3. Synthèse : WBS ou Epics, quand utiliser quoi ?
Vous vous demandez peut-être : "Dois-je utiliser le WBS ou les Epics ?". La bonne nouvelle est que ce n'est pas un choix exclusif. Ce sont deux outils complémentaires qui opèrent souvent à des niveaux différents.
| Critère | Work Breakdown Structure (WBS) | Epics & User Stories |
|---|---|---|
| Philosophie | Décomposition de tout le périmètre | Décomposition de la valeur utilisateur |
| Unité de base | Le livrable (un résultat, un produit) | La fonctionnalité (un besoin utilisateur) |
| Focalisation | Qu'est-ce qui doit être construit ? | Pourquoi est-ce construit ? |
| Approche type | Prédictive (Waterfall) | Adaptative (Agile, Scrum) |
| Exemple | "1.4 Documentation technique" | Epic: "Recherche de produits" |
Comment les faire cohabiter ?
Dans de nombreuses entreprises, un WBS peut être utilisé au niveau du portefeuille de projets pour définir les grandes masses de travail. Un des lots de travail de ce WBS pourrait être "Développement de la V2 du produit". Ce lot de travail serait ensuite confié à une équipe de développement Agile qui, elle, le décomposerait en Epics et en User Stories dans son propre outil (comme Jira ou Azure DevOps).
La ressource LINK (Fiche méthode WBS) l'évoque d'ailleurs dans sa section Intégration dans les outils projet, en mentionnant que le WBS peut être intégré dans un outil Agile via des "Features" ou des "Epics". C'est la preuve que les deux mondes peuvent et doivent communiquer.
Testez votre compréhension !
Pour notre projet de migration d'authentification, nous avions défini un livrable dans le WBS : "1.3 Développement et intégration de la nouvelle solution". L'un des objectifs SMART était "Augmenter le niveau de sécurité en implémentant l'authentification multifacteur (MFA)".- Considérez-vous "Implémenter le MFA" comme une Epic ou un lot de travail WBS ? Pourquoi ?
- Comment commenceriez-vous à décomposer cette Epic en quelques User Stories simples ?
Show answer
-
"Implémenter le MFA" est une Epic parfaite. C'est une grande fonctionnalité orientée utilisateur qui apporte une valeur claire (sécurité). Elle est trop grande pour être faite en quelques jours et nécessite d'être décomposée en étapes plus petites.
-
Voici quelques exemples de User Stories pour décomposer cette Epic :
- "En tant qu'utilisateur, je veux pouvoir m'inscrire au MFA en scannant un QR code avec mon application d'authentification."
- "En tant qu'utilisateur, je veux pouvoir me connecter en saisissant le code à 6 chiffres de mon application."
- "En tant qu'utilisateur, je veux pouvoir générer des codes de récupération au cas où je perds mon téléphone."
- "En tant qu'administrateur, je veux pouvoir forcer l'activation du MFA pour tous les utilisateurs."
Conclusion
Félicitations ! Vous savez maintenant comment prendre un projet, même intimidant, et le découper en morceaux gérables, que ce soit dans un contexte traditionnel ou Agile.
Les points clés à retenir :
- La décomposition est l'art de diviser un grand projet en parties plus petites pour en faciliter la gestion.
- Le WBS (Work Breakdown Structure) est une méthode de décomposition hiérarchique orientée livrables. Son unité de base est le lot de travail. C'est un excellent outil pour définir et valider l'ensemble du périmètre d'un projet.
- Les Epics sont de grandes fonctionnalités orientées valeur utilisateur, utilisées dans les contextes Agiles. Elles sont décomposées en User Stories qui peuvent être réalisées par l'équipe en une seule itération.
- Ces deux approches ne sont pas ennemies, mais complémentaires. Un WBS peut définir le cadre global, tandis que les Epics structurent le développement du produit lui-même.
Et après ?
Maintenant que nous avons décomposé le travail en unités plus petites, une question cruciale se pose : combien de temps et d'effort faudra-t-il pour les réaliser ? C'est exactement le sujet de notre prochaine leçon, où nous aborderons les principes de l'estimation de l'effort, en explorant les différences entre l'estimation en temps (jours/hommes) et l'estimation en points de complexité, typique de Scrum.