La valeur métier la plus grande d'abord

Auteur : Joe Bergin
Source : High Value First (Published Patterns)

---

Traducteur : Fabrice Aimetti
Date : 14/08/2011

---

Traduction :

Vous êtes un client sur ​​un projet agile et vous êtes impliqué dans le jeu du Planning Game. Vous essayez de décider quelles stories seront planifiées dans les prochaines itérations ou sprints.Vous travaillez avec un seul client, de sorte que la valeur relative de chaque livrable est claire.

Les stories ont différentes valeurs métiers. Elles ont des coûts de développement différents.

• Dans une approche de développement descendante (structurée, cascade), il est fréquent que les développeurs ne disposent pas de la valeur métier des fonctionnalités exigées. Ils peuvent dépenser beaucoup d'efforts (en temps et en argent) sur des fonctionnalités de faible valeur. Ceci doit être évité.
• Du point de vue du client, certaines fonctionnalités sont essentielles et d'autres sont du luxe. Quatre-vingts pour cent de la valeur métier est obtenu à partir de 20% des fonctionnalités.
• Le client doit être en mesure d'attribuer une valeur à chaque story qu'il écrit. Les développeurs attribueront alors un coût (estimation) à cette story. Cela peut être difficile.
• La valeur changera au fur et à mesure que les conditions et stratégies du métier changeront.
  
  

Par conséquent, construisez les stories les plus importantes, de plus grande valeur d'abord. Lorsque la courbe de la valeur et la courbe du coût se croisent, arrêtez le projet. 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 . À tout moment, planifiez 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. Une fois que ces parties sont ré-estimées, vous êtes en meilleure position pour continuer.

• Cela suppose bien sûr 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é. Cela rend l'estimation plus facile, mais le découpage plus difficile. Si quelque chose d'important est beaucoup trop complexe pour être réalisé dans une itération, elle doit être divisée. Lorsque c'est fondamentalement impossible, XP ne sera pas la méthode idéale.
• Cela suppose également que la valeur est plus élevée que le coût associé à l'estimation fournie par les développeurs.
• Il y a un coût supplémentaire ici, puisque les développeurs ne voient pas toutes les stories au début, ils ne peuvent pas anticiper certaines optimisations qui auraient pu baisser le coût global.
• Mais ces optimisations gaspilleront de l'argent si ces exigences changent dans le temps et qu'elles deviennent obsolètes. Les développeurs XP n'anticipent pas les besoins futurs.
• 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 .

Généralement, la valeur des stories va ensuite diminuer. Le coût augmentera généralement, puisqu'il devient plus difficile d'intégrer de nouvelles stories au fur et à mesure. 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, cependant, 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 : les exigences de faible valeur seront simplement abandonnées. Cela vous permettra également de livrer un produit plus tôt.

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 : vous obtenez un produit plus adapté.

Après avoir appliqué le pattern LA VALEUR MÉTIER LA PLUS GRANDE D'ABORD, vous pouvez alors continuer avec les patterns LE CHANGEMENT EST GRATUIT et DE L'ARGENT POUR RIEN. Comme autre alternative, 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.

L'article original est sur http://csis.pace.edu/~bergin/patterns/xpPatternsEuroV7.html

1. Do The Simplest Thing That Could Possibly Work = Faites la chose la plus simple qui puisse fonctionner
2. skeleton