« Première chose à faire, prioriser les exigences » : différence entre les versions

[[Category: Portail Product Owner]]

[[Category: Karl E. Wiegers]]

----

----

''Traduction :''<br /> <br /> <span style="display: block; text-align: justify">Les clients ne sont jamais heureux de découvrir qu'ils ne pourront pas obtenir toutes les fonctionnalités qu'ils désiraient dans la version 1.0 d'un nouveau produit logiciel (en tout cas, pas s'ils veulent que les fonctionnalités soient opérationnelles). Cependant, si l'équipe de développement ne peut pas livrer toutes les fonctionnalités d'ici la date de livraison initialement planifiée, les parties prenantes du projet doivent se mettre d'accord sur un sous-ensemble à implémenter en premier. Tout projet avec des ressources limitées doit établir les priorités relatives des fonctionnalités, cas d'utilisation, exigences nécessaires. La priorisation aide le chef de projet à résoudre les conflits, planifier des livraisons intermédiaires et négocier les compromis nécessaires.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">'''Pourquoi prioriser les exigences ?'''</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Une caractéristique d'exigences excellentes est qu'elles sont explicitement priorisées. Lorsque les attentes des clients sont grandes, que les délais sont courts et que les ressources sont limitées, vous voulez vous assurer que le produit contient les fonctionnalités les plus importantes. Établir l'importance relative de chacune des fonctionnalités vous permet d'ordonner la fabrication pour fournir la plus grande valeur du produit au moindre coût. Les clients et les développeurs doivent collaborer sur la priorisation des exigences. Les développeurs ne savent pas toujours quelles exigences sont les plus importantes pour les clients, et les clients ne peuvent pas juger du coût et de la difficulté technique associés à une exigence donnée.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Un chef de projet doit contrebalancer le périmètre du projet avec les contraintes de délai, de budget, de ressources pour les équipes et d'objectifs de qualité. Une stratégie possible est de laisser tomber ou de reporter les exigences de faible priorité à une version ultérieure lorsque vous acceptez de nouvelles exigences de plus haute priorité ou d'autres changements dans le projet. Si les clients n'arrivent pas à distinguer leurs exigences par ordre d'importance et d'urgence, le chef de projet doit alors trouver les compromis nécessaires. Puisque les clients ne seront peut-être pas d'accord avec les décisions prises par le chef de projet, ils devront indiquer quelles exigences sont critiques et celles qui peuvent attendre. Établissez les priorités très tôt dans le projet, lorsque vous avez le plus d'alternatives à disposition pour atteindre avec succès le résultat du projet.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">C'est assez difficile d'obtenir de la part d'un client qu'il se décide à dire quelles exigences sont plus importantes que d'autres ; obtenir l'accord de plusieurs clients avec des attentes diverses est encore plus difficile. Les gens ont généralement des intérêts qui leur tiennent à coeur et ils ne sont pas toujours disposés à faire des compromis pour le bénéfice de quelqu'un d'autre. Pourtant, décider des priorités est une des responsabilités des clients dans la relation de partenariat client / développeur.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Au début, les clients priorisent les exigences en tenant uniquement compte de la valeur que chacune d'entre elles leur apportent. Une fois qu'un développeur met en avant le coût, le risque technique ou tout autre compromis lié à une exigence donnée, les clients peuvent éventuellement se dire que l'exigence n'est finalement pas aussi importante qu'ils le pensaient initialement. Les développeurs peuvent aussi déterminer que certaines exigences de faible priorité devraient être implémentées plus tôt en raison de leur impact sur l'architecture du produit. Lorsque vous définissez les priorités, vous devez comparer le bénéfice métier que chaque exigence apporte, par rapport à son coût et toutes les implications que celle-ci peut avoir sur l'évolution future de l'architecture socle du produit.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">'''Le jeu difficile des priorités'''</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Le réflexe qu'ont les clients lorsqu'on leur demande de prioriser : "J'ai besoin de toutes ces fonctionnalités, faites que ça passe". Ça n'aide pas beaucoup. Cela peut être difficile de persuader les clients de définir des priorités s'ils savent que vous n'allez jamais implémenter les exigences de priorité faible. Une fois, un développeur m'a dit que les priorités n'étaient pas nécessaires, parce que si nous écrivons quelque chose dans le document de spécifications fonctionnelles, c'est que nous avons bien l'intention de le fabriquer. Cependant, on n'aborde pas le problème qui consiste à savoir ''quand'' vous allez implémenter chaque fonctionnalité. Les développeurs ne souhaitent peut-être pas s'embêter avec les priorités, parce que cela rentre en conflit avec leur attitude habituelle "on peut tout faire" qu'ils adoptent face à leurs clients et leurs managers.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">La réalité c'est que certaines fonctionnalités sont plus importantes que d'autres. Cela devient évident lors de la trop classique "étape rapide de réduction du périmètre" en fin de projet, lorsque les fonctionnalités de faible priorités sont sacrifiées pour assurer la livraison du produit à la bonne date. Définir des priorités tôt dans le projet vous aide à négocier ces compromis tout au long, plutôt qu'en toute urgence à la fin. Disposer d'une fonctionnalité déjà à moitié développée lorsque vous venez de déterminer que sa priorité est faible, c'est du gaspillage et de la frustration.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Si on les laisse faire, les clients diront que 85% des exigences sont de priorité haute, 10% de priorité moyenne et 5% de priorité faible. Ça n'aide pas beaucoup le chef de projet. Steve McConnell avait identifié une phase de nettoyage-élimination de ces exigences qui ne sont pas nécessaires et de simplification de celles qui sont inutilement compliquées, qui est devenue une bonne pratique du développement rapide d'applications (voir ''Rapid Development'', Microsoft Press, 1996).</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Sur un projet que je connais bien, le management, qui pilotait l'équipe, s'est impatienté lorsqu'un analyste a insisté sur la priorisation des exigences. Les managers ont souligné qu'ils pouvaient souvent se passer d'une fonctionnalité donnée, mais qu'il fallait du coup peut-être renforcer une autre fonctionnalité pour compenser celles qui avaient été négligées. Leur raisonnement était basé sur le fait que si l'on reportait trop d'exigences, le système obtenu ne générerait pas le chiffre d'affaires promis dans le business plan. Lorsque vous évaluez les priorités, jetez un coup d'oeil aux connexions et interdépendances entre les différentes exigences et leur alignement avec les besoins du métier.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">'''Échelles''' '''de priorisation'''</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Généralement, la priorisation consiste à regrouper les exigences en trois catégories. Le tableau 1 montre les trois niveaux associés à deux échelles de priorisation habituelles. Toutes les échelles de ce type sont subjectives et imprécises, si bien que les personnes impliquées doivent se mettre d'accord sur la signification de chaque niveau de l'échelle avant de l'utiliser. La priorité est un attribut-clé de chaque exigence, elle devrait être présente dans tout document de spécifications fonctionnelles ou base d'exigences. Établissez une règle de rédactions du document de spécifications fonctionnelles de telle façon que le lecteur sache si la priorité assignée à une exigence de plus haut niveau, est automatiquement héritée par ses exigences filles ou dérivées, ou alors si chaque exigence se voit individuellement attribuée sa propre priorité.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Une autre problématique concerne la granularité à laquelle vous prioriser les exigences. Même un projet de taille moyenne peut avoir des centaines ou des milliers d'exigences fonctionnelles détaillées, trop pour les analyser et les classer de façon cohérente. Vous devez choisir un niveau d'abstraction approprié pour la priorisation. Cela peut être au niveau du cas d'utilisation, de l'exigence fonctionnelle détaillée, ce qui paraît logique dans votre situation.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">'''''Tableau 1 : deux échelles de priorisation des exigences'''''</span><br />