Méthode MoSCoW
La méthode MoSCoW est une technique visant à établir les priorités 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 parfois utilisé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 C seront les premières à être annulées, suivies par les exigences S.
L'avantage de la méthode MoSCoW réside dans la signification de l'acronyme, qui est plus compréhensible que d'autres techniques d'établissement de priorités comme élevé, moyen et faible.
Historique
Cette méthode de définition de priorités a été inventée par Dai Clegg[1] vers 1994 et largement utilisée pour la première fois dans le cadre de la démarche de projet agile dynamic systems development method (DSDM)[2].
La méthode MoSCoW est souvent utilisée en blocs de temps, où une échéance est fixée pour se concentrer sur les exigences les plus importantes. Elle est donc souvent utilisée avec les approches de développement logiciel tels que Scrum, rapid application development (RAD) et DSDM.
Exemple
Soit un logiciel imaginaire de gestion de tâches comprenant les fonctionnalités suivantes :
- Les utilisateurs peuvent se connecter au logiciel.
- Les utilisateurs doivent pouvoir demander un nouveau mot de passe par email s'ils l'ont oublié.
- Les utilisateurs peuvent créer des tâches.
- Un utilisateur peut envoyer un email au logiciel et cet email sera attaché à la bonne tâche.
- 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 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 :
- Must : il est obligatoire de s'authentifier compte tenu de la politique sécurité du client
- Should : il est fortement souhaitable de pouvoir se reconnecter à l'application, mais cela ne fait pas pour autant partie du chemin critique des fonctionnalités de l'application.
- Must : c'est la raison d'être d'un "logiciel de gestion de tâches" !
- Could : fonctionnalité intéressante mais qui reste du domaine du confort, on peut travailler sans.
- 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 niveaux de définition de priorité; sinon le risque est que tout devienne must, autrement dit que tout soit prioritaire.
Références
- (en) Dai Clegg et Barker, Richard, Case Method Fast-Track : A RAD Approach, Addison-Wesley, , 207 p. (ISBN 978-0-201-62432-8)
- (en) Kurt Bittner et Spence, Ian, Use Case Modeling, Addison-Wesley Professional, , 347 p. (ISBN 978-0-201-70913-1, lire en ligne)