Qu’est-ce que la technique MoSCoW ?
La méthode MoSCoW est une technique de hiérarchisation utilisée en gestion, en analyse d’entreprise, en gestion de projet et en développement de logiciels pour parvenir à une compréhension commune avec les parties prenantes sur l’importance qu’elles accordent à la livraison de chaque exigence ; elle est également connue sous le nom de hiérarchisation MoSCoW ou d’analyse MoSCoW. La technique de priorisation MoSCoW joue un rôle clé dans la gestion de projet Agile. Dans un projet Agile, il est vital de comprendre l’importance des différentes choses. En effet, le temps étant une ressource fixe, la hiérarchisation est appliquée aux exigences, aux tâches, aux produits, aux cas d’utilisateurs, etc. Attention, il ne s’agit pas d’une technique Agile (Scrum, Kanban, XP, etc.), mais d’une technique largement utilisée en Agile. Il y a quelques questions dans presque toutes les certifications concernant la technique MoSCoW.
Le terme MoSCoW lui-même est un acronyme dérivé de la première lettre de chacune des quatre catégories de priorisation (Must have, Should have, Could have, et Won’t have), avec les Os interstitiels ajoutés pour rendre le mot prononçable. Bien que les Os soient généralement en minuscules pour indiquer qu’ils ne représentent rien, le MOSCOW tout en majuscules est également utilisé.
Priorisation des exigences MoSCoW
Toutes les exigences sont importantes, mais elles sont classées par ordre de priorité afin de fournir rapidement les avantages commerciaux les plus importants et les plus immédiats. Les développeurs essaieront initialement de livrer toutes les exigences Must have, Should have et Could have, mais les exigences Should et Could seront les premières à être supprimées si le délai de livraison semble menacé.
Must Have
Ces exigences fournissent le sous-ensemble minimal utilisable (MUS) des exigences que le projet garantit de livrer. Cela peut être défini en utilisant certains des éléments suivants :
Pas de livraison à la date cible sans cette exigence
Aucun intérêt à livrer à la date cible sans cette exigence ; si elle n’était pas livrée, il n’y aurait aucun intérêt à déployer la solution à la date prévue
Pas légal sans cette exigence
Insécuritaire sans cette exigence
Pas de livraison de l’analyse de rentabilité sans cette exigence
Positionner la question suivante : » Que se passe-t-il si cette exigence n’est pas satisfaite ? » Si la réponse est » annuler le projet – il n’y a aucun intérêt à mettre en œuvre une solution qui ne répond pas à cette exigence « , alors il s’agit d’une exigence incontournable. S’il existe un moyen de contourner l’exigence, même s’il s’agit d’une solution de contournement manuelle, il s’agit alors d’une exigence « Should Have » ou « Could Have ». Le déclassement d’une exigence en Should Have ou Could Have ne signifie pas qu’elle ne sera pas livrée, simplement que la livraison n’est pas garantie.
Should Have
Important mais pas vital
Peut être douloureux à laisser de côté, mais la solution reste viable
Peut nécessiter une sorte de contournement, par exemple la gestion des attentes, une certaine inefficacité, une solution existante, la paperasserie, etc.
Un Should Have peut être différencié d’un Could Have en examinant le degré de douleur causé par sa non-réalisation, en termes de valeur commerciale ou de nombre de personnes affectées.
Could Have
Wanted ou souhaitable mais moins important
Moins d’impact si on le laisse de côté (par rapport à un Should Have)
Won’t Have this time
Un avantage de la méthode MoSCoW est qu’elle place plusieurs initiatives dans la catégorie » won’t-not-have « . Cela aide à gérer les attentes sur ce qui ne sera pas inclus dans une version spécifique (ou un autre délai pour lequel vous établissez des priorités).
Placer des initiatives dans la catégorie « ne sera pas nécessaire » est une façon d’aider à prévenir le scope creep. Si les initiatives sont dans cette catégorie, l’équipe sait qu’elles ne doivent pas être une priorité pour ce délai spécifique. Certaines initiatives de la catégorie « ne pas avoir » deviendront prioritaires à l’avenir, tandis que d’autres n’auront probablement pas lieu du tout. Certaines équipes décident de les différencier en créant une sous-catégorie au sein de ce groupe.
Résumé
MoSCoW (Must Have, Should Have, Could Have, Won’t Have this time) est principalement utilisé pour hiérarchiser les exigences, bien que la technique soit également utile dans de nombreux autres domaines. Atern recommande de ne pas consacrer plus de 60% de l’effort aux Must Haves d’un projet, avec 40% de Shoulds et Coulds. Tout ce qui est supérieur à 60 % pose un risque pour la réussite et la prévisibilité du projet, à moins que l’environnement soit bien compris, que l’équipe soit établie et que les risques externes soient minimes.