« 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 |
||
| (3 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 28 : | Ligne 30 : | ||
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/> | 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/> | <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. | 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. | |||
