MoSCoW (technique externe et qualitative) - Historique des versions

Fabrice Aimetti le 13 août 2018 à 07:41

2018-08-13T07:41:58Z

← Version précédente		Version du 13 août 2018 à 07:41
Ligne 2 :		Ligne 2 :
	[[Category: Portail Planification]]		[[Category: Portail Planification]]
	[[Category: Daniel Zacarias]]		[[Category: Daniel Zacarias]]
			[[Category: MoSCoW]]
	Auteur : Daniel Zacarias<br />		Auteur : Daniel Zacarias<br />
	Source : [https://foldingburritos.com/product-prioritization-techniques/ 20 Product Priorization Techniques: A Map and Guided Tour]<br />		Source : [https://foldingburritos.com/product-prioritization-techniques/ 20 Product Priorization Techniques: A Map and Guided Tour]<br />

Fabrice Aimetti le 12 août 2018 à 18:39

2018-08-12T18:39:29Z

← Version précédente		Version du 12 août 2018 à 18:39
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.

Fabrice Aimetti le 12 août 2018 à 18:38

2018-08-12T18:38:01Z

← Version précédente		Version du 12 août 2018 à 18:38
Ligne 15 :		Ligne 15 :
	<br />		<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/>		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", 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".

Fabrice Aimetti le 12 août 2018 à 14:03

2018-08-12T14:03:19Z

← Version précédente		Version du 12 août 2018 à 14:03
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 ou 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.

Fabrice Aimetti le 12 août 2018 à 14:03

2018-08-12T14:03:06Z

← Version précédente		Version du 12 août 2018 à 14:03
Ligne 17 :		Ligne 17 :
	* '''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", 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 ~~des~~ 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 ou 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 ou 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.

Fabrice Aimetti le 12 août 2018 à 14:02

2018-08-12T14:02:30Z

← Version précédente		Version du 12 août 2018 à 14:02
Ligne 15 :		Ligne 15 :
	<br />		<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/>		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 ~~essentielles~~ 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", 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 des 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 des caractéristiques "Nice to have".

Fabrice Aimetti le 12 août 2018 à 14:01

2018-08-12T14:01:59Z

← Version précédente		Version du 12 août 2018 à 14:01
Ligne 15 :		Ligne 15 :
	<br />		<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/>		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 - ces exigences sont essentielles 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 essentielles 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 - 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 - 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 des 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 des caractéristiques "Nice to have".
	* '''Won't''' have - celles-ci sont considérées comme les moins critiques ou 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 ou 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.

Fabrice Aimetti : Page créée avec « Category: Portail Product Owner Category: Portail Planification Category: Daniel Zacarias Auteur : Daniel Zacarias
Source : [https://foldingburritos.com/... »

2018-08-12T14:00:35Z

Page créée avec « Category: Portail Product Owner Category: Portail Planification Category: Daniel Zacarias Auteur : Daniel Zacarias Source : [https://foldingburritos.com/... »

Nouvelle page

[[Category: Portail Product Owner]]
[[Category: Portail Planification]]
[[Category: Daniel Zacarias]]
Auteur : Daniel Zacarias 
Source : [https://foldingburritos.com/product-prioritization-techniques/ 20 Product Priorization Techniques: A Map and Guided Tour] 
----
Traducteur : Fabrice Aimetti 
Date : 12/08/2018 
----
Traduction : 
 
'''Article de référence :''' [[Tableau_périodique_des_techniques_de_priorisation_produit|Tableau périodique des techniques de priorisation produit]] 
 
La [https://en.wikipedia.org/wiki/MoSCoW_method méthode MoSCoW] est une technique de priorisation utilisée dans de multiples domaines de management pour parvenir à un consensus sur les éléments les plus importants pour les parties prenantes et les clients. 
 
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 : 
* '''Must''' have - ces exigences sont essentielles 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 - 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 - 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 des caractéristiques "Nice to have".
* '''Won't''' have - celles-ci sont considérées comme les moins critiques ou 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.
 
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.

MoSCoW (technique externe et qualitative) - Historique des versions

Fabrice Aimetti le 13 août 2018 à 07:41

Fabrice Aimetti le 12 août 2018 à 18:39

Fabrice Aimetti le 12 août 2018 à 18:38

Fabrice Aimetti le 12 août 2018 à 14:03

Fabrice Aimetti le 12 août 2018 à 14:03

Fabrice Aimetti le 12 août 2018 à 14:02

Fabrice Aimetti le 12 août 2018 à 14:01

Fabrice Aimetti : Page créée avec « Category: Portail Product Owner Category: Portail Planification Category: Daniel Zacarias Auteur : Daniel Zacarias Source : [https://foldingburritos.com/... »

Fabrice Aimetti : Page créée avec « Category: Portail Product Owner Category: Portail Planification Category: Daniel Zacarias Auteur : Daniel Zacarias
Source : [https://foldingburritos.com/... »