« MoSCoW (technique externe et qualitative) » : différence entre les versions
De Wiki Agile
Aucun résumé des modifications |
Aucun résumé des modifications |
||
| Ligne 16 : | Ligne 16 : | ||
Le terme est un acronyme, chaque lettre représentant l'une des catégories de priorisation possibles (avec des ''O'' ajoutés pour le rendre mémorable). Les exigences sont donc classées comme suit :<br/> | Le terme est un acronyme, chaque lettre représentant l'une des catégories de priorisation possibles (avec des ''O'' ajoutés pour le rendre mémorable). Les exigences sont donc classées comme suit :<br/> | ||
* '''Must''' have (NdT : Vital) - ces exigences sont critiques et doivent être incluses dans le produit. Même si une seul manque, la version est considérée comme un échec. Ces exigences peuvent être dégradées si les parties prenantes sont d'accord. | * '''Must''' have (NdT : Vital) - ces exigences sont critiques et doivent être incluses dans le produit. Même si une seul manque, la version est considérée comme un échec. Ces exigences peuvent être dégradées si les parties prenantes sont d'accord. | ||
* '''Should''' have (NdT : Essentiel) - ces exigences sont importantes mais pas cruciales pour la version. Elles sont le premier niveau de "Nice to have", et partagent généralement l'importance des exigences ''MUST'', sans être aussi sensibles aux échéances. | * '''Should''' have (NdT : Essentiel) - ces exigences sont importantes mais pas cruciales pour la version. Elles sont le premier niveau de "Nice to have" (NdT : souhaitable), et partagent généralement l'importance des exigences ''MUST'', sans être aussi sensibles aux échéances. | ||
* '''Could''' have (NdT : Confort) - ces exigences sont souhaitables mais pas nécessaires pour la version. Elles apportent généralement des améliorations peu coûteuses au produit. En raison de leur faible importance, elles constituent le deuxième niveau de caractéristiques "Nice to have". | * '''Could''' have (NdT : Confort) - ces exigences sont souhaitables mais pas nécessaires pour la version. Elles apportent généralement des améliorations peu coûteuses au produit. En raison de leur faible importance, elles constituent le deuxième niveau de caractéristiques "Nice to have" (NdT : souhaitable). | ||
* '''Won't''' have (NdT : Luxe) - celles-ci sont considérées comme les moins critiques voire même non alignées avec la stratégie du produit. Elles doivent être définitivement abandonnées ou reconsidérées pour les versions futures. | * '''Won't''' have (NdT : Luxe) - celles-ci sont considérées comme les moins critiques voire même non alignées avec la stratégie du produit. Elles doivent être définitivement abandonnées ou reconsidérées pour les versions futures. | ||
<br/> | <br/> | ||
Cette méthode offre une solution de priorisation simple et rapide. Le problème vient de son manque de classement dans les catégories. Par exemple, comment pouvons-nous savoir quelles exigences ''SHOULD'' ou ''COULD'' sont plus importantes que les autres ? En raison de cette limitation, la méthode MoSCoW est probablement mieux adaptée aux projets internes plutôt qu'aux produits avec de nombreux clients. Parler à une poignée de parties prenantes des subtilités de la priorisation sera toujours plus facile que contacter à une plus grande échelle les clients finaux. | Cette méthode offre une solution de priorisation simple et rapide. Le problème vient de son manque de classement dans les catégories. Par exemple, comment pouvons-nous savoir quelles exigences ''SHOULD'' ou ''COULD'' sont plus importantes que les autres ? En raison de cette limitation, la méthode MoSCoW est probablement mieux adaptée aux projets internes plutôt qu'aux produits avec de nombreux clients. Parler à une poignée de parties prenantes des subtilités de la priorisation sera toujours plus facile que contacter à une plus grande échelle les clients finaux. | ||
