« Buy a Feature (technique externe et quantitative) » : différence entre les versions

De Wiki Agile
Aucun résumé des modifications
Aucun résumé des modifications
 
(7 versions intermédiaires par le même utilisateur non affichées)
Ligne 1 : Ligne 1 :
[[Category: Portail Product Owner]]
[[Category: Portail Product Owner]]
[[Category: Portail Planification]]
[[Category: Portail Planification]]
[[Category: Daniel Zacarias]]
[[Category: Innovation Games]]
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 />
Ligne 17 : Ligne 19 :
# Le budget de chaque joueur doit être compris entre un tiers et la moitié du coût total de toutes les fonctionnalités ;
# Le budget de chaque joueur doit être compris entre un tiers et la moitié du coût total de toutes les fonctionnalités ;
# Il est possible de jouer à ce jeu de deux manières :
# Il est possible de jouer à ce jeu de deux manières :
*# '''Individuellement''' - Les joueurs doivent utiliser leur budget pour acheter les fonctionnalités les plus importantes pour eux.
#* '''Individuellement''' - Les joueurs doivent utiliser leur budget pour acheter les fonctionnalités les plus importantes pour eux.
*# '''Collaborative''' - Utiliser une échelle de prix qui rend certaines fonctionnalités trop coûteuses pour les acheteurs individuels. Cela déclenche la collaboration et la négociation entre les joueurs pour acheter des fonctionnalités qui apportent de la valeur pour plusieurs joueurs.
#* '''Collaborative''' - Utiliser une échelle de prix qui rend certaines fonctionnalités trop coûteuses pour les acheteurs individuels. Cela déclenche la collaboration et la négociation entre les joueurs pour acheter des fonctionnalités qui apportent de la valeur pour plusieurs joueurs.
# Lorsque les joueurs achètent des fonctionnalités, collectez l'argent et demandez-leur d'expliquer pourquoi ils les achètent.
# Lorsque les joueurs achètent des fonctionnalités, collectez l'argent et demandez-leur d'expliquer pourquoi ils les achètent.
# Le jeu se termine lorsqu'il n'y a plus d'argent ou lorsque les joueurs ont acheté toutes les fonctionnalités qui les intéressent (expliquez-leur à l'avance que c'est normal s'il ne reste plus d'argent.)
# Le jeu se termine lorsqu'il n'y a plus d'argent ou lorsque les joueurs ont acheté toutes les fonctionnalités qui les intéressent (expliquez-leur à l'avance que c'est normal s'il ne reste plus d'argent.)
<br/>
<br/>
Cela fournira un ensemble précieux d'informations sur les fonctionnalités les plus importantes pour les clients, car nous pouvons analyser les fonctionnalités les plus achetées, les raisons de leur achat et les offres collaboratives effectuées sur des produits coûteux.<br/>
<br/>
Pour obtenir plus de données, plusieurs instances du jeu peuvent être jouées (en groupes de 8 personnes maximum). En outre, pour les ensembles volumineux de fonctionnalités, vous pouvez [http://www.slideshare.net/innovgames/why-buy-a-feature-is-great-at-prioritizing-features configurer un championnat] où les fonctionnalités les plus populaires passent par plusieurs phases de jeux.<br/>
<br/>
Il vaut mieux jouer à ''Buy a Feature'' en face à face compte tenu de son caractère collaboratif, mais il existe des [http://www.innovationgames.com/buy-a-feature/ solutions en ligne] si vous en avez besoin.<br/>
<br/>
Consultez [http://www.uxforthemasses.com/buy-the-feature/ cet article] pour une explication plus détaillée du jeu et des modèles pour les cartes de fonctionnalités et les billets pour jouer.<br/>
<br/>
'''Note pour les chefs de projet'''<br/>
<br/>
Cette méthode est également très utile pour les projets internes ou de consultation qui ne sont pas exposés au marché, en impliquant les parties prenantes comme acheteurs dans le jeu. C'est un excellent moyen pour construire une stratégie pour le projet, un consensus sur ce qui est le plus important et pour faire comprendre aux parties prenantes que les fonctionnalités ont des coûts de développement différents[5].
== Références ==
[5] Cela semble trivial, mais cette réalité est difficile à accepter pour certains non-techniciens.