« MoSCoW (technique externe et qualitative) » : différence entre les versions
De Wiki Agile
Aucun résumé des modifications |
Aucun résumé des modifications |
||
| Ligne 18 : | Ligne 18 : | ||
* '''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", 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". | ||
* '''Won't''' have (NdT : Luxe) - celles-ci sont considérées comme les moins critiques | * '''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. | ||
