Voir la source de La valeur métier la plus grande d'abord

[[Category: Portail Product Owner]]
[[Category: Joe Bergin]]
<div id="content_view" class="wiki" style="display: block"> Auteur : Joe Bergin<br />  Source : [https://sites.google.com/a/scrumplop.org/published-patterns/value-stream-pattern-language/product-backlog/high-value-first High Value First] (Published Patterns)<br />
----
Traducteur : Fabrice Aimetti<br />  Date : 14/08/2011<br />
----
Traduction :<br /> <br /> <span class="hps">Vous êtes un client sur un projet agile et vous êtes impliqué dans le jeu du '''Planning Game'''</span>. <span class="hps">Vous essayez de décider quelles stories seront planifiées dans les prochaines itérations ou sprints.Vous travaillez avec un seul client</span>, de sorte que <span class="hps">la valeur relative de chaque livrable est claire.</span><br /> <br /> <span class="hps">Les stories ont différentes valeurs métiers</span>. Elles<span class="hps"> ont des coûts de développement différents.</span><br /> <br /> 

* <span class="hps">Dans une approche de développement descendante </span><span class="hps atn">(</span>structurée, cascade), il est fréquent que les <span class="hps">développeurs ne disposent pas de la valeur métier des fonctionnalités exigées</span>. <span class="hps">Ils peuvent </span><span class="hps atn">dépenser beaucoup d'</span>efforts <span class="hps">(en temps et en argent</span>) sur des fonctionnalités <span class="hps">de faible valeur. Ceci doit être évité</span>.
* <span class="hps">Du point de vue du client</span>, certaines fonctionnalités sont <span class="hps">essentielles et d'autres sont du luxe</span>. <span class="hps">Quatre-vingts pour cent de la valeur métier est obtenu à partir de 20</span>% des fonctionnalités.
* <span class="hps">Le client doit être en mesure d'attribuer une valeur à chaque story qu'il écrit</span>.<span class="hps"> Les développeurs attribueront alors un</span><span class="hps atn"> coût (</span>estimation) à cette story. <span class="hps">Cela peut être difficile</span>.
* <span class="hps">La valeur changera au fur et à mesure que les conditions et stratégies du métier changeront</span>.<br /> <br /> 
<span class="hps">'''Par conséquent''', ''construisez les stories les plus importantes, de plus grande valeur d'abord''</span>. <span class="hps">Lorsque la courbe de la valeur et la courbe du coût se croisent</span>,<span class="hps"> arrêtez le projet</span>. <span class="hps">Et notez qu'aucun dispositif n'a été mis en place pour encourager le traitement des fonctions à faible valeur puisque que vous appliquez toujours la pratique DTSTTCPW</span><sup class="reference">[1]</sup> .<span class="hps"> À tout moment</span>, planifiez <span class="hps">les stories restantes de plus haute valeur dans les prochaines itérations disponibles. Si le coût d'une story est supérieur à sa valeur, vous pouvez souvent découper la story pour obtenir sa partie essentielle et sa partie non essentielle</span>. <span class="hps">Une fois que ces parties sont ré-estimées, vous êtes en meilleure position pour continuer.</span><br /> <br /> [[Image:HighValueFirst.jpg|HighValueFirst.jpg]]<br /> <br /> 

* <span class="hps">Cela suppose</span> bien sûr <span class="hps">que votre estimation de la valeur est mesurable et précise. C'est souvent difficile à réaliser. Des itérations courtes vous forcent à penser en termes de fonctionnalités de petite granularité</span>. <span class="hps">Cela rend l'estimation plus facile, mais le découpage plus difficile</span>. <span class="hps">Si quelque chose d'important est beaucoup trop complexe pour être réalisé dans une itération, elle doit être divisée</span>. <span class="hps">Lorsque c'est fondamentalement impossible, XP ne sera pas la méthode idéale</span>.
* <span class="hps">Cela suppose également que la valeur est plus élevée que le coût associé à l'estimation fournie par les développeurs.</span>
* <span class="hps">Il y a un coût supplémentaire ici</span>, <span class="hps">puisque les développeurs ne voient pas toutes les stories au début</span>, ils <span class="hps">ne peuvent pas anticiper certaines optimisations qui auraient pu baisser le coût global.</span>
* <span class="hps">Mais ces optimisations gaspilleront de l'argent si ces exigences changent dans le temps et qu'elles deviennent obsolètes</span>.<span class="hps"> Les développeurs XP n'anticipent pas les besoins futurs</span>.
* <span class="hps">Ce qui complique tout c'est que la première livraison doit sortir une version du produit qui parcourt les fonctionnalités de '''de bout en bout'''. Certaines fonctionnalités seront omises et d'autres seront sous leur forme la plus élémentaire possible<sup class="reference">[2]</sup> .</span>
<br /> <span class="hps"> Généralement, la valeur des stories va ensuite diminuer. Le coût augmentera généralement</span>, puisqu'<span class="hps">il devient plus difficile d'intégrer de nouvelles stories au fur et à mesure</span>.<span class="hps"> Le '''refactoring''' essaye de conserver cette augmentation de la courbe des coûts aussi plate que possible en gardant une conception cohérente même si de nouvelles choses sont ajoutées. À un certain point</span>, cependant,<span class="hps"> les stories restantes ne vaudront probablement pas la peine d'être construites. Notez que c'est l'un des principaux moyens pour les processus agiles d'économiser de l'argent sur les développements prévus </span>: <span class="hps">les exigences de faible valeur seront simplement abandonnées. Cela vous permettra également de livrer un produit plus tôt.</span><br /> <br /> <span class="hps">Dans des situations extrêmement volatiles, le croisement des courbes ne se produira peut-être pas. Vous pourriez uniquement prendre connaissance d'une exigence de grande valeur tard dans le processus de sorte que la courbe de valeur prendra un virage serré vers le haut. Mais cette capacité à rapidement re-cibler le projet vers un objectif différent apporte de la valeur d'une manière différente</span> : <span class="hps">vous obtenez un produit plus adapté.</span><br /> <br /> <span class="hps">Après avoir appliqué le pattern [[La%20valeur%20m%C3%A9tier%20la%20plus%20grande%20d%27abord|LA VALEUR MÉTIER LA PLUS GRANDE D'ABORD]], vous pouvez alors continuer avec les patterns [[Le%20changement%20est%20gratuit |LE CHANGEMENT EST GRATUIT]] et [[De%20l%27argent%20pour%20rien|DE L'ARGENT POUR RIEN]]. Comme autre alternative</span>,<span class="hps"> jetez un coup d’œil au pattern [/ROI ROI], qui sacrifie l'optimisation du ROI à court terme de chacun des éléments au profit d'un bien meilleur ROI sur le long-terme.</span><br /> <br />  L'article original est sur [http://csis.pace.edu/%7Ebergin/patterns/xpPatternsEuroV7.html http://csis.pace.edu/~bergin/patterns/xpPatternsEuroV7.html]
# Do The Simplest Thing That Could Possibly Work = Faites la chose la plus simple qui puisse fonctionner
# skeleton
</div>