 **MoSCoW** est une technique permettant de prioriser les besoins ou les exigences d'un projet. Cette technique est utilisĂ©e dans l'analyse business et le dĂ©veloppement de logiciels afin de parvenir Ă une comprĂ©hension commune sur l'importance qu'ils accordent Ă la livraison de chaque exigence. Ceci ce fait avec toutes les parties prenantes du projet. Les lettres majuscules de l'acronyme **MoSCoW** signifient : **M**ust, **S**hould, **C**ould, **W**on't. Les _**o**_ ont Ă©tĂ© ajoutĂ©s afin que ce soit prononçable. Pour certains, la classification avec des numĂ©ros semble plus logique, plus naturel. Cependant, une fois le dĂ©veloppement commencĂ©, toutes les fonctionnalitĂ©s prennent souvent pour prioritĂ© '1' ce qui crĂ©Ă© de fortes confusions et ne permet donc pas de livrer le projet dans de bonnes conditions. ## M comme Must **MUST**, ce qui **DOIT** ĂȘtre fait. Cela dĂ©crit une exigence qui doit ĂȘtre satisfaite dans la solution finale afin que le produit soit un succĂšs. Ces exigences sont non-nĂ©gociables, sans elles, le projet est un Ă©chec. Elles doivent ĂȘtre finalisĂ©es en tenant compte de : - l'accord de tous les intervenants, - l'examination de la portĂ© du projet ainsi que son but, - la correspondance entre l'objectif du projet et les exigences listĂ©es. ##S comme Should **SHOULD**, ce qui **DEVRAIT** ĂȘtre fait dans la mesure du possible. Cela dĂ©crit une exigence qui doit ĂȘtre incluse dans la solution finale si tout se passe bien. Ces exigences sont importantes mais moins critiques pour le succĂšs du projet. En effet, ces exigences sont tout aussi importantes que les _**MUST**_ mais peuvent ĂȘtre faites plus tard dans le cycle de dĂ©veloppement du projet. Lors des prochaines itĂ©rations par exemple. ##C comme Could **COULD**, ce qui **POURRAIT** ĂȘtre fait dans la mesure oĂč cela n'a pas d'impact sur les autres tĂąches. Ce sont des exigences non-critiques. Elles sont souvent dĂ©crites comme des fonctionnalitĂ©s qui seraient bien d'avoir : "Ca serait top d'avoir ça !". Ce n'est donc pas indispensable pour le succĂšs du projet. Cependant elles ne sont pas Ă oublier, inclure ces exigences peut permettre d'augmenter le confort ainsi que la satisfaction du client pour un coup de dĂ©veloppement souvent faible. ##W comme Won't **WON'T**, ce qui **NE SERA PAS** fait mais prĂ©vu pour plus tard. Ce sont des exigences qui n'affectent pas le succĂšs du projet. Elles ne sont gĂ©nĂ©ralement pas prĂ©vues dans le planning mais peuvent ĂȘtre traitĂ©es dans une version ultĂ©rieure du projet. Certains, utilise le **W** pour "_Would like_", ce qui permet d'ĂȘtre moin dĂ©finitif et laisse donc la possibilitĂ© d'ajouter ces exigences si le scope, le budget ou les dĂ©lais changent.
Afin de fournir un projet réussi, il est essentiel que l'ensemble des exigences soient clairement priorisées avec le client. Ceci n'est bien sûr qu'un élément pour la réussite, il ne faut pas oublier de bien définir l'objectif globale, la qualité, les délais ainsi que le budget. - Avez-vous déjà utilisé cette méthode ? - Vous utilisez une autre méthode de prioritisation ? Quels sont ses avantages ?
