La méthode MoSCoW est une technique de priorisation utilisée dans la gestion de projet, le développement logiciel et l’analyse métier. Elle permet de prioriser les exigences en fonction de leur importance et de leur urgence, et permet aux gestionnaires de projet d’allouer les ressources et le budget en conséquence. Dans cet article, nous explorerons la méthode MoSCoW et fournirons un exemple de son implémentation.
Qu’est-ce que la méthode MoSCoW ?
La méthode MoSCoW est une technique de priorisation qui catégorise les exigences en quatre groupes : les indispensables, les souhaitables, les souhaitables mais non essentiels et les non-essentiels. L’acronyme MoSCoW signifie :
- Indispensable :des exigences critiques qui sont essentielles au succès du projet. Ces exigences sont obligatoires et doivent être incluses dans le périmètre du projet.
- Souhaitable :des exigences importantes qui sont nécessaires au succès du projet, mais qui peuvent être reportées si nécessaire. Ces exigences sont importantes, mais pas critiques, et peuvent être reportées à une phase ultérieure du projet.
- Souhaitable mais non essentiel :des exigences souhaitables qui ne sont pas essentielles au succès du projet, mais qui peuvent améliorer sa valeur. Ces exigences sont facultatives et peuvent être incluses si le temps et le budget le permettent.
- Non essentiel :des exigences qui ne sont pas nécessaires au succès du projet et qui ne sont pas incluses dans le périmètre du projet.
La méthode MoSCoW aide les gestionnaires de projet à prioriser les exigences en fonction de leur importance et de leur urgence. Elle leur permet de se concentrer sur les exigences critiques et d’allouer les ressources et le budget en conséquence.
Exemple de la méthode MoSCoW
Examinons un exemple de projet de développement logiciel pour comprendre comment fonctionne la méthode MoSCoW.
Supposons qu’une entreprise souhaite développer une nouvelle application mobile pour ses clients. L’application doit permettre aux clients de passer des commandes, de suivre leurs commandes et de recevoir des notifications. L’entreprise souhaite également inclure certaines fonctionnalités supplémentaires pour rendre l’application plus attrayante pour les clients.
L’équipe du projet identifie les exigences suivantes :
- Indispensable : L’application doit permettre aux clients de passer des commandes, de suivre leurs commandes et de recevoir des notifications.
- Souhaitable : L’application doit inclure une fonction de recherche permettant aux clients de rechercher des produits, et une fonction de paiement permettant aux clients de régler leurs commandes par divers moyens de paiement.
- Souhaitable mais non essentiel : L’application pourrait inclure une fonction de programme de fidélité qui récompense les clients pour leurs achats, et une fonction de programme de recommandation qui incite les clients à recommander l’application à leurs amis et à leur famille.
- Non essentiel : L’application ne comportera pas de fonctionnalité d’intégration avec les réseaux sociaux qui permettrait aux clients de partager leurs achats sur les plateformes de réseaux sociaux.
En utilisant la méthode MoSCoW, l’équipe du projet a priorisé les exigences en fonction de leur importance et de leur urgence. Les exigences indispensables sont cruciales pour le succès du projet et doivent être incluses dans l’application. Les exigences souhaitables sont importantes, mais peuvent être reportées à une phase ultérieure du projet si nécessaire. Les exigences souhaitables mais non essentielles sont facultatives et peuvent être incluses si le temps et le budget le permettent. Les exigences non essentielles ne sont pas nécessaires au succès du projet et ne sont pas incluses dans le périmètre du projet.
Exemple réel – Système de gestion de la relation client (CRM)
Description du projet : Développement d’un système de gestion de la relation client (CRM)
L’objectif de ce projet agile est de développer un système CRM pour une petite entreprise spécialisée dans la fourniture de solutions sur mesure à ses clients. Le système CRM sera conçu pour simplifier le processus de vente et améliorer les interactions avec les clients, permettant à l’entreprise d’améliorer la satisfaction et la fidélité de ses clients.
Le projet suivra la méthodologie Agile, qui repose sur un développement itératif et incrémental. L’équipe Agile travaillera étroitement avec le client pour recueillir les exigences, développer des prototypes et livrer des incrémentations fonctionnelles de logiciel en itérations courtes, généralement de deux semaines.
Identifier une liste d’histoires utilisateur
Pour créer la liste des histoires utilisateur, vous pouvez considérer les différents rôles qui interagiront avec le système, tels que les représentants commerciaux, les gestionnaires et les clients, et réfléchir aux différentes tâches qu’ils devront accomplir pour atteindre leurs objectifs. Vous pouvez également considérer les différents types de données qui devront être stockés et gérés dans le système, tels que les informations clients, les données commerciales et les campagnes marketing.
Sur la base de cette analyse, vous pouvez ensuite générer une liste d’histoires utilisateur couvrant une large gamme de fonctionnalités, allant du suivi des prospects au service client, en passant par les propositions commerciales et les rapports. La liste des histoires utilisateur vise à fournir un point de départ pour l’équipe de développement afin de prioriser et planifier le développement du système CRM.
Voici une liste d’histoires utilisateur pour le projet de développement du système CRM :
- En tant que représentant commercial, je souhaite pouvoir suivre tous mes leads en un seul endroit afin de gérer facilement mon pipeline de ventes.
- En tant que responsable commercial, je souhaite pouvoir visualiser et surveiller en temps réel les progrès de mon équipe afin de leur fournir un accompagnement et un soutien lorsque nécessaire.
- En tant que représentant du service client, je souhaite pouvoir consulter toutes les interactions d’un client avec notre entreprise afin de lui offrir un support personnalisé.
- En tant que responsable marketing, je souhaite pouvoir segmenter nos clients en fonction de leurs préférences et de leur comportement afin de les cibler avec des campagnes pertinentes.
- En tant que client, je souhaite pouvoir consulter mon historique d’achats et mes informations de compte afin de gérer facilement mon relation avec l’entreprise.
- En tant que représentant du service client, je souhaite pouvoir enregistrer et suivre les réclamations et les demandes des clients afin de m’assurer qu’elles soient traitées en temps voulu.
- En tant que représentant commercial, je souhaite pouvoir générer rapidement et facilement des devis et propositions afin de conclure les affaires plus rapidement.
- En tant qu’administrateur, je souhaite pouvoir gérer les autorisations des utilisateurs et les niveaux d’accès afin de contrôler qui a accès aux informations sensibles.
- En tant que représentant commercial, je souhaite pouvoir planifier et gérer les rendez-vous avec mes clients afin de rester organisé et au fait de mon emploi du temps.
- En tant que manager, je souhaite pouvoir générer des rapports sur la performance commerciale, la satisfaction client et d’autres indicateurs afin de prendre des décisions commerciales éclairées.
Ces histoires utilisateur couvrent une gamme de fonctionnalités que le système CRM devrait offrir. L’équipe de développement peut utiliser ces histoires utilisateur pour prioriser les fonctionnalités les plus importantes pour le système, et s’assurer que le système répond aux besoins de tous les acteurs.
Sous forme de tableau, présentons un résumé clair et concis des 10 histoires utilisateur liées à une situation commerciale afin de donner un aperçu des histoires utilisateur.
| Histoire utilisateur | Rôle utilisateur | Objectif |
|---|---|---|
| 1 | Représentant commercial | Suivre tous les leads en un seul endroit pour gérer le pipeline de ventes |
| 2 | Responsable commercial | Visualiser et surveiller les progrès de l’équipe en temps réel pour un accompagnement et un soutien |
| 3 | Représentant du service client | Consulter toutes les interactions client pour un support personnalisé |
| 4 | Responsable marketing | Segmenter les clients selon leurs préférences et leur comportement pour des campagnes ciblées |
| 5 | Client | Consulter l’historique d’achats et les informations de compte pour une gestion facile |
| 6 | Représentant du service client | Enregistrer et suivre les réclamations et les demandes des clients afin de les résoudre en temps voulu |
| 7 | Représentant des ventes | Générer rapidement et facilement des devis et des propositions pour conclure les affaires plus rapidement |
| 8 | Administrateur | Gérer les autorisations d’utilisateur et les niveaux d’accès aux informations sensibles |
| 9 | Représentant des ventes | Planifier et gérer les rendez-vous avec les clients pour rester organisé |
| 10 | Gestionnaire | Générer des rapports sur la performance des ventes, la satisfaction des clients et d’autres indicateurs pour prendre des décisions commerciales éclairées |
Le tableau fournit des informations sur le rôle de l’utilisateur, l’objectif spécifique qu’il souhaite atteindre, et le numéro de l’histoire utilisateur pour référencer facilement chaque histoire. En organisant les histoires utilisateurs dans un tableau, il devient plus facile de comprendre et de prioriser les fonctionnalités qui doivent être développées pour répondre aux besoins des parties prenantes impliquées dans le projet. Ce tableau peut servir de référence pour l’équipe de développement afin de concevoir et d’implémenter des fonctionnalités alignées sur les besoins des utilisateurs finaux et des parties prenantes.
Prioriser les histoires utilisateurs
Il est important de prioriser les histoires utilisateurs en fonction de leur valeur commerciale et de leur impact sur les objectifs du projet. Cela garantit que les efforts de développement sont concentrés sur les fonctionnalités les plus importantes et les plus valorisantes, et que le projet peut être livré dans les délais et dans le budget prévu.
La priorisation peut être effectuée à l’aide de diverses techniques, telles que la méthode MoSCoW, qui classe les histoires utilisateurs en « indispensables », « souhaitables », « pouvant être ajoutés » et « ne seront pas ajoutés ». Les histoires utilisateurs classées comme « indispensables » sont les plus critiques et doivent être développées en premier, tandis que les « souhaitables » et les « pouvant être ajoutés » peuvent être développées ultérieurement lors de itérations ou de versions ultérieures.
Voici un tableau des 10 histoires utilisateurs mentionnées précédemment, avec les informations pertinentes et la priorisation basée sur la méthode MoSCoW :
Il est important de prioriser les histoires utilisateurs en fonction de leur valeur commerciale et de leur impact sur les objectifs du projet. Cela garantit que les efforts de développement sont concentrés sur les fonctionnalités les plus importantes et les plus valorisantes, et que le projet peut être livré dans les délais et dans le budget prévu.
La priorisation peut être effectuée à l’aide de diverses techniques, telles que la méthode MoSCoW, qui classe les histoires utilisateurs en « indispensables », « souhaitables », « pouvant être ajoutés » et « ne seront pas ajoutés ». Les histoires utilisateurs classées comme « indispensables » sont les plus critiques et doivent être développées en premier, tandis que les « souhaitables » et les « pouvant être ajoutés » peuvent être développées ultérieurement lors de itérations ou de versions ultérieures.
Voici un tableau des 10 histoires utilisateurs mentionnées précédemment, avec les informations pertinentes et la priorisation basée sur la méthode MoSCoW :
| Histoire utilisateur | Description | Priorité |
|---|---|---|
| 1 | En tant que représentant des ventes, je souhaite pouvoir suivre tous mes prospects en un seul endroit afin de gérer facilement mon pipeline de ventes. | Indispensable |
| 2 | En tant que responsable des ventes, je souhaite pouvoir visualiser et surveiller en temps réel l’évolution de mon équipe afin de pouvoir apporter un accompagnement et un soutien lorsque nécessaire. | À avoir obligatoirement |
| 3 | En tant que représentant du service client, je souhaite pouvoir visualiser toutes les interactions d’un client avec notre entreprise afin de pouvoir lui offrir un support personnalisé. | À avoir obligatoirement |
| 4 | En tant que responsable marketing, je souhaite pouvoir segmenter nos clients en fonction de leurs préférences et de leur comportement afin de les cibler avec des campagnes pertinentes. | À avoir si possible |
| 5 | En tant que client, je souhaite pouvoir consulter mon historique d’achats et mes informations de compte afin de gérer facilement mon relation avec l’entreprise. | À avoir si possible |
| 6 | En tant que représentant du service client, je souhaite pouvoir enregistrer et suivre les réclamations et les demandes des clients afin de m’assurer qu’elles soient traitées en temps voulu. | À avoir si possible |
| 7 | En tant que représentant des ventes, je souhaite pouvoir générer rapidement et facilement des devis et propositions afin de conclure les affaires plus rapidement. | À avoir si possible |
| 8 | En tant qu’administrateur, je souhaite pouvoir gérer les autorisations des utilisateurs et les niveaux d’accès afin de contrôler qui a accès aux informations sensibles. | À avoir si possible |
| 9 | En tant que représentant des ventes, je souhaite pouvoir planifier et gérer les rendez-vous avec mes clients afin de rester organisé et au fait de mon emploi du temps. | À avoir si possible |
| 10 | En tant que gestionnaire, je souhaite pouvoir générer des rapports sur la performance des ventes, la satisfaction client et d’autres indicateurs afin de prendre des décisions commerciales éclairées. | Ne sera pas fait |
Dans ce tableau, les histoires utilisateur sont listées par ordre de priorité, les fonctionnalités « à avoir obligatoirement » étant listées en premier, suivies des « à avoir si possible » et des « à avoir si possible ». La fonctionnalité « ne sera pas faite » n’est pas prévue pour être mise en œuvre dans ce projet, mais pourrait être envisagée pour un développement futur.
En priorisant les histoires utilisateur, l’équipe de développement peut s’assurer que les fonctionnalités les plus critiques sont développées en premier, apportant de la valeur aux parties prenantes et permettant au projet de répondre à ses objectifs dans les contraintes de temps et de budget.
Exemple : Un plan de développement Scrum pour le CRM
Voici un aperçu de haut niveau d’un plan de développement Scrum pour lancer le projet agile. Toutefois, les détails spécifiques du plan dépendront des exigences du projet, de la structure de l’équipe et d’autres facteurs. Voici un exemple de plan de développement Scrum :
- Définir le backlog produit :La première étape consiste à définir le backlog produit, qui est une liste priorisée de toutes les fonctionnalités, fonctionnalités et exigences qui doivent être mises en œuvre dans le projet. Ce backlog sera maintenu tout au long du projet et sera continuellement affiné et mis à jour en fonction des besoins changeants des parties prenantes.
- Mener la planification du sprint :Une fois que le backlog produit a été défini, l’équipe tiendra une réunion de planification du sprint pour sélectionner un ensemble d’histoires d’utilisateurs issues du backlog à développer pendant le prochain sprint. L’équipe estimerá l’effort requis pour chaque histoire d’utilisateur, et sélectionnera les histoires d’utilisateurs pouvant être terminées dans le cadre du délai du sprint.
- Tenir les réunions quotidiennes de scrum: Dès le début du sprint, l’équipe tiendra des réunions quotidiennes de scrum pour examiner les progrès, identifier les obstacles ou les défis, et ajuster le plan si nécessaire. Les réunions quotidiennes de scrum doivent être courtes et ciblées, chaque membre de l’équipe fournissant une mise à jour sur ses progrès.
- Développer l’incrément produit :Pendant le sprint, l’équipe travaillera sur le développement des histoires d’utilisateurs sélectionnées, en se concentrant sur la livraison d’un incrément produit fonctionnel à la fin du sprint. L’équipe collaborera étroitement, les développeurs, les testeurs et les autres membres de l’équipe travaillant ensemble pour livrer l’incrément produit.
- Tenir la revue de sprint :À la fin du sprint, l’équipe tiendra une réunion de revue de sprint pour démontrer l’incrément produit aux parties prenantes, recueillir des retours et examiner les progrès réalisés pendant le sprint.
- Tenir la rétrospective de sprint :Après la revue de sprint, l’équipe tiendra une réunion de rétrospective de sprint pour examiner le processus du sprint, identifier les domaines d’amélioration et planifier le prochain sprint.
- Répéter le processus :L’équipe répétera ce processus pour chaque sprint suivant, en continuant à affiner et à mettre à jour le backlog produit, tout en se concentrant sur la livraison d’un incrément produit fonctionnel à la fin de chaque sprint.
Ce plan de développement Scrum fournit un cadre pour gérer le projet agile, avec des réunions et des revues régulières afin de s’assurer que le projet est sur la bonne voie et qu’il apporte de la valeur aux parties prenantes.
Conclusion
L’article aborde la méthode MoSCoW, qui est une technique de priorisation utilisée dans la gestion de projet agile pour prioriser les exigences du projet. La méthode MoSCoW divise les exigences en quatre catégories : obligatoires, souhaitables, possibles et non réalisables. L’article fournit un exemple concret d’un projet agile et explique comment identifier les histoires d’utilisateurs pour le projet. Les histoires d’utilisateurs sont ensuite priorisées à l’aide de la méthode MoSCoW, les exigences obligatoires étant prioritaires.
L’article présente également un plan de développement Scrum, qui comprend la définition du backlog produit, la planification du sprint, les réunions quotidiennes de scrum, le développement de l’incrément produit, la revue de sprint, la rétrospective de sprint et la répétition du processus. Le plan de développement Scrum fournit un cadre pour gérer le projet agile, en veillant à ce que le projet soit sur la bonne voie et qu’il apporte de la valeur aux parties prenantes.