Méthode MoSCoW

La méthode MoSCoW est une technique visant à prioriser des besoins ou des exigences en matière d'assistance à maîtrise d'ouvrage et de développement logiciel. L'objectif est que le maître d'œuvre et le maître d'ouvrage s'accordent sur l'importance des tâches à réaliser par rapport aux délais prévus.

Les lettres majuscules de l'acronyme MoSCoW signifient (en anglais):

• M - MUST have this, c'est-à-dire 'DOIT être fait' (Vital).
• S - SHOULD have this if at all possible, c'est-à-dire 'DEVRAIT être fait dans la mesure du possible' (Essentiel).
• C - COULD have this if it does not affect anything else, 'POURRAIT être fait dans la mesure où cela n'a pas d'impact sur les autres tâches' (Confort).
• W - WON'T have this time but WOULD like in the future, 'NE SERA PAS fait cette fois mais sera fait plus tard' (Luxe, c'est votre zone d'optimisation budgétaire).

Les o dans MoSCoW sont ajoutés uniquement pour rendre l'acronyme prononçable et sont, dans la majorité des cas, écrites en minuscule pour indiquer qu'elles ne correspondent pas à des mots. Toutefois, l'écriture MOSCOW, avec les o en majuscule, est tolérée.

Toutes les exigences sont importantes, mais il faut leur affecter des priorités afin de garantir les meilleurs intérêts pour le maître d'ouvrage. Les développeurs concentrent leurs travaux sur les tâches M, puis sur les tâches S et C. Cependant, si les délais ne peuvent être respectés, les exigences S et C seront les premières à être annulées.

L'avantage de la méthode MoSCoW réside dans la signification de l'acronyme, qui est plus compréhensible que d'autres techniques de priorisation comme élevé/moyen/faible.

Soit un logiciel imaginaire de "Gestion de tâches" comprenant les fonctionnalités suivantes :

1. Les utilisateurs peuvent se connecter au logiciel.
2. Les utilisateurs doivent pouvoir demander un nouveau mot de passe par email s'ils l'ont oublié.
3. Les utilisateurs peuvent créer des tâches.
4. Un utilisateur peut envoyer un email au logiciel et cet email sera attaché à la bonne tâche.
5. Lorsqu'un utilisateur clique sur un n° de téléphone enregistré dans le logiciel, le numéro est automatiquement composé.

Un atelier entre le le maître d'œuvre et le maître d'ouvrage permettra d'obtenir une compréhension commune et partagée des priorités.

Par exemple :

1. Must : il est obligatoire de s'authentifier compte tenu de la politique sécurité du client
2. Should : il est fortement souhaitable de pouvoir être capable de se reconnecter à l'application, mais cela ne fait pas pour autant partie du chemin critique des fonctionnalités de l'application.
3. Must : c'est la raison d'être d'un logiciel de "Gestion de tâches" !
4. Could : fonctionnalité intéressante mais qui reste du domaine du confort... on peut travailler sans.
5. Won't : excellente idée mais qui pourrait être traitée dans une version ultérieure de l'application.

Tout est affaire de point de vue, mais on a essayé ici de se limiter à 50% de Must afin de pouvoir jouer avec les autres niveau de priorisation ; sinon le risque est que tout devienne Must, autrement dit que tout soit prioritaire.

• Portail de l’informatique